How many "service accounts" does your team run these days? Once it was a tidy list: a Stripe key here, a Snowflake credential there, each one a predictable piece of code with a fixed job. Now you're being asked to onboard AI agents that reach across APIs, databases, and tools, and the natural move is to file them in that same drawer. It's an understandable move, and it will undermine every control you've built.
Every core control in security sits downstream of identity. Authorisation asks "is this actor allowed this action?", audit asks "which actor did this?", and least privilege asks "what is the minimum this actor needs?". All three assume you have a trustworthy answer to "who". For a service account, you do. For an agent, you don't, and that gap is what this article is about. It is the identity half of a larger problem, mapped end to end in our guide to AI agent identity and runtime authorisation.
Why does agentic AI break the assumption that a credential names a bounded, attributable actor?
Enterprise security rests on a load-bearing premise: a credential names one known, bounded, attributable actor whose authority you can define up front. That premise is what makes a credential a meaningful unit of accountability.
Agentic AI breaks it. An agent can delegate across multiple hops, invoke tools on a user's behalf, and be redirected by prompt injection, so the actor behind a credential shifts mid-task and a valid identity can perform an invalid action. Yih Khai Wong of IDC Asia/Pacific put it plainly in an analysis of NIST IR 8587: "Token hardening assumes the token holder is a known, bounded actor. An agentic system breaks that assumption."
Delegation is the first crack. An agent acting for a user invokes a tool, which reaches another service, and so on, so a simple request becomes a chain: user to agent to tool to database. Each hop lengthens that chain until "whose authority is being exercised?" becomes unanswerable. The chain has to be captured in the log as it happens, and OAuth 2.0 was never built to express nested chains of one agent standing in for several principals. If you want to see how far that gap goes, the missing delegation primitive and the NIST IR 8587 scope gap pick up the thread.
Credential sharing and user impersonation are the failure mode when that chain collapses. Once "acting for a user" can't be told apart from "a shared credential acting loosely", attribution has no subject. It cuts both ways: a shared identity ties actions to no one, while an inherited token ties them to the wrong someone.
Prompt injection is the clearest example. A legitimate credential gets redirected toward an action the user never requested, and token verification won't catch it because the token itself is still valid. The identity stays intact while the action it authorises does not.
What is AI agent identity, and why is it the foundation of agentic AI security?
AI agent identity is the claim set that answers four questions: which actor is acting, for whom, within what scope, and across what lifecycle. Principal, delegator, scope, lifecycle. It's the foundation of agentic AI security because every downstream control depends on a trustworthy answer to those questions, and when identity is wrong, the controls fail.
The four-part claim is the unit of agent identity, and the agent identity and runtime authorisation picture shows how its parts fit together.
Agents sit inside the non-human identity (NHI) category, the umbrella that already holds service accounts, API clients, and workload identities. But they exceed it, and the difference is structural: agents add non-determinism and delegation that a static NHI record cannot express, as WorkOS explains. A service account's behaviour is defined in code and its scope is fixed at provisioning. An agent's behaviour is produced at runtime and its scope varies per task. Treat it as a variant and your business inherits real problems across authentication, authorisation, audit, and revocation.
Then there is machine-scale identity. Non-human identities already outnumber humans by a wide margin in the average enterprise, and agents multiply and churn faster than manual governance can track. That turns identity from a configuration task into a volume problem, and volume is only the first way agents strain access control. The second is non-determinism, which is where least privilege starts to behave differently.
Why does least privilege behave differently for non-deterministic agents than for deterministic services?
A deterministic service has a fixed permission surface known at provisioning time, so least privilege can be set once and stay correct. A non-deterministic agent's intent varies per task, so the permission set it needs can't be known in advance. Least privilege becomes a runtime property, evaluated per tool call, rather than a provisioning-time grant.
Non-determinism is the mechanism. As the agent's goals change mid-execution, a static permission set drifts out of scope, so the minimum access it needs isn't knowable up front.
The figures show guessing wide is the current default. Research from Enterprise Management Associates and Cequence Security, a survey of 202 enterprise technology and security leaders, found that 65% of enterprises have seen an agent act outside its intended scope. Yet only 32.7% provision least-privilege access scoped to the task. In other words, you grant wide because you can't predict narrow, then call it a security model.
So least privilege for AI agents relocates to the moment of action. The "necessary" permission set is evaluated against the originating request, using short-lived, task-scoped credentials, worked through in the authorisation gap piece. The standards and vendor backdrop is covered in the runtime authorisation pillar.
Conclusion
The bounded-actor assumption breaks structurally. It was built for a different kind of actor, and token hardening cannot restore it.
Rebuild on the four-part claim and the question changes from "who holds this credential?" to "which actor, for whom, within what scope, for how long?", answered at the moment of action.
That reframe is what relocates least privilege from a provisioning-time grant to a runtime property, and it's the change you carry forward into authorisation, audit, and access control. That change is the entry point to the wider agentic identity picture.
Frequently Asked Questions
What is a non-human identity (NHI), and is an AI agent one?
Non-human identity (NHI) is the umbrella term for any digital actor that is not a person: service accounts, API clients, workload identities, and digital certificates. An AI agent is an NHI, but it exceeds the category. Service accounts and API clients behave predictably and hold a fixed scope, while agents add non-determinism and delegation that a static NHI record cannot express.
Can I just give an AI agent a service account credential?
You can, but it will fail the controls that matter. A service account authenticates a workload whose behaviour is defined in code and whose scope is fixed at provisioning. An agent's behaviour is produced at runtime and its scope varies per task, so a service account leaves authorisation, audit, and revocation without a trustworthy answer. Issue short-lived, task-scoped credentials instead.
Isn't token hardening enough to secure an AI agent?
No. Token hardening confirms that a token is genuine, but as IDC's Yih Khai Wong notes, it assumes the holder is a known, bounded actor. An agentic system breaks that assumption. A perfectly valid token can carry the wrong actor once an agent delegates across hops or is redirected by prompt injection, so the credential stays intact while the action it authorises does not.
What is a delegation chain, and why does it matter for audit?
A delegation chain is the sequence of authority that runs from the originating principal to the agent and on to the tools it invokes. Each hop adds a link, and the chain answers who authorised which action. It matters because multi-hop delegation makes 'whose authority is being exercised' ambiguous, so the chain must be captured in the audit log rather than reconstructed afterwards.
What happens when an AI agent delegates to a sub-agent?
The sub-agent must receive a strict subset of the parent agent's authority, never the full permission set. The parent presents its workload identity plus a delegation scope, and the authorisation server issues a token bound to that narrower scope. Revocation also has to cascade, so withdrawing the parent's access immediately cuts off every sub-agent beneath it.
How do I apply least privilege to an agent when I cannot predict what it will do?
Move the decision to the moment of action. Evaluate each tool call against the specific user request that prompted it, and issue a just-in-time credential scoped to that task window rather than granting standing access. Because the necessary permission set is not knowable in advance, least privilege has to be enforced at runtime, not configured once at provisioning.
Can token verification catch prompt injection?
No. A prompt-injected action still arrives holding a valid, correctly signed token, so verification sees nothing wrong. The token proves possession, not intent. Catching this requires runtime context: whether the instruction came from a trusted source, whether the action was in scope of the original request, and whether the behaviour deviated from the agent's declared purpose.
What are the delegated, bounded, and autonomous agent authority models?
They describe who an agent acts for. A delegated agent acts on behalf of a named human, so its actions must trace back to that person. A bounded agent acts for a system or workflow, with no human subject in the chain and authority scoped to an operational boundary. An autonomous agent pursues a goal with minimal oversight and may spawn sub-agents.
Does Zero Trust already cover AI agents?
Not on its own. Zero Trust verifies identity and then trusts, but for agents it usually verifies only the token's validity. If a valid agent presents a valid token to perform an action the user never requested, standard Zero Trust allows it. Covering agents means verifying behaviour and intent alongside identity, which is a runtime problem rather than a one-time check.
Does an AI agent need its own identity, or should it act as the user?
It needs both, and they must stay distinct. The agent requires its own workload identity so its actions are attributable to a specific process, while a user-bound delegated token carries whose authority is being exercised. Collapsing the two into one credential is exactly what produces the attribution failure, because you can no longer separate the acting agent from the delegating human.
How many non-human identities does the average enterprise have?
Far more than people. The Cloud Security Alliance puts non-human identities ahead of human ones at a ratio of 144 to 1 in cloud-native environments, up from 92 to 1 in early 2024, while other surveys report figures around 45 to 1. Whichever number you use, agents multiply that population faster than manual governance can track, which is the machine-scale identity problem.
If an agent is compromised, how far can the damage spread?
As far as its standing privileges allow. An over-provisioned agent with long-lived credentials can act at machine speed, executing thousands of calls before a human even receives an alert, so the blast radius is effectively the permission surface you granted. Issuing short-lived, task-scoped credentials shrinks that window and limits how much a single compromise can reach.