MCP runtimes solve three planes, not ten separate controls

At a glance

What this is: This is an analysis of how MCP runtime controls map to the OWASP MCP Top 10, with the central finding that most items sit in runtime, identity, and policy planes rather than as ten isolated controls.

Why it matters: It matters because IAM, platform security, and AI governance teams need to separate what an MCP runtime can enforce from what only the agent or model layer can actually control.

Context

MCP governance fails when teams treat every OWASP MCP Top 10 item as if it were a runtime feature. The real issue is control placement: some risks live in the server and network path, some in identity and policy, and some only in the agent or model layer.

For MCP deployments, that means runtime teams can reduce blast radius, but they cannot validate user intent or manage the model's working context. The article's core claim is that good control design depends on knowing which plane owns which problem, especially when secret handling, authorization, and context safety are being conflated.

This is an architecture question as much as a security one. If a programme uses gateway controls as a substitute for agent-layer controls, it will appear covered while still leaving the highest-risk parts of the interaction ungoverned.

Key questions

Q: What fails when teams treat MCP runtime controls as if they cover the whole OWASP Top 10?

A: They end up applying gateway and container controls to problems that only exist in the agent or model layer. That creates false confidence because the runtime can constrain execution, but it cannot validate intent or manage the model's context window. The result is partial coverage presented as full governance.

Q: Why do MCP runtimes need separate identity and policy controls?

A: Because access scope, user attribution, and per-request authorization are different from the mechanics of running a tool. A runtime can centralise policy enforcement, but if identity is not propagated correctly, the environment falls back to shared credentials and weak auditability. That defeats least privilege even when the runtime is otherwise hardened.

Q: What breaks in practice when MCP tool poisoning is left to the runtime alone?

A: The runtime can reduce the blast radius, but it cannot prove that a tool's description or schema is the one an operator approved. If the definition changes after registry review, the agent may still trust and execute it. That makes definition integrity a separate trust problem, not just a containment problem.

Q: How should security teams govern shadow MCP servers discovered on managed devices?

A: Security teams should treat shadow MCP discovery as a governance and exposure problem, not just a tooling issue. The first priority is to identify where unmanaged servers are being configured, separate new or unknown instances from ones with managed alternatives, and review affected users and audit logs. That gives teams a practical path to reduce sprawl, prioritize migration, and limit hidden access paths.

Technical breakdown

The runtime and network plane in MCP

The runtime plane is where MCP servers execute, where container isolation exists, and where network egress, filesystem access, and secret handling can be enforced. In this layer, the runtime can make misuse harder by controlling process boundaries, token handling, and outbound traffic. It can also centralise audit logging and policy enforcement so individual tools do not each need to reimplement the same controls. The key limitation is that this plane governs execution conditions, not the model's reasoning or the user's intent.

Practical implication: Treat the runtime as the place to contain execution, not as the place to decide whether the agent should have acted at all.

Identity and policy enforcement in MCP

Identity and policy are the control plane that decides who can call which tool, with which credentials, and under what conditions. In the article's model, this is where policy-as-code, OAuth, OIDC, and per-request authorization belong. The important architectural point is that centralising auth at the proxy removes duplicated security logic from individual MCP servers and makes authorization auditable. This is the most reliable layer for governing access scope, but it still depends on accurate identity propagation and correctly written policy.

Practical implication: Use identity and policy to govern access scope centrally, then verify that the authorization decision survives the full request path.

Why agent and model controls cannot be replaced by an MCP runtime

Agent and model controls address what the model is reasoning about, what sits in context, and whether a proposed next action still matches the user's intent. The runtime can restrict what reaches the model, but it cannot inspect or correct the model's internal plan. That is why intent flow subversion and context over-sharing sit above the gateway. These risks need controls that can compare user goal, current plan, and proposed action, which is a different problem from container or proxy enforcement.

Practical implication: Add agent-layer controls where the failure is about intent or context, because those risks are structurally invisible to the runtime alone.

Threat narrative

Attacker objective: The attacker wants the agent to take a destructive or exfiltrating action while appearing to follow a legitimate user request.

