Runtime governance is the missing layer for agent access

At a glance

What this is: This is an analysis of why agent identity protocols are not enough and why per-action runtime governance is the missing control layer for AI agents.

Why it matters: It matters because IAM, PAM, and NHI teams have to govern delegated agent actions at execution time, not just provision identities and credentials up front.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Cakewalk's analysis of runtime governance for agent access

Context

Agent access becomes a governance problem the moment a human delegates work to software that can call tools on their behalf. In this model, the core issue is not whether the agent has an identity, but whether the enterprise can control what that identity is allowed to do at runtime. That is the primary identity security gap this article addresses.

The article argues that existing agent identity protocols solve discovery, registration, and credential binding, but they do not answer the execution question. For IAM, NHI, and PAM teams, that means the real control point sits between delegation and action, where each tool call needs a policy decision tied to the user, the agent, and the target application.

Key questions

Q: How should security teams govern AI agents that choose tools at runtime?

A: Security teams should treat runtime tool choice as a governed access event, not a normal application call. That means task-scoped credentials, explicit approval boundaries for sensitive actions, and logs that record both the tool selected and the identity used. If the agent can change its plan, the control model must be able to change with it.

Q: Why are agent identity protocols not enough on their own?

A: They solve discovery, registration, and credential binding, but they do not answer the runtime question of whether a particular action should proceed. Without that decision layer, an agent can remain fully identifiable and still perform harmful or excessive actions with valid access. The gap is execution control, not identity naming.

Q: What breaks when AI agents inherit a human's permissions without runtime checks?

A: Accountability breaks first, because the enterprise loses the point where intent, scope, and permission are evaluated together. Operational risk then rises because the agent can execute actions at machine speed using access that was never assessed for the specific task. Standing permissions become too broad for delegated autonomy.

Q: Who is accountable when a delegated agent performs the wrong tool action?

A: Accountability should rest on the decision chain, not only on the session owner. You need to know who approved the delegated action, which policy version applied, what token was bound to the child principal and what side effect occurred. Without those records, accountability becomes speculative instead of provable.

Technical breakdown

Why agent identity protocols stop short of runtime control

The article maps five identity-building efforts for agents, including A2A, IETF Agent Auth, AAuth, SCIM agent extensions, and OWASP ANS. Each one gives the agent a name, a registered presence, or a bound credential, but none of them decides whether a specific action should proceed. That matters because identity and authorization are not the same problem. An agent can be known, authenticated, and registered while still being free to misuse a permitted tool path. The missing layer is not identity issuance, but action-time authorisation.

Practical implication: teams should separate agent identity registration from per-action authorization design.

How runtime governance works across every tool call

Runtime governance in the article is a policy decision inserted before each tool call reaches the target system. The policy engine evaluates three inputs: the action itself, the human who delegated the task, and the target application. The outcome can be approve, deny, or escalate, and the audit trail records who asked, what was attempted, and why the decision was made. This is materially different from provisioning-time access control because it treats each tool invocation as a distinct authorization event rather than a standing entitlement.

Practical implication: implement decision points at the protocol path, not only in identity provisioning workflows.

Why protocol-level identity does not prevent destructive agent actions

The Kiro example shows the architectural limit clearly. The agent had legitimate access, but nothing enforced a runtime check before it executed a destructive operation. That means the failure was not identity absence, but control absence between permission and action. Protocols can prove who the agent is, yet still leave the enterprise exposed to high-impact operations if no runtime policy engine sits in the middle. In security terms, the issue is uncontrolled execution scope, not uncontrolled enrollment.

Practical implication: treat destructive actions as runtime authorization events, not as ordinary tool usage.

Threat narrative

Attacker objective: The objective is to execute harmful actions through a trusted delegated identity without a compensating control at the moment of action.

1. Entry occurs through legitimate delegation when a human gives an AI agent access to enterprise tools and data on their behalf.
2. Escalation happens when the agent inherits the human's permissions and uses them without a runtime policy check on the specific action.
3. Impact follows when the agent performs a destructive or unauthorized operation at machine speed before any human review can intervene.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime governance is the missing security layer for delegated agent access. Agent identity protocols solve naming, discovery, and credential binding, but they do not decide whether a specific action should happen. That leaves enterprises with authenticated agents that can still behave outside acceptable bounds. The practitioner conclusion is simple: identity for agents is necessary, but it is not sufficient without per-action control.

