AI agent governance needs runtime evidence, not policy theatre

At a glance

What this is: This is an analysis of why AI agent governance programs often fail at runtime, with the key finding that enforcement inside the agent’s own process cannot independently prove compliance.

Why it matters: It matters because IAM, PAM, and AI governance teams need evidence that agent permissions, tool use, and delegated access are actually constrained at runtime, not just documented in policy.

👉 Read ARMO's analysis of AI agent governance and runtime enforceability

Context

AI agent governance is moving beyond policy documents into runtime control, but most programmes still cannot prove that enforcement actually happened. The core problem is a control boundary issue: if the policy engine sits inside the agent’s own process, the agent can influence what gets observed and what gets reported. That creates a verification gap for AI agent identity, delegated access, and runtime authorisation.

For identity and security teams, this is the same governance challenge seen in other trust-boundary failures: configuration is not the same as enforcement. Where AI agents call tools, use service accounts, or operate through middleware, the organisation needs evidence from outside the workload itself. That makes the article relevant to AI security, IAM, and NHI governance at the point where they overlap.

Key questions

Q: What fails when AI agent governance stays inside the agent process?

A: It fails at verification. A policy engine embedded in the agent can block some actions, but it cannot independently prove that every action was seen or stopped. If the agent changes code paths, spawns child processes, or is influenced through prompt injection, the control may report success without trustworthy evidence. That is why runtime enforcement needs an external observation plane.

Q: Why do AI agents create new risk in non-human identity management?

A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts. They can connect quickly, persist across teams, and accumulate permissions that are hard to review. That combination increases the chance of unnoticed access drift and credential exposure.

Q: How do security teams know if agent governance is actually working?

A: It is working only if the team can answer three questions quickly for any agent: what it can reach, what it did recently, and whether that behaviour matches intent. If any of those answers require manual reconstruction, governance exists on paper but not in operations.

Q: How should organisations decide whether to build or buy AI governance controls?

A: Choose build when the organisation needs deep custom instrumentation, strict data residency, and has dedicated engineering capacity to own the system long term. Choose buy when audit deadlines are close, governance coverage is needed quickly, or enforcement must be delivered faster than an internal team can build it. Hybrid approaches often work best for large enterprises.

Technical breakdown

Why application-plane enforcement is not enough

Application-plane enforcement means the policy engine intercepts actions inside the agent’s own execution path, usually before a tool call or outbound request is allowed. That can block obvious violations, but it still shares process memory, identity context, and control flow with the system it is meant to constrain. If the agent uses another process, an unmonitored library path, or indirect prompt injection to alter behaviour, the policy engine may never see the action. The result is a control that can truthfully say it evaluated a request, but not prove it saw every request.

Practical implication: treat middleware policy engines as enforcement aids, not proof of compliance, unless they are paired with independent observation.

What two-plane verification changes for AI agent governance

Two-plane verification adds an independent runtime signal outside the agent’s process boundary. In practice, that means observing syscalls, network destinations, file access, and child processes from the infrastructure plane, then comparing them to the policy plane’s decisions and the agent’s declared scope. This separates what the agent says it did from what the host actually observed. It is the difference between a control that blocks and a control that can be audited after the fact with evidence the workload cannot selectively hide.

Practical implication: require runtime telemetry outside the agent boundary before accepting any claim of enforceable AI governance.

Why the enforceability ladder is a useful governance model

The Enforceability Ladder is a maturity model for AI policy clauses, not for AI ambition. It distinguishes aspirational statements, documentary commitments, attested configuration, application-plane enforcement, and two-plane verified evidence. That matters because many programmes confuse a deployed policy layer with verified control effectiveness. Clause-by-clause scoring exposes where governance is real, where it is only documented, and where runtime evidence is still missing. For AI agents, this becomes an identity question too, because the agent’s service account, delegated tools, and runtime privileges all need verifiable scope boundaries.

Practical implication: score your AI policies clause by clause so you can identify which controls need host-level verification or stronger identity governance.

Threat narrative

Attacker objective: The objective is to make the agent perform actions outside its intended policy boundary while preventing the defender from producing trustworthy proof of enforcement.

1. Entry begins when an AI agent receives malicious or unexpected instructions through prompt injection, delegated tooling, or an untrusted workflow path.
2. Escalation occurs when the agent acts through its own middleware or generated code path, bypassing the intended policy checkpoint while retaining access to tools and credentials.
3. Impact follows when the organisation cannot prove whether blocked actions were truly blocked, leaving runtime abuse, data exposure, or unsafe tool execution unverified.

NHI Mgmt Group analysis

