> ## Documentation Index
> Fetch the complete documentation index at: https://anthale.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Anthale Link Control for Allowed and Blocked Domains

> Understand Anthale link control, how allowlists and blocklists work, and where domain enforcement belongs across input, retrieval, tool, and output flows.

Link control answers a narrow question: may this link or domain appear at this boundary. It governs inbound and outbound links based on the policy you configure.

Anthale applies link control from the policy you configure. Your allowed list and blocked list define the explicit domain rules for the `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 the `input` and `output` paths. A domain can arrive from user text, retrieved pages, or tool output, and it can leave through model output.

## Common link-abuse patterns

| Pattern                        | What it looks like                                                                          | Why it matters                                                    |
| ------------------------------ | ------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| Direct external link insertion | The prompt asks the model to include a specific external URL                                | This is the simplest path for exfiltration or unsafe referrals    |
| Shortlink masking              | A shortened or branded link hides the true destination                                      | The displayed domain no longer tells you enough                   |
| Redirect chains                | A trusted-looking URL sends the user through one or more intermediate hops                  | The first URL is not the real destination                         |
| Query-string exfiltration      | Sensitive content is placed into URL parameters                                             | The data leak happens inside the link itself                      |
| Lookalike domains              | Homoglyphs or very similar domains imitate trusted destinations                             | Human review can miss them, especially in chat output             |
| Retrieved-page pivots          | The model is pointed toward a page that contains hidden instructions or unsafe destinations | This turns link control into an indirect prompt-injection defense |

## What it does not replace

Link control does not replace [Prompt Injection Protection](/docs/learn/guardrails/prompt-injection) or [Data Leakage Prevention](/docs/learn/guardrails/data-leakage). It tells you whether a domain should appear. It does not explain whether the surrounding prompt is trying to seize control or whether the content being moved is sensitive.

## Next steps

Next, read [Data Leakage Prevention](/docs/learn/guardrails/data-leakage) or return to [Guardrails Overview](/docs/learn/guardrails).