input or output path. Anthale also applies built-in malicious-domain coverage and a built-in well-known good-domains set where that option is available in policy configuration.
This page explains how Anthale applies those built-in sets. It does not document the current contents of the malicious-domain or well-known good-domains sets as separate public reference pages.
What makes it different
This guardrail follows your allowed list, your blocked list, and the platform’s malicious-domain coverage. There is no sensitivity tuning.Where it matters
Link control matters anywhere links can enter or leave the runtime path: user input, retrieved pages, tool results, file parsing, and model output. It is one of the clearest controls for stopping link-based data exfiltration and reducing indirect prompt-injection exposure.How to design domain rules
Start with the domains your product actually needs. If a domain is not necessary for your prompts, retrieved context, tool results, or model responses, do not allow it because it feels familiar or widely used. If your product benefits from common documentation or infrastructure domains, the well-known-domain option can reduce maintenance. If the workflow is tighter, keep the rule set narrower and more explicit. Use the blocked list for domains that should never appear, including subdomains inside an otherwise allowed parent. This is where internal-only destinations, unsafe destinations, or competitor references often belong. Keep malicious-domain blocking on unless you have a strong reason not to. The built-in malicious-domain set exists to catch domains you would not think to enumerate one by one. Check both theinput and output paths. A domain can arrive from user text, retrieved pages, or tool output, and it can leave through model output.