Runtime policy for AI agents: the governance gap teams are missing

At a glance

What this is: This is an analysis of the emerging governance gap around AI agent runtime control, with the key finding that most enterprises still lack identity, audit, and policy boundaries for agent actions.

Why it matters: It matters because IAM, PAM, and lifecycle programmes must now govern agents as runtime actors, not just users or workloads, or they will lose visibility and control over delegated actions.

👉 Read Cerbos' analysis of runtime policy for AI agent orchestration

Context

AI agent governance is becoming a runtime identity problem, not just a model safety problem. The core issue is that current controls were built for systems that request access and then act within predefined boundaries, while agents can decide, delegate, and execute at runtime.

In practice, that means identity, auditability, and policy enforcement have to move closer to the action itself. The article argues that most organisations still treat one long-lived credential as if it represented an entire agent class, even though each agent instance and each delegated step changes the governance picture.

That gap sits directly at the intersection of NHI governance and agentic AI. The more an agent can chain decisions or call tools independently, the less useful static approval models, framework allowlists, and post hoc audit trails become without external runtime controls.

Key questions

Q: What breaks when AI agents share one long-lived identity across instances?

A: Shared long-lived identity breaks containment, revocation, and accountability because the real unit of action is the agent instance, not the agent class. When multiple instances reuse the same credential, you lose the ability to prove which instance acted, who sponsored it, and whether the access still matches the original purpose.

Q: Why do AI agents complicate existing IAM and audit models?

A: AI agents complicate IAM because they can delegate, chain actions, and select tools at runtime, which means access decisions are no longer fixed at provisioning time. Existing audit models struggle because they often show what happened, but not the preserved chain of consent and purpose across delegation.

Q: How can security teams tell whether agent runtime controls are actually working?

A: Look for evidence that policy decisions happen outside the agent, that tool calls fail closed when the policy service is unavailable, and that each action carries sponsor and purpose context. If the agent can keep working without that boundary, the control is cosmetic rather than enforceable.

Q: Who should be accountable when an AI agent delegates work to a sub-agent?

A: Accountability should remain with the named human sponsor and the organisation operating the agent, because delegation does not erase ownership. If the governance model cannot preserve sponsor identity, purpose, and approval across the chain, the organisation cannot defend the action in audit or incident review.

Technical breakdown

Per-instance agent identity and short-lived credentials

Agent identity breaks when one credential is reused across multiple spawned instances. The article’s core point is that an agent should not be treated as a class-level principal but as an instance-level one, with credentials scoped to a single tool call or narrowly bounded action. That is the non-human identity analogue of per-session privilege, but with tighter lifecycle and sponsorship expectations because the actor can branch into new execution paths. If a spawned agent inherits the same long-lived key, accountability and containment both collapse.

Practical implication: stop issuing shared long-lived keys for agent classes and require instance-scoped identity with explicit sponsor linkage.

Why audit trails fail across agent-to-agent delegation

Traditional logs can show that a service account or API principal performed an action, but they often lose the chain of consent once an agent delegates to a sub-agent. That creates a custody problem: who approved the original purpose, whether the approval survived delegation, and which data or tool access was valid at each hop. The technical failure is not a lack of logging volume, but a lack of semantic continuity across the delegation chain. Without that continuity, logs describe events but not accountable authorization.

Practical implication: preserve sponsor, purpose, and authorization context through every delegated call, not just the initial request.

Runtime policy enforcement outside the agent loop

The article’s architectural position is that the agent should not decide what it is allowed to do. Instead, a separate policy engine should evaluate each agent-to-tool call outside the reasoning loop and fail closed if the policy service is unavailable. That separates probabilistic reasoning from deterministic authorization, which is the core security boundary. It also makes policy change, rollback, and audit consistent across agents, tools, and environments. When policy remains inside the agent, the control is effectively self-referential.

Practical implication: externalise authorization for agent tool calls and verify that policy unavailability blocks execution rather than defaulting to allow.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Per-instance identity is the right control boundary for agents. The article shows why class-based agent identity is already too coarse for governance. One long-lived API key cannot safely represent multiple spawned instances because the execution unit is the instance, not the label. Practitioners should treat per-instance identity as the baseline assumption for agent governance, otherwise accountability, scope, and revocation all become ambiguous.

Chain-of-custody audit is the missing governance layer in delegated agent action. Existing logs can record that an action happened, but they often cannot prove who authorised the original purpose after delegation to sub-agents. That is not a minor observability gap. It means consent, intent, and data purpose no longer survive the hop, which undermines both operational control and audit defensibility.

