An AI agent identity is what an agent acts with. In practice it is an account or a set of credentials, a scope that says which systems and actions are in reach, a named human owner, and a record of what the agent did and on whose behalf. Written down like that it sounds like every other non-human identity, and for the first three properties it is.
The fourth property has no precedent in a stack. A backup job does the same thing every night. An agent reads input it was handed, decides what to do, and picks which of its permissions to use to do it. That makes the scope of an agent's identity the control that matters, because everything else about its behaviour is decided after the grant.
human service account AI agent
----- --------------- --------
has a manager yes no no
in the HR system yes no no
acts on a schedule no yes no
decides at runtime yes no YES
acts for someone itself its job a person, or another agent
credential password+MFA a long-lived secret whatever it was handed
the delegation chain, which is the part that is new:
Ana --asks--> agent A --calls--> agent B --calls--> the CRM
| |
acts as Ana acts as agent A acting as Ana
the question at every hop: whose authority is this, and who approved itWhat does an agent identity have that other identities do not?
Four properties, and only the last is genuinely new.
It acts for someone
A human identity acts for itself, and a service account acts for the job it was created to run. An agent acts for a person, or for another agent that is acting for a person, and the record has to carry that. A commenter on a thread about an agent that published a hit piece asked the question the industry has not answered:
It does raise an interesting question whether AI Agents should be required to specify/identify their user. Otherwise, AI agents become a "anonymizer" for humans who want to act shitty on GH (or elsewhere) but want to pass it off as an AI agent
It decides at runtime
The permissions an agent holds and the permissions it uses on a given day are different sets, and nobody knows the second in advance. This is why a scope that is merely plausible is not enough: whatever is in reach will eventually be used, on input the owner did not write.
It chains
Agents call other agents, and authority passes along the chain, and by the third hop the scope granted at the first is usually unrecoverable. The practitioner answer is to bind authorization to the task rather than to the identity:
What seems more promising is accepting that the model will be tricked and constraining what it can do when that happens. Authorization at the tool boundary, scoped to the task and delegation chain rather than the agent's identity. If a child agent gets compromised, it still can't exceed the authority that was delegated to it.
It arrives without a purchase
A service account is created by IT or an engineer solving an operational problem. An agent is created by whoever is curious, in a tool they already have, using a credential to hand. There is no request, no ticket and no inventory entry, which is why most companies cannot say how many they have.
How does it compare with the identities a company already has?
| Employee | Service account | AI agent | |
|---|---|---|---|
| Created by | HR, through onboarding | An engineer, for a job | Anyone, in a tool they already use |
| Authenticates with | Password and MFA | A long-lived secret | Whatever it was handed, often a person's token |
| Acts | While present, in a session | On a schedule | On demand, deciding what to do |
| Acts for | Itself | Its job | A person, or another agent |
| Scope changes | At a role change | When the job changes | Never, while what it does changes constantly |
| Leaves when | HR says so | Someone remembers | Nothing says so |
Why the last two rows produce the incidents
The first four rows of that table explain why an agent feels new. The last two explain why agents cause incidents. An employee's scope changes at a role change and a service account's changes when its job changes, so both are corrected by an event someone can see. An agent's scope is set once and rarely revisited, while what the agent does with that scope changes every time its input changes. The leaver row is the same failure from the other side. An employee leaves when HR says so, a service account when somebody remembers, and an agent when nothing at all says so.
Iden treats an agent as an identity in the same table as the people: an owner, the applications it can reach, and a place in the access review. The Identities screen lists MCP tokens and agent accounts beside employees and service accounts, so the question of what an agent may reach has the same answer path as the question of what an employee may reach. The feature behind it is Service accounts, API keys and agents.
433 identities. 321 human, 112 not. cc_github and the MCP token sit in the same table as Amy Lee, with the same columns and the same offboarding states.
What does governing an agent identity require?
Five things, of which the first four are what every non-human identity already needs and the fifth is what agents add.
1An owner
A named human who answers for the agent, approves its scope and is the trigger for reassigning it when they leave. Ownership is what makes every other control enforceable, because a scope nobody approved cannot be narrowed with confidence and an expiry nobody owns is renewed by default.
2A scope
The smallest set of systems and actions the task needs, expressed as the credentials the agent holds rather than as an instruction in a prompt. A prompt that tells an agent to stay out of production is a preference. A token that cannot reach production is a control. The gap between the two shows up the first time the agent is handed input written outside the company.
3An expiry
A date on which the agent is re-justified or removed, with credentials short enough that a leaked one has a deadline. Expiry is the only control on this list that works while nobody is paying attention, and it is worth setting even on an agent whose scope is already narrow.
4A place in the review
The agent appears in the access review beside the people, routed to its owner. What it reached recently sits next to what it is permitted to reach. Reviewing an agent on its permissions alone reproduces the rubber stamp, because the permissions looked plausible when they were granted and look plausible now.
5A trail of actions rather than of permissions
For a service account, what it could do is a fair summary of what it did. For an agent it is not, because the two sets diverge every day. The record has to say what the agent reached, when, and on whose behalf, or nobody can answer the question after an incident. A register of agents is not an audit trail either, because the register holds what was granted and the question after an incident is always what was used.
Where do the standards stand?
Nowhere settled, and that is worth saying plainly rather than implying otherwise.
What exists today
SPIFFE gives workloads a verifiable identity and predates the agent wave, which makes it a good fit for a container and a poor fit for an agent an employee created inside a chat tool this morning. The Model Context Protocol authorization specification puts an OAuth model around tool access. An agent's reach into a tool can then be expressed as scopes and withdrawn as a grant. The IETF has draft work that treats agents as workloads, and NIST has asked for public comment on security considerations for AI agents.
What none of it settles
None of it yet answers what to write in an access review row for an agent, and three questions are open in particular. The first is what identifier travels along a delegation chain, so that a second-hop action can be traced to the person who started it. The second is who counts as the accountable party for an agent created inside a product rather than issued by IT. The third is what evidence an auditor should accept for an identity whose behaviour changes daily.
What to do while the standards move
The practical position for a company of 50 to 2,000 people is that the frameworks already apply. SOC 2 CC6 and ISO 27001 A.5.16 govern accounts, an agent has an account, and an auditor sampling accounts will eventually sample one. An agent with an owner, a scope, an expiry and a trail passes that sample. An agent running on an engineer's personal token does not.
How does SCIM treat agent identities?
SCIM does not reach them at all.
Why the protocol does not see them
SCIM provisions people from a directory into applications, and it carries the attributes a directory holds: a name, an email address, a group, an employment status. An agent has none of those attributes, and no directory record behind them. It is created inside a tool, with credentials handed to it by whoever was configuring the tool, and no directory event marks either its arrival or its departure. The protocol also pushes only what the directory knows, so an identity the directory never knew about stays invisible however well the connector works.
What covering them requires instead
Governing agents means reading each application's own lists: accounts, API tokens, OAuth grants and installed integrations. Those lists are reconciled, application by application, against a record of who owns what. That is the same coverage problem as every application outside SCIM, applied to the identities that change fastest and are created most casually. It is also the population nobody has a baseline for, so the first pass through it produces an inventory rather than a review.