MCP runtimes solve three planes, not ten separate controls

At a glance

What this is: This is a Stacklok analysis of how MCP runtime controls map to the OWASP MCP Top 10, with the key finding that runtimes can fully govern identity, audit, and many supply-chain risks but cannot replace agent-layer controls.

Why it matters: It matters because IAM and security teams evaluating MCP need to separate runtime-enforceable NHI controls from agent-context risks that sit outside the gateway and require different governance.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Stacklok's analysis of how MCP runtimes map to the OWASP Top 10

Context

MCP runtime governance is the problem of deciding which risks can be controlled at the server, proxy, and identity layers, and which risks live in the model's reasoning context. Stacklok's core point is that the OWASP MCP Top 10 is being oversimplified when teams treat it as ten equal controls instead of three different planes of responsibility.

That distinction matters for MCP deployments because the runtime can own secrets, policy, telemetry, and much of the supply chain, but it cannot inspect or correct the model's intent window. For identity teams, the important question is not whether an MCP stack is modern enough, but whether the governance model matches the layer where the control actually operates.

The article is a practical framework for evaluating MCP runtimes, and that starting position is typical of real deployments: most organisations can govern the gateway layer sooner than they can govern the agent layer.

Key questions

Q: How should security teams evaluate MCP runtimes against the OWASP Top 10?

A: They should evaluate runtimes by control plane, not by checklist coverage. Ask which OWASP items are handled in the runtime and identity layers, which ones depend on the agent layer, and whether the product can prove per-request authorization, short-lived token handling, auditability, and session-level trust in tool definitions.

Q: Why do MCP runtimes not solve every OWASP MCP risk?

A: Because some risks live in the model's reasoning and context window, not in the gateway. A runtime can constrain secrets, policy, and execution blast radius, but it cannot fully validate intent flow or manage what the model has already absorbed into memory.

Q: What breaks when MCP security is treated as a single control layer?

A: Teams overestimate runtime coverage and miss the risks that sit above it. That usually leads to weak assumptions about intent validation, context leakage, and shadow endpoints, while the real control gaps remain unowned across identity, platform, and agent operations.

Q: Who should own governance for shadow MCP servers and tool trust?

A: Platform security, identity governance, and application owners all have a role, but no single team can own it alone. Discovery belongs with exposure management, authorization belongs with identity, and tool-definition trust belongs with the MCP runtime or agent framework.

Technical breakdown

MCP runtime, identity, and agent planes

An MCP deployment splits cleanly into three layers. The runtime or network plane controls where servers run, what reaches them, and how secrets and traffic are handled. The identity and policy plane decides which user or service account can call which tool, under what authorization rules, and with what audit trail. The agent or model plane is where the model reasons, plans, and consumes context. A runtime can constrain the first two planes directly, but it cannot validate the model's internal intent or rewrite what the model has already absorbed into context. That is why the OWASP MCP Top 10 contains controls that sit in different places in the stack.

Practical implication: Evaluate MCP products by control plane and reject claims that a gateway alone can govern model intent or context.

Secret handling and token exchange in MCP runtimes

MCP token mismanagement is really a lifecycle problem for non-human identities. Secrets may live in configs, environment variables, logs, or shared service accounts, and the runtime's job is to shrink their exposure window. Short-lived token exchange, encrypted secret storage, runtime injection, and log sanitization all reduce the chance that an MCP server becomes a secret reservoir. But the important design point is that the runtime is only the execution boundary. If the broader identity system still relies on long-lived credentials or shared accounts, the runtime can hide them from view but cannot make them governable.

Practical implication: Tie MCP runtime evaluation to credential lifecycle, token exchange, and secret exposure controls, not just encryption at rest.

Why tool poisoning is different from command injection

Tool poisoning and command injection are related but not identical. Command injection is a code-path failure inside a tool implementation, such as passing untrusted input into a shell. Tool poisoning is a contract failure, where the tool definition, schema, or description is altered so a benign operation becomes something harmful. A runtime can sandbox the consequences of a compromised tool and constrain egress, but it cannot by itself prove that the tool definition is trustworthy at session start. That is why signed manifests, schema pinning, and provenance checks are becoming central to the MCP conversation.

Practical implication: Ask whether the runtime verifies tool definitions at connection time, not only whether it sandboxes execution.

NHI Mgmt Group analysis

MCP governance is really a three-plane identity problem, not a ten-control checklist. The runtime plane, identity plane, and agent plane each absorb different risks, and only the first two are fully reachable from an MCP gateway. That means teams that buy for "MCP security" without mapping the plane of control will overestimate coverage and underfund the missing layer. The practical conclusion is that architecture must start with control-plane ownership, not feature counting.

