AI agent identity strains traditional IAM and raises audit gaps

At a glance

What this is: Aembit argues that AI agent identity breaks the assumptions behind people-centric IAM, because requests can pass through multiple identities before policy or audit can anchor them.

Why it matters: This matters because IAM, NHI, PAM and governance teams need to decide where identity is verified, where authorization is enforced, and what evidence remains when an agent acts on behalf of a person.

Context

AI agent identity is the problem of governing software that acts on behalf of a person without behaving like a logged-in human session. In this model, identity can shift across the user, the agent, the workload hosting it, and the downstream service that receives the request.

Traditional IAM assumes an interactive human session with a login, MFA challenge, timeout, and a single accountable operator. AI agents disrupt that assumption because the access path may be continuous, delegated, and distributed across systems before any policy decision is applied.

Key questions

Q: What breaks when AI agents inherit human IAM controls?

A: Human IAM controls break because they assume a person makes a request, waits, and can later be reviewed or deprovisioned. AI agents can chain actions, spawn downstream agents, and complete tasks faster than review cycles can observe. The result is weak attribution, stale privilege, and revocation paths that are too blunt to contain one actor cleanly.

Q: What is the difference between workload identity and authorization for AI systems?

A: Workload identity proves what the AI system is, while authorization decides what it can do. A strong identity without tight authorization still allows overreach, and tight authorization without reliable identity cannot safely distinguish one workload from another. Effective AI governance needs both controls working together.

Q: How should security teams audit AI access to sensitive data before approving deployment?

A: Start by tracing one AI output back to the identity that invoked it, the data it reached, the guardrails that applied, and the record retained afterward. Then verify who can actually access the underlying files, because the assistant usually reflects existing permissions. A defensible audit turns policy into evidence, showing whether access boundaries are real, testable, and enforceable in the live tenant.

Q: When should organisations use NHI governance, PAM, or workload IAM for agents?

A: Use NHI governance to discover agents and ownership, PAM to protect high-risk destinations, and workload IAM to enforce live access decisions. None of those roles replaces the others. The right choice depends on whether the control must discover, broker, or deny the request during execution.

Technical breakdown

Why interactive login no longer anchors trust

Human IAM assumes a person proves themselves at session start and then carries that identity through the transaction. AI agents do not always work that way. They may be launched by a user, run inside a separate workload, call an MCP server, and request downstream access through credentials issued elsewhere. That means the visible request is not the same thing as the initiating identity. The core technical issue is identity provenance: which entity authenticated, which entity is acting, and which entity is actually entitled to use the target resource. When those layers diverge, a simple login event is no longer enough to establish trust.

Practical implication: verify the running workload and the delegated context separately, rather than assuming the user’s sign-in covers every agent action.

Why workload authentication and authorization are different controls

Workload authentication proves that a specific software process or runtime is making the call. Authorization decides what that process may do in the current context. Those are not interchangeable, and the article is clear that a system can identify an agent without deciding whether the request should proceed. SPIFFE is a good example of this split: it can provide cryptographic workload identity, but it does not on its own broker credentials, preserve human authority, or enforce policy at the destination. A mature architecture therefore separates identity evidence, policy enforcement, and credential delivery into distinct functions.

Practical implication: do not treat workload identity standards, secrets brokers, and policy engines as substitutes for one another.

Why audit trails become the real control plane

When an agent acts for a person, the audit question is not just who logged in. It is who directed the agent, which workload executed the request, which credentials were used, what policy allowed it, and where the enforcement point sat. If those elements are not preserved together, the enterprise may have an access event but no defensible chain of authority. That is why the article emphasises the distinction between governance and runtime enforcement. Discovery and ownership are necessary, but they do not prove what happened during the live transaction. The audit record has to connect initiation, delegation, enforcement, and destination.

Practical implication: require audit records that retain user, agent, workload, policy, credential and destination context in one transaction history.

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.
• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

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

