OWASP MCP Top 10 defines the new security boundary for AI tools

At a glance

What this is: Cycode frames the OWASP MCP Top 10 as the first dedicated security model for Model Context Protocol deployments, with early evidence showing rapid vulnerability growth and exploitable trust gaps.

Why it matters: It matters because MCP is becoming the control plane between AI agents and enterprise systems, so IAM, AppSec and platform teams now have to govern tool access, context flow and runtime auditability together.

By the numbers:

• More than 30 CVEs were filed against Model Context Protocol servers, clients and infrastructure between January and February 2026.
• Palo Alto Networks Unit 42 measured a 78.3 percent attack success rate when five MCP servers were connected to a single AI agent.
• CVE-2025-6514 in mcp-remote carried a CVSS score of 9.6 and affected a package downloaded more than 437,000 times.

Context

Model Context Protocol is the tool and context layer that lets AI agents reach into external systems, which makes it a security boundary rather than a simple integration pattern. Once tool descriptions, retrieved documents and tool outputs are treated as trusted context, the risk moves from model misuse to governed access, inventory and runtime control.

Cycode’s analysis shows that the MCP problem is already practical, not theoretical. The governance gap is especially visible where AppSec, platform engineering and AI development workflows meet, because shadow MCP servers, broad scopes and missing telemetry create an identity and authorization problem around non-human tool use.

Key questions

Q: What breaks when AI tools are exposed through loosely governed MCP servers?

A: Loose governance lets model-driven tools cross from context retrieval into state-changing actions without enough oversight. That can expose sensitive data, trigger unauthorized system changes, or widen lateral movement paths. The failure is a control boundary mismatch between what the AI can ask for and what it can safely do.

Q: Why do shared credentials create so much risk in MCP deployments?

A: Shared credentials erase accountability and make containment harder because every tool call appears to come from the same identity. In practice, that means one leaked key can expose multiple users, multiple agents, and multiple tools at once. Request-level identity is what preserves auditability and lets teams scope access correctly.

Q: How do security teams know whether MCP server governance is working?

A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.

Q: Should organisations treat MCP access like third-party software risk or IAM risk?

A: Both. MCP server onboarding is a third-party trust decision, while tool permissions, authorization, and revocation are identity governance decisions. If either side is handled in isolation, the organisation can approve a connector that still gives AI systems too much practical access.

Technical breakdown

Why MCP changes the trust boundary for AI tool access

MCP separates the agent from the external tool, but it also creates a new trust layer between the two. Tool descriptions, metadata, retrieved documents and tool outputs can all be interpreted by the agent as instructions, which means malicious content does not need to enter source code to become dangerous. In practice, that turns the protocol into a context delivery channel, not just a transport layer. Security controls that only inspect repositories or packages miss the real attack surface because the exploit can live in runtime context, not in code.

Practical implication: Treat every MCP connection as a governed trust boundary and inspect tool metadata, retrieved content and runtime context separately.

How token misuse and scope creep turn MCP into an identity problem

MCP deployments often rely on static API keys, PATs or weak delegated access patterns, which blurs ownership between the human who configures the tool and the non-human system that uses it. Once a token is shared across servers or left active after setup, the agent inherits more privilege than the task needs and attackers can pivot through that standing access. This is where MCP crosses into IAM and NHI governance: the protocol does not just move data, it moves authority, and authority without scoping becomes the compromise path.

Practical implication: Bind MCP credentials to server audience, task scope and expiry so the token cannot outlive the action it authorises.

Why telemetry and inventory are now mandatory for MCP deployments

MCP servers are frequently added by individual developers and small teams, so many exist outside central inventory, policy and monitoring. That creates shadow infrastructure with no reliable record of which server called which tool, what context was passed, or whether a malicious instruction changed the agent’s behaviour. Without immutable logs and continuous discovery, security teams cannot reconstruct agent activity after a leak or misuse event. The result is a blind spot that undermines both incident response and compliance evidence.

Practical implication: Discover MCP servers continuously, log every tool invocation and context change, and fold them into audit and monitoring workflows.

Threat narrative

Attacker objective: The attacker wants to hijack agent behaviour through the MCP trust boundary and use that access to reach systems, data or credentials the agent can already touch.

