What is Agent Identity

Agent Identity is the identity system built for a new kind of actor: it makes every AI agent identifiable, authorizable, accountable, and revocable.

This page is about something else — why "just make the existing identity system do it" doesn't work.

Three assumptions that no longer hold

Every building block in a traditional identity system — accounts, roles, scopes, API keys — rests on three assumptions nobody ever bothers to state:

1. Behavior is deterministic. The actor runs along fixed code paths: whatever endpoints it called yesterday, it calls today.
2. Permissions are static. Permissions are configured at design time — set once, valid for a long time.
3. Actions are predictable. Every possible call is written in the code, so an audit before release can enumerate them all.

An AI agent reasons at runtime. From one sentence a user types, it decides which tool to call, which data to read, which path to take. The same reporting agent that only pulls CRM summaries today might try to export the entire customer list tomorrow, because the user phrased the request differently. All three assumptions fail at once: behavior is no longer deterministic, permissions cannot be pre-provisioned, actions cannot be enumerated.

This is not a matter of degree that "tighter permission config" fixes. It is a matter of identity model type: you cannot enumerate an agent's behavior at design time; you can only constrain its permissions at runtime. And constraining permissions requires an identity first — one built for an actor that reasons at runtime.

An agent is not a user, and not a service account

Faced with a new actor, most teams reach for an old model first. Both directions have been tried. Both crash.

Treat it as a user — hand it a person's credential. Three problems appear immediately:

• Permissions are too broad. A person's credential represents everything that person can do, while the agent should only do the one thing in front of it.
• You can't take it back. Once a credential is shared, revocation means a full reset — which interrupts every session the person themselves has open.
• Audit goes blind. The log says "Zhang San did it" every time, with no way to tell which action was the person and which was the agent. When something goes wrong, the first one who can't explain it is Zhang San.

Treat it as a service account — issue a long-lived API key. Three more problems follow:

• Static. The key sits unchanged for months, while an agent's task boundary shifts by the minute.
• Unowned. The key has no idea who it is acting for right now, and by the time accountability matters, whoever created it has often left the company.
• Can't be narrowed on demand. A service account's permissions are a union — configured broadly to cover every possible task. An agent needs the opposite: the smallest slice for this one task.

There is only one conclusion. An agent needs a third kind of identity: first-class registration, a named responsible person, permissions that come from an explicit human delegation, short-lived by default, and narrowable layer by layer.

Three identities, one table

Dimension	Human account	Service account	Agent Identity
Credential lifetime	Session-scoped: login to logout, protected by MFA	Long-lived and static: one key for months or years	Task-scoped: minutes to hours, void on expiry
Permission granularity	Everything the person's roles allow	Fixed pre-configured scopes — the union of everything any task might need	The smallest slice per delegation, never broader than the delegating person's own permissions
Accountability	The person	Frequently unclaimed — whoever created the key has left	Bound to a responsible person at registration; every action traces back to the person who delegated it
How you revoke	Disable the account, change the password	Rotate the key, and every dependent system follows	Short-lived tokens go void on expiry; disabling the key cuts off new issuance instantly (give each agent its own key and no agent takes down another). Tokens already issued run until they expire — see Revocation and emergency response
Behavior pattern	Human judgment; you can ask the person directly	Deterministic code paths	Runtime reasoning, dynamic decisions — only permission boundaries hold it; code review will never enumerate it

Five design principles

A credible agent identity system satisfies five principles at once. The first three are old principles from the identity world that have to be re-earned in agent scenarios; the last two are new to the agent era.

1. Least privilege — every agent action needs explicit authorization; scope narrows to the task at hand instead of widening for "what it might need later."
2. Auditability — every audit record answers three questions: who authorized, who was authorized, what was done. The token names both the delegating person and the actual actor; neither subject can be missing.
3. Revocability — credentials are short-lived by default and go void on expiry; new issuance can be stopped at any moment, and the resource side has a way to block requests. However long the validity window is, that is how large your risk window is — the layered controls and their respective timings are in Revocation and emergency response.
4. Explainability — new in the agent era — the agent must be able to tell the user "these are the permissions I hold right now, this is the grant they came from, this is when they expire." A grant the user can't understand isn't a real choice.
5. Attenuation — new in the agent era — permissions may only narrow as they pass along, never widen; that is attenuation. A subtask always receives a smaller slice, and it expires as soon as the work is done.

Next steps

• Why Agent Identity — incidents, numbers, and standards frameworks: ignoring this already has a price tag.
• What is GenAuth — what the system is made of, and how far each piece has shipped.
• The full journey of one delegation — 8 moments covering the whole life of "a person hands permissions to an agent."
• Glossary and migration — the authoritative terms used on this page.