AI agent identity vs service accounts: where IAM assumptions break

At a glance

What this is: This analysis explains why AI agents cannot be governed like service accounts and identifies the IAM assumptions that fail when identity is produced at runtime.

Why it matters: It matters because IAM teams now have to govern AI agents, NHI, and human delegation together, or they will miss where authority, audit, and revocation actually live.

👉 Read WorkOS's analysis of AI agent identity vs service accounts

Context

AI agent identity is not just another form of non-human identity. The key problem is that agents do not behave like fixed service accounts, because their actions are produced at runtime and their authority changes with the prompt, tools, and session context.

That creates a governance gap for IAM, PAM, and NHI programmes that were designed around stable credentials and predictable request patterns. The practical question is no longer whether the identity has access, but when that access is decided and what evidence exists after the action is taken.

Key questions

Q: How should security teams govern AI agents differently from service accounts?

A: Security teams should govern AI agents at the action layer, not just the credential layer. Service accounts are managed through stable scopes and predictable code paths, while agents need per-session provenance, delegated identity, tool review, and authorisation that can evaluate each call against user intent.

Q: Why do AI agents complicate least privilege in IAM programmes?

A: AI agents complicate least privilege because their useful scope is often broader than a traditional service account, but their actual authority should still be narrower at each action. The control has to move from static entitlement management to request-time decisioning, especially for tool use and downstream side effects.

Q: What breaks when organisations audit AI agents like service accounts?

A: Audit trails break when teams record only the API call and ignore the prompts, tools, and model outputs that caused it. For AI agents, the explanation for an action is part of the evidence chain, and without it incident response cannot reliably reconstruct intent or accountability.

Q: How do organisations prevent AI agent access from outliving the user session?

A: They should issue short-lived delegated tokens, enforce downstream validation of the user context, and revoke credentials when the task ends. The goal is to keep access tied to the session and the request, not to leave the agent with a persistent identity that can be reused later.

Technical breakdown

Runtime behaviour vs code-defined service accounts

A service account has behaviour that can usually be traced back to code, deploy history, and reviewed change. An AI agent does not. Its actions emerge from model interpretation of instructions, tool descriptions, and live context, which means the same identity can produce different outcomes without any code change. That breaks assumptions in policy review, behavioural baselining, and change control. The security problem is not volume or speed. It is that the identity's action set is not fully enumerable ahead of time, so conventional NHI review methods cannot reliably predict what it will do next.

Practical implication: move review and approval to the action layer, not the credential layer.

Delegated identity and multi-hop authorisation

A service account acts as itself, but an AI agent often acts on behalf of a user through a chain that includes the user, the host application, the agent process, and downstream tools. That chain matters because the right authorisation decision depends on who requested the task, not only on what the agent can technically call. OAuth-style delegation and short-lived user-bound tokens improve this model, but only if every downstream service respects the delegated identity. Without that, the system collapses the user, the agent, and the tool into one weakly accountable executor.

Practical implication: preserve provenance across the delegation chain and require downstream services to honour it.

Tool calls are the real permission boundary

In agentic systems, the credential is rarely the full story. The actual permission boundary sits inside the tool layer, where descriptions influence model behaviour, schemas constrain arguments, and server-side code enforces what is allowed to happen. That means tool inventory management becomes a security control, not just an engineering concern. Adding a tool is effectively adding capability, and poorly scoped tools can expand the agent's blast radius even when the underlying identity looks narrowly scoped. Traditional IAM models do not treat descriptions and schemas as policy surfaces, but for agents they are.

Practical implication: manage tools as permission catalogs and review them with the same rigor as access policy.

Threat narrative

Attacker objective: The objective is to coerce a legitimate agent into taking actions that extend beyond the user's intended scope while remaining inside the system's apparent permissions.

1. Entry occurs when a legitimate user session exposes the agent to prompts, tool outputs, or documents that the model interprets as instructions.
2. Escalation occurs when the agent uses its allowed tools beyond the user's intent because the system treats model output as a trustworthy control signal.
3. Impact occurs when the agent completes actions that were technically authorised by tooling but not governed by a boundary that understood user intent or reversibility.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 breaks the service-account model because behaviour is no longer provisioned at build time. Service accounts were designed for deterministic code paths and stable permission sets. That assumption fails when the actor is autonomous in execution timing or at least runtime-directed in behaviour, because the identity can generate new actions from the same credential without a code change. The implication is that IAM teams must stop treating all non-human identities as operationally equivalent.