Runtime controls solve the secret and audit problem, but only if the organisation has already abandoned shared-credential thinking. MCP token handling, traceability, and per-request policy enforcement are strong only when they are built around short-lived user-scoped access instead of durable service accounts. The hidden governance issue is not just leakage, but persistence of trust in credentials that were never meant to survive beyond the task. Practitioners should treat MCP as an NHI lifecycle design exercise, not a point product checklist.

Tool poisoning is the named concept that matters most here because it exposes the trust boundary between registry and session. A tool can be authorised, packaged, and audited yet still behave differently if its schema or description is not pinned and verified at the moment of use. That makes MCP governance more like software supply-chain trust than simple authorization. The implication is that the field needs session-level trust in tool definitions, not just runtime containment after the fact.

Intent flow subversion and context over-sharing are above-gateway problems, which means runtime vendors cannot claim complete coverage. These risks depend on the model's current plan, user goal, and working memory, none of which the gateway fully owns. That does not make the runtime irrelevant, but it does make its limits explicit. Security teams should stop asking whether a runtime "covers" these risks and start asking what companion controls govern the agent layer.

Shadow MCP governance will become a discovery problem as much as a policy problem. A sanctioned registry and a managed proxy reduce exposed endpoints, but they do not discover developer-run servers or ad hoc clusters on their own. That makes MCP an overlap zone for identity, platform, and exposure management teams. The practical conclusion is that runtime governance must be paired with discovery and inventory discipline, or shadow servers will remain outside policy.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of Secrets Sprawl 2026.
• Hardcoded secrets and configuration-file exposure remain persistent entry points, and 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone.
• For a broader NHI lifecycle lens, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for provisioning, rotation, and offboarding controls.

What this signals

Tool poisoning: the next governance fight in MCP will be about proving that a tool definition has not drifted between approval and session start. That pushes teams toward signed manifests, schema pinning, and stronger provenance checks in the same way software supply-chain controls matured for containers and packages.

The practical signal for IAM and NHI programmes is that runtime authorization alone will not contain agent-context risk. If your governance model still assumes a stable credential, a stable tool contract, and a stable agent plan, MCP deployments will expose where those assumptions collapse.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, according to The State of Secrets Sprawl 2026, secret exposure remains a scaling problem, not a niche hygiene issue. The implication for MCP is that every new runtime becomes another place where lifecycle discipline has to be enforced rather than assumed.

For practitioners

• Map every MCP control to its owning plane Separate runtime, identity, and agent-layer controls before buying or deploying any MCP runtime. If a control depends on model intent, context memory, or tool plan evaluation, treat it as outside the gateway boundary and assign a different owner.
• Replace shared credentials with user-scoped token exchange Use short-lived per-user tokens for backend calls and remove long-lived shared service accounts wherever possible. Pair that with secret storage that never writes decrypted material to disk and with audit logs that can preserve identity without exposing credentials.
• Require tool-definition trust at session start Ask vendors how they pin tool schemas, verify manifests, and detect description drift when a client connects. This is the control gap behind tool poisoning, and it should be tested explicitly rather than assumed from container isolation alone.
• Test MCP sandboxing against real command-injection paths Validate container isolation, filesystem allowlists, and egress restrictions using a tool implementation that tries to call a shell unsafely. If the runtime only logs the event but does not contain the blast radius, the deployment is not ready for production.
• Inventory sanctioned and unsanctioned MCP endpoints Treat shadow MCP servers as an exposure-management issue, not only a policy issue. Build discovery into your platform and cloud governance process, and keep the registry as the sanctioned path rather than the only detection mechanism.

Key takeaways

• MCP security is a control-plane problem, not a ten-item checklist.
• Runtime gateways can govern secrets, policy, audit, and containment, but they cannot replace agent-layer intent and context controls.
• Tool poisoning and shadow MCP servers show why session trust, discovery, and provenance now matter as much as authorization.

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.
• 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.
• 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.

What's in the full article

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

• How ToolHive maps individual OWASP MCP items to runtime, identity, and agent-layer controls in practice
• The specific container, registry, and policy mechanisms used to constrain malicious or misconfigured MCP servers
• Stacklok's detailed guidance on MCP03 tool poisoning, including signed-manifest and schema-pinning questions
• The exact audit, telemetry, and token-handling patterns used to reduce secret exposure in real deployments

👉 The full Stacklok post breaks down the runtime boundary, the agent-layer gaps, and the tool-poisoning questions to ask vendors.

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.