How Stacklok maps OWASP MCP risks to runtime controls

At a glance

What this is: This is a comparison of how an MCP runtime addresses the OWASP MCP Top 10, with the key finding that most MCP risks are identity and governance failures rather than purely model issues.

Why it matters: It matters because IAM, NHI, and agentic AI teams need to separate gateway-level controls from model-layer gaps so they do not overstate what a runtime can secure.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Stacklok's analysis of OWASP MCP Top 10 coverage and runtime controls

Context

Model Context Protocol creates a new identity and access surface because it lets AI agents discover and call tools across systems. In practice, MCP security is not just about protocol correctness. It is about whether secrets, scopes, auditability, and authorization remain governed when tool use becomes dynamic and distributed.

Stacklok’s comparison frames the real issue for practitioners: many MCP risks are controllable at the runtime and gateway layer, but not all of them are. That distinction matters for NHI governance, because some failures are about leaked credentials and over-privilege, while others are about intent alignment inside the agent itself.

For teams building MCP into production, the governance question is no longer whether the protocol can connect tools. It is whether the identity model behind those connections can survive exposure, delegation, and audit requirements without creating invisible privilege expansion.

Key questions

Q: How should security teams govern MCP tool access in enterprise environments?

A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools. A gateway can enforce policy at the edge, but governance only exists when the identity system knows who is calling, what they are allowed to do, and whether approval or offboarding has already occurred.

Q: Why do MCP servers create more NHI risk than ordinary service integrations?

A: MCP servers often sit in front of multiple tools and data sources, so a single exposed secret can grant broad downstream access. That makes scoping, revocation, and ownership more important than the protocol label itself. The risk grows when teams treat access as a development convenience instead of a governed non-human identity.

Q: What breaks when MCP servers are not registered centrally?

A: Unregistered servers create shadow deployment. That means the organisation cannot tell which tools are connected, which identities can invoke them, or whether a connection is governed at all. The result is hidden access paths that weaken both policy enforcement and assurance reporting.

Q: Which controls matter most when evaluating MCP security tools?

A: Prioritise controls that manage secrets, enforce per-request authorization, preserve auditability, and prevent shadow deployment. If a control only hardens the model but does not govern identity, it will miss the main operational risks that MCP introduces into production environments.

Technical breakdown

MCP server secrets and token exchange

MCP deployments often fail when long-lived tokens, API keys, and shared service credentials are embedded in configuration, logs, or environment files. A runtime gateway can reduce that exposure by injecting short-lived secrets at startup, exchanging upstream OAuth tokens for scoped backend tokens, and keeping credentials out of disk-backed artifacts. The architectural point is that the secret lifecycle must be separated from the server package lifecycle. If secrets travel with the configuration, compromise becomes a matter of discovery rather than exploitation.

Practical implication: move MCP secrets into a controlled runtime path and remove plaintext credentials from configuration, images, and logs.

Per-request authorization and scope creep

MCP agent privilege often expands because access is granted for the session rather than the specific request. A policy engine such as Cedar can evaluate every tool call, resource read, and prompt fetch before execution, which makes scope enforcement continuous instead of static. Tool annotations such as readOnlyHint or destructiveHint add semantic context, but the key architectural control is request-time authorization tied to identity claims and policy decisions. That is the difference between bounded access and privilege drift.

Practical implication: enforce request-level authorization and bind tool visibility to policy decisions instead of session-wide access.

Audit trails, shadow servers, and intent limits

MCP governance also depends on whether every server, tool call, and policy decision is visible enough to investigate. Structured audit logs and tracing help with attribution, but shadow MCP servers remain a separate control problem because undiscovered endpoints bypass the sanctioned path entirely. The harder limit is intent flow subversion, where the agent’s goal is redirected after retrieval. A gateway can constrain the action space, but it cannot fully validate intent inside the model context window.

Practical implication: pair audit logging and server discovery with separate agent-layer controls for intent validation.

Threat narrative

Attacker objective: The objective is to turn an MCP connection into broad, persistent operational access across multiple tools and data sources.

1. Entry occurs when MCP secrets, exposed tokens, or weak authentication let an attacker or malicious prompt reach connected tools through the MCP surface. Escalation follows when loose tool scope, shared credentials, or unfiltered tool lists allow broader access than intended. Impact occurs when the attacker uses that access to modify repositories, exfiltrate data, or trigger destructive tool actions across connected systems.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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

