Traditional identity models were designed around human logins and long-lived service accounts. AI agents operate more like dynamic software identities that are created on demand, act on behalf of a user, and may touch multiple systems in one task. Without dedicated controls, organisations lose visibility into scope, duration, and accountability for each action.
Why Traditional Identity Models Break Down for AI Agents
Traditional identity models assume a fairly stable actor: a person signs in, or a service account runs a bounded workload. AI agents do neither cleanly. They can be spawned on demand, delegated from a user, and asked to complete a task across multiple systems, which makes the identity boundary move during the workflow instead of staying fixed. That is why the core problem is not just authentication, but scope, duration, and traceability.
For citizen-facing workflows, the agent may act as the visible front door to an organisation, yet the real decisions happen in the background through tools, APIs, and downstream services. For internal workflows, the agent may be given broad operational latitude because the task is complex and time-sensitive. In both cases, traditional models struggle to express “who is acting”, “under what authority”, and “for how long” in a way that remains auditable once the task spans multiple steps.
In practice, many teams only discover the mismatch after an agent has already been allowed to chain together permissions that no single human user should ever hold end to end.
How It Works in Practice
AI agents behave more like dynamic software identities than like fixed human accounts. A single task can involve a prompt, a planner, one or more tool calls, temporary tokens, and delegated access to business systems. That creates three practical gaps: the identity may not be unique to the task, the permissions may not match the actual step being executed, and the audit trail may show only the underlying service account rather than the agentic decision path.
The main operational issue is that legacy identity controls were built around login events, session duration, and static entitlements. An agentic workflow needs finer control over the action itself. Organisations usually need to separate user intent from agent execution, bound the agent to a specific task or policy, and record enough context to explain why a given action was authorised. Without that, a “successful” workflow can still be a governance failure because the organisation cannot later reconstruct the decision chain.
- Identity becomes task-scoped instead of user-scoped, especially when the agent completes a sequence of actions on behalf of someone else.
- Authorisation becomes step-specific, because the same agent may need read access in one step and write or approve access in another.
- Auditability depends on preserving the link between the human request, the agent action, and the downstream system change.
LLMjacking: How Attackers Hijack AI Using Compromised NHIs is a useful reminder that once an AI system can act with real credentials, attackers will target the identity path as aggressively as the model itself. These controls tend to break down when one agent is allowed to reuse long-lived credentials across many tools, because the workflow becomes difficult to contain or reconstruct.
Common Variations and Edge Cases
Tighter control often increases friction, requiring organisations to balance automation speed against accountability. That trade-off is most visible in citizen-facing journeys, where users expect low latency and one continuous experience, but the organisation still needs reliable step-level governance behind the scenes.
One common edge case is a hybrid workflow where the agent drafts, triages, or recommends, but a human approves the final action. In that model, the identity question does not disappear, it shifts to who authorised the agent to prepare the action, what the agent was allowed to pre-fill, and whether the approval step actually limits the blast radius. Another edge case is internal operations, where teams give agents broader access because the work is repetitive or urgent. That is often where excess privilege creeps in first.
NIST AI Risk Management Framework is relevant where organisations need a governance structure for accountable AI use, while OWASP Top 10 for Agentic Applications 2026 is more specific to identity, tool misuse, and agent privilege abuse. The practical point is that citizen-facing agents usually fail first at trust and explainability, while internal agents usually fail first at privilege creep and control sprawl.
Best practice is still evolving, but the direction is clear: organisations need to treat agent identity as a distinct control surface rather than a variant of employee IAM. If the workflow crosses systems, the identity model must survive the crossing, not dissolve into generic automation.
Risk and Threat Considerations
AI agents create concentrated access risk because a single delegated identity can touch many systems faster than a human operator can. That raises the impact of credential theft, excessive privilege, prompt-driven abuse, and unauthorised task chaining, especially where the agent is trusted to act inside customer journeys or operational back offices.
Failure mechanism: attackers can abuse the same identity and tool pathways the agent uses for legitimate work, then pivot through delegated permissions, reused tokens, or overly broad entitlements. If the organisation cannot distinguish human intent from agent execution, malicious actions can look like normal automation until damage is already done.
Impact: compromised agents can expose customer data, trigger unauthorised transactions, alter internal records, or perform lateral actions across connected systems with little immediate visibility. The resulting problem is not only breach exposure, but also loss of accountability for which action came from which authority.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 — Agentic Privilege Abuse | Agent workflows create privilege and delegation abuse risk |
| A4 — Tool Misuse and Overreach | AI agents act through tools across systems, widening misuse risk | |
| Recommendation — Constrain agent permissions to the minimum task scope and revoke standing authority. Restrict tool access per step and validate each tool call against policy. | ||
| NIST AI RMF | GV.1 — Govern AI Risk | The question is about governing AI agent identity and accountability |
| MAP.2 — Map Context and Intended Use | Agent identity depends on task context and delegated purpose | |
| Recommendation — Establish governance for agent authority, oversight, and accountability. Map each agent use case to its intended scope, users, and system interactions. | ||
| CIS Controls v8 | 6.3 — User Account Management | Agent identities need lifecycle control, revocation, and scoping |
| 8.2 — Audit Log Management | Agentic workflows require traceability across requests and actions | |
| Recommendation — Inventory, scope, and remove agent accounts and tokens when they are no longer needed. Log agent actions with enough context to reconstruct who authorised each change. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Excessive Privilege | AI agents often inherit broad machine access beyond their task needs |
| NHI-04 — Lack of Visibility | Traditional identity models lose visibility into agent actions and scope | |
| Recommendation — Minimise agent entitlements and remove any access that is not required for the workflow. Track agent identity, token use, and downstream system access end to end. | ||
Practitioner Guidance
What to prioritise: bind each agent to a bounded task, not a standing persona. The most important question is whether the agent can only do the action it was created to do, for the shortest useful time, with a traceable handoff from request to execution.
What to verify: confirm that logs preserve the full decision chain, including the initiating user, the agent instance, the tool used, and the downstream system touched. If any of those links are missing, the control model is already weaker than it appears.
Decision rule: if an agent can reach production systems or customer data, treat its access as high-risk by default and require explicit scoping, short-lived authority, and clear revocation paths before rollout. Broad reuse of the same access path across multiple workflows is usually the wrong baseline.
Practitioner takeaway: the test is not whether an AI agent can authenticate, but whether the organisation can bound, observe, and explain every action the agent takes once authentication succeeds.
