TL;DR: Akeyless argues that AI agent identity cannot be governed reliably through a universal directory because agents are ephemeral, non-enumerable, and runtime-issued, so static RBAC and ABAC fail when the actor can change actions mid-session. The decisive control boundary is workload-anchored, intent-aware enforcement at every action, not enrollment into a ghost directory.
At a glance
What this is: This analysis says AI agent identity belongs at the workload and gateway layer, not in a synthetic directory, because agents are ephemeral and non-deterministic at runtime.
Why it matters: IAM and security teams need to rethink agent governance as runtime enforcement over workload identity and action context, not as a human-style lifecycle and certification problem.
👉 Read Akeyless's analysis of AI agent identity enforcement and runtime governance
Context
The core problem is a governance model that assumes AI agents can be discovered, enrolled, named, and then controlled like human identities. That assumption breaks when the principal is ephemeral, may exist for milliseconds, and can change behaviour mid-session before any directory process catches up.
In identity terms, the article argues that the meaningful control point is the workload identity issued by the runtime, not a synthetic agent record. For IAM, PAM, and NHI programmes, that shifts the security boundary from inventory to issuance and from static role assignment to per-action enforcement.
Key questions
Q: What breaks when teams try to govern AI agents through a directory model?
A: Directory-first governance breaks because AI agents are ephemeral, may never be fully enumerable, and can disappear before enrollment or certification completes. That means the control plane sees a record of an identity rather than the runtime actor itself. Security teams should treat the directory as inventory support, not as the point where protection begins.
Q: Why do traditional RBAC and ABAC controls fall short for AI agents?
A: They usually assume one stable identity making one request at a time. Agent workflows can span tools, sub-agents, and long-running tasks, so the original intent can drift while the identity remains valid. That makes static entitlements too blunt unless they are paired with delegation-aware policy and expiry.
Q: How can organisations tell whether AI agent governance is actually working?
A: Look for evidence that agent access is ephemeral, traceable, and constrained at the action level. If the organisation cannot show which runtime acted, what it touched, and which endpoint or command it used, then governance is still too coarse. Effective control produces auditable decisions, not just authentication events.
Q: What is the difference between workload identity and directory-managed agent identity?
A: Workload identity is issued by the runtime environment that proves the workload exists and belongs in a trust domain. Directory-managed identity assumes the subject is first enrolled and then governed through a persistent record. For AI agents, workload identity maps better to ephemeral execution, while directory-first models create delay and blind spots.
Technical breakdown
Why directory-based agent inventory breaks down
Directory models work when identities are persistent, enumerable, and stable over time. AI agents do not meet those conditions: they can be spawned on demand, run briefly, delegate tasks, and disappear before discovery completes. A directory entry can record that an agent existed, but it cannot serve as the authoritative control plane for a principal whose identity is created and consumed inside a short-lived runtime. In practice, this makes registration useful for observability and policy inputs, but not as the prerequisite for protection. The more the model depends on inventory before governance, the more gaps it creates between what is known and what is already acting.
Practical implication: Treat discovery as telemetry for policy, not as the gate that decides whether an AI agent can operate.
Workload identity is the real anchor for AI agents
The article’s central technical argument is that an AI agent should inherit trust from the platform that issued it. In cloud and Kubernetes environments that means runtime-issued credentials such as cloud IAM attestations, service account tokens, OIDC federation, certificates, or SPIFFE/SPIRE SVIDs. These are workload identities, not human identities, and they already express who the runtime vouches for, when, and under what trust domain. That makes them the correct source of truth for agent authentication. Copying that state into a separate agent directory adds delay and administrative fiction without increasing enforcement fidelity.
Practical implication: Bind agent access to runtime-issued workload identity and treat the directory as supplementary metadata only.
Static RBAC and ABAC stop at authorization, not action
RBAC and ABAC can limit which systems and scopes an agent may reach, but they do not control what the agent does after access is granted. That limitation matters because an AI agent can replan, chain tools, or alter intent inside the same session. The article therefore places the missing control layer at the gateway, where each action is evaluated in context against the declared intent, the target object, and session history. This is a different security boundary from traditional IAM because it is action-level, not session-level, and it must operate before a credential is minted or released to the agent.
Practical implication: Move enforcement to the action path and require every agent request to be checked before execution.
Threat narrative
Attacker objective: The objective is to turn a legitimate agent session into unauthorised system action by exploiting the gap between static authorisation and runtime behaviour.
- Entry occurs when an AI agent authenticates through a valid runtime-issued workload identity rather than through a human-style directory record.
- Escalation happens when the agent changes task scope mid-session and attempts actions beyond the original authorisation intent.
- Impact follows when a permissive control model allows the agent to obtain or use credentials for actions the policy author never meant to permit.
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.
- 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.
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
Ghost directories are a governance anti-pattern for AI agents. The premise that agents can be discovered, enrolled, and then governed through a universal directory assumes a stable identity lifecycle that autonomous runtimes do not provide. Once the principal is ephemeral and may only exist for a single task, directory-first governance becomes a reporting layer with no enforcement value. The implication is that identity programmes must stop treating inventory as the control boundary and start treating runtime enforcement as the boundary.
Workload identity is the only defensible anchor for agent trust. AI agents inherit identity from the runtime that issues them, whether that runtime is cloud IAM, Kubernetes, OIDC federation, or SPIFFE/SPIRE. That is the control plane that can actually attest to origin and bound the credential lifetime. For practitioners, the lesson is that agent governance belongs where the workload is minted, not where a directory hopes to catalogue it.
Static authorisation collapses when the actor can change intent mid-session. RBAC and ABAC remain useful for coarse access, but they were designed for actors whose intended action is knowable before execution. AI agents can replan, chain tools, or shift from read to write inside the same session, which means the policy author cannot rely on provisioning-time scope alone. The implication is a shift from identity certification to action-time mediation.
Intent-aware enforcement becomes the new control boundary. The article correctly moves the decisive check to the gateway, where declared intent, target system, and session state can be evaluated before the next action executes. This is the named concept that matters: intent-aware enforcement is the control layer that replaces directory fantasy with runtime decisioning. Practitioners should read that as a signal that agent governance now belongs in the action path, not in a naming registry.
Zero standing privilege logic extends naturally to AI agents, but only if credentials are brokered at the edge. The article’s architecture aligns with a no-persistent-credential model in which the agent never holds reusable access. That is the right direction for high-risk AI workloads because it reduces harvestable blast radius and forces every action through a brokered decision point. The practical takeaway is that agent security and NHI governance are converging on the same operational principle: no durable privilege, no durable token, no durable assumption.
From our research library:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Identity Maturity Model
What this signals
Intent-aware enforcement is the control pattern that agentic programmes now need to internalise. If the policy decision happens only at onboarding, the real risk arrives after the agent starts chaining actions, which is why the control must move to the gateway and not stay in the directory.
The governance shift here is broader than agent security alone. Identity teams that already manage workload identity, secrets, and zero standing privilege should recognise the same pattern: durable trust objects are giving way to short-lived, brokered, and action-scoped access decisions, which changes where policy, audit, and incident containment need to live.
For practitioners
- Define the runtime as the identity source Map every AI agent class to the workload identity it already inherits from cloud IAM, Kubernetes service accounts, OIDC federation, certificates, or SPIFFE-issued identity. Remove any dependency on a synthetic agent directory as the primary gate for access.
- Move governance to the action boundary Require each agent action to be checked by a gateway that can evaluate declared intent, target system, and session history before issuing or brokering access.
- Treat discovery as policy input, not protection Use discovery and observability to improve coverage and policy quality, but do not make agent enrollment a prerequisite for enforcement against production systems.
- Broker short-lived access outside the agent Keep credentials out of the agent itself and inject them only at execution time so the agent cannot retain reusable secrets after the task ends.
Key takeaways
- AI agent identity cannot be managed safely as a naming and registration exercise because the actor may be ephemeral before a directory can govern it.
- The article’s core evidence is architectural, not theoretical: runtime-issued workload identity and action-level enforcement fit agents better than static identity records.
- The decisive control move is to broker short-lived access at execution time and to treat discovery as supporting telemetry rather than as the trust boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on agent identity, privilege assignment, and runtime misuse. |
| Recommendation — Bind agent privileges to runtime checks and prevent identity assumptions from persisting across sessions. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article argues that agent auth must come from workload runtime attestation, not directory enrollment. |
| NHI-05 — Overprivileged NHI | It warns that static scopes and directory-centric models overstate what transient agents should be able to do. | |
| Recommendation — Authenticate agents through runtime-issued workload identity instead of synthetic directory records. Limit agent access to the minimum runtime-scoped privilege needed for the current action. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | AI agents are service-like actors authenticating through workload and runtime identity. |
| Recommendation — Use service authentication controls to validate workload-issued identities before granting access. | ||
| NIST Zero Trust (SP 800-207) | Continuous Verification — Continuous Verification | The article places the control boundary at each action, not at onboarding or certification time. |
| Recommendation — Apply continuous verification so each agent action is evaluated at the point of execution. | ||
Key terms
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
- 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.
- Authentication Method: An authentication method is the mechanism used to prove the identity of a human user or workload before access is granted. In secrets platforms, it can include API keys, federated identity, or other trusted mechanisms, and it forms the first gate before authorisation decisions are applied.
- Ghost Directory: A ghost directory is a synthetic identity catalogue that records agent names and owners without providing meaningful enforcement over the runtime actor. It is useful for visibility and inventory, but weak as a trust boundary when identities are ephemeral and may no longer exist by the time governance catches up.
What's in the full article
Akeyless's full analysis covers the operational detail this post intentionally leaves for the source:
- The step-by-step runtime identity model for AI agents across cloud IAM, Kubernetes, OIDC, and SPIFFE/SPIRE
- The gateway enforcement pattern that evaluates declared intent, target system, and session history before access is granted
- The practical distinction between discovery for observability and discovery as a false prerequisite for protection
- The architectural comparison with workforce-IdP and directory-centric approaches in production environments
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.
Published by the NHIMG editorial team on September 14, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org