What Recent Agentic Security Developments Actually Show
The most instructive recent development in agentic AI security is not a single breach but a protocol correction. The Model Context Protocol (MCP), the open specification originally published by Anthropic for connecting AI applications to external tools and data sources, has been revised to add a formal authorization framework built on OAuth 2.1 patterns. That revision matters because it implicitly confirms that earlier versions of the protocol did not fully specify authentication and authorization. A protocol used to grant AI agents access to real tools and real data was, for a period, operating without a complete answer to the question of who is allowed to call what.
This is consistent with risk categories that OWASP has already catalogued for LLM and agentic applications: excessive agency, insecure plugin or tool design, and improper output handling sit at the top of that taxonomy. NIST's AI Risk Management Framework similarly treats third-party tool and data integration as a distinct governance concern under its Govern, Map, Measure, and Manage functions. None of this is new theory. What is new is that the industry's own protocol evolution is now confirming, in practice, the gaps these frameworks warned about.
The Structural Gap: Model-Level Controls Do Not Govern the Execution Layer
Tool-calling architectures introduce a trust boundary that most enterprise AI security programs were not built to handle: the line between the model's reasoning layer and the execution layer where tool calls actually happen. Prompt filtering and output moderation operate on what the model says. They do not govern what the model is authorized to do once it decides to call a tool.
MCP's client-host-server design compounds this. The AI application (host), the protocol client, and the external tool or data server are separate components, often built and operated by different parties. Authorization decisions can occur at multiple points, and there is no guarantee those points enforce permissions consistently across every connected server in an enterprise's environment.
Chained tool calls make this worse. A single over-permissioned or unvalidated call can be used to reach systems well outside the original task's scope, and the risk compounds across a session rather than resetting with each request. Static, request-time authorization checks were designed for single transactions, not multi-step agent workflows where context and privilege can accumulate silently.
Key structural observation: Prompt filtering and output moderation operate on what the model says. They do not constrain what the model is authorized to do once it has been granted tool access. These are two different control surfaces requiring two different governance mechanisms.
Where Runtime Governance Fits Between Agent and Tool
Addressing the structural gap requires four specific controls, each targeting a distinct failure mode in the execution layer.
| Control | What It Addresses |
|---|---|
| Agent Identity | A distinct, revocable machine identity for every agent, separate from any human user credential. Without it, tool access cannot be attributed, audited, or revoked per agent. |
| Least Privilege | Scoped, per-tool tokens instead of broad session-level credentials. This limits the blast radius when an agent is compromised or misbehaves. |
| Tool-Call Governance | A policy enforcement point that evaluates each call against context, not just model instructions. This is the control that actually runs at the execution boundary. |
| Audit Logging | A verifiable record of tool calls across the full lifespan of a session, not only individual requests. Multi-step sessions require session-scoped traceability. |
Runtime Controls Required to Close the Gap
Translating these structural gaps into enforceable controls means moving governance from documentation into the runtime path between agent and tool. The following capabilities are needed to do that.
- Issue a distinct machine identity to each agent, scoped to its deployment context and revocable independently of user credentials.
- Enforce least-privilege token scoping at the level of individual tool calls, not at the session or application level.
- Place a policy enforcement point in the execution path between the agent runtime and the tool server, so authorization decisions happen continuously rather than only at session initiation.
- Maintain a session-level audit log that captures the full sequence of tool calls, the permissions evaluated, and the outcomes, not just individual request records.
- Support revocation of tool access in real time, so a compromised or misbehaving agent can be constrained without requiring a full system restart or redeployment.
Existing Governance Frameworks Already Point Here
Enterprises are not starting from zero. CISA and international partners have published guidance identifying secure design, secure deployment, and secure operation and maintenance as distinct stages of AI system governance, explicitly including how third-party components are handled. NIST's SP 800-218A extends secure software development practices to generative AI systems, with specific recommendations on provenance and access control for integrated components.
The gap for most organizations is not a lack of framework language. It is that these principles were written at a policy and process level, and have not yet been operationalized as enforcement mechanisms that run continuously against live agent behavior. A governance document that describes least privilege is not the same as a runtime system that actually issues, scopes, and revokes tool-level tokens as agents operate.
Operationalization gap: Most enterprise AI governance programs can point to a policy that requires least-privilege access for AI agents. Far fewer can demonstrate a runtime mechanism that actually enforces that policy call-by-call in a live deployment.
Evaluation Criteria for Enterprise Runtime Governance
When assessing whether a runtime governance capability is sufficient for enterprise agentic deployments, the following questions are a reasonable starting framework.
- Does each deployed agent hold its own machine identity, or does it share credentials with other agents or human users?
- Are tool-call permissions scoped to the minimum required for each specific task, or are they granted at the session or application level?
- Is there a policy enforcement point in the actual execution path between agent and tool, or does enforcement rely solely on model instructions or developer configuration?
- Does the audit record capture the full sequence of calls within a multi-step session, including intermediate steps that do not produce final outputs?
- Can tool access be revoked per agent in real time without a system restart or redeployment?
- Are authorization decisions consistent across all connected tool servers, or can individual servers be reached through a less-governed path?
Tradeoffs to Weigh Before Implementation
Runtime governance for agents is not free of tradeoffs. Scoping permissions tightly per tool and per task adds configuration overhead and can introduce latency if enforcement checks are poorly implemented. Overly granular controls can also create friction that pushes teams toward workarounds, which undermines the governance intent entirely.
The opposite failure mode is more common and more dangerous: treating a written policy or a model-level system prompt as sufficient control. Neither constrains what happens once an agent actually issues a tool call. The practical goal is enforcement that is granular enough to limit blast radius, but implemented at the runtime layer so it does not depend on the agent, or a developer's configuration discipline, to hold consistently over time.
Frequently Asked Questions
Why does MCP's authorization revision matter for enterprise governance?
The revision to add OAuth 2.1-based authorization to the Model Context Protocol confirms, at the protocol specification level, that earlier versions left authentication and authorization incompletely defined. For enterprises relying on MCP-connected agents, this means any deployment built on earlier protocol versions should be reviewed for whether authorization was handled consistently at the application layer, since the protocol itself did not mandate it.
What is the difference between model-level safety and runtime governance?
Model-level safety controls, such as prompt filtering, output moderation, and system prompts, operate on the content of what a model generates. Runtime governance controls operate on what an agent is permitted to do in its execution environment: which tools it can call, what data it can access, and under what conditions those permissions hold. The two are complementary but not substitutable. A well-prompted agent that holds overly broad tool permissions is still a governance risk.
Does this apply to agents built on frameworks other than MCP?
Yes. The structural gap described here, between a model's reasoning layer and the execution layer where tool calls happen, is not specific to MCP. It applies to any architecture where an AI agent can invoke external tools, APIs, or data sources. MCP is instructive because its protocol revision made the gap explicit at a specification level, but the same concern applies to proprietary tool-calling implementations, function-calling APIs, and multi-agent orchestration frameworks.
How do multi-step sessions change the risk profile compared to single-request interactions?
In single-request interactions, each call is independent and the authorization state resets. In multi-step agent sessions, permissions and context can accumulate. An agent might acquire access to a resource in step two that was not contemplated when permissions were assigned at session start, then use that access in step seven to reach a system outside the original task scope. Session-level audit logging and enforcement that re-evaluates permissions at each tool call, rather than only at session initiation, are required to manage this compounding risk.
What is the relationship between agent identity and existing IAM systems?
Machine identities for AI agents should integrate with, not bypass, an organization's existing identity and access management infrastructure. The key requirement is that each agent holds its own identity, separate from human user credentials and from other agents, so that access can be attributed, audited, and revoked at the agent level. How that identity is issued and managed will depend on the organization's existing IAM capabilities, but the agent identity layer should not be treated as a parallel system that operates outside normal access governance processes.