AI agent identity governance is shifting to runtime enforcement

At a glance

What this is: This is a viewpoint piece arguing that AI agent governance cannot depend on directory-centric identity models because agent runtime behaviour outpaces static enrollment and issuance-time controls.

Why it matters: It matters because IAM and PAM teams now have to govern autonomous execution, not just named identities, and that changes where trust, authorization and credential exposure need to be controlled.

👉 Read Akeyless's analysis of AI agent identity governance shifting to runtime enforcement

Context

AI agent identity governance is the problem of deciding how autonomous software gets authenticated, authorised and constrained when it acts inside enterprise systems. The article argues that the old assumption behind directory-centric identity models no longer fits because agents are ephemeral, multi-substrate and able to change behaviour within a single session.

The governance gap is not discovery by itself. Visibility still helps, but static registration and issuance-time policy do not stop an agent whose permissions, tools or execution path change at runtime, which is why the article shifts the control point to workload-issued identity and runtime enforcement.

This is fundamentally an identity architecture question, not just an AI tooling question. The article frames AI agents as workloads that need runtime-bound trust, short-lived credentials and continuous evaluation rather than persistent directory records.

Key questions

Q: What breaks when AI agent identity is attached only at the directory layer?

A: You get authentication without behavioural control. The directory can confirm that an agent is valid, but it cannot decide each downstream model call or tool call once the session is underway. That creates a gap between access establishment and action governance, which is exactly where high-risk agent behaviour needs control.

Q: Why do autonomous AI agents change the authorization model?

A: Autonomous agents can alter their tool use, scope and sequencing after access has been granted, so the original authorization decision may no longer match the action being taken. That means static RBAC or OAuth scopes are necessary but insufficient. Teams need runtime evaluation that checks the action in context, not just the token at issuance.

Q: What are the failure signs that AI agent governance is too static?

A: The clearest signs are separate inventories that never match reality, long-lived credentials inside agent workflows, and access decisions that happen only at onboarding. If controls assume the agent exists long enough to be reviewed later, the programme is already misaligned with transient runtime behaviour.

Q: How should teams govern AI agent access when downstream systems still require secrets?

A: Use the agent's attested identity as the trust anchor, then issue short-lived downstream credentials that are scoped to one resource and one task. The goal is to keep the secret disposable while preserving an audit trail that ties every access back to the workload that requested it. That reduces standing privilege without requiring every target system to support native workload identity.

Technical breakdown

Why directory-centric identity breaks for AI agents

Directory-centric identity assumes an entity can be discovered, enrolled, assigned an owner and governed through a persistent record. That model works for people because human identities are stable enough for joiner-mover-leaver processes, periodic reviews and static role assignment. AI agents are different: they can exist for seconds, spawn sub-agents, move across substrates and disappear before a directory sync completes. The result is an enrollment lag that makes issuance-time authorization too late to matter. The article’s core technical point is that registration is not enforcement, especially when the identity itself is transient and runtime-shaped.

Practical implication: Treat discovery as inventory, not control, and move enforcement to the execution path.

How workload-issued identity replaces synthetic agent directories

The article argues that AI agents already have an identity primitive at runtime through systems such as cloud IAM, Kubernetes service accounts, OIDC federation and SPIFFE/SPIRE. These mechanisms issue short-lived, environment-bound credentials from the workload context rather than from a manually maintained agent directory. That matters because trust is established where the workload is produced, not copied into another static identity store. Runtime identity therefore becomes the anchor for authentication, while the agent directory becomes redundant overhead unless it contributes something operationally unique.

Practical implication: Anchor trust in runtime-issued workload identity instead of creating persistent agent records that age out immediately.

Why static authorization fails without runtime intent checks

RBAC, ABAC and OAuth scopes still matter, but they assume the request at issuance time describes the action that will actually occur. AI agents make that assumption brittle because prompt injection, tool chaining and dynamic reasoning can cause a valid token to authorize a harmful action that no one intended. The article’s mechanism is an intent gap: the access decision may be correct when made, yet wrong by the time the action executes. Runtime enforcement closes that gap by evaluating the action in context before execution proceeds.

Practical implication: Add runtime decision points for agent actions that can drift away from the original authorization intent.

Threat narrative

Attacker objective: Exploit runtime drift in agent behaviour to get a validly authorised system to perform unintended actions, including destructive changes or data exfiltration.

1. Legitimate access is granted to an AI agent through a valid runtime credential or federation path.
2. During the session, the agent’s scope can drift as prompts, tool calls or spawned sub-agents change what it attempts to do.
3. A valid token or scope can then be used for unintended write, read or exfiltration activity that static authorization did not anticipate.
4. The impact is execution of actions outside the original intent, with no directory record or issuance-time policy able to stop them in time.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

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

NHI Mgmt Group analysis

