Notifications
Clear all
Topic starter
19/08/2026 3:48 pm
TL;DR: MCP deployments can pass full tool responses into LLM context, logs, and downstream calls, allowing PII to leak even when access controls are in place, according to Obot. The missing control is data minimization at the control plane, because authorization alone does not stop overexposed records from propagating into AI workflows.
NHIMG editorial — based on content published by Obot: MCP PII Data Security: How Tool Calls Leak PII and How to Stop It
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 79% of organisations have experienced secrets leaks, and 77% of these incidents resulted in tangible damage.
Questions worth separating out
Q: How should security teams prevent PII from leaking through MCP tool calls?
A: Start by inspecting what each tool actually returns, then filter or redact fields before the response reaches the model.
Q: When does MCP create a privacy problem even if access is approved?
A: The privacy problem begins when a tool returns full records that contain personal data the agent does not need.
Q: What do teams get wrong about least privilege for AI agents?
A: They often stop at permission scope and ignore behavioural scope.
Practitioner guidance
- Audit actual tool responses Sample the payloads returned by high-use MCP tools and identify which fields are not required for the task but still reach the model context.
- Apply response filtering at the control plane Use redaction for routine overexposure and blocking for data that should never reach an LLM, such as health records or financial account numbers.
- Separate tool access from data visibility Review whether dedicated service accounts and RBAC scopes still allow broad record retrieval even when the agent only needs a single attribute.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- Filter design examples for CRM, HR, support, and document retrieval tools
- Decision rules for when to redact, when to block, and when to log a tool response
- Implementation guidance for MCP control-plane placement and enforcement
- Operational notes on encryption, audit logging, and per-tool policy tuning
👉 Read Obot's analysis of MCP PII leakage and control-plane filtering →
MCP PII leakage in tool calls: what IAM and AI teams miss?
Explore further
19/08/2026 4:25 pm
Data minimisation is the missing control, not access approval. The article shows that a tool can be properly authorised and still over-disclose personal data once it returns a full record into LLM context. That is a governance failure in the data path, not an authentication failure. For IAM teams, the lesson is that approving access to a tool is not the same as approving unrestricted consumption of every field that tool returns.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, and 77% of these incidents resulted in tangible damage, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how often identity governance still lacks basic inventory depth.
A question worth separating out:
Q: Who is accountable when an agent leaks data through an MCP server?
A: Accountability sits with the teams that defined the trust boundary and the controls that failed to enforce it, usually identity, platform, and security owners together. If tool authorization, context validation, or monitoring was missing, the breach is a governance failure, not just a runtime incident. Shared ownership must be explicit before deployment.
👉 Read our full editorial: MCP PII leakage persists when tool responses overexpose personal data
