Deny Email PII
This policy stops a request if it contains an email address. If there's no email address, the request goes through as normal.
This policy stops a request if it contains an email address. If there's no email address, the request goes through as normal.
This policy automatically masks email addresses in what a tool sends back, replacing each one with [REDACTED] before your agent ever sees it.
Generic, app-agnostic starter policies surfaced in the DTwo Hub "Define a security policy for your agents" onboarding step. They are designed to deliver immediate, observable policy activity without requiring you to author any Rego first — pick one, attach it, and watch the gateway exercise a real policy on your traffic.
Unlike the app-specific policies elsewhere in this catalog, these are not scoped to a single MCP server. Each one scans the whole request or response body for PII (email addresses, in this starter set) regardless of which tools you have connected, so they work the moment you connect anything.
| Policy | Direction | Purpose |
|---|---|---|
| detect-email-allow | ingress | Passive/observability starter: scan the whole request body for email addresses and allow with an Email Detected reason. Never blocks. |
| deny-email | ingress | Scan the whole request body for email addresses and deny the call when one is found; all other calls pass through. |
| redact-email | egress | Scan the whole response body and redact any email address to [REDACTED] (transform-only); never blocks. |
The three cover the same detection (email addresses, scanned across the whole body) with the three enforcement stances — allow-with-reason, deny, and redact — so you can start passive and graduate to enforcement when you're ready.
These policies are deliberately app-agnostic and match on content, not tool name, so they do not depend on how any MCP server is named on your gateway. If you later want to scope one to a specific server, gate the relevant rule with startswith(lower(input.resource.name), "<server>-") and confirm the exact tool name your gateway sends using the dump-input debug technique.
These policies do not require any specific IdP claims. If you want to add identity-based exemptions (e.g., an InfoSec break-glass user who may pass or read raw PII), gate the relevant allow rule with object.get(input.subject.claims, "<claim>", "<default>").
To add an onboarding starter policy:
apps/onboarding/<policy-slug>/ with policy.md and a tests.yaml test file.apps: ["onboarding"] and include onboarding in tags so Hub surfaces it in the onboarding step.pnpm manifest from the repo root.See CONTRIBUTING.md for the full process.