MCP vulnerabilities show why AI agent identity needs tighter controls

At a glance

What this is: This is an analysis of common MCP security failures and the controls needed to harden AI agent connectivity, with a focus on authentication, scope limitation, and tool trust.

Why it matters: It matters because MCP is becoming part of agentic AI identity design, and the same weaknesses that expose tools also expand risk across NHI, autonomous, and human-linked access paths.

👉 Read Descope's analysis of the top MCP vulnerabilities and how to mitigate them

Context

MCP security is fundamentally an identity and authorisation problem, not just a protocol problem. Once AI agents can discover tools, inherit metadata, and call external services, the question becomes which identities are trusted to do what, and under which scope.

The article shows that weak defaults such as broad network exposure, unauthenticated servers, overly permissive OAuth scopes, and silent tool updates turn MCP into a control-plane risk for AI systems. For practitioners, the immediate concern is not only protecting a single server, but governing how agents, tools, and tokens interact across the full access chain.

Key questions

Q: How should security teams harden MCP servers in production?

A: Security teams should harden MCP by combining identity controls with network isolation. That means authenticating every remote server, constraining OAuth scopes, pinning tool schemas, and preventing broad interface exposure. The practical goal is to stop an untrusted server from becoming a trusted execution path.

Q: Why do MCP environments create a larger identity risk than ordinary API integrations?

A: MCP environments create larger identity risk because the model consumes tool descriptions as context and may act on them immediately. That means authority can change through metadata, not just through explicit authentication events. When token scope and tool trust are weak, the blast radius expands quickly.

Q: What breaks when MCP tool definitions change without re-approval?

A: What breaks is the assumption that a previously trusted tool still behaves the same way. If definitions can change silently between sessions, the agent may continue using a modified capability under old approval. That undermines auditability, makes security reviews stale, and hides new malicious instructions.

Q: Who is accountable when a compromised MCP server causes unauthorized actions?

A: Accountability sits with the organisation that allowed the trust chain to exist without enough controls. That includes ownership of server identity, token lifecycle, approval boundaries, and logging. If the environment cannot show who approved which tool and when, accountability is already weak.

Technical breakdown

Tool poisoning in MCP contexts

Tool poisoning occurs when malicious instructions are delivered through tool metadata or retrieved content, then folded into the model’s active context. In MCP, the server can supply descriptions that the LLM treats as operational guidance, even though those instructions are not user intent. That makes the model vulnerable to manipulated tool use, data exfiltration, and unsafe command generation. The security boundary is not the prompt alone, but the trustworthiness of the tool registry and the context it injects.

Practical implication: treat tool metadata as untrusted input and constrain which tools an agent can discover in the first place.

Cross-server shadowing and confused deputy behaviour

Cross-server shadowing happens when multiple MCP servers feed tool descriptions into the same agent context, allowing one malicious server to influence how the agent uses another trusted server. This creates a confused deputy condition, where a lower-trust component steers a higher-trust one into misusing its authority. The problem is structural: if the agent cannot reliably attribute instructions to the correct server, it cannot distinguish trusted tool intent from hostile interference.

Practical implication: namespace tools by source server and block any server that references other tools in suspicious ways.

OAuth 2.1, token theft, and silent schema drift

MCP servers often sit on top of OAuth tokens, service credentials, and changing tool schemas. If tokens are stored poorly or scopes are too broad, token theft becomes enough to impersonate legitimate usage without triggering obvious login anomalies. The article also highlights silent schema drift, where tool definitions change between sessions without user re-approval. That combination turns a one-time trust decision into an ongoing identity risk, because the agent may keep using a modified capability under the old assumption.

Practical implication: require short-lived, sender-constrained tokens and re-approve any tool schema change before production use.

Threat narrative

Attacker objective: The attacker wants to turn trusted AI connectivity into a covert control channel for data theft, unauthorized actions, and persistent access.

1. Entry begins when an attacker reaches an internet-exposed or spoofed MCP server and injects malicious tool descriptions or intercepts an agent connection.
2. Credential access follows when the agent or server reveals OAuth tokens, broad API scopes, or privileged service credentials that can be reused as normal application traffic.
3. Impact occurs when the attacker leverages those trusted calls to exfiltrate data, issue unauthorized actions, or hijack downstream systems through the agent’s authority.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tool trust is becoming an identity control, not a developer convenience. MCP collapses the distance between model context and action, which means tool descriptions now influence authorisation outcomes. That shifts the governance burden from simple application security to identity and access design across servers, tokens, and agent permissions. Practitioners should treat tool trust as a first-class identity decision.

