They fail when tool identity, provenance, or description trust is weak. A malicious or shadowed tool can be selected instead of the intended one, and mutable metadata can steer the model toward unsafe actions. Teams should treat tool inventory and trust boundaries as part of the security design, not optional metadata.
Where MCP assistants fail in practice: the trust boundary, not the model
MCP-based assistants usually fail at the seam between model reasoning and tool execution. The breakage is rarely about language understanding alone, it is about whether the assistant can distinguish the intended tool from a lookalike, decide whether the tool description can be trusted, and preserve the right execution boundary when metadata changes or the tool set is polluted.
That makes MCP less like a pure prompt-routing problem and more like an authorization and inventory problem. Once tool identity becomes ambiguous, the assistant may optimistically select a harmful, shadowed, or repackaged tool because the surrounding metadata looks plausible enough to satisfy its planner.
MCP Security Guide is a practical starting point for understanding how authorization, token handling, and tool poisoning interact in real deployments. The same design pressure appears in the OWASP Agentic AI Top 10, which treats tool misuse and identity or privilege abuse as first-class risks rather than edge cases.
Why tool identity and metadata drift break the selection loop
The most common failure mode is not a dramatic exploit, but a quiet mismatch between what the assistant thinks a tool does and what the tool actually does. If names, descriptions, scopes, or registry entries are mutable, the model may rely on stale or attacker-influenced context and route a request to the wrong capability.
That matters because assistants frequently treat tool metadata as part of their working context. If a malicious server, compromised registry entry, or shadowed integration can present a persuasive description, the model may infer legitimacy where none exists. In practice, the failure is often a trust problem disguised as a planning error.
This is why the MCP authorization specification matters: it formalises resource-server behaviour, audience-bound tokens, and the rejection of token passthrough. When those boundaries are weak, tool selection becomes easier to manipulate than most teams expect.
What actually fails at runtime, and why it is dangerous
At runtime, the assistant can fail in three distinct ways: it may choose the wrong tool, it may send the right task to the wrong endpoint, or it may accept tool output that should have been treated as untrusted. All three can produce unsafe side effects, especially when the tool can read secrets, trigger external actions, or chain into other services.
The deeper issue is that MCP assistants are often operated as if tools are passive helpers. In reality, tools are execution surfaces. A single mis-selected tool can turn a harmless-seeming request into data exposure, destructive action, or privilege abuse, especially when the environment contains duplicated capabilities, ambiguous names, or inherited trust from an upstream registry.
AI Agent Identity Security: The 2026 Deployment Guide is useful here because it frames ephemeral credentials, task-scoped access, and least privilege as the conditions that keep tool execution bounded. The companion NHI Authentication Guide helps teams connect those runtime failures to machine and workload authentication choices rather than treating them as abstract AI issues.
Risk and Threat Considerations
MCP failures are attractive to attackers because they create a trust gap between the interface the model reads and the action the environment performs. If tool descriptions, registries, or gateway metadata can be influenced, an attacker does not always need to break the model, they only need to bias what the model believes is safe or intended.
Failure mechanism: A poisoned or shadowed tool identity, stale metadata, or weak boundary checking can cause the assistant to invoke the wrong capability, reuse an unsafe path, or accept a deceptive tool description as authoritative.
Impact: The result can be unauthorized actions, secret exposure, confused-deputy behaviour, or silent policy bypass across connected systems, especially where the assistant is allowed to act with delegated credentials.
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 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP assistants fail when tool identity and delegated authority are abused. |
| ASI02 — Tool Misuse | Wrong-tool selection and unsafe tool invocation are central MCP failure modes. | |
| Recommendation — Restrict agent tool access to least-privilege scopes and validate each tool's authority before execution. Constrain tool selection with allowlists, scope checks, and explicit approval for high-impact actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP trust breaks when tool/server identity and token handling are weak. |
| NHI-05 — Overprivileged NHI | Delegated tool credentials can turn a misselected tool into broad unauthorized access. | |
| NHI-06 — Insecure Cloud Deployment Configurations | Shadowed or mutable tool infrastructure creates trust and provenance gaps in MCP deployments. | |
| Recommendation — Authenticate MCP servers and tool endpoints with bound, verifiable credentials before trusting metadata. Reduce tool credentials to the minimum scope needed for each action and separate high-risk capabilities. Harden MCP hosting and gateway configuration so tool identity and routing cannot be quietly altered. | ||
Practitioner Guidance
What to verify: Treat tool identity, issuer, and registry provenance as first-class control points. If you cannot prove which server, descriptor, and scope produced a tool entry, do not let the assistant rely on that entry for high-impact actions.
Decision rule: If a tool can access secrets, external systems, or privileged business flows, require explicit allowlisting and bounded authorization before the assistant can select it. If the tool set is dynamic, revalidate trust whenever metadata changes rather than assuming the previous approval still applies.
Practitioner takeaway: The core control is not “better prompting”, it is making sure the assistant can only see and use tools whose identity, purpose, and authority are stable enough to trust.