Runtime governance is the missing layer for agent access

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Cakewalk's blog post: Agent identity alone does not stop unsafe actions, and per-call runtime governance is the missing layer between agent access and execution.

Why it matters: For IAM, PAM, and NHI teams, this matters because delegated agent access behaves like standing privilege unless every tool call is checked against policy in real time.

Context

Agent access is not just an identity problem. It is a governance problem that begins after authentication, when an agent starts using delegated permissions to call tools and reach downstream systems.

Cakewalk argues that protocols such as A2A, Agent Auth, AAuth, SCIM extensions, and OWASP ANS solve discovery, registration, and binding, but do not define runtime authorization. That leaves security teams with a familiar identity object and an unfamiliar execution risk.

The article frames runtime governance as the missing control plane for AI agents: a per-action policy decision tied to the human behind the delegation, the requested action, and the target system. In other words, identity can name the actor, but governance must decide the act.

Key questions

Q: What breaks when AI agents are given access without identity governance?

A: What breaks is accountability. The organisation may see actions, logs, and alerts, but it cannot reliably tie them to a governed identity with clear scope and revocation. That creates uncontrolled blast radius, especially when agents can reach sensitive systems through shared tokens, delegated service accounts, or broad API access.

Q: Why do delegated AI agents increase the risk of destructive actions?

A: Because the agent inherits the human's effective access and can execute tool calls far faster than a person can review them. If no per-action governance layer sits in the path, a single delegated task can become an outage, data loss event, or unauthorized change before anyone has the chance to intervene.

Q: How can security teams tell if runtime context governance is working?

A: It is working when the team can trace each prompt component to a source, distinguish policy from retrieved content, and see when injected instructions alter model decisions or tool use. If the organisation cannot reconstruct context provenance after an incident or test, the control is incomplete. Observable traceability is the clearest effectiveness signal.

Q: What is the difference between agent identity governance and runtime security?

A: Identity governance decides what an agent may access, while runtime security decides whether the agent’s live behaviour stays within policy after execution begins. You need both. Governance without runtime leaves misuse undetected, and runtime without governance leaves the agent over-permissioned from the start.

Technical breakdown

Why agent identity protocols stop short of authorization

The article separates agent identity from agent authority. MCP, A2A, Agent Auth, SCIM extensions, and Agent Name Service-style registration can prove that an agent exists, who it is, and how it is bound to a user or directory object. What they do not do is decide whether a specific tool call is allowed at the moment of execution. That gap matters because identity metadata is static, while tool use is dynamic and context-sensitive. A verified agent can still make the wrong call, or the right call in the wrong context, if nothing evaluates the request at runtime.

Practical implication: Practitioners should treat identity protocols as enrollment and binding layers, not as the final authorization decision.

How runtime governance evaluates each tool call

Runtime governance adds a decision point between the agent and the target system. Each request is checked against three inputs: the action itself, the human who delegated the work, and the target system. The policy engine can approve, deny, or escalate the call, and the audit trail records who requested, what was attempted, and why it happened. Architecturally, this is different from provisioning an identity or issuing a token, because the control sits on the execution path and inspects the actual operation before it reaches the app or data source.

Practical implication: Teams need enforcement that sits in the path of execution, not only at enrollment or token issuance.

Why protocol-level identity does not equal safe delegation

The deeper issue is delegated power. When a human grants an agent access, the agent often inherits the human's effective permissions and can exercise them faster than a person can review them. The article's Kiro example shows why this matters: if the permission scope is wider than expected and no runtime check exists, the agent can execute destructive actions at machine speed. That is a governance failure, not an identity naming failure. Once tool calls are allowed to proceed unchecked, the existence of a valid agent identity does not constrain behavior.

Practical implication: Governance must constrain the action path, not just the identity record.

Threat narrative

Attacker objective: The objective is to turn delegated agent access into immediate control over production actions without a human decision at execution time.