Cross-server shadowing is a confused deputy problem for agentic systems. When a malicious server can steer a trusted one through shared context, the issue is not just bad input. It is a breakdown in source attribution, namespace separation, and authority containment across the tool plane. The implication is that agentic platforms need server-scoped trust boundaries, not a flat pool of callable tools.

OAuth 2.1 alone does not solve MCP risk if scopes remain broad and tokens persist too long. The article correctly points to authentication and authorisation, but the deeper problem is accumulated trust debt in long-lived credentials and unverified tool changes. That makes the real governance challenge lifecycle control over tokens, schemas, and server identity. Practitioners should reframe MCP as an identity lifecycle problem, not a login problem.

Named concept: context-to-control drift. MCP is vulnerable when a model’s context changes faster than its authorisation model can adapt, so the agent continues acting under stale assumptions. That drift explains why manual approval, scoped namespaces, and short-lived tokens matter together rather than separately. The practical conclusion is that identity policy must be evaluated at the point of execution, not just at onboarding.

From our research:

• From our research: 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Our research also shows that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That is why the next control question is governance, not enthusiasm, so read OWASP Agentic AI Top 10 to map the agent risk surface more completely.

What this signals

Context-to-control drift: MCP teams are inheriting the same access-governance problem that has already emerged in agentic AI deployments. With 98% of companies planning to deploy more AI agents within 12 months, the operational challenge is no longer whether to add tooling but whether identity policy can keep pace with runtime behaviour. For teams building around OWASP Agentic AI Top 10, that means treating tool scope, approval, and provenance as live controls.

The governance signal is clear: weak visibility into agent access will become a control failure in MCP-heavy environments. If organisations cannot tell which tool an agent used, which server supplied it, and which token authorised it, incident review and compliance evidence both degrade quickly. That is why identity teams should align MCP monitoring with the same assurance model used for sensitive workload identity and privileged access.

For practitioners, the near-term priority is to reduce trust debt before deployment scale compounds it. The article’s failure modes map directly to approval boundaries, token lifecycle, and server identity controls, which are easier to set early than to retrofit later. Teams that wait for a production incident will find the trust chain already too broad to unwind cleanly.

For practitioners

• Enforce server-specific trust boundaries Namespace every tool by source server and block cross-server references that let one server influence another. Use MCP gateways or equivalent controls to isolate tool discovery and prevent a malicious server from inheriting authority through shared context.
• Require OAuth 2.1 with constrained tokens Use short-lived, sender-constrained credentials and validate every request against the original client and server identity. Pair that with strict scope design so a stolen token cannot be reused as broad application access.
• Re-approve tool changes before execution Pin tool schemas in production, detect changes between sessions, and force explicit re-approval when definitions drift. Treat altered metadata as a trust event, not a routine update, because silent schema changes can alter behaviour without user awareness.
• Stop exposing development defaults in production Never bind production MCP servers to all interfaces and never leave shell execution paths open to untrusted input. Restrict read and write operations to predefined directories and apply firewall rules that limit who can reach the server at all.

Key takeaways

• MCP introduces identity risk because tool metadata can influence action, which makes authorisation and provenance central to security design.
• Internet-exposed servers, weak authentication, broad scopes, and silent schema changes create a compound attack surface that attackers can abuse quickly.
• Practitioners should isolate servers, tighten tokens, and re-approve tool changes so AI connectivity does not become a hidden control plane.

Key terms

• Model Context Protocol: An open protocol that standardises how AI systems connect to external tools and data sources. In practice, MCP turns tool discovery, metadata, and execution into part of the model’s operating environment, which makes identity and authorisation controls part of the security boundary.
• Tool Poisoning: A manipulation technique where malicious instructions are placed in tool descriptions or retrieved content so the model treats them as legitimate guidance. For MCP environments, the risk is that the model may execute harmful actions because the trust decision happened inside context, not through explicit human review.
• Confused Deputy: A security failure where a less trusted component tricks a more privileged one into using its authority in unintended ways. In MCP, this can happen when one server influences another through shared context, causing the agent to misuse higher-trust permissions on the attacker’s behalf.
• Sender-Constrained Token: A token that can only be used by the authorised client because it is cryptographically bound to that client’s identity. For MCP and other NHI flows, sender constraint reduces token replay risk and makes stolen credentials less useful outside the original trust relationship.

What's in the full article

Descope's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of how each MCP vulnerability manifests in production server setups
• Specific mitigation patterns for OAuth 2.1, scope design, and token handling in remote MCP deployments
• Detailed guidance on server whitelisting, tool filtering, and schema-change detection
• Practical implementation examples for developers building secure MCP servers and clients

👉 The full Descope post covers the attack patterns, mitigation details, and implementation guidance for secure MCP servers.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.