Least privilege becomes action-scoped, not identity-scoped, when an agent can choose tools at runtime. A broad delegated token may be necessary for the session, but it is not sufficient as a security boundary. This is a runtime authorisation problem, not a provisioning problem, and it aligns more closely with OWASP Agentic AI Top 10 and NIST AI Risk Management Framework concerns than with traditional service-account review.

Delegation chains are now part of identity governance, not just application plumbing. When an agent acts for a user, accountability depends on preserving the user request, the originating session, and the tool call history together. That is an NHI and human IAM convergence problem, because the governance question is who authorised the action and whether downstream systems can still prove it after the fact.

Tool descriptions and schemas are security policy surfaces, not documentation. The article's core insight is that the agent's effective permissions are defined by what its tools expose and how those tools are interpreted. That means permission review has to extend to tool catalogs, argument validation, and revocation paths, or the real control plane will remain invisible to IAM teams.

Session-bound credentials reduce blast radius, but they do not solve accountability by themselves. Short-lived delegation is healthier than long-lived secrets, yet it shifts risk into token minting, downstream trust enforcement, and audit retention. The practitioner takeaway is that lifecycle governance must follow the session, not the secret, if the organisation wants reliable control over AI agents.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to the 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
• The Ultimate Guide to NHIs explains why lifecycle and revocation have to follow the identity model, not the other way around.

What this signals

Runtime governance will become the dividing line between mature NHI programmes and legacy service-account management. AI agents force teams to treat tool review, delegated identity, and action-scoped policy as part of the access model. As agent features spread, programmes that still centralise control around static secrets will find that the real decision point has moved into the session.

With 30.9% of organisations already storing long-term credentials directly in code, the jump from service-account hygiene to agent governance is not abstract. The same operational habits that tolerated static secrets will fail harder when the identity can act at runtime and consume hostile inputs. The governance response is to link session-bound authority with auditable tool use, not to assume the old model can absorb a new actor type.

Delegation chains are becoming the practical boundary of identity architecture. Teams that understand where user intent, application context, and agent execution intersect will be better positioned to adopt controls from the NIST AI Risk Management Framework and OWASP Agentic AI Top 10 without forcing those models into a service-account template.

For practitioners

• Authorize agent actions at the call level Evaluate each tool invocation against the requesting user, the intended task, and the allowed side effects before execution.
• Bind delegated credentials to user sessions Issue short-lived tokens that carry the user context into downstream services and refuse calls that collapse provenance into the agent identity.
• Treat tool inventories as permission catalogs Review every tool description, schema, and backend implementation as an access control surface before it is exposed to an agent.
• Capture reasoning as part of the audit trail Retain prompts, tool inputs, model outputs, and action results so incident response can reconstruct why the agent acted.
• Assume hostile instructions inside inputs Design controls so that a model that is manipulated by prompt injection cannot trigger irreversible actions without additional checks.

Key takeaways

• AI agents are not just faster service accounts, because their behaviour is produced at runtime and can change without a code change.
• The real governance gap is not the credential alone, but the delegation chain, the tool boundary, and the audit record that proves intent.
• Practitioners should shift from static entitlement management to per-action authorisation, short-lived delegation, and complete reasoning logs.

Key terms

• Delegated Identity: A delegated identity is an access context issued on behalf of a user so a non-human actor can act within a bounded session. For AI agents, the important control is not just who the actor is, but whose request and intent the downstream system still recognises.
• Tool Boundary: The tool boundary is the point where an agent's model output becomes an enforced action. In agentic systems, this boundary acts like a permission layer because tool names, schemas, and implementations determine what the agent can actually do, not just what it appears able to request.
• Reasoning Trace: A reasoning trace is the record of prompts, tool inputs, model outputs, and decisions that led to an agent action. For governance, it is part of the audit trail because simple API logs rarely explain why the agent acted or whether the action matched the user's intent.
• Action-Scoped Authorization: Action-scoped authorization means deciding permission at the moment a specific tool call or operation is attempted. For autonomous or agentic behaviour, this is more reliable than static identity-scoped access because the risk is tied to the current request, context, and intended side effect.

Deepen your knowledge

AI agent identity and delegated access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agents that act on behalf of users, the course is a practical place to start.

This post draws on content published by WorkOS: AI agents vs service accounts, the reasons IAM controls built for service accounts and API clients do not transfer to AI agents. Read the original.