1. Entry begins when an attacker places malicious instructions, poisoned metadata or untrusted content into a document, issue or tool surface that an MCP-connected agent will later read.
2. Credential or privilege abuse follows when the agent acts on the poisoned context using broad server scopes, static tokens or shared access across trusted boundaries.
3. Impact occurs when the agent exposes secrets, modifies code, accesses private repositories or invokes connected systems beyond the user’s intended scope.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP governance is now an identity problem, not just an application integration problem. The protocol moves tool authority into the AI runtime, which means credential scope, audience validation and offboarding now matter as much as code review. Once a server can act on behalf of a user or workflow, the control question becomes who or what is allowed to speak for that identity at runtime. Practitioners should treat MCP as part of the identity perimeter, not a side channel.

Shadow MCP servers create a new form of governance debt. The hardest issue is not just vulnerability volume, but unmanaged growth outside inventory, policy and telemetry. A server that no one can see cannot be assessed, approved or revoked, which makes discovery a control, not a convenience. Teams need to assume that unmanaged AI tooling already exists and build governance around continuous detection.

Context injection is the named concept practitioners should track. In MCP environments, malicious instructions can enter through retrieved documents, tool descriptions or output fields and then masquerade as legitimate context. That makes the security problem broader than prompt injection because the agent may follow the content at the protocol layer before any application control sees it. The practical conclusion is that trusted context must be explicitly scoped and quarantined, not assumed.

Auditability is becoming the minimum viable control for agentic workflows. Once an agent can call tools across development and production systems, runtime evidence becomes the only way to prove what happened and whether a delegated action was legitimate. That requires immutable logs, behavioural monitoring and a retained record of context changes. Practitioners should expect auditors to ask for the same things security teams need for incident response.

The OWASP MCP Top 10 signals a broader shift toward protocol-level governance for AI systems. Security teams will increasingly have to manage the interfaces between models, tools and enterprise systems as first-class risk surfaces. That aligns naturally with NIST AI RMF, NIST CSF and OWASP-NHI thinking, because the problem is authority flow across machine identities and delegated runtime access. The practical implication is that AI security programmes must move from model-centric reviews to connection-centric control design.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Context injection is the governance fault line in MCP deployments. The protocol lets retrieved text influence agent action, so teams cannot rely on repository scanning alone to secure the environment. What matters is whether the agent can be steered by untrusted context before policy or approval checks intervene, which is why context isolation belongs in the control stack.

Shadow AI becomes shadow authority when MCP servers proliferate outside inventory. If the server is not discovered, its credentials, scopes and tool paths cannot be reviewed or revoked. That is a programme-level control failure, not a tooling gap, and it means continuous discovery should sit beside identity governance and DevSecOps in the operating model.

MCP Security Guide: the new control objective is to make agent tool use observable, scoped and revocable across the full runtime path. Teams should expect the practical work to shift from model safety reviews toward identity-bound tool governance, especially where AI coding agents reach into production-adjacent systems.

For practitioners

• Inventory every MCP server Continuously discover MCP servers across repos, developer machines, CI runners and production so no shadow connection sits outside governance.
• Scope credentials to each server Use short-lived, server-specific credentials with audience validation and revoke any token that can be reused across tools or environments.
• Quarantine untrusted context Treat retrieved documents, tool descriptions and tool outputs as untrusted input and block sensitive actions until the context is verified.
• Log tool invocations and context changes Capture immutable audit evidence for every tool call, context update and delegated action so incident response can reconstruct agent behaviour.
• Enforce policy at the developer edge Intercept prompts, file reads and tool calls in IDE and CLI workflows before secrets or sensitive data leave the workstation.

Key takeaways

• MCP changes the security problem from model behaviour to governed tool access, and that shift exposes identity, inventory and telemetry gaps that traditional AppSec scanning will miss.
• The early evidence is already concrete, with more than 30 CVEs in two months and a 78.3 percent attack success rate in a multi-server agent test.
• The control answer is to scope credentials, isolate untrusted context and make every server, tool call and delegated action auditable.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Shadow MCP Server: An MCP server that exists in an environment without being fully visible, approved, or governed by the teams responsible for identity and access. In practice, it becomes a hidden trust path for tools, data, and credentials, especially when developers install it directly into agent workflows.
• Context Injection: A failure mode where malicious or misleading content enters an agent's decision path and affects what it does next. In MCP environments, the injected context can alter tool selection, broaden data exposure, or trigger unsafe follow-on actions across multiple systems.
• Delegated Tool Authority: Delegated tool authority is the practical permission a model receives when it is allowed to invoke scanners, APIs, shells, or other operational tools. The security risk is not only misuse, but also overreach, because the model may chain actions beyond what a human operator explicitly intended.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It is designed for practitioners who need to govern delegated access across AI and identity programmes.