anoman
Guardrails

PII protection

Detect personal data in your prompts and choose how to handle it — mask it, swap it for reversible tokens, or block the request entirely.

What it detects

PII detection tuned for Southeast Asia

Anoman runs Microsoft Presidio over your prompts to detect personal data before it reaches the provider. Beyond the usual global entities, the detectors are tuned for SEA national identifiers — Indonesian NIK, Singapore NRIC, Malaysian MyKad, and Thai national ID — the identifiers that matter for UU PDP and PDPA compliance.

SEA identifiers
  • 🇮🇩ID_NIK
  • 🇸🇬SG_NRIC
  • 🇲🇾MY_MYKAD
  • 🇹🇭TH_NATIONAL_ID
Global entities
  • EMAIL_ADDRESS
  • PHONE_NUMBER
  • CREDIT_CARD
  • IP_ADDRESS
  • URL
  • PERSON

Modes

How to handle detected PII

Set pii_mode per policy group to one of six modes. The default is redact. tokenize and synthetic are the modes that keep raw PII away from the provider while still giving you a correct answer.

ModeBehavior
redactDefaultMask detected entities with a placeholder (e.g. [REDACTED]) before sending to the provider. Irreversible. This is the default.
tokenizeReplace each entity with a reversible token, send the tokenized prompt to the provider, then de-anonymize the model's response back to the real values before returning it to you.
syntheticSwap each entity for a realistic fake value (a plausible name, email, or ID) so the model reasons over coherent data, then de-anonymize on the response.
blockReturn HTTP 403 if any PII is present in the prompt. Nothing is sent to the provider.
maskLegacy alias for redact (full `<ENTITY_TYPE>` placeholder).
detectLegacy alias for block — returns 403 when PII is found.
// Policy group config (PATCH /anoman/v1/policy-groups/{id})
{
  "pii_mode": "tokenize"   // redact | tokenize | synthetic | block | mask | detect
}

De-anonymization

You get the real answer back

The key idea behind tokenize and synthetic: the PROVIDER never sees raw PII, but YOU still get a correct, real answer. The gateway maps entities to tokens (or fakes) on the way in, and reverses the mapping on the way out — a dedicated de-anonymization step runs on the model's response before it's returned to you.

Why de-anonymize on the response? Masking a user's own PII back at them would be terrible UX — if a user asks about their own record, they should see their own data. tokenize/synthetic protect the third-party provider, not the caller, so the response is restored to the real values.

Use redact or block when you never want the real data to leave your own boundary; use tokenize or synthetic when you need a correct answer AND provider-side privacy.

Per-key override

Skip PII for one key

PII is one of only two guardrails you can override per API key. An API key's guardrail_overrides JSONB can set piiEnabled: false to skip PII scanning for that key alone, independent of its policy group. (Injection detection is mandatory and can never be disabled per key — see policy groups for the full priority order.)

// Per-key override (guardrail_overrides JSONB on the API key)
// Skips PII scanning for THIS key only. Injection stays mandatory.
{
  "piiEnabled": false
}

Whatever mode is active, the completion reports the outcome in the X-Anoman-Guardrail-Pii response header, including the masked entity count.

Configure

Where to set the mode

Set the PII mode per policy group in the dashboard PII menu at /dashboard/guardrails. Per-key overrides live on the API key toggles at /dashboard/keys.

Related: output DLP scans the response side, and the guardrails overview shows where PII sits in the full pipeline.

Protect personal data

Pick a PII mode per policy group and keep raw data away from providers.

Open guardrailsGuardrails overview