Inventory fallacy: directory visibility is not agent governance. The article’s central argument is that discovery and enrollment cannot keep pace with transient AI agents because the identity may exist for less than a second. That makes IdP-centric governance structurally late, not merely operationally immature. The practitioner implication is that AI agent controls have to be enforced where the action occurs, not where the record is stored.

Runtime-issued identity is the right baseline for non-human execution. AI agents behave more like cloud workloads than like employees, so the proper analogy is workload identity, not workforce identity. A runtime-issued credential tied to the environment that produced it is more defensible than a synthetic directory object that outlives the workload. Practitioners should therefore treat workload identity as the governing primitive for autonomous execution.

Intent-aware enforcement is a control layer, not an identity layer. Static authorization can answer whether a token is valid, but it cannot answer whether the current action still matches the original purpose of access. That distinction matters because autonomous systems can reinterpret prompts, chain tools and change behaviour mid-session. The implication is that governance must move from one-time permissioning to continuous runtime evaluation.

Least privilege for AI agents is a runtime property, not a provisioning artifact. Traditional least privilege assumes the actor’s intent is knowable when access is granted. That assumption fails when the actor is autonomous because the action sequence is not fixed in advance. The implication is that practitioners must rethink privilege as something that must be constrained during execution, not merely assigned before execution begins.

Secretless access is the practical boundary for agent trust. The article’s brokered-access model removes reusable credentials from the agent entirely, which matters because prompts, logs and outputs become leakage paths once secrets sit inside the agent context. For AI agents, exposing the secret is often the breach precursor. Practitioners should therefore push credentials out of agent memory and into mediated runtime exchange.

From our research library:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Security Guide

What this signals

Runtime governance will become the default control point for AI agents. Once agents can appear, act and disappear inside a single execution window, controls built around directory enrollment stop being the primary defence. Practitioners should plan for enforcement at session time, not after discovery cycles complete, because the control problem has moved from inventory to action control.

Identity blast radius becomes the more useful metric than identity count. The question is no longer how many agents exist, but how much damage a validly authorised agent can do before runtime policy intervenes. With least-privileged AI access showing a 17% incident rate versus 76% for over-privileged systems according to the 2026 Infrastructure Identity Survey, privilege scope is now a board-level risk signal.

Agentic AI identity governance will converge on workload identity and mediated credentials. As autonomous systems become more common, static secrets and synthetic directories will look increasingly like legacy scaffolding around a runtime problem. The operational design goal is to ensure every privileged action is mediated, attributable and revocable at execution time.

For practitioners

• Define the runtime enforcement boundary Map where agent actions are actually executed and place controls on that path rather than on directory enrollment, because transient agents may never exist long enough to be registered meaningfully.
• Replace synthetic agent records with workload-issued identity Use cloud attestation, Kubernetes service accounts, OIDC federation or SPIFFE-based identity as the trust primitive, and stop treating a static agent directory as the control plane.
• Eliminate exposed credentials from agent context Move to secretless brokered access so API keys, passwords and tokens are injected only into live sessions and destroyed after use, reducing the chance of leakage through prompts, logs or outputs.
• Add runtime intent checks for high-risk actions Require the enforcement layer to evaluate whether a requested action still matches the declared task before write, delete or exfiltration operations are allowed to proceed.

Key takeaways

• AI agent governance breaks when directory enrollment is treated as the control rather than as inventory, because transient agents can act before registration is complete.
• Runtime-issued identity and mediated access are better aligned to autonomous execution than persistent directory records and static scopes.
• The governance shift is not just technical housekeeping, it moves the decisive control point from onboarding to execution.

Key terms

• Runtime-Issued Identity: An identity created and verified by the environment where the workload is actually running, rather than by a static directory record. For AI agents, this means trust is tied to execution context, attestation and short-lived credentials, which makes governance closer to workload control than human identity management.
• Intent-Based Enforcement: Intent-based enforcement evaluates what a user or agent is trying to do, not only what words or files are present. In AI environments, that makes it possible to block, redact, warn, or route a request based on context, identity, and policy before sensitive data leaves the session.
• Secretless Access: Secretless access is a pattern where workloads authenticate and receive access without relying on long-lived embedded credentials. It typically uses runtime identity verification, federation, and short-lived authorization decisions. The goal is to reduce exposure from hardcoded or reusable secrets while keeping machine-to-machine access functional.
• Inventory Fallacy: The mistaken belief that discovering and registering every agent is a prerequisite for governing it safely. That assumption works poorly when the subject can appear and disappear in seconds. In autonomous environments, visibility helps with oversight, but enforcement must still occur in the runtime path.

What's in the full article

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

• How the Gateway evaluates agent actions in the runtime path
• Specific examples of Auth Methods bound to target systems such as databases, SaaS applications and Kubernetes clusters
• Implementation details for SPIFFE and SPIRE integrations, including SVID authentication
• How secretless brokered access is configured to keep credentials out of the agent itself

👉 The full Akeyless article covers runtime enforcement, workload-issued identity and secretless access in more implementation 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 IAM programme, it is worth exploring.