TL;DR: AI agents now make decisions, execute tasks, and adapt in runtime, which means identity controls must track delegation, auditability, and scope as first-class requirements, according to Strata Identity. The old assumption that access can be reviewed after the fact breaks when agents act and re-act within a session, leaving accountability gaps that human-centric IAM cannot close.
NHIMG editorial — based on content published by Strata Identity: AI agent identity and accountability in the enterprise identity model
By the numbers:
- With 80x more agents than human users in coming years, identity for agents is not optional.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams govern AI agents that act on behalf of users?
A: Security teams should govern AI agents as delegated identities, not as ordinary service accounts.
Q: Why do AI agents create accountability problems for IAM programmes?
A: AI agents create accountability problems because they can make runtime decisions, chain actions, and adapt scope without a human pause point.
Q: What breaks when organisations treat AI agents like normal service accounts?
A: What breaks is the governance model.
Practitioner guidance
- Classify agent identities by delegated authority Inventory every AI agent, copilot, and automated workflow by who or what it acts for, what tools it can call, and whether it can change scope mid-session.
- Require end-to-end delegation traceability Log originator, agent identity, downstream API calls, and scope changes in a single chain that survives incident review.
- Define JIT registration and expiry for agents Register agents only when the task or workflow begins, bind them to a named owner, and expire them when the task ends.
What's in the full article
Strata Identity's full article covers the operational detail this post intentionally leaves for the source:
- A practical breakdown of the Six A's and how each one maps to agent authentication, authorisation, and audit logging.
- Examples of agentic identity flows such as OAuth OBO, PKCE, SPIFFE/SVID, and DPoP in runtime workflows.
- The sandbox and hands-on lab material for testing delegated policies and traceability across agent actions.
👉 Read Strata Identity's analysis of AI agent identity and accountability →
AI agent identity and accountability: what changes for IAM teams?
Explore further
AI agent identity is becoming a governance layer, not a feature layer. Once software can decide, act, and adapt in runtime, identity has to describe the actor, the scope, and the delegation chain, not just prove login state. That shifts the control problem from access possession to action accountability. Practitioners should treat agent identity as a core IAM design domain, not an add-on to existing machine identity tooling.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- Only 80% of organisations report their AI agents have already performed actions beyond their intended scope, including unauthorised system access, sensitive data sharing, and revealing credentials.
A question worth separating out:
Q: Who is accountable when an AI agent causes an unauthorised action?
A: Accountability should flow from the delegated human or system owner through the agent to the action record. The organisation must be able to identify the originator, the policy that allowed the action, and the scope in force at the time. If that chain is missing, the issue is not just security. It is governance failure.
👉 Read our full editorial: AI agent identity requires a new model for accountability