Runtime Governance: The Missing Layer for Agent Access

1Agent Identity Is Not Enough

In December 2025, an AWS engineer asked Amazon's Kiro agent to fix a bug in AWS Cost Explorer. The agent decided the cleanest path was to delete the production environment and rebuild it from scratch. It did. AWS Cost Explorer went down for thirteen hours.^[1]

The agent had not broken in. A human operator had granted it their own access level, which turned out to be broader than anyone realized. Amazon's two-person approval process did not apply to AI agents in practice. Nothing evaluated the deletion before it happened. Amazon's post-mortem called it "misconfigured access controls, not AI." Both things are true. And both miss the bigger point: when controls are misconfigured, nothing catches it at runtime. The agent does what its permissions allow, at machine speed, with no second pair of eyes.

This pattern is not specific to Kiro. Every AI agent inherits the permissions of the human who delegates to it. Those permissions are wide at setup and accumulate over time. In The New Frontier in Identity Security: AI Agent Access, we laid out why that is the default shape of agent access today.

The industry has been responding. Over the past year, five protocols have emerged to give agents a place in enterprise identity. Four enforcement architectures have emerged above them. Stopping the next Kiro needs more than identity. It needs a decision on every tool call before it happens, traceable back to the human who delegated.

1.1The five protocols aimed at agent identity

Model Context Protocol (MCP) gives agents a universal way to call tools. A tool is a single, named action an agent can take, like send_email, query_database or delete_file. An app (GitHub, Slack, Salesforce) exposes its capabilities as tools through an MCP server. One app, many tools. MCP defines how the call travels, but not who may make it or under what conditions.

Five efforts now address that gap. They come from different parts of the stack: two standards bodies (IETF, OWASP), one protocol author (Google) and one identity vendor (Okta).

1. A2A, the Agent-to-Agent protocol (Google → Linux Foundation). Google describes A2A as “designed to support enterprise-grade authentication and authorization, with parity to OpenAPI's authentication schemes.”^[2] In practice, A2A lets one agent delegate a task to another. The requesting agent reads the target's Agent Card, a JSON file listing what the target can do. It then sends the work as a structured task object. The target processes the task and updates its state as it goes: submitted on arrival, working during processing, auth-required when an action needs permission. At this point execution pauses. Because A2A specifies no authorizer, the protocol marks the pause without defining who should answer it.

2. IETF Agent Auth (AWS, Zscaler, Ping Identity). A resource server is the app or service an agent is trying to reach. This draft defines how an agent identifies itself to that server when acting on a user's behalf. Standard OAuth issues a token that names only the user. This draft binds two identities into the same token: the agent goes into the client_id claim and the delegating user into the sub claim. A resource server reads both and authorizes the request against the pair, not the user alone. To do this, the draft composes existing standards rather than inventing new ones. Its authors acknowledge the limit: “additional specification or design work may be needed to define how out-of-band interactions with the User occur at different stages of execution.”^[3] The framework binds the agent's identity at token issuance but defers the runtime authorization question to future specifications.

3. AAuth (IETF Draft). AAuth extends OAuth 2.1 with a reason parameter. The specification defines it as a “concise, human-readable explanation provided by the agent.”^[4] The authorization server must echo this reason verbatim and display it to the user. It does not verify that the reason is accurate, proportionate or consistent with policy. Any claim passes. Once the token is issued, AAuth has no further role. It grants access once, at the start of a session. What the agent does with that access is not governed by the framework. AAuth addresses transparency at first access. It does not address control during execution.

4. SCIM Agent Extension (Okta). SCIM is an existing standard for provisioning and managing user accounts across enterprise systems. Okta's IETF draft extends it with two new resource types, Agent and AgenticApplication, that register AI agents as directory objects alongside human users. An agent with a SCIM entry has an official identity in the system: a name, an ID, a lifecycle that can be managed and revoked. The extension is designed as complementary infrastructure, “intended to provide greater interoperability… while reducing the responsibilities assumed by… new protocols for agents.”^[5] It manages whether an agent exists, but not what the agent does at runtime.

