TL;DR: Enterprise AI agents traverse systems, change intent at runtime, and can move through human, machine, and sub-agent chains in ways static IAM models were not built to govern, according to Aizome. The real issue is not extending today’s fabric, but recognising that ownership mapping and provisioning-time policy stop being sufficient once identity becomes dynamic and context-driven.
NHIMG editorial — based on content published by Aizome: Not All AI Agents Are Born Equal, And Your Identity Stack Doesn't Know the Difference
Questions worth separating out
Q: How should security teams govern enterprise AI agents that can change behaviour at runtime?
A: Security teams should govern enterprise AI agents as runtime actors, not static accounts.
Q: Why do enterprise AI agents complicate existing IAM and NHI controls?
A: They complicate them because IAM and NHI controls generally assume stable identity, predictable scope, and traceable ownership.
Q: What breaks when organisations map every AI agent to a human owner?
A: Ownership mapping still helps governance, but it breaks as a complete control because it does not explain current behaviour.
Practitioner guidance
- Separate stable identities from runtime actors Classify enterprise AI agents by what they can do at runtime, not only by the account or token they use to start.
- Trace agent-to-agent delegation chains Map how one agent can invoke another, including the systems, data sets, and approvals that sit between them.
- Add intent checks to existing policy controls Use live behavioural signals to compare the agent’s current action with the task it was authorised to perform.
What's in the full article
Aizome's full blog post covers the operational detail this post intentionally leaves for the source:
- The article’s agent taxonomy, including how the author distinguishes development agents, in-product agents, and enterprise AI agents.
- The M2M to A2A framing that explains why delegation chains change how identity and accountability work in practice.
- The intent-based control model the author argues should sit alongside policy enforcement and ownership mapping.
- The Identiverse context and speaker framing that situate the argument within current industry debate.
👉 Read Aizome's analysis of why enterprise AI agents need a new identity model →
Enterprise AI agents and IAM: where the identity model breaks?
Explore further
Enterprise AI agents require a different identity model because static governance assumes stable intent. Human identity, and even most NHI governance, assumes the actor’s purpose is knowable at provisioning time. That assumption fails when the actor can reason, adapt, and change its action path at runtime. The implication is that least privilege defined once at setup is no longer a complete governance boundary for agent behaviour.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to SailPoint.
A question worth separating out:
Q: How do identity teams decide whether an AI agent needs more than standard policy enforcement?
A: Use standard policy for baseline permissioning, then add runtime observation when the agent can adapt, chain decisions, or cross systems. If the answer depends on what the agent is doing right now, not just what it was allowed to do at provisioning, policy alone is insufficient.
👉 Read our full editorial: Enterprise AI agents need agent-native identity, not adapted IAM