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

At a glance

What this is: This guide maps the OWASP MCP Top 10 to the protocol-specific risks that arise when AI agents connect to external tools, data sources, and credentials.

Why it matters: It matters because MCP now sits inside development and operational workflows, so identity, privilege, token handling, and auditability all need to be governed as runtime security controls, not optional add-ons.

By the numbers:

• Security researchers filed more than 30 CVEs 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.
• Cycode’s 2026 State of Product Security report found that 81 percent of organisations lack full visibility into how AI is used across the SDLC.

👉 Read Cycode's guide to the OWASP MCP Top 10 and AI tool security

Context

Model Context Protocol, or MCP, is becoming the connective layer between AI agents and enterprise systems, which means the security problem is no longer just model behaviour but tool access, context handling, and credential exposure. The OWASP MCP Top 10 is an attempt to name the most common failure modes before they become normalised across development and operations.

The first-order governance issue is visibility. Once tool servers, prompts, and runtime actions are spread across IDEs, CI/CD pipelines, and production assistants, conventional application security loses line of sight into how access is being used. That makes MCP especially relevant to IAM, PAM, and NHI teams because the protocol creates new places where tokens, scopes, and delegated permissions can be overextended.

Cycode’s framing reflects a broader pattern in agentic systems: the risk is not only what the agent can do, but which external systems it is allowed to trust while doing it. That starting position is increasingly typical wherever AI tools are being connected to real enterprise resources without a mature control plane.

Key questions

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

A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.

Q: Why do MCP servers create new identity risk for AI-native development?

A: MCP servers create risk because they extend delegated access from the model into repositories, data, and workflow tools. If the trust path is too broad, the agent can act with capabilities that were never intended for that task. Teams should review those connections as access paths, not just as integration plumbing.

Q: What breaks when tool descriptions or retrieved context are trusted blindly?

A: Blind trust in context lets attacker-controlled text influence decisions that should have been policy checked. A poisoned issue, document, or tool response can redirect the agent’s intent and lead it to disclose data, modify resources, or invoke the wrong tool. That is why context isolation is a security control, not a UX preference.

Q: Who is accountable when an AI agent takes action through an MCP server?

A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.

Technical breakdown

How MCP expands the trust boundary beyond code

MCP moves trust out of source code and into the interaction layer between an AI agent and external tools. Tool descriptions, retrieved documents, and tool outputs are ingested as context, which means malicious instructions can arrive through metadata rather than executable code. Traditional SAST and SCA controls are weak here because they inspect code and dependencies, not the runtime meaning of tool prompts, server responses, or context windows. In practice, a single compromised MCP server can influence the behaviour of a connected agent across repositories, tickets, and APIs. This is why MCP security has to be treated as a control problem around trust boundaries, not just a coding problem.

Practical implication: inventory every MCP trust boundary and classify which tool outputs can influence privileged actions.

Why token mismanagement and scope creep are the core identity risks

The identity problem in MCP is that access often starts as a convenience token and quickly becomes a standing permission set. Static API keys, PATs, and long-lived delegated credentials are easy to reuse across servers, but they also create broad blast radius when a server, connector, or context stream is compromised. Scope creep happens when permissions accumulate without expiry, per-server audience checks, or meaningful revocation. That turns an agent connection into a durable identity with more reach than the original use case justified. In NHI terms, MCP servers behave like machine identities that need lifecycle controls, not like one-off integration shortcuts.

Practical implication: treat MCP credentials as governed non-human identities with expiry, scoping, and revocation.

What intent flow subversion means for agentic applications

Intent flow subversion is the protocol-level version of indirect prompt injection. The agent is not merely reading text, it is using that text to decide what to do next, so poisoned context can redirect actions from the user’s goal to the attacker’s objective. This becomes more dangerous when the agent has permission to modify code, access repositories, or call external APIs, because a hijacked instruction stream can translate immediately into harmful execution. The OWASP Agentic AI Top 10 and the MCP Top 10 overlap here, but MCP is the layer where context becomes operational action. That makes human approval and context isolation part of the attack surface, not just the governance layer.

Practical implication: isolate untrusted context and require step-up approval before sensitive agent actions.

Threat narrative

Attacker objective: The attacker’s objective is to turn trusted agent connectivity into unauthorised access, data exposure, or system manipulation across enterprise tools.

1. Entry occurs when an attacker plants malicious instructions, poisoned metadata, or a vulnerable dependency inside an MCP-connected workflow.
2. Escalation follows when the agent trusts that context, reuses over-scoped credentials, and invokes tools with broader permissions than intended.
3. Impact is achieved when the agent exposes secrets, modifies systems, or exfiltrates data across connected enterprise resources.

NHI Mgmt Group analysis

MCP governance is now an identity problem disguised as an integration problem. The article shows that the most damaging failures in MCP come from token exposure, scope creep, and ungoverned tool permissions. That puts MCP squarely in the same control family as NHI lifecycle management and PAM, because every server connection is effectively a machine identity with reach. Practitioners should govern MCP access as a credentialed runtime relationship, not as a convenience plugin.

