PII Redaction for AI Agents: Mask Personal Data Before the Model Sees It

PII redaction is the removal or replacement of personally identifiable information, such as email addresses, phone numbers, and card numbers, before the text reaches a system or person that should not see the original values. For an AI agent, that system is the model: anything a tool returns lands in the context window and is sent to the LLM provider.

SealGate masks PII at the gateway, on tool results. Detected values are swapped for opaque tokens before the result reaches the agent, and the real value is put back only when the agent passes the token to a tool. The model does its work on tokens and never reads the raw data.

PII redaction vs PII masking vs tokenization

The three terms are often used interchangeably. They differ in what replaces the value and whether you can get it back:

SealGate uses tokenization. Its dashboard calls the feature "PII obfuscation", and "PII masking" is the common search term for the same idea. From the model's side the result is the same as redaction: the value is not in its context. From the tools' side nothing is lost, because the gateway can restore it.

Under GDPR, pseudonymized data is still personal data, because it can be linked back to a person. Tokenization limits who can see the value but leaves the data in scope.

Common types of PII

• Direct identifiers: name, email address, phone number, postal address, date of birth.
• Government and account numbers: Social Security or national insurance numbers, passport numbers, bank account numbers.
• Payment data: card numbers and expiry dates.
• Sensitive categories: health, biometric, and similar data that GDPR treats as special category data and HIPAA treats as protected health information.
• Credentials: API keys, access tokens, and private keys. Not PII in the legal sense, but they leak through the same channels and belong in the same filter.

Some of these have a fixed shape. An email address, a card number with a valid checksum, or an AKIA… AWS key can be matched by a pattern with few false positives. Names and street addresses have no fixed shape, so detecting them takes a language model or named-entity recognizer, which trades missed values against false alarms.

Why AI agents make PII exposure worse

A chatbot sees what a user types. An agent with tools sees whatever those tools return, and tools return more than the task needs:

• Whole records come back. A CRM lookup to find a deal owner returns the contact's email, phone, and notes. An inbox search returns full threads, signatures included.
• Context leaves your network. Everything in the context window is sent to the model provider on every turn, and often to tracing and observability tools as well.
• Context can be redirected. A prompt injection hidden in a ticket or web page can tell the agent to send what it just read to an attacker. That is the Lethal Trifecta: private data, untrusted content, and a way to send data out, all in one session.
• It repeats. The same agent runs for many users and many sessions, so one tool that over-shares exposes records again and again.

Where to redact: prompt, model, or gateway

There are three places to put a PII control in an agent system:

1. In the prompt. A system instruction such as "never repeat personal data" is advisory. The model can ignore it or be talked out of it, and the data has already been sent to the provider by the time the instruction applies.
2. At the model provider. Output filters and zero-retention agreements govern what the provider stores or returns. The raw values still leave your network and enter the context window.
3. At the tool layer, through a gateway. Tool results pass through one choke point before they reach the agent. The check is deterministic code, and it applies the same way to every agent and client connected through it.

Only the third runs before the data enters the context window. An MCP gateway already sits on that path, since every tool call goes through it, so it can apply redaction without changes to the agent.

How SealGate handles PII

SealGate has two PII controls: masking on tool results, and a policy function that blocks calls containing PII.

Masking tool results

With PII obfuscation turned on, SealGate scans the text of each tool result and replaces every match with a token such as |<PRIVATE_DATA_9f3a…>|, built from 32 random bytes. The mapping from token to value is stored on the gateway, scoped to the user and the session. When the agent later passes a token back as a tool argument, SealGate swaps the original value in before the call reaches the tool. An agent can be asked to "email the customer on this ticket" and complete it without the model ever reading the address.

Four detectors can be turned on independently:

PII obfuscation is an Enterprise feature. Each user enables it and chooses detectors under Settings → Enterprise Features → PII Obfuscation.

Blocking calls that contain PII

For data that should not move at all, SealGate's policy engine has a built-in CEL function, pii_detect(value, [categories]), that returns true when a value contains PII in the listed categories. Used in a pre-phase rule with a block action, it stops an agent from sending card numbers or keys out through a tool before the tool runs:

pii_detect(tool.args, ["CREDIT_CARD", "API_KEYS"])

The policy editor ships this as a ready-made "Block PII egress" template scoped to send, email, message, and post tools. A post-phase rule with block can instead withhold a whole tool result, replacing it with a refusal. pii_detect fails open: if the detector errors, the rule does not fire, so treat it as a second layer. See policy rules for the full syntax.

What the detectors do not cover

Detection is pattern-based. SealGate does not detect names, postal addresses, dates of birth, or national ID numbers in tool results, so a record made of those passes through unmasked. For tools that return that kind of data, rely on the controls that work at the tool level rather than the value level:

• Access Control Levels. Classify each tool as PUBLIC, PRIVATE, or SECRET. A rule like session.highest_acl_level == "SECRET" && resource.server == "email" keeps a session that has read secret data away from the mail server.
• Lethal Trifecta blocking. A restored token is a real value again, so masking alone does not stop an agent from passing a token to an outbound tool. SealGate always tracks whether a session has read private data, seen untrusted content, and can send data out. With blocking enabled for the organization (off by default), a write that completes all three is stopped or held for approval.
• Session review. Each session keeps a timeline of every tool the agent called and whether each call succeeded, was blocked, or waited for approval, so you can trace which tools a session read from before it tried to send anything.

FAQ