Redact PII from API Responses Before the Model

The larger personal-information leak in an AI agent is often not the prompt. It is the API or MCP (Model Context Protocol) response: a full customer record the model never needed. Response-side redaction removes those fields and rows at the proxy, with deterministic rules, before the model sees them.

Prompt-side tools still matter. They are the wrong layer for a CRM lookup that returned every attribute on the contact.

The contact card that included a tax file number

A privacy lead at a mid-market insurer watched a support assistant look up one policyholder. The ticket asked for the postal address. The CRM API returned the address, plus a tax file number, date of birth, two previous residential addresses and a notes field that mentioned a medical claim. The model summarised the address correctly. It also wrote the extra fields into the session log the vendor retained for thirty days.

Nobody had pasted those fields into the prompt. The leak was the response. The assistant had been allowed to call the contact endpoint. The endpoint was honest. Honesty at the vendor is not least privilege for the model.

Where does PII enter an agent’s context?

It enters from tool and API responses, from retrieval-augmented generation (RAG) chunks, and only then from what a human typed.

Tool and API responses. CRM, HR, claims and finance APIs are built for applications that display a full record. An agent asked for a name and company still receives the default payload.

MCP tool results. An MCP server that wraps those APIs forwards the same payload. The model treats tool output as trusted context. Controls that live only inside that server disappear if the server is later poisoned.

RAG. A knowledge base that indexed exported customer files will retrieve paragraphs the current task does not need.

The prompt. Users do paste personal information. That is the leak most products advertise they can catch.

OWASP API10:2023, Unsafe Consumption of APIs, exists because “Developers tend to trust data received from third-party APIs” more than user input. Agents inherit that trust and then store the result in a context window that can be logged, summarised or stolen by the lethal trifecta.

Prompt-side versus response-side redaction

Prompt-side redaction inspects what is about to be sent to the model from the user. Response-side redaction inspects what an API already returned.

You need both. The gap in today’s tooling is the API hop. An AI or LLM gateway that redacts model I/O does not see the Salesforce JSON unless that gateway is also the outbound API proxy. Which layer does what is the longer map.

Deterministic rules versus model-based detection

Deterministic filters name fields and rows. Model-based detectors guess that a string looks like personal information.

A deterministic filter can say: on GET contact, retain name and company, destroy everything else. On an invoices array, keep rows where status is OVERDUE and drop the rest. The same input produces the same output. You can show an auditor the rule.

A model-based detector can catch a tax file number in a free-text notes field you did not list. It can also miss a field with an unexpected name, or redact a number that is not personal information. It is a second model, with its own errors, sitting on a path you wanted to make less dependent on models.

Fair trade-off:

• Use deterministic field- and row-level rules for known schemas (CRM, HR, finance).
• Use detection on unstructured notes if you accept the extra model and log its misses.
• Do not replace a retain-list with “the redaction model will find PII”. That is hope, not a control.

RequestRocket’s filters are deterministic. A filter is scoped to methods and a request path. Operations either retain or destroy matching fields. When matchField is set, the operation is a row filter on an array; otherwise it is a field filter. Destroy wins if both match the same element. That is the live behaviour. There is no AI classifier in that path.

A CRM lookup that returns only name and company

The task is “which company does this contact work for”. The vendor endpoint returns a contact object.

1. Allow GET on the contact path only. Deny list and write methods.
2. Add a response filter on that path. Retain name and company (or the vendor’s equivalent keys). Destroy the other fields.
3. If the endpoint returns an array of contacts, add a row filter so only the requested record remains.
4. Call it from the agent. Confirm the model’s context and your audit log show the reduced payload, not the vendor default.

The assistant can still complete the task. The tax file number never entered the context. That is the difference between “the CRM is allowed” and “this caller may see two fields”.

The same pattern is what Australia’s APP 1.7 disclosure needs when it asks for the kinds of personal information a computer program used. If the program never received the extra kinds, the disclosure can stay narrow.

Row-level filtering is the second half of the same idea. A list endpoint that returns every contact in a segment will put other people’s records into a task about one company. A row filter that keeps only the requested identifier, or only rows matching a status the task named, stops that. Field filters then run on what remains. The live evaluation order is row operations first, then field operations, with destroy beating retain when both match. You do not need to show the agent that machinery. You do need the rule to be written down so a privacy officer can read it.

Unstructured notes fields remain the awkward case. A retain-list that drops notes is the conservative default for an agent. If the task truly needs the note, you accept that free text may contain personal information no schema listed, and you decide whether a second, model-based pass is worth the extra error mode. Do not quietly keep notes because “we might need it later.”

Where RequestRocket fits

RequestRocket applies field- and row-level filters on outbound API and MCP responses before they reach the caller. Rules decide which calls happen. Filters decide what comes back. The audit trail records the call. Identity and the inbound gateway still do their jobs. RequestRocket does not host or train a model, and it does not claim to detect PII by inference.

This is one control on the egress seam.

FAQ

Is prompt redaction enough if staff are trained not to paste PII?

No. The CRM will still return PII the staff member never typed. Training does not change the vendor payload.

Can we just ask the model to ignore extra fields?

A prompt is a suggestion. Anything in context can be logged, summarised or extracted. Remove the field.

What if the vendor schema changes?

A retain-list fails closed: new fields are destroyed until you add them. A destroy-list of named PII fields fails open when the vendor adds taxFileNumber2. Prefer retain for agent callers.

Does this replace a data-loss-prevention product?

No. DLP still has a job on email, endpoints and SaaS-to-SaaS paths you do not proxy. Response-side filters cover the agent’s API hop.

Can we filter MCP tool results the same way?

Yes, if the MCP server’s HTTP calls to the vendor go through the same proxy. Filtering inside an untrusted MCP server is the control that disappears when the server is poisoned.

Will the agent break if it expects the full record?

Then the task was defined as “read the full record”. Narrow the task or keep the extra fields and accept the disclosure. Do not keep the full record “just in case”.

Book a walkthrough of RequestRocket

Sources

• OWASP, API10:2023 Unsafe Consumption of APIs
• RequestRocket filter model (filterActive, methods, path match, retain/destroy, matchField row mode) as specified in the live API