They should classify each tool by the data it can return, restrict high-risk queries, and require per-call logging and protection controls before any result reaches the model. The control must follow the record, not just the connection.
How MCP tool governance should work when regulated customer data can be returned
MCP changes the governance problem because the tool is not just a connector, it is a controlled data-return path. If a tool can surface regulated customer data, teams need to classify its outputs, constrain which prompts or queries it will serve, and treat every response as a governed record with logging, reviewability, and downstream handling rules.
The practical question is not whether the model can ask for the data, but whether the organisation can justify, trace, and contain the data once the tool returns it. That means access policy, output filtering, and audit evidence have to be designed around the record that comes back, not only around the transport session or agent connection.
When an MCP tool can return regulated data, the safest default is to govern it like a sensitive data service with an additional orchestration layer. The control point is the combination of tool identity, query scope, result content, and post-return handling. A tool that is “safe enough” for low-risk metadata may still be unacceptable for records that contain financial, health, or personally identifiable information.
Why the return path, not just the connection, determines the control
Security teams should assume that the same tool can behave very differently depending on what it is allowed to return. A harmless lookup for account status can become a regulated-data disclosure path if the tool can expand to full customer records, support notes, exports, or correlated identifiers. That is why classification must be tied to the data class in the response, not to the MCP server itself.
This also changes the enforcement point. Connection security is necessary, but it does not answer whether a tool may return a particular record, under a particular context, to a particular requester, for a particular purpose. Current guidance for MCP authorization explicitly treats the MCP server as a resource server and discourages token passthrough, which supports a design where the tool mediates access rather than inheriting broad ambient authority. See the MCP authorization specification for the protocol-level control model.
For teams building or reviewing agentic workflows, the main design implication is that output classification must be enforced at the tool boundary and again after retrieval. The model should only receive the minimum response needed for the task, and any regulated fields should be redacted, truncated, tokenized, or withheld unless the call context explicitly allows disclosure.
Controls that keep regulated outputs governable
Good governance starts with a data-return matrix: which tools can return which classes of records, under which approved use cases, and with what approval path. High-risk queries should be explicitly limited, not just monitored after the fact. If a tool can return customer records, support history, payment details, or other regulated data, the query should be narrowed to the minimum fields and the default should be deny unless there is a documented business need.
Per-call logging is essential because the audit trail must show who requested the data, which tool answered, what scope was requested, what the tool returned, and whether any policy filter altered the payload. A useful log is one that supports reconstruction of the data exposure event later, not just evidence that an API call happened.
Protection controls should follow the returned record. That means masking, field-level filtering, consent or purpose checks, DLP-style inspection where appropriate, and retention rules that prevent the model conversation or downstream cache from becoming a shadow copy of regulated data. If the tool can retrieve records from a system of record, the response handling should inherit the same sensitivity as that source data.
Useful internal references on related MCP and token-risk failure modes include LiteLLM MCP auth bypass 2026, which shows how gateway weaknesses can expose upstream keys, and Vercel Context.ai OAuth Supply Chain Breach, which illustrates how third-party integration paths can surface customer data unexpectedly.
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 and OWASP API Security Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP tools can over-extend agent authority over regulated records. |
| Recommendation — Constrain tool-scoped authority and require least privilege for any regulated-data retrieval. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Tool calls must be authorized by function and data scope, not just connection. |
| API3 — Broken Object Property Level Authorization | The main issue is which record fields the tool may disclose in each response. | |
| Recommendation — Enforce function-level authorization on every MCP tool that can return regulated data. Restrict returned fields to the minimum authorized object properties for the caller. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Per-call logging is required to reconstruct regulated-data access through MCP tools. |
| AC-6 — Least Privilege | High-risk queries should be minimized and limited to approved need-to-know access. | |
| Recommendation — Log each MCP tool call with requester, scope, and returned data class. Grant only the minimum tool access and query scope needed for the task. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Tool access must be governed by policy tied to regulated data exposure. |
| Recommendation — Define and enforce access rules for MCP tools that can disclose regulated data. | ||
Practitioner Guidance
What to prioritise: Start by inventorying every MCP tool that can retrieve customer-facing or regulated records, then assign each one a data-return class and a permitted query scope. The first governance question is whether the tool can return content that would trigger legal, contractual, or privacy handling obligations if exposed outside the intended workflow.
What to verify: Verify that the enforcement point sits before the model receives the payload, and that logging captures the tool name, requester context, record class, and response disposition. If you cannot show what was returned and why it was allowed, the tool is not yet governed tightly enough for regulated data.
Decision rule: If the tool can return regulated customer data, require field-level minimization and per-call auditability before enabling the integration for production use. If those controls cannot be implemented cleanly, restrict the tool to non-sensitive summaries or metadata only.
Practitioner takeaway: The mature control model is to treat MCP as a governed data-return surface, not a generic prompt extension, and to enforce policy on the record that leaves the tool as strictly as on the system that stores it.
Related resources from NHI Mgmt Group
- How should security teams govern MCP-enabled AI assistants that can act on tools and data?
- How should security teams govern AI tools that query endpoint risk data through MCP?
- How should security teams govern non-human identities at scale?
- How should security teams govern non-human identities for compliance?