AI Gateway features

PII masking

AI Gateway can redact personal data from your requests before they reach the upstream provider, then restore the original values in the response it returns to you. It is enabled per API key by an administrator in the dashboard — there is nothing to set in the request body, and your code keeps calling the standard OpenAI-compatible endpoints.

What happens when it is enabled

For non-streaming /v1/chat/completions and /v1/responses.

AI Gateway detects entities — emails, phone numbers, IBANs, credit cards, names, plus any custom org-specific patterns — and replaces them with stable placeholders such as <PERSON_1> or <EMAIL_1>.
The masked request is what the provider actually sees — raw PII never leaves the gateway.
The provider response is rehydrated: placeholders are swapped back to the original values before you receive it.

The redaction is transparent — request and response look normal to your code. No request parameter turns it on; an administrator attaches a masking config to the API key under /pii-masking.

Streaming is not supported (fail-closed)

Masking cannot be applied to a streamed response.

On a key with masking enabled, a stream: true request is rejected with 400 instead of being forwarded unmasked. The request never reaches a provider and nothing is logged.

json

{
  "error": {
    "message": "PII masking is enabled for this API key but is not supported on streaming requests. Send a non-streaming request, or disable PII masking for this key.",
    "type": "client_error",
    "code": "pii_masking_streaming_unsupported"
  }
}

warning · Streaming on a masked key

To stream, either drop stream: true or ask an administrator to disable masking on the key.

Stable placeholders across turns

Keep multi-turn context coherent for the model.

Pass the same metadata.trace_id on every call of a conversation and the same original value always maps to the same placeholder (<PERSON_1> stays <PERSON_1>), so the redacted ↔ original bindings are reused across turns. See Monitoring & traces for how trace_id groups generations.

Coverage

Which endpoints the masking pipeline applies to.

Endpoint	PII masking	Notes
/v1/chat/completions, /v1/responses — non-streaming	Masked	Masked before the provider, rehydrated in the response.
/v1/chat/completions, /v1/responses — streaming	400 rejected	Rejected with 400 on a key that has masking enabled.
/v1/embeddings	Not masked	Not masked — pre-embedding masking would distort the vector.
/v1/images/*, audio, files	Not masked	Not covered by the masking pipeline.
/mcp/<slug> — tools/call	Masked	Same key config as the LLM endpoints: arguments masked before the upstream MCP server, values restored in the result.

Without an active config on the key, every surface behaves normally — masking is opt-in per key.

What you see in monitoring

Auditing what the provider actually received.

When masking ran, the trace drill-down shows the masking duration, the active-entity snapshot, and a clear/masked payload toggle so operators can audit exactly what the provider saw. The same pairing is kept for failed generations that were masked before the failure — the failed trace stores both the clear and masked request, not the clear one alone.