A governance failure where a Model Context Protocol tool or skill contains sensitive behaviour that appears legitimate until an agent executes it. The issue is not protocol misuse alone, but hidden credential access inside a trusted interface that scanners or reviewers may not inspect deeply enough.
Expanded Definition
MCP Trust Leakage describes a security and governance gap in which a Model Context Protocol tool, connector, or skill looks ordinary at review time but exposes sensitive behaviour only when an agent invokes it. The risk is not simply that MCP exists, but that trusted integration surfaces can conceal credential access, data movement, or tool chaining that is difficult to see in a shallow inspection. In practice, this makes the boundary between legitimate automation and hidden privilege use much harder to validate.
Definitions are still evolving because MCP is new enough that no single standard governs how trust boundaries, tool descriptions, and execution permissions should be audited across vendors. Security teams often treat the manifest, name, or repository metadata as sufficient evidence of safety, even though the harmful behaviour may sit inside the callable function, downstream dependency, or delegated action path. That is why terms such as OWASP Agentic AI Top 10 are useful for framing the control problem around agent trust and tool abuse rather than protocol syntax alone. The most common misapplication is assuming a trusted MCP interface is safe because it passes code review, which occurs when reviewers do not inspect the agent-executable actions behind the interface.
Examples and Use Cases
Implementing MCP trust controls rigorously often introduces review overhead and runtime restrictions, requiring organisations to weigh faster agent enablement against stronger inspection and permission boundaries.
- A customer support agent is allowed to use an MCP tool for case summaries, but the same tool also has hidden access to a secrets store and can exfiltrate tokens if invoked with crafted inputs.
- An internal coding assistant connects to an MCP server that appears to offer documentation lookup, yet the tool can silently enumerate repositories and retrieve privileged configuration data.
- A security operations agent relies on an approved skill package, but the package includes a secondary action that forwards alerts, logs, or credentials to an unreviewed external endpoint.
- A deployment workflow uses an MCP integration for change requests, but its downstream calls can mutate infrastructure settings beyond the stated purpose, creating an unseen privilege path.
- During supply chain review, teams use guidance from the OWASP Top 10 for Agentic Applications 2026 to check whether a tool’s declared purpose matches its actual execution behaviour.
In these examples, the core issue is not that the agent “misbehaves” on its own. The issue is that a trusted interface can become a hidden privilege boundary, especially when tool metadata is sparse, review processes focus on the wrapper instead of the callable path, or downstream permissions are broader than the use case.
Why It Matters for Security Teams
MCP Trust Leakage matters because it turns agent enablement into a trust-integration problem rather than a simple application onboarding task. If a team only validates the visible prompt, tool description, or registry entry, it may miss where secrets are actually accessible and where the agent can be induced to use them. That creates an identity and authorization issue as much as a software review issue, because the effective risk often lies in who or what can act with delegated authority.
For security teams, the practical control question is whether every MCP-connected capability is bound to least privilege, explicit purpose, and inspectable execution paths. This is especially important when tools can reach NHI secrets, API keys, certificates, or service credentials, because a trusted agent interface can become the path by which hidden access is exercised. The Anthropic report on the first AI-orchestrated cyber espionage campaign report is a reminder that agentic workflows are already being operationalised in hostile ways, which makes trust leakage a concrete governance concern rather than a theoretical one. Organisations typically encounter the impact only after an agent has used an approved tool to reveal, copy, or execute something that was never obvious during review, at which point MCP Trust Leakage becomes operationally unavoidable to address.
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 Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic AI guidance covers tool abuse and hidden execution risk in trusted agent interfaces. | |
| NIST AI RMF | AI RMF addresses governance and risk management for AI systems using delegated tools. | |
| OWASP Non-Human Identity Top 10 | NHI guidance is relevant when MCP tools expose secrets, tokens, or service credentials. |
Review each MCP tool for hidden actions, privilege boundaries, and prompt-to-execution trust gaps.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