5. OWASP ANS. OWASP describes the Agent Name Service as “a framework for secure discovery and registration of AI agents in multi-agent systems.”^[6] ANS functions like DNS for agents: an agent registers by publishing an Agent Card that contains its name, capabilities and endpoint. Other systems query the registry to confirm the agent exists and is who it claims to be. The framework resolves the question of identity. It does not resolve the question of authorization. A verified agent is not a permitted agent.

All five efforts address questions that arise before an agent acts: is it real, can it prove its identity, is it registered. These are prerequisites for execution, not constraints on it. Once resolved, the agent holds a valid identity, proven credentials and a place in the directory. Nothing in that stack evaluates what happens next.

The missing question is runtime governance: should this agent perform this specific action right now, given the data it has already accessed and the tools it has already called? "Who" and "how" have answers. "Should" is still the missing question.

2Four Architectures for Runtime Governance

The moment before Kiro executed the delete: the agent has the request formed, the token ready, the production environment in reach. Identity is confirmed. Intent is generated. Every Section 1 protocol has done its job. What is missing is the single decision in between: should this specific action go through, or not? That decision has to sit somewhere in the stack, and where it sits is constrained by what the security team actually controls.

Three things determine the options. Does the team run the infrastructure the agent executes on, or is it a cloud service like ChatGPT, Claude or Microsoft Copilot? Does the agent platform expose hooks the team can instrument? Does the downstream app accept external policy enforcement? Different answers rule out different architectures.

The market has converged on four enforcement architectures. Each places a checkpoint at a different layer: in the network, inside the agent's runtime, at the operating system or inside the downstream app. The Autonomous Action Runtime Management specification (arXiv, February 2026)^[7] formalizes the same four patterns. Here is what each one does, where it sits and what it trades away:

2.1Protocol gateway

A protocol gateway places the enforcement boundary in the network, between the agent and the tools it connects to. When an agent is about to send an email, query a database or delete a file, the request passes through the gateway first. The gateway intercepts every tool call, checks it against policy and decides: allow, deny, escalate to a human or wait for more context. Because the gateway speaks the same protocol the agent already uses (MCP, A2A or any standard protocol), nothing changes on either side. The agent does not know the gateway is there. The downstream app does not know either.

The gateway remembers everything the agent has done in a session: which tools it called, what data it accessed, what parameters it used and what the tools returned. The gateway evaluates each new action against the entire chain, not in isolation. An agent with permission to query a customer database and permission to send emails can do both individually. But if it reads customer records and then sends an email to an external address, a protocol gateway recognizes the composition attack: data exfiltration. The composition violates policy in a way that neither action reveals on its own.

The tradeoff is visibility at the boundary. The gateway sees every action that passes through the protocol. It cannot see the agent's internal reasoning, its memory or actions that bypass the protocol (local file reads, shell commands, in-memory operations). It controls the border between the agent and its tools, not what happens inside the agent.

2.2SDK instrumentation

SDK Instrumentation places governance checkpoints inside the agent's own runtime. Before the agent reads a customer record, a hook (an extension point the platform exposes) fires inside the runtime. The SDK checks it against policy and records what happened. Because it operates inside the agent, it has the deepest visibility of any architecture. It sees the original user request, the reasoning chain, prior actions in the session and what data the agent has already accessed.

The limitation: every agent framework needs its own integration. There is no universal SDK. If you run five different agent frameworks, you need five separate integrations. And because the SDK runs inside the same program as the agent, it can be bypassed. A compromised agent can call tools directly without passing through the hooks. A protocol gateway, by contrast, runs outside the agent as a separate service, and the agent has no path to its tools except through it. The SDK is only as trustworthy as the agent it governs.

2.3Kernel-level monitoring

