> ## 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 Data Leakage Prevention Across Boundaries

> Understand Anthale data leakage prevention, what counts as sensitive data, and where to enforce it across model, tool, and output boundaries.

Data leakage prevention is about keeping sensitive information from crossing a boundary it should not cross. That boundary might be a third-party model, a connector, an external domain, another user, or a downstream system.

Anthale treats this as policy-driven runtime behavior. When your policy enables this guardrail, you configure it to detect, redact, or block when it finds sensitive content. The returned enforcement action can still be `allow`, `detect`, `redact`, or `block`, depending on what Anthale finds for that request.

## What counts as leakage

Leakage is not limited to classic PII. It also includes secrets, internal instructions, confidential business information, and organization-specific identifiers that should stay inside a trusted boundary.

## Common sensitive entity families

| Entity family                            | Typical examples                                                                             | Why it matters                                                                            |
| ---------------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Personal identifiers                     | Names, email addresses, phone numbers, physical addresses, and government-issued identifiers | These are the most common classes of customer and employee data                           |
| Financial and network identifiers        | Credit card numbers, IBAN values, IP addresses, and account numbers                          | Exposure can create payment risk, fraud risk, or infrastructure discovery                 |
| Credentials and secrets                  | API keys, access tokens, passwords, session identifiers, and private keys                    | A single leak can become a direct system compromise                                       |
| Internal instructions and system context | System prompts, hidden instructions, internal URLs, and configuration values                 | These leaks reveal how the application works and how to target it                         |
| Confidential business data               | Contracts, pricing models, customer lists, internal metrics, and unreleased plans            | These leaks create commercial and operational damage even when no classic PII is involved |
| Custom identifiers                       | Employee IDs, project codes, proprietary entity names, and internal taxonomy labels          | In many deployments, these are the most important things to protect                       |

Treat exact format validation, model behavior, and detector coverage as platform behavior rather than as a documentation promise. Use policy tests and real enforcement responses as the source of truth for production tuning.

## Where it matters

This guardrail matters before a model call, before retrieved or tool-generated context is appended on the `input` path, and before model output is shown to a user or passed into another system. If retrieved context is untrusted, check it on the `input` path before prompt assembly.

## When to enforce it first

Start with the boundaries where sensitive content is most likely to escape the trusted path: before third-party model calls, before external tools receive content, and before generated output is returned to users or downstream systems.

## What it does not replace

Data leakage prevention does not replace access control, business authorization, or [Prompt Injection Protection](/docs/learn/guardrails/prompt-injection). It answers whether sensitive data is being exposed, not whether a user was entitled to ask for it or whether an attacker is trying to seize control of the model.

## Related pages

Read [Exfiltration Patterns](/docs/learn/guardrails/data-leakage/exfiltration-patterns) when repeated leak attempts change their wording but follow the same underlying pattern.

## Next steps

Next, read [Exfiltration Patterns](/docs/learn/guardrails/data-leakage/exfiltration-patterns) or go to [Link Control](/docs/learn/guardrails/link-control).