The privacy boundary breaks because the agent receives data it does not need, and that data can then appear in prompts, logs, responses, or downstream calls. The issue is not that access was unauthorised. The issue is that authorised access still produced excessive processing of personal data.
When MCP tools over-collect, the privacy boundary moves from access control to data minimisation
The break is architectural, not just procedural. Once a tool returns full records, the agent is no longer operating on a narrow purpose-built payload. It is handling surplus personal data that can be copied into prompts, traces, responses, caches, or downstream tool calls, which widens the processing boundary even when the original access was legitimate.
That matters because MCP is often used to mediate a very specific task, not to expose entire records. A tool that returns only the needed fields preserves purpose limitation and reduces the chance that sensitive attributes are incidentally exposed to the model or to adjacent systems that were never required to see them. The control objective is therefore field-level scoping, not just successful authentication or tool authorization.
In practical terms, the difference is between a tool that supplies a bounded answer and one that hands the agent a reusable dataset. The second pattern creates avoidable spillover, because the model may summarise, transform, or route data in ways that were not part of the user’s immediate request. The more complete the record, the more likely the system is to process personal data beyond what the task actually needs.
Where full-record responses create the most damage
Full-record responses tend to fail in three places: disclosure, propagation, and retention. Disclosure happens when the agent or surrounding application renders more data than intended. Propagation happens when the record is forwarded into other calls, embeddings, audit trails, or developer-visible logs. Retention happens when those extra fields persist longer than the task requires, increasing the blast radius of a later compromise or operational mistake.
This is especially sharp in MCP-style workflows because the agent may not be the final consumer. A downstream summariser, router, or policy layer can inadvertently inherit data it never needed, and once that happens the boundary is already lost. If the tool response includes identifiers, notes, or other sensitive attributes, the problem is not simply over-sharing, it is unnecessary processing at multiple layers.
From a security perspective, the weakness is that legitimate access can still produce excessive exposure. That is why the failure looks more like privacy leakage and data minimisation failure than classic access control failure. The access decision may be correct, yet the response shape is still too broad for the task.
How to design MCP tools so they stay narrow
The safest pattern is to make the tool return only task-specific fields, with a separate path for any broader retrieval that is explicitly justified and logged. This is easier to enforce when the tool contract is designed around the question being answered, not around the record being stored. A narrow schema reduces both the amount of personal data processed and the number of places it can be copied.
Tool authors should also treat redaction and projection as first-class controls, not post-processing conveniences. If the agent only needs name, status, and timestamp, the tool should not return address, notes, internal identifiers, or unrelated attributes by default. When broader fields are occasionally needed, that should be an exception with an obvious business reason and a clear audit trail.
The Model Context Protocol authorization specification is useful here because it reinforces that transport authorization and payload minimisation are different problems. JWT client authentication and authorization grants help with client trust, but they do not justify returning more data than the task requires.
Risk and Threat Considerations
Returning full records expands the surface for accidental disclosure, policy drift, and secondary reuse. Even without an attacker, the system can violate internal privacy expectations by moving unnecessary personal data into prompts, logs, or chained requests where it becomes harder to control and harder to delete.
Failure mechanism: The tool response contains more fields than the agent needs, so the model or orchestration layer processes data beyond the original purpose and copies it into additional components.
Impact: Excessive processing increases privacy exposure, retention risk, and the chance that later prompts, logs, or downstream calls reveal sensitive information that should never have left the narrow task boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API3 — Broken Object Property Level Authorization | Full records expose extra object properties beyond the task's need. |
| Recommendation — Return only the fields the caller is allowed and needs, not the entire object. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Narrow field return enforces least privilege over data exposed to the agent. |
| Recommendation — Limit tool outputs to the minimum data required for the task. | ||
| GDPR | Art. 5(1)(c) — Data minimisation | Returning full records processes more personal data than is necessary for the purpose. |
| Recommendation — Minimise tool outputs to what is necessary for the stated purpose. | ||
| ISO/IEC 27001:2022 | A.5.12 — Classification of information | Field scoping depends on knowing which record attributes need tighter handling. |
| Recommendation — Classify record fields so tools suppress unnecessary sensitive attributes by default. | ||
Practitioner Guidance
What to verify: Check the actual tool response schema, not just the authorization model. If a field is not needed for the user-visible task, it should not be in the default response, even when the caller is permitted to read the underlying record.
Decision rule: If a tool must return broad records for operational reasons, treat that as a higher-risk design and require explicit justification, tighter logging controls, and a clear limit on where the extra fields may flow.
What good looks like: The agent receives the minimum fields needed to complete the task, sensitive attributes stay out of prompts and logs, and any broader retrieval is visibly exceptional rather than routine.
Practitioner takeaway: In MCP, the key question is not whether the caller was allowed to access the record, but whether the tool response was scoped tightly enough to avoid unnecessary processing and propagation of personal data.
Related resources from NHI Mgmt Group
- What breaks when MCP tools return sensitive data without inline redaction or masking?
- What breaks when MCP tools rely on the UI instead of server-side authorization?
- What breaks when security tools only inspect individual agent actions instead of the full workflow?
- What breaks when organisations keep asking for full identity records instead of selective attributes?