AI agent governance now has a verification problem, not just a policy problem. Most programmes can describe what agents should do, but they cannot prove what happened when the agent executed outside the monitored path. That gap matters because security control only exists when it is independently observable. For AI governance teams, the practical conclusion is that documentation without external evidence should not be treated as enforceable control.

The strongest named concept here is the runtime enforceability ladder. It captures the difference between saying a policy exists, attesting that a setting was configured, and proving that enforcement held in production. This is useful because it separates governance maturity from runtime assurance. For practitioners, the ladder provides a vocabulary for vendor evaluation and for identifying where AI agent identity and privilege controls stop being measurable.

Identity is the hidden dependency in AI agent enforcement. If an agent’s service account, delegated tool scope, or runtime permissions are broader than the policy layer can observe, enforcement becomes partial by design. That makes IAM and NHI governance part of AI control validation, not a separate discipline. The practical conclusion is that agent identity scope must be verifiable outside the workload itself.

Vendor evaluations should now test whether runtime claims survive bypass conditions. A product that can block a tool call in the happy path may still fail when the agent spawns a child process, uses an alternate code path, or is manipulated by indirect prompt injection. The key question is whether the defender can observe and prove the outcome from outside the agent boundary. That is the standard buyers should use when deciding whether a platform enforces policy or only records intent.

What this signals

AI agent governance is moving toward a stronger evidence model, but many programmes will still overstate control quality if they rely on application-layer logs alone. The practical shift is toward runtime proof, which means security teams need telemetry that exists outside the workload and can survive bypass conditions.

Runtime enforceability gap: this is the point where policy, configuration, and actual behaviour diverge. The more agentic systems use delegated credentials and tool access, the more identity teams will need host-level verification to support governance decisions.

Programmes that already manage NHI sprawl, secret lifecycle, and delegated access will adapt faster because they understand that identity scope without independent evidence is only partial control. The next maturity step is not more policy text, but better proof.

For practitioners

• Score AI agent clauses by enforceability level Classify policy statements as aspirational, documentary, attested, application-plane enforced, or two-plane verified, then prioritise the clauses that still lack external runtime evidence. Use the resulting gap list to drive control investment and vendor review.
• Separate policy decisions from host-level evidence Collect telemetry from outside the agent process, including syscalls, network destinations, file access, and child processes, so enforcement can be checked independently of the workload’s own reporting. This is essential when agent middleware can be bypassed.
• Validate agent identity scope end to end Review the service accounts, delegated tools, and credential boundaries used by each agent, then confirm those scopes are visible to the enforcement and observation layers. A policy engine cannot compensate for overbroad identity grants.
• Test bypass conditions in every demo Ask vendors to prove that enforcement still holds when the agent executes generated code, follows an alternate tool path, or encounters indirect prompt injection. If the answer depends on a single monitored code path, the control is incomplete.

Key takeaways

• AI agent governance fails when enforcement cannot be independently verified outside the agent’s own process boundary.
• The enforceability ladder helps teams distinguish documented intent, configured control, active blocking, and real runtime proof.
• Identity governance for AI agents now depends on proving service-account scope and tool use at runtime, not just in policy.

Key terms

• Runtime Enforceability: The degree to which a policy can be proven to have been applied during actual execution, not just documented or configured. In AI agent governance, runtime enforceability depends on evidence that survives bypass conditions, alternate execution paths, and workload self-reporting.
• Two-Plane Verification: A control model that compares policy-plane enforcement with independent infrastructure-plane observation. The aim is to confirm that a blocked or allowed action is validated outside the agent’s own process, so the workload cannot fully control the evidence of compliance.
• Application-Plane Enforcement: Policy enforcement that occurs inside the application or agent execution path, such as middleware intercepting tool calls before they run. It can stop actions in the monitored path, but it cannot on its own prove that every meaningful action was observed or blocked.
• Per-Agent Baseline: A runtime profile of normal tool use, destinations, and state changes for one specific agent deployment. It allows security teams to distinguish expected behaviour from coercion or drift, and it becomes the basis for moving from audit mode to enforced controls.

What's in the full article

ARMO's full blog covers the implementation detail this post intentionally leaves at the governance and assurance level:

• Clause-by-clause examples of how to score AI governance statements across the enforceability ladder
• The runtime evidence model for verifying enforcement outside the agent process boundary
• Demo questions that separate application-plane policy engines from two-plane verification platforms
• Practical guidance on which control gaps map to attestation, enforcement, or host-level observation

👉 ARMO's full post explains the enforceability ladder, runtime evidence model, and vendor evaluation questions in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps security practitioners build the governance model needed for AI agents, workloads, and privileged service accounts.