Runtime policy outside the agent is a category-level shift, not a feature request. The article correctly frames tool gating as a separate policy plane rather than an internal guardrail. That changes the identity security model because authorisation is no longer embedded in the actor that is being constrained. Practitioners should recognise this as the emergence of a new control surface for agentic systems, with direct implications for NHI governance and PAM-like enforcement.

Governance programmes built for post-action review are being outpaced by agent runtime decisions. The assumption that access persists long enough to be reviewed, logged, and certified was designed for slower-moving identities. That assumption fails when an agent can decide, delegate, and execute within the same workflow boundary. The implication is that access review cadences alone no longer describe the real control problem.

Shadow AI is now a discovery and lifecycle problem, not just an inventory problem. If teams cannot enumerate which agents already exist, they cannot assign sponsors, revoke access on departure, or prove lifecycle accountability. That makes agent discovery an identity governance requirement, not a tooling nicety. Practitioners should treat unknown agents the same way they treat unmanaged NHIs, but with faster escalation because the action layer is autonomous in practice.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
• That confidence gap is why the next governance step is to connect agent runtime policy to lifecycle and visibility controls, as explored in Ultimate Guide to NHIs , Regulatory and Audit Perspectives.

What this signals

Identity per agent instance is becoming the practical control plane for agentic systems. Teams that still manage agents as a single reusable principal will struggle to answer basic ownership and revocation questions once agents begin chaining actions. The governance shift is toward instance-level sponsorship, external policy, and audit continuity rather than broader but weaker allowlists.

Chain-of-custody controls are now a first-class requirement for agent governance. A log that only shows a tool call is no longer enough when the real question is who authorised the action and whether that approval survived delegation. This is where the discipline starts to converge with NHI lifecycle thinking, because the lifecycle of the actor and the lifecycle of the credential must be governed together. For the policy model behind that shift, see NIST Cybersecurity Framework 2.0.

Runtime authorisation will separate serious agent programmes from experiments. With 1 in 4 organisations already investing in dedicated NHI security capabilities, according to The State of Non-Human Identity Security, the market is moving toward enforceable controls rather than policy statements. The programmes that survive will be the ones that can prove fail-closed behaviour, not merely promise it.

For practitioners

• Inventory all active agents and sub-agents Build a live register of agent instances, delegated assistants, and tool-connected workflows. Tie each one to a business owner, a technical sponsor, and an explicit purpose so you can revoke or pause access when that owner changes.
• Assign sponsor-tied lifecycle ownership Require every agent to have a named human sponsor whose status governs the agent’s continued operation. If the sponsor changes role or leaves, the agent should lose standing access until re-approved.
• Externalise tool-call authorisation Place decisioning outside the agent’s reasoning loop so the policy engine evaluates each tool call before execution. Verify that policy unavailability fails closed, and log the decision, context, and outcome for each call.
• Preserve delegation context in audit records Record original purpose, sponsor identity, and downstream delegation context for every agent action. Without that chain, you cannot explain why a sub-agent was allowed to act or which human accepted the risk.
• Test fail-closed behaviour under policy outages Simulate unreachable policy services and confirm that the agent cannot continue by default. If the workflow still completes, the control plane is not actually governing runtime behaviour.

Key takeaways

• AI agent governance fails when identity is assigned to a class rather than to each runtime instance.
• Audit trails that cannot preserve sponsor, purpose, and delegation context do not provide accountable control over agent actions.
• Externalised runtime policy is the control that turns agent governance from a documentation problem into an enforceable boundary.

Key terms

• Per-instance agent identity: A per-instance agent identity is a distinct credential and governance record assigned to one running agent instance, not to the whole agent type. It allows security teams to revoke, audit, and scope access at the level where action actually occurs, which is essential when agents can spawn or delegate.
• Chain of custody for delegated action: Chain of custody for delegated action is the record that preserves who authorised an agent’s purpose, what data it could touch, and how that approval carried through each hop. In agentic systems, this is what turns a sequence of tool calls into an accountable decision path rather than an opaque workflow.
• Fail-closed runtime policy: Fail-closed runtime policy means an agent cannot continue acting when the policy decision service is unavailable or unreachable. The design is deliberate: if authorisation cannot be checked in real time, execution stops rather than defaulting to permit, which is the safer model for high-risk agent tool use.
• Sponsor-tied lifecycle: Sponsor-tied lifecycle is the governance pattern where an agent’s existence, access, and renewal depend on a named human owner. When sponsorship changes or ends, the agent’s permissions should be reassessed or removed, which gives identity teams a clear accountability hook across provisioning, review, and offboarding.

Deepen your knowledge

AI agent identity, runtime authorisation, and sponsor-tied lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for agentic workflows with similar control gaps, it is worth exploring.

This post draws on content published by Cerbos: runtime policy for AI agents and the governance gap they expose. Read the original.