How is an agent identity different from a service account?

It is the same kind of thing, used differently. A service account authenticates a program whose behaviour is fixed at deploy time, so its permissions can be scoped to what that code does and left alone. An AI agent authenticates with a credential of the same shape, but decides its next action from the model at runtime, so the same identity now stands behind a range of behaviour no permission list was written against.

Does a non-human identity control what an AI agent does?

It controls what the agent is permitted to reach, not what it does with that reach on a given turn. Identity and its permissions set the outer boundary: which systems, which scopes, which roles. Inside that boundary an agent still chooses each action, and two actions that are both inside the boundary can be one the operator wanted and one an attacker induced. The credential cannot tell them apart, because it is the same key doing both.

What are the OWASP Non-Human Identities Top 10 risks?

The OWASP Non-Human Identities Top 10 (2025) lists improper offboarding, secret leakage, vulnerable third-party NHI, insecure authentication, overprivileged NHI, insecure cloud deployment configurations, long-lived secrets, environment isolation, NHI reuse, and human use of NHI. Nine of the ten concern the lifecycle of the credential itself. The tenth, overprivileged NHI, is the one that touches what the identity may do, and it is answered by scoping permissions rather than by judging actions.

If an agent is authenticated and authorized, can it still do harm?

Yes, and this is the case identity does not cover. Authentication confirms the key is genuine and authorization confirms the action is within the role. An agent talked into deleting a production database with a valid, adequately scoped token passes both checks and destroys the data anyway. Nothing about the identity was compromised. The gap is between having the authority and this particular use of it being the one intended.

Reference · Updated 2026-09-18

What Is a Non-Human Identity?

A non-human identity is the credential an automated actor authenticates with: a service account, an API key, an OAuth token, a workload identity. It answers who is calling. It does not answer whether the call is one the caller should be making right now, because a credential is issued once and read at every use, while an agent decides what to do turn by turn.

Non-human identities outnumber human ones in most production environments by a wide margin, and securing them is its own discipline with its own tooling and its own OWASP list. This page is about what that discipline covers, why an autonomous agent puts a new kind of weight on it, and where the identity question ends and a different question begins.

What counts as a non-human identity?

A non-human identity, or NHI, is any credential that authenticates something other than a person. Service accounts, API keys, OAuth client credentials, workload identities, signed tokens, and the certificates that identify one service to another are all NHIs. They exist because software has to prove who it is to other software, and a human login is the wrong shape for that: no password to type, no second factor to approve, no session that ends when someone goes home.

The discipline around them is mature. You rotate the secret, scope it to least privilege, store it somewhere it cannot leak, retire it when the workload retires, and keep an inventory so none go unaccounted for. The OWASP Non-Human Identities Top 10 (2025) is the field's checklist, and it is worth reading as one: improper offboarding, secret leakage, overprivileged identities, long-lived secrets, and reuse are all failures of how a credential is issued, stored, and retired.

What does the OWASP NHI Top 10 actually cover?

Read the ten in order and a pattern appears. Nine of them are about the credential's lifecycle: how it is created, where it lives, how strong it is, how long it lasts, who inherited it, and whether anyone remembered to revoke it. These are real risks and the tooling that addresses them, secret managers, rotation, workload identity federation, is genuinely good.

One risk on the list, overprivileged NHI, is about what the identity is permitted to do rather than about the secret itself. Its fix is least privilege: give the identity the narrowest set of permissions its job requires. That is the correct fix, and it is where identity's answer to "what may this actor do" runs out, because least privilege is decided once, against the job as it was understood at issue time. It sets a boundary. It does not watch what happens inside the boundary.

Why does an AI agent strain the identity model?

A service account has historically stood behind fixed behaviour. The code that holds it does one job, so its permissions can be scoped to that job and left alone; the identity and the behaviour are pinned to each other. Least privilege works well precisely because the privilege and the use are decided together and neither moves.

An AI agent breaks that pairing. It authenticates with a credential of exactly the same shape, but its behaviour is not fixed at deploy time. It is chosen at runtime by a model reading instructions, some of which arrive from outside, from a retrieved document, a tool result, a message from another agent. The identity is stable; the behaviour behind it is now a moving range. Scope the permissions tightly and a wide band of actions still sits inside them, and an attacker who cannot steal the key does not need to: they only need to influence which in-scope action the agent takes next. OWASP's 2026 list for agentic applications names this ASI03, Agent Identity and Privilege Abuse, as a distinct risk for exactly this reason.

Where does identity stop and action governance start?

Draw the line as two questions. Who is calling is the identity question, and NHI tooling answers it well: authenticate the credential, check it against the role, reject it if it is unknown, expired, or out of scope. Is this call the one the caller should be making right now is a different question, and it is not answerable from the credential, because the credential is the same on the call you wanted and the call an attacker induced.

Answering the second question means looking at the action itself at the moment it is attempted: is the content of it hostile, is it inside the task the agent was actually declared for, and does it fit what this session has been doing. Those are judgements about an action, made per action, against a declared purpose, not judgements about an identity made once at issue time. This is the distinction between authentication and authorization taken one step further: even a correctly authenticated, correctly authorized action can be the wrong action, and the layer that catches that is not the identity layer.

The two are complements, not competitors. Identity sets the ceiling; nothing an agent does should ever exceed the permissions its NHI holds. Action governance works inside that ceiling, on the actions the identity is allowed to attempt, deciding which of them proceed. A deployment wants both: a tightly scoped identity so the blast radius is bounded, and an action-time check so that a compromised-in-behaviour agent inside those bounds is still stopped before it commits the damage.

How should you divide the work?

A practical split, once you accept the two questions are different:

Give the identity layer the lifecycle. Rotate secrets, federate workload identity, scope to least privilege, offboard on retirement, inventory everything. The OWASP NHI Top 10 is the checklist and existing tooling covers it well.
Give the action layer the runtime decision. Judge each consequential action as it is attempted, against a declared purpose for the agent and against what the session has done so far, with a human in the loop for the actions that warrant one.
Do not ask either to do the other's job. A secret manager cannot tell a good action from a bad one, and an action check is not where you rotate a key. Overprivilege reviews and action adjudication are both necessary and neither substitutes for the other.

What is action governance? The action-layer question stated in full, and why an agent cannot govern itself.
Four approaches to governing an agent: where credential scoping stops and action-time adjudication starts.
The 14 governance surfaces of an AI agent: every surface an identity's actions can touch.
When does an AI agent need governance? The point at which a scoped identity stops being enough.

Sources

Shrike is the action layer described above. An operator declares what an agent is for and which tools it may use, and each action is judged against that declaration at the moment it runs, independent of the identity the agent authenticates with. See action governance for what the layer does, or agent scope for how the declaration works.