NHI Mgmt Group analysis

AI agent identity is forcing IAM to separate delegation from authentication. A human sign-in can prove who started the session, but it cannot by itself prove what an agent later did with delegated authority. That breaks the old assumption that user authentication and downstream access decisions belong to one continuous identity event. The practitioner implication is that policy must follow the request path, not just the login.

Runtime enforcement, not discovery, is the decisive control point for agents. Inventory and ownership matter, but they do not stop a live agent request. The real governance gap is the point where an authorized user, an active workload, and a downstream resource all have to be reconciled at the moment of access. Practitioners should treat agent identity as operational only when policy is enforced in-flight and not merely recorded afterward.

SPIFFE is an identity foundation, not an identity outcome. Verifiable workload identity helps establish which runtime is speaking, but the article correctly distinguishes that from authorization, credential brokering, and delegated human authority. That separation matters because many programmes will over-credit strong workload identity and under-design the control layer around it. The implication is to avoid collapsing identity evidence into governance evidence.

Delegated authority across user, agent and workload creates an audit gap if evidence is fragmented. The article’s core finding is not that more identities exist, but that multiple identities may participate in one action without a single source of truth for enforcement. That is a governance problem, not just a technical one. Practitioners need a policy model that can prove both entitlement and context when a request crosses identity boundaries.

Agentic access management is converging with NHI governance and PAM for a reason. The category split in the article shows that no single tool class solves agent identity end to end. Discovery, secrets, runtime authorization, and privileged access all play different roles. The practical conclusion is that buyers should design for control-point coverage, not category loyalty.

From our research library:

• 59% of organisations say they lack viable alternatives to standing privileged access for NHIs and AI agents, according to Delinea research.
• Read next: Agentic AI Identity Guide

What this signals

Delegated authority is the new boundary condition: programmes built around human session control now have to preserve who directed an agent, not just who authenticated first. That shifts governance from login-centric assurance to request-centric evidence.

The strongest architectures will split discovery, workload authentication, credential delivery and runtime authorization into separate control points. That division matters because an agent can be visible, owned and still over-privileged at the moment of use.

For practitioners

• Map the enforcement point Document where each agent request is decided, whether at token issuance, an MCP gateway, a privileged access broker, or the destination system. Then verify that the decision point matches the risk of the resource being accessed.
• Separate workload proof from user authority Require one control to verify the active workload and another to preserve the human direction behind the agent. Do not allow ownership metadata alone to stand in for delegated authority.
• Inventory the credentials an agent can still reach List persistent API keys, passwords, certificates, and tokens that an agent can retrieve or exchange during runtime. Use that inventory to decide which credentials should be brokered, replaced, or removed from the agent path.
• Preserve transaction-level audit context Ensure logs retain the initiating user, the agent identity, the hosting workload, the policy result, the credential path, and the destination. Without that linkage, delegated actions are hard to prove after the fact.
• Test whether governance and enforcement are split Confirm that discovery and certification products are not being mistaken for runtime controls. If a product identifies agents but cannot stop a request in-flight, pair it with a control that can.

Key takeaways

• AI agents expose a structural gap in people-centric IAM because delegated software actions do not map cleanly to a single human session.
• The article’s core message is that policy enforcement and audit evidence must survive the live request path across workloads, MCP servers and downstream systems.
• Enterprises should treat workload identity, NHI governance, PAM and secrets management as complementary controls rather than interchangeable answers.

Key terms

• Agentic AI Identity: The complete set of credentials, permissions, and governance controls applied to an autonomous AI agent, covering authentication, authorisation, action logging, and access revocation. Distinct from traditional NHI because agent identities are often ephemeral, delegated, and multi-hop.
• Delegated Context: The identity and usage context carried with an agent request, such as which user the agent acts for and which client initiated the call. It helps an API understand the request, but it does not replace policy enforcement or validate whether the action should proceed.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• 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.

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.