Standing permissions are the wrong mental model for agentic execution. The article shows that an agent inherits the human's access level and can exercise it immediately, at machine speed. That assumption works for conventional delegated access, but it fails when the actor can chain actions without pause. The implication is that access must be evaluated as a runtime event, not treated as a static grant.

Decision trace becomes the new audit primitive for agent oversight. The article's emphasis on who delegated, what was attempted, and why the policy fired reflects a broader shift in identity governance. For autonomous or semi-autonomous work, auditors need the full action trail rather than just entitlement snapshots. Practitioners should treat decision trace as part of identity control, not an optional logging enhancement.

Tool-call authorization should be treated as a core IAM control, not an application add-on. The article makes clear that protocol registration, directory presence, and credential binding all stop short of governing actual behaviour. That creates a runtime governance gap that IAM, PAM, and NHI programmes must own together. The conclusion is that agent access control belongs in the identity plane, where policy can see both delegation and execution.

Policy that runs before each action is the only way to preserve accountability in agentic systems. When a delegated actor can act repeatedly without human pacing, governance tied only to enrollment or session start becomes obsolete. The enterprise must re-centre accountability on the individual tool invocation. Practitioners should treat this as a structural change in identity governance, not a point product discussion.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• The runtime governance gap becomes harder to ignore when delegated access expands faster than review and visibility can keep up.

What this signals

Runtime governance: the next control layer for agentic work is not better authentication, but decisioning before each tool call. Teams that already struggle to govern NHIs should expect the same blind spots to surface faster when agents inherit access from humans.

As agents become embedded in operational workflows, the identity programme has to move from entitlement snapshots to action-level evidence. The practical shift is toward policy engines, decision traces, and denial logic that can be audited after the fact without assuming a person reviewed every step.

The broader lesson is that delegated autonomy collapses the usefulness of static access assumptions. When access is exercised at machine speed, security teams need controls that see the action, not just the account, and governance models that can explain why a specific call was allowed.

For practitioners

• Map every agent tool call to a policy decision Place an authorization check in the execution path so each tool invocation is evaluated against the action, the delegating human, and the target system before it reaches the app.
• Separate agent registration from action approval Use identity protocols for discovery and lifecycle, but do not mistake registration, naming, or credential binding for permission to act.
• Define deny rules for destructive operations Block actions such as deletion, bulk export, or privilege change unless the runtime policy explicitly allows them for that specific delegated context.
• Build decision traces into identity audit workflows Record who delegated, what the agent tried to do, which policy fired, and whether the action was approved, denied, or escalated.

Key takeaways

• Agent identity alone does not control behaviour, because protocols for naming and registration stop before the point of action.
• Runtime governance changes the control model by evaluating every tool call against the delegated human, the action, and the target system.
• Identity teams need audit-ready decision traces and deny logic for destructive actions if they want accountability to survive delegated autonomy.

Key terms

• Runtime Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.
• Decision trace: The record of how an access decision was made, including inputs, policy logic, and the final allow or deny outcome. For AI-assisted identity systems, decision traces are necessary for auditability, troubleshooting, and proving that automated access was bounded and explainable.
• Tool-Call Authorisation: Tool-call authorisation is the practice of making each agent action request a distinct security decision. Instead of granting broad access to the agent process, the system evaluates the specific tool, inputs, role, and context before execution, which creates a reviewable control boundary.
• Delegated Agent Authority: The permission granted to an AI agent to act on behalf of a human user or another agent, inheriting some or all of their access rights. Delegated authority must be explicitly scoped, time-limited, and auditable.

What's in the full article

Cakewalk's full article covers the operational detail this post intentionally leaves for the source:

• A deeper walkthrough of the five agent identity protocols and where each one stops governing behaviour.
• Architecture diagrams showing protocol gateway, SDK, kernel, and vendor-app enforcement patterns.
• The full runtime governance flow for approve, deny, and escalate decisions across tool calls.
• The complete Decision Trace model that records delegation, policy inputs, and execution outcomes.

👉 Cakewalk's full article covers the protocol gap, enforcement layers, and decision-trace model in more operational detail.

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.