Shadow MCP servers create an inventory problem that traditional AppSec cannot solve alone. If a server is not discovered, it cannot be reviewed, scoped, or monitored, which means the organisation is already operating with blind trust. This is the same pattern seen in unmanaged NHI estates: the risk comes from what is invisible, not only from what is misconfigured. The practical conclusion is that discovery and allowlisting must precede any serious control discussion.

Context poisoning is the defining concept of MCP risk. Tool descriptions, retrieved documents, and server responses are all able to shape agent behaviour, which means untrusted context can become an execution trigger. That collapses the old separation between reading and acting, and it is why the OWASP MCP Top 10 should be read alongside OWASP Agentic AI guidance and MITRE ATLAS. Security teams should assume that context can steer privilege unless it is actively quarantined.

Static credentials are the wrong foundation for protocol-driven AI access. The article’s own risk list makes clear that long-lived tokens, PATs, and embedded secrets are structurally incompatible with fast-moving agent workflows. A short-lived, scoped, auditable credential model is not a nice-to-have here. Practitioners should reframe MCP as a lifecycle management problem for machine identities.

Auditability is becoming a compliance boundary, not just a detection control. Once agents can act through MCP across development and production systems, regulators and auditors will ask who approved access, what was invoked, and whether the activity was bounded. That aligns MCP risk with NIST AI RMF, NIST CSF, and the broader evidence expectations emerging around AI systems. Teams should prepare to prove control, not merely claim awareness.

What this signals

The immediate signal for practitioners is that MCP cannot be managed as a developer convenience layer. Once agents can inherit tool access, your programme needs policy on scoping, approval, and revocation that is closer to PAM and NHI governance than to ordinary application configuration. The first measurable improvement is not more detection noise, but fewer unowned connections and fewer standing credentials.

Context poisoning: the next control gap is not only credential theft but context that silently changes agent intent. Teams should watch for policy decisions that occur after retrieval, because that is where untrusted content becomes executable behaviour. The right response is to align AI guardrails, inventory, and identity controls so the agent’s trust boundary is explicit and auditable.

The programme implication is that AI security and identity security will converge around evidence. When auditors ask how an agent was authorised to act, teams will need more than a diagram. They will need an inventory of MCP servers, time-bounded credentials, logs of tool invocation, and a clear owner for each delegated trust relationship.

For practitioners

• Inventory every MCP server and connector Build a continuously updated register of MCP servers, tools, and dependent packages across IDEs, CI runners, and production agents. Classify each connection by owner, business purpose, credential type, and data sensitivity so shadow servers can be removed or brought under review.
• Replace long-lived tokens with scoped, short-lived credentials Eliminate static API keys and persistent PATs where MCP integrations can use delegated, audience-bound, and time-limited authentication. Tie issuance and revocation to the service identity lifecycle, not to developer convenience.
• Quarantine untrusted context before agent execution Treat retrieved documents, tool descriptions, issue text, and server outputs as untrusted input until they pass policy checks. Block sensitive actions until the agent’s context has been filtered, reviewed, or explicitly approved.
• Log tool invocation, context changes, and approval events Capture immutable records of every tool call, context update, credential use, and human approval so investigations can reconstruct the agent’s decision path. Feed those records into the SIEM and behavioural monitoring to detect multi-step abuse.

Key takeaways

• MCP turns AI integrations into a governed identity surface, not just a tooling layer.
• The main failures are visible already in token exposure, scope creep, and context-driven privilege abuse.
• Teams should combine discovery, short-lived credentials, context quarantine, and audit logging before MCP use expands further.

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.
• Intent Flow Subversion: A failure mode where untrusted text or retrieved context changes what an AI agent decides to do next. It is more dangerous than simple prompt injection because the attacker is aiming at the agent’s decision path, not only the wording of the output.
• 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.
• AI bill of materials: An inventory of the components used by an AI development environment, including models, plugins, hooks, skills, and agent integrations. It gives security teams visibility into what is operating in the stack so they can assess trust, dependency risk, and governance coverage.

What's in the full article

Cycode's full guide covers the operational detail this post intentionally leaves for the source:

• Risk-by-risk mapping across all ten OWASP MCP categories, including the specific CVEs and disclosed attacks tied to each one
• The full defense playbook for SDLC and Agentic Development Lifecycle controls, including where to enforce policy in IDE, CLI, CI/CD, and production
• Cycode's control stack for MCP visibility, including continuous discovery, AI guardrails, and audit telemetry across the software factory
• Implementation context for teams evaluating MCP in real environments, including how to prioritise fixes when multiple servers and tools are already connected

👉 Cycode's full guide covers the risk categories, example attacks, and layered defenses in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It is designed for practitioners building the controls that connect identity lifecycle management to real-world security operations.