A policy is the set of rules the Gateway applies to every request in a project: which data types to look for, what to do with each, and which content to refuse outright. They are the configurable half of the AI privacy and policy enforcement layer — the Gateway brings the detectors, you decide what happens when one fires. Policies are versioned, so you can change them safely and see exactly which version handled any past request.
Entity types
The Gateway ships with tuned detectors for the sensitive data that matters most.
| Category | Examples | Default action |
|---|---|---|
| PII | Names, addresses, SSN / TIN, DOB | Redact |
| Contact | Email, phone | Mask |
| Cardholder data (PCI) | Card numbers (PAN), CVV | Mask / block |
| Health (PHI) | Diagnoses, MRNs, clinical notes | Redact |
| Secrets | Passwords, tokens, API keys, private keys | Block |
| Custom | Your own patterns (account IDs, case numbers) | Configurable |
Detection combines deterministic patterns (for well-structured data like card numbers) with ML classifiers (for free-text names, addresses, and health details), so it catches entities that a regular expression alone would miss.
Actions: redact, mask, block
For every entity type you choose one of three actions:
- Redact — remove the value entirely, replaced with a typed reversible token.
- Mask — reveal only part of it (for example, the last four digits of a card).
- Block — refuse the whole request; it is never sent to a model.
You can set different actions per type and per project — mask phone numbers in a support assistant, but block them in a marketing tool, for instance.
Content rules
Beyond entities, policies can block whole classes of content that should never reach a model, regardless of the PII in them:
- Password-reset and MFA-code emails — the Gateway won't read or forward them.
- Credentials and secrets in any field.
- Documents above a sensitivity label (see Microsoft Purview integration).
- No training — a standing rule that customer data is never used to train a third-party model.
Block rules always win
If a request matches a block rule, it is stopped before the model call — even if other parts of the request would have been fine to send. Block is a hard stop, not a redaction.
Framework mappings
Policies map to the controls auditors ask about, so "are you compliant" has a concrete answer.
| Framework | What the policy enforces |
|---|---|
| HIPAA | Redact PHI on non-clinical prompts; audit every access. |
| PCI DSS | Mask or block PAN before any model call. |
| GDPR | Minimize and redact personal data; honor data-residency settings. |
| SOC 2 | Full audit trail, access control, and no-training guarantee. |
Managing policies
- Per project — each project has one active policy; reuse a shared policy across projects or fork one.
- Versioned — every change creates a new version; logs record which version ran.
- Testable — run a policy against sample prompts in Policy → Test before you publish it.
- Human-in-the-loop — optionally route borderline requests to a reviewer instead of auto-blocking.
To have the Gateway propose and maintain these rules for you, see Automatic policy setting.