The third architecture operates below the application, at the operating system itself. Every action an agent takes on a machine, whether it opens a network connection, writes a file or starts a process, passes through the kernel. Monitoring at this level means intercepting those system calls before they execute. The kernel can allow the call, block it or log it for review. Tools like Falco and Sysdig already do this for general security. The same approach applies to agent governance.

The tradeoff is visibility without context. The kernel knows the agent opened a network connection, but not that it was trying to delete a production database or whether the actor who triggered it had permission to do so. Kernel-level monitoring catches forbidden actions like connections to known malicious endpoints, but it cannot replace a governance layer that understands what the agent is doing and why.^[7]

2.4Vendor app integration

The fourth approach pushes enforcement into the downstream apps themselves. Each app vendor (GitHub, Slack, Salesforce) implements its own governance hooks. Before the agent calls any app, the identity provider (IdP) authenticates it and issues a scoped token. What happens after that depends entirely on what the app vendor chose to enforce. Its appeal is independence from the agent side of the chain. The approach works whether the agent runs on a cloud platform you do not control (such as ChatGPT, Claude.ai, Microsoft Copilot), inside a self-hosted runtime or anywhere in between. It does not require the agent platform to expose any instrumentation hooks. The cost is that enforcement only exists where vendors have built it.

Once the agent holds that token, the IdP has no visibility into what happens next. Okta and CyberArk are building runtime controls for this layer, but both remain limited: Okta's Agent Relay is in early access, not general availability,^[9] CyberArk's AI Agent Gateway works only within its own identity stack.^[10] Both depend on every downstream app vendor cooperating. Getting hundreds of apps to implement governance hooks takes years, not months. And even when apps cooperate, neither approach gives you per-action visibility across tools. No app-vendor approach today offers per-action governance across multiple applications.

3How Cakewalk Turns a Gateway Into Governance

Which of the four would have stopped Kiro's delete? The SDK would have needed Kiro's platform to instrument itself. The kernel would have seen the system call but not the intent. A vendor app hook only exists where the vendor has built one. Only the protocol gateway needs nothing new from either side. It is the one position every tool call has to pass through and no agent can route around. That is where Cakewalk runs.

The tradeoff is visibility. The gateway sees every action the agent tries to take against the outside world, but not the internal reasoning. That is the surface that matters when something goes wrong. Governance has to run at machine speed, or it becomes the bottleneck that defeats the point of agent delegation. The gateway evaluates each action against policy deterministically, matching rules rather than asking the model. Every decision is auditable and reproducible before the action executes.

A gateway by itself is a checkpoint, not governance. What turns a checkpoint into governance is the context around every decision it makes.

3.1The gateway inherits its context from the identity platform

An MCP gateway sits between an agent and the tools it calls. On each call, it sees two things: the name of the tool being invoked and an allowlist configured at setup. That catches the obvious: tools not on the allowlist, MCP servers the organization never approved. It misses what makes an action safe or unsafe. That takes three inputs: the kind of action, the human behind the agent and the system the agent is calling.

Cakewalk's gateway evaluates all three on every call: the action, the user behind the agent and the target app. Actions are Read, Write, Destructive or External. The user brings department, seniority and role, pulled automatically from HR systems or IdPs. Target apps carry risk level, data classification and category. A read from the CFO on an internal document runs clean. The same call from a contractor on a customer-data app escalates. The same tool triggers a different decision.

The same logic extends beyond your own org. When a customer's data processing agreement names the employees who may touch their data, the gateway needs to know who is asking, not what is being asked.

All of this requires an identity governance platform underneath: users, roles, departments, app risk classifications, permission models, approval workflows and audit infrastructure. Cakewalk already operates that platform. A gateway without an identity platform underneath would need to build it.

3.2The agent's context grows as the task unfolds

Most gateways give an agent a fixed set of tools at setup time. The agent's knowledge boundary is decided before the task begins and does not move. This is static agent context. It is the default model in MCP gateways, agent SDKs and vendor app integrations. If the task needs a tool the agent was not configured for, the task either fails or completes with degraded output.

