Because sanitisation often protects only what the human sees, not what the agent sends through tool arguments. If the model suppresses records from the summary but still forwards them to another server, the privacy control has been applied to presentation rather than to movement. Governance has to cover every output channel the agent can use.
Why PII-aware sanitisation fails in MCP workflows
PII-aware sanitisation usually fails when the workflow treats the model’s visible response as the only leakage point. In MCP, the agent can redact a summary and still pass the underlying data through tool arguments, server calls, logs, or downstream actions. The control has to follow the data path, not just the presentation layer.
That mismatch is common in tool-using systems because the model can transform, enrich, or forward data independently of what the user sees. If the agent can invoke a tool that receives the original payload, sanitising the final answer does not prevent disclosure or secondary use. The practical question is whether the workflow constrains every output route, including machine-to-machine handoff.
This is why privacy controls in MCP need to be designed around movement and disclosure boundaries, not only around text redaction. The relevant security issue is not just whether sensitive fields appear in the chat transcript, but whether they can be reintroduced through MCP Security Guide patterns such as token passthrough, local server credentials, or tool forwarding. Once tool execution is involved, the sanitiser must sit at the boundary where data leaves the trusted context.
Where the privacy boundary is usually misplaced
Teams often place the sanitisation step after the model has already seen the full record. That is too late if the model can still use the original data to decide what to call, what to pass, or what to persist. A safer boundary is before tool invocation, with separate handling for the minimum fields each tool actually needs.
Another common failure is assuming one filtered channel covers all channels. MCP workflows can expose data through natural-language output, structured tool parameters, intermediary logs, and server-side side effects. The privacy rule must be enforced consistently across those paths, otherwise the sanitised summary becomes a misleading artefact rather than a real control.
For agentic systems, this is closely related to OWASP Agentic Applications Top 10 concerns around tool misuse and identity or privilege abuse. The workflow can be compliant at the interface level and still unsafe if the agent has enough authority to forward sensitive material into another system.
What practitioners should design instead
Sanitisation needs to be paired with explicit data minimisation, scoped tool inputs, and policy checks at the moment of action. If a tool does not need raw PII, do not send it. If a tool needs a subset, pass only that subset. If the agent must reason over sensitive fields, isolate that reasoning from the path that reaches external tools or downstream services.
The same logic applies to authorization. The MCP transport and the receiving service should not accept more data than the task requires, even if the model is capable of producing it. That is why MCP authorization specification guidance on audience-bound tokens and no token passthrough matters here: it reduces the chance that the workflow can silently forward privileged data or credentials as part of routine tool use.
If privacy requirements are strong, treat tool calls as separate disclosure events that need their own review and logging. That is especially important where the workflow can cross trust boundaries or where multiple tools receive different slices of the same record. The safer pattern is to validate each outbound payload against purpose, necessity, and recipient scope before it leaves the agent runtime.
Risk and Threat Considerations
PII-aware sanitisation can create a false sense of safety when the agent still has access to the original data. The risk is silent secondary disclosure: the human sees a cleaned response, while the agent forwards the uncleaned record to another tool, server, or log sink.
Failure mechanism: The control is applied only to the presentation layer, so the underlying data remains available to the agent’s tool arguments, context, or downstream side effects. That lets sensitive data bypass the sanitiser without visibly appearing in the final answer.
Impact: PII can be exposed outside the intended disclosure boundary, retained in logs, copied into another system, or used in ways the user did not authorise. In an MCP workflow, that can also create cross-system propagation that is hard to detect after the fact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP workflows can forward sensitive data through agent tool authority and privilege boundaries. |
| ASI02 — Tool Misuse | The failure mode is an agent using tools to move data after redaction of the visible answer. | |
| Recommendation — Enforce least-privilege tool access and restrict agent actions to the minimum required data and authority. Validate every tool call against purpose and data-minimisation rules before execution. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | MCP workflows often rely on tokens and credentials that can be forwarded beyond the intended boundary. |
| AC-6 — Least Privilege | The answer hinges on limiting what the agent and each tool can access or transmit. | |
| SC-28 — Protection of Information at Rest | Sanitised data can still be persisted in logs or storage if downstream paths are not controlled. | |
| Recommendation — Restrict credential handling so secrets and tokens are not reused or passed outside their intended scope. Limit each agent and tool to the minimum data and permissions needed for the task. Protect sensitive fields wherever downstream systems may store or retain them. | ||
Practitioner Guidance
What to verify: Check whether sanitisation runs before any tool call, not just before the user-visible response. If the model can still send the raw field in an argument or payload, the control is incomplete.
Decision rule: If a tool does not strictly need the sensitive field, strip it before invocation and pass a purpose-limited substitute instead. If the workflow cannot enforce that consistently, treat the design as a data-movement problem, not a redaction problem.
Practitioner takeaway: The real control objective is to restrict what the agent can move, not merely what the user can read, because privacy fails when disclosure is redirected through execution paths the sanitiser never covered.