Skip to main content
Caronte
Docs

Admin guide · Platform

PII masking

Redact sensitive data in requests before they leave the gateway, then rehydrate it in the response — configured per target under PII Masking.

Configurations

One config per target, listing which entities it masks. Toggle a config active/inactive from the list; the Custom entities tab holds organization-specific patterns.

The PII Masking page: counters for configs, active configs, API keys covered and custom entities, over a table showing what each config applies to and its built-in entities.
PII Masking — one row per config, with what it applies to.

Applies to names the target and says which kind it is: an API key, whose LLM requests are masked, or an MCP server, whose tool arguments are. The counters above — and API keys covered in particular — are the quick answer to how much of the organization is actually masked: traffic through a key with no config is not.

Entities

Editing a config shows the full catalog, in two families.

  • Structured — matched with regular expressions: EMAIL, PHONE, IBAN, BIC_SWIFT, CREDIT_CARD, IP_ADDRESS, URL.
  • Contextual — resolved by a NER model from surrounding context: PERSON, ORG, ….
The PII masking config editor listing structured and contextual entities, with the injected-prompt preview.
A config — structured and contextual (NER) entities, plus the injected-prompt preview.

note · The model sees placeholders

When masking is active, a system prompt is injected so the model treats <PII type="…" id="N"/> placeholders as opaque. The editor previews the exact text injected. Changes publish to running proxies immediately.

How it behaves at request time

Masking, rehydration over multi-turn conversations, and the streaming limitations are documented for developers on the PII masking developer page.

tip

Reusing the same trace_id across turns keeps the redacted ↔ original bindings stable, so the model can refer back to earlier masked values consistently.