Cakewalk inverts that default. Every agent starts each task with no context at all. As the task progresses, every approved access request expands the agent's working context by one tool. Cakewalk calls this Dynamic Agent Context.

Two boundaries hold the model together. The outer boundary is the total information surface of your company: every app, every dataset, every tool your org runs. It is the ceiling of what any agent could act on. The inner boundary is your agent's Dynamic Agent Context: what it currently knows about and can act on. It starts at zero on every task, grows one tool at a time and collapses back to zero when the task ends. The outer boundary does not move.

Each expansion follows a different path depending on how far the tool is from the agent's current reach. A tool the agent already holds credentials for requires only a policy check. If the user can access a tool but the agent cannot yet, the user authenticates. A tool the user does not have access to triggers a full request through the company's approval chain. On approval, Cakewalk's provisioning agent handles the rest: account created, permissions assigned, agent connected. Just-in-time provisioning at runtime, not a ticket in an IT queue.

3.3The gateway evaluates every action against policy

What decides each expansion? A product manager asks their agent to analyze customer churn. The first time the agent reaches for a CRM tool, the call passes through the gateway. The gateway evaluates the call against the user, the action and the target app. The engine returns one of three outcomes. Escalate if the data is classified as sensitive. Deny if it violates policy. Approve if the user has CRM access and the action is a read.

Escalations trigger a pattern Cakewalk calls Suspend-and-Resume. The gateway holds the connection while a different human reviews the request: a manager, a security admin, an app owner. Not the user who initiated the task. To the agent, this looks like a slow tool call. Denials return a structured response so the agent can adapt or surface the reason to the user. Every decision is captured in the Decision Trace.

If approved, the gateway reads the credential from your vault and injects it into the outbound call. The agent does not see real credentials, only a temporary reference that expires with the task. The agent's Dynamic Agent Context has grown by one tool. When the task ends, the inner boundary collapses to zero, while the outer boundary stays unchanged.

3.4Every call is auditable back to a human

Every tool call produces a Decision Trace: a structured, immutable record. It captures who delegated, which policy fired, what inputs matched, who approved, what executed and when access ended. One call, one trace.

A marketing manager asks their agent to pull campaign performance from HubSpot. The gateway intercepts the call, evaluates it against the manager's role and HubSpot's risk classification, then approves. The gateway injects the credential from the vault and the agent pulls the data. The trace lands before the call leaves.

The point is queryability. Ask “who approved this agent's access to customer data?” and the answer is a name, a policy and a timestamp. Ask “who owns this agent?” and the answer traces to the delegating user, their department and their current employment status. Log files would require parsing free text across systems. Because the trace is tied to identity, lifecycle changes propagate automatically. When an employee in your org is offboarded, their agents lose access the moment they do. Role changes adjust agent access without manual intervention.

3.5Agents hold zero standing privileges

Every tool call, every credential exchange and every policy decision passes through the gateway. A component with that much control over your security posture needs to earn trust through architecture, not promises.

The gateway is stateless. It reads credentials from your vault at the moment of each tool call and discards them when the call completes. Agents never see real tokens. Nothing is cached, nothing is stored and nothing persists beyond the action.

4Governed Agents Run Autonomously

Our previous article, The New Frontier in Identity Security: AI Agent Access, laid out the bind every security team faces. Block agents outright or allow them without controls. Companies are not stuck because they distrust agents. They are stuck because no governance layer lets them deploy agents at full speed. The first option destroys the productivity gain agents promise. The second opens risk that compounds with every tool they reach.

The third path exists. Policy-driven governance that lets agents operate autonomously with real-time evaluation at every action. Low-risk actions execute at machine speed. Sensitive actions escalate to the right human. External actions wait for the human in the loop. Destructive actions are denied outright. Access is provisioned when needed and revoked when the task completes. Every decision traces back to a human.

Governance and autonomy. Not governance or autonomy.