PII Redaction for AI Agents Must Follow the Data

An agent creates several data boundaries in one run

A support agent may receive a customer message, retrieve a CRM profile, read an order, call a model, invoke a payment tool, create a ticket, and record evidence. Each step has a different purpose, recipient, and data need. A single filter at the chatbot input doesn't govern the full path. Map where data enters, which fields are retrieved, where they are sent, what returns, what is shown to the person, and what is retained. Apply the configured rule before every restricted destination.

Choose the right handling action for the purpose

Redaction is one data-handling option. Depending on the workflow and policy, the control may remove a field, mask part of it, replace it with a stable token, generalise it, block the request, or route the work to an approved environment. Preserve the minimum context needed for the task. For example, a CRM lookup may require the customer identifier while the model only needs order status and policy facts. Do not remove data so aggressively that the agent can't complete the approved job or explain the outcome.

• Remove data that the destination doesn't need
• Mask values when partial visibility is sufficient
• Tokenise when the workflow needs a stable reference
• Generalise precision when an exact value is unnecessary
• Block or reroute when the destination isn't approved

Apply policy before model and tool calls

The agent shouldn't be trusted to remember which fields to remove. Put the control in the governed data path before the request reaches the restricted model, tool, API, or external service. Evaluate the data class, destination, use case, purpose, and policy that apply. Validate both the agent-generated arguments and retrieved context. Record the transformation and rule without copying the original protected value into a trace or error message.

Protect outputs and evidence too

Sensitive data can return from a tool, appear in a model output, reach a customer response, or be duplicated into an evidence store. Apply output handling before the response reaches a recipient who shouldn't see the field. Design evidence to preserve accountability while minimising content. A reviewer may need to know that an email address was detected and redacted, not the email address itself. Use stable references back to authorised systems when full values are needed for investigation.

Test false negatives, false positives, and format changes

Real data is messy. Test formatted and unformatted identifiers, names in free text, copied signatures, attachments, international phone numbers, partial account values, and structured tool arguments. False negatives create exposure. False positives can break the workflow or remove evidence the business needs. Define a review process for uncertain classifications and monitor patterns over time. Coverage depends on language, data type, configuration, and integration path, so avoid absolute claims.

Keep the customer experience separate from internal controls

The agent shouldn't reveal policy internals, sensitive classifications, or security mechanisms to the customer unless the business process requires it. If a data rule or permission changes the workflow, provide a normal service response and follow the approved fallback. Internally, the evidence should record that the data control applied, which destination was protected, and how the run continued. This creates accountability without turning governance into confusing customer-facing dialogue.

Use a destination-by-destination data worksheet

Do not write one global rule that says PII is redacted. Record what each destination needs and verify the transformed payload. The same value may be permitted in the system of record, tokenised for a model, masked in a review screen, and omitted from an analytics event.

• Source and authoritative record owner
• Data element and classification
• Destination and business purpose
• Whether the original value is required
• Remove, mask, tokenise, generalise, block, or route action
• Detection method, supported formats, and known coverage limits
• Permitted retention and authorised viewers
• Evidence recorded without reproducing the protected value
• False-negative, false-positive, attachment, output, and error-path tests