How the PII firewall works

The PII firewall replaces personal data with tokens before any external call, and restores it in the response. The external model sees tokens, never the person. Here is what happens between the request you send and the answer you get back.

The path a request takes

Every firewalled request runs through four steps:

1. Detect. The request is scanned for personal data: names, emails, phone numbers, national IDs, account numbers, and the entity types your policy adds.
2. Pseudonymize. Each detected value is replaced with a stable token. "Contact Maria Jansen at [email protected]" becomes "Contact [PERSON_1] at [EMAIL_1]".
3. Route and infer. The pseudonymized prompt goes to the chosen model through the router and the egress guard. The model reasons over tokens and returns tokens.
4. Restore. On the way back, the tokens are swapped for the original values, so your application receives a normal, readable answer.

The model does its job. The person stays out of the transfer.

A worked example

Say a support assistant receives this prompt:

Draft a reply to Maria Jansen ([email protected]) about invoice 4471.

What reaches an external model is:

Draft a reply to [PERSON_1] ([EMAIL_1]) about invoice [NUMBER_1].

The completion comes back addressed to [PERSON_1], and the firewall restores "Maria Jansen" before your application ever sees it. The assistant is just as useful. The provider never received a name or an email.

Why pseudonymize instead of strip

The blunt approach is to delete personal data before sending. It is also the wrong one. Strip "Maria Jansen" out entirely and the model loses the thread: it cannot address the reply, cannot keep two people apart, cannot reason about the relationships in the text. Pseudonymize-and-restore keeps the structure the model needs while keeping the identity out of the request. A token is a placeholder the model can carry through its answer, not a hole in the sentence.

What never leaves

The mapping from token back to value, the token map, lives only in the request context inside the EU. It is never sent to a provider and never serialized into a log or a queue payload. If the audit trail records that a request was firewalled, that is the behavior it records: which entity types were pseudonymized, not what they were.

Metered, audited, and off the hot path

The firewall is a module you enable per tenant or per request. When it runs, it is metered on its own line, so you can see exactly what governance costs. When a request is not firewalled, reaching an external model requires a recorded acknowledgment from an authorized admin, because the egress guard fails closed. The firewall is what makes external routing safe. It is not an afterthought bolted onto the response.