1. Entry occurs when a human delegates work to an AI agent and the agent inherits the human's permissions for downstream tools and systems.
2. Escalation happens when the agent uses that delegated access to select a high-impact action, such as deletion or environment-wide change, without a runtime policy checkpoint.
3. Impact follows when the action executes at machine speed against production systems, creating outage, data loss, or operational disruption before a person can intervene.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime governance is the missing control layer for delegated agent access. Identity protocols can establish that an agent exists and is bound to a user, but they do not decide whether a tool call should proceed. That leaves a gap between authentication and execution that traditional IAM and directory controls were never designed to close. The implication is that agent access must be governed at the point of action, not only at the point of identity creation.

Agent access inherits the human's effective privilege, so the real question is delegation scope. The article shows that once an agent receives a person's access, it can exercise that access at machine speed and across multiple tools. That makes the delegation boundary more important than the agent's name or registration record. Security teams should view this as a privilege translation problem, where the user's access becomes the agent's operational capability unless runtime policy intervenes.

Permissioning AI agents like ordinary applications underestimates the execution risk. The control issue is not whether the agent is known, registered, or authenticated. It is whether each action is assessed against the action itself, the delegator, and the destination system before execution. That is a materially different governance model from static provisioning, and it forces identity teams to think in terms of per-call authority rather than durable access grants.

Identity without runtime policy creates false confidence in agent governance. A verified agent can still perform an unsafe action if the policy layer does not inspect the request at the moment of use. This is why agent identity standards and runtime governance are complementary rather than interchangeable. Practitioners should treat registration and binding as necessary but incomplete, because the decisive control is whether the action is still acceptable when the agent is about to act.

Decision traceability becomes the control that makes agent autonomy governable. If every tool call records who delegated, what was requested, which policy fired, and whether the action was approved or denied, the organisation gains an audit trail that can support review and accountability. Without that trace, the agent becomes a permission amplifier with no reliable evidence of why a given action happened. The practical conclusion is that observability must be built into the decision path, not added afterward.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Authorisation Guide

What this signals

Runtime governance turns agent access from a static identity problem into a per-action control problem. That shift matters because review processes built for durable accounts do not automatically map to agents that can act, escalate, and complete work inside a short session. The practical programme question is no longer just who has access, but who decides each action before the agent reaches the target system.

Decision trace is the new accountability layer for agent delegation. If your programme cannot reconstruct who delegated, what was requested, and which policy outcome applied, then agent governance remains too thin for audit or incident review. For teams building agent controls, the focus should move from naming the agent to proving every action path is observable and enforceable. AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.

For practitioners

• Define a runtime authorization point for agent tool calls Place policy evaluation between the agent and every tool or application it can reach so each request is checked before execution. The control should evaluate the action, the delegating human, and the target system on the same request path.
• Reduce delegated scope to the minimum viable task Treat every agent assignment as temporary delegation rather than durable application access. Map which permissions the human actually needs for the task, then ensure the agent cannot reuse broader standing access outside that task.
• Record per-call decision traces Log who delegated the task, what the agent tried to do, which policy outcome was returned, and when access ended. That evidence is the only practical way to reconstruct agent actions and prove governance worked.
• Separate identity proof from action approval Keep agent registration, credential binding, and directory presence distinct from authorization. A verified agent should still face a fresh policy decision at runtime before it reaches high-risk systems or destructive functions.
• Test destructive-action paths before broad rollout Simulate deletion, mass update, and privileged write operations through the proposed governance path so you can see whether approvals, denials, and escalation behave as intended under real tool-call pressure.

Key takeaways

• Agent identity protocols can establish naming and binding, but they do not decide whether a specific tool call should proceed.
• Runtime governance is the control that checks each action against the delegating human, the target system, and the request itself.
• Without per-call policy and audit traces, delegated AI agents can amplify privilege at machine speed with little accountability.

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 access: A pattern where an AI agent performs actions on behalf of a human user and should therefore inherit that user's permissions. The governance challenge is preventing the agent from becoming a privilege amplifier or bypassing user-scoped controls.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.