MCP Isn't Broken. It's Missing a Control Plane.

The recent OX Security research on MCP-related risks has rightly drawn industry attention. Agents can be manipulated into invoking tools or executing actions in ways their operators did not anticipate. The conversation that followed has focused on vulnerabilities, developer hygiene, and supply chain integrity.

Those concerns are real. They are also incomplete.

The deeper lesson is architectural. AI agents are being given connectivity and capability without a runtime layer that consistently decides whether a specific action should proceed. The real problem is not just that agents can act. It is that nothing in the execution path is consistently deciding whether they should.

That is not a bug to patch. It is a missing layer to build.

What MCP Does

The Model Context Protocol is a useful and important standard. It gives AI agents a consistent way to discover and invoke tools, services, and resources. It improves interoperability across agent frameworks. It accelerates developer velocity. It reduces the friction of connecting an agent to the systems it needs to do useful work.

These are legitimate benefits. MCP solves a real problem in agent enablement.

But MCP is, by design, an enablement protocol. It standardizes how agents and tools communicate. It does not standardize whether a particular communication should occur. Connectivity is not control. Standardization is not runtime governance. A protocol that lets an agent invoke any registered tool does not, on its own, decide which tool invocations are appropriate in a given context.

This is not a flaw in MCP. It is a property of what MCP is. The same observation would apply to HTTP. The protocol does its job. Something else has to decide which calls are permitted.

What IAM Does

Identity and access management remains foundational. OAuth issues scoped tokens. OIDC handles authentication. SCIM manages lifecycle. SPIFFE/SPIRE provides workload identity in containerized environments. These standards are not optional, and nothing about the MCP conversation suggests they should be replaced.

What IAM does well is establish identity and baseline authority. It answers two questions reliably: who is this agent, and what has it been granted permission to access in general?

What IAM was not designed to answer is the question that AI agents introduce: should this authenticated, properly tokenized agent perform this specific action right now, in this context, for this goal, with these parameters, under this delegation chain?

That is not a pure identity question. It is a runtime decision question. And it is the question that determines whether an agent's action is appropriate in the moment, regardless of whether the agent's credentials are valid in the abstract.

The Architectural Gap

Consider the typical execution path for an agent action:

User input → agent reasoning → tool invocation via MCP → system action

Each link in this chain can be working exactly as designed. The user input is legitimate. The agent's reasoning produces a coherent plan. MCP correctly invokes the tool with valid parameters. The downstream system accepts the call from a properly authenticated agent. The protocol is sound. The token is valid. The tool is registered. And the outcome can still be unsafe.

This is the heart of the issue. The OX Security research is one example of a broader pattern: an agent's actions can be technically permitted at every layer and still be substantively wrong in context. The tool was valid. The agent had access. The protocol worked. But nothing in the path asked whether the action was appropriate for this agent, this task, this delegation chain, this moment.

Possible is not the same as permissible. Executable is not the same as governable.

The diagram makes the distinction concrete. In the top flow, every component works as designed and the outcome can still be unsafe. In the bottom flow, an explicit decision layer evaluates intent, delegation, policy, and human-approval requirements before the tool is invoked. Both flows depend on IAM for identity. Only one of them governs the action.

This Is a Decision Problem

AI agent security is increasingly a decision problem, not just an identity problem.

The questions that need to be answered at runtime, on every action, are the questions that traditional infrastructure was not designed to answer:

• Should this agent call this tool right now?
• Should it use these exact parameters?
• Should it continue execution after discovering something unexpected during the task?
• Should it act on behalf of another agent or user through a multi-hop delegation chain?
• Should this action require human approval before it proceeds?

None of these are questions about identity. They are questions about behavior in context. And they cannot be answered statically at deployment time, because the agent's plan, the parameters of its tool calls, the delegation chain it is operating under, and the contextual risk of any given action are all determined at runtime by a model whose reasoning is not visible to the systems trying to govern it.

The MCP-related risks getting attention are one symptom. The underlying condition is that the execution path lacks a runtime decision layer.

What Is Missing

Building this decision layer requires a specific set of architectural capabilities. Each one is necessary; none of them are addressed by either MCP or traditional IAM in isolation.

A runtime policy evaluation engine that assesses every action against formal policy at the moment of execution. An authorization model that incorporates the agent's declared intent for the current task, not just its abstract permissions. Delegation-aware enforcement that maintains and validates the chain of authority across agent boundaries. Scoped credential handling so agents do not hold raw secrets and authority is bound to specific tasks. Human-in-the-loop checkpoints that escalate consequential actions dynamically based on the action itself, not on static configuration. Execution lineage that records every action with its full governance context, supporting both real-time intervention and after-the-fact reconstruction. Continuous evaluation that re-checks authority as the agent progresses through its plan, because mid-execution discoveries change the risk profile.

These are not product features. They are architectural requirements for the safe production deployment of AI agents that use tools, take actions, and operate with any meaningful authority.

Where Agent Runtime Governance Fits

Agent Runtime Governance is the layer that provides these capabilities. It is not a replacement for IAM. It is not another identity silo. It is not a rejection of MCP. It is a runtime control layer that sits between enterprise identity systems and the agent execution environment, including the tool invocations that flow through MCP.

The relationship is compositional. IAM establishes who the agent is and what it has been granted in the abstract. MCP standardizes how the agent reaches tools and services. ARG evaluates whether a specific action, invoked through any protocol, against any tool, should proceed in the current context.

This becomes essential as soon as agents do anything beyond a single, predictable action. When agents chain actions, use tools dynamically, adapt their plans based on intermediate results, or operate with authority delegated through other agents, the only way to know whether any given action is appropriate is to evaluate it at runtime, with full context, before it executes.

The MCP risks being discussed are an early indicator of a category of problems that will become more visible as agent adoption deepens. The fix is not to harden MCP further. MCP is not the failure point. The fix is to introduce the missing layer.

What This Means for Enterprises

Enterprises adopting AI agents do not just need authenticated agents and connected tools. They need governable agents.

The protocols and standards that enable AI agents to do useful work are necessary and valuable. They are also not sufficient on their own. Production AI deployments require an explicit runtime governance layer that determines whether agent actions should proceed, in real time, with full context, before they execute.

The most important question is no longer only who the agent is. It is whether the agent should be doing this right now.

That question is not answered by a protocol or an identity system. It is answered by a control plane.

---

If your team is evaluating how to govern AI agents in production, we would welcome the conversation. We are also actively working with Founding Design Partners on these architectural patterns.

Need to design the runtime governance layer for your AI agent infrastructure? Our Agent Authorization & Runtime Control Architecture engagement helps enterprise teams design the control plane that fits between IAM, MCP, and the agent execution environment. Download the one-pager (PDF) or discuss an engagement.