1. Entry occurs when malicious content or poisoned tool definitions reach the MCP environment through a server, registry entry, or retrieved context.
2. Credential or policy abuse follows when the runtime allows the request to proceed under the wrong scope or with over-shared context.
3. Impact happens when the model executes a harmful tool call, leaks sensitive data, or acts on subverted intent despite the runtime boundary.

Breaches seen in the wild

• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

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 a control-plane mapping problem, not a checklist problem. The article is strongest when it stops treating the OWASP MCP Top 10 as ten equal features and instead groups them by where enforcement actually lives. That framing is more useful for IAM, platform, and AI security teams because it separates execution controls from identity controls and from model-intent controls. Practitioners should evaluate every MCP risk by asking which plane can truly enforce it.

Runtime control is necessary, but it is only one layer of the trust model. MCP servers can be isolated, logged, and policy-guarded, but that still does not mean the agent's next action is aligned with the user's request. The runtime can narrow blast radius and harden transport, yet it cannot reason about intent flow or manage model context. Teams should stop claiming full coverage when the control only exists below the decision point.

Tool poisoning exposes a governance gap that looks like supply chain risk but behaves like trust-boundary drift. The article shows that tool manifests, descriptions, and schemas are part of the security contract, not just metadata. That makes MCP tooling a lifecycle problem as much as a runtime problem because definitions can change between registry vetting and session use. Practitioners should treat signed tool definitions and session-time verification as the real unresolved issue.

Shadow MCP servers belong in the same conversation as shadow IT and unsanctioned APIs. A runtime can provide a sanctioned path and better governance over approved endpoints, but it cannot scan the environment for every undeclared server someone spins up. That boundary matters because discoverability is a separate control from execution. Security teams should align MCP governance with broader discovery and inventory disciplines rather than assuming the runtime inventory is complete.

Agent-layer intent and context controls are the decisive gap in MCP security. This is the named concept that matters most: the runtime governance gap. Once the model begins reasoning, the gateway no longer owns the most dangerous part of the decision chain, so teams must design their programme around that boundary instead of pretending it does not exist. The implication is straightforward: runtime maturity does not equal agent governance maturity.

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

Runtime governance gap: MCP programmes should be designed around the boundary between what a gateway can enforce and what only the agent or model can decide. That distinction determines whether the control is containment or true governance, and it should shape architecture reviews from the start.

MCP security programmes should also separate inventory, authorization, and intent validation into different workstreams. A single control layer cannot credibly solve secret handling, shadow deployment discovery, and context safety at once, so practitioners should measure maturity by plane coverage rather than by feature count.

For practitioners

• Map each MCP risk to its owning control plane Classify every OWASP MCP Top 10 item as runtime, identity and policy, or agent and model before choosing controls. This prevents teams from buying gateway features for problems that can only be solved in the model layer.
• Centralise authorization at the proxy Use a single policy decision point for per-request access checks, then propagate user identity through backend calls so each tool invocation carries scoped authorization rather than shared service credentials.
• Verify tool definitions at session start Pin tool schemas and descriptions, then compare them at connection time so a changed manifest cannot silently alter tool behaviour between registry review and execution.
• Separate execution hardening from intent validation Contain the tool process with container, network, and filesystem restrictions, but add a distinct agent-layer validator for proposed actions because the runtime cannot compare intent with the current plan.
• Inventory unsanctioned MCP endpoints Extend discovery beyond the runtime so development clusters, sidecar deployments, and ad hoc servers are visible to the governance team before they become shadow MCP servers.

Key takeaways

• MCP runtime controls are essential, but they only govern the execution and policy planes, not the model's reasoning layer.
• The biggest governance mistake is assuming a gateway can substitute for intent validation or context management.
• A defensible MCP programme maps each risk to the control plane that can actually enforce it.

Key terms

• MCP runtime: An MCP runtime is the execution environment that hosts and manages Model Context Protocol interactions between an AI agent and external tools or data sources. It handles session state, message exchange, permissions, and tool invocation, while enforcing protocol rules so the agent can request context and actions in a controlled, auditable way.
• Control Plane: The control plane is the set of actions that create, configure, or manage a service. For AI workloads, it covers deployment and administration of the model platform, while data-plane permissions govern what the service and its identities can read or process.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• 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.

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 building or maturing an identity security programme, it is worth exploring.