Topic starter
14/09/2026 10:10 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “AI Agent Identity Security: Why IdP-Centric IAM Falls Short”.
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.
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.
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.
Practitioner guidance
- 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.
- 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.
Bottom line: 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.
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
👉 Read Akeyless's analysis of AI agent identity enforcement and runtime governance →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/09/2026 10:11 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent identity needs workload enforcement, not a ghost directory