NHI Mgmt Group analysis

MCP governance is really identity governance with a protocol wrapper. The article shows that the highest-value controls are not cosmetic protocol features but authorization, token handling, auditability, and server discovery. That is why NHI teams should treat MCP runtimes as part of the identity plane, not as a separate AI-only problem.

Least privilege in MCP must be evaluated per request, not per session. Stacklok’s mapping makes clear that MCP risk rises when agents accumulate tools and permissions over time. The practical lesson for practitioners is that static role assignment is too blunt for tool-mediated access unless it is continuously re-evaluated at the call boundary.

Shadow MCP servers create the same governance blind spot as unmanaged service accounts. If a server is not in the registry, the policy model and audit plane do not exist for it. That is a lifecycle failure, not just a discovery issue, and it means the sanctioned path has to be the only path that matters in production.

Intent flow subversion exposes a boundary that runtime controls cannot fully close. The gateway can constrain what the agent may call, but it cannot prove that the agent’s current objective still matches the user’s original intent after retrieval. That distinction matters because it separates identity enforcement from cognition control, and practitioners need both classes of control if they are serious about agentic AI governance.

Named concept: identity blast radius in MCP. The combination of secrets exposure, weak scoping, and shared backend trust turns one compromised MCP entry point into multi-system reach. This is not a single control failure, it is a multiplication effect across identity, tool, and audit layers. Practitioners should read MCP deployment risk through blast radius, not just through exposed credentials.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• 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.
• If you are building MCP governance, compare that exposure pattern with OWASP Agentic AI Top 10 and the 52 NHI Breaches Analysis to separate runtime control gaps from identity lifecycle failures.

What this signals

Identity blast radius is now the right way to think about MCP risk. The more tools an agent can discover, the more a single credential mistake can expand into system-wide exposure. Teams should map MCP exposures against Top 10 NHI Issues and decide where the sanctioned path ends, because every unmanaged server increases the effective blast radius.

With 80% of organisations already reporting AI agents acting beyond intended scope, the governance problem is no longer theoretical. That makes request-level access controls, audit-quality logging, and ownership mapping essential programme controls rather than advanced features.

The next maturity step is to treat MCP as a governed identity substrate, not a plugin layer. Organisations that align runtime policy, secret handling, and server registration will be better placed to absorb agentic AI growth without creating hidden access paths.

For practitioners

• Enforce request-time policy decisions Bind every MCP tool call to a policy decision at the request boundary, not to a broad session grant. Use identity claims, tool annotations, and deny-by-default rules so scope cannot silently widen during use.
• Remove plaintext secrets from MCP artifacts Keep API keys, tokens, and backend credentials out of configuration files, container images, and logs. Use encrypted secret storage, runtime injection, and short-lived token exchange so compromise requires more than file access.
• Build a sanctioned-path registry for MCP servers Require every production MCP server to be registered, versioned, and mapped to an owner before it can be called. Tie the registry to audit logging so unsupported endpoints become visible governance exceptions, not hidden paths.
• Separate gateway controls from agent-intent controls Use runtime policy to limit what the agent can call, but add agent-layer validation where intent drift matters. Gateway policy alone cannot prove that a retrieved instruction still matches the user’s original goal.

Key takeaways

• MCP security is primarily an identity governance problem because the largest risks arise from secrets, scope, authentication, and auditability.
• Runtime controls can reduce exposure, but they do not fully solve intent drift or shadow server risk inside agentic workflows.
• Practitioners should design MCP deployments around request-level authorization, short-lived credentials, and a sanctioned-path registry.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Tool scoping: Tool scoping is the process of limiting which actions an AI client or service account can invoke through a protocol or platform. It is the control that prevents conversational access from becoming broad execution, and it should align with the smallest set of operations needed for the task.
• 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.
• 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.

What's in the full article

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

• Per-risk capability mapping across all ten OWASP MCP Top 10 items, including where the runtime coverage is partial rather than complete.
• Concrete configuration examples for Cedar policies, tool filtering, token exchange, and audit logging.
• Documentation references for runtime deployment patterns, registry criteria, and container isolation settings.
• Limits of gateway-only enforcement for intent flow subversion and context over-sharing.

👉 The full Stacklok post covers per-risk feature mappings, implementation notes, and where MCP governance still needs complementary controls.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.