Disclosure: BlueBear builds a platform that issues and scopes agent credentials, so we have a commercial interest. The properties described here are ordinary machine identity practice rather than anything proprietary; our own implementation appears only as one worked example of the shape.
The short answer: the agent needs to be someone, not something's side effect
AI agent identity is a credential and a set of attributes belonging to the agent itself, rather than to the application it happens to run inside. It says which agent this is, which boundary it belongs to, who it acts on behalf of, and what it is permitted to reach.
Most agents do not have one. They inherit an identity by accident: the agent runs inside an application, so it uses the application's database connection or API key. Nobody decided this — it is what happens when you add an agent to a system that already worked.
What that accident costs
| Inherited identity | Its own identity | |
|---|---|---|
| Attribution | Every action looks like the application's. You cannot say which were the agent's. | Actions are attributable to an actor |
| Scope | The agent reaches whatever the application reaches — always more than its job | Permissions can be narrowed to the job |
| Revocation | Cutting the agent off means breaking the application. In practice, a deploy. | A configuration change, in seconds |
| Accountability | "A system did it" | "This agent, acting for this team, inside this boundary" |
| Incident scope | Everything the application did in the window is suspect | Everything the agent did in the window is a query |
The revocation row is the one to feel in your stomach. In an incident, the question is how quickly you can make the agent's access unusable, and if the answer is "we would redeploy", your containment time is the length of your release process. The breach response playbook covers why that number matters more than almost anything else you prepare.
What an agent identity has to carry
Four attributes, and the third is the one people miss:
- Which agent this is — a stable identifier that survives redeployment.
- Which boundary it belongs to — the tenant or workspace, so its reach is bounded before any permission is considered.
- Who it acts for — the human or team behind it. An agent rarely acts for itself, and a record that names only the machine lets you say a system did something while leaving nobody responsible for it.
- What it may reach — the permitted operations, which is a separate subject covered in least privilege for AI agents.
Our own implementation is a reasonable illustration of the shape rather than the only one. Tenant API keys carry a subject type that is either the whole tenant or a specific user, so a key issued for one person cannot act as another; what is stored is a hash rather than the key, so a database read cannot recover a usable credential; the plaintext is shown once, which is why regeneration rather than retrieval is the recovery path; keys expire by default rather than living forever; and revocation is a status transition scoped to the boundary, so cutting one actor off is a local operation. There is also a database-level constraint enforcing one active key per boundary and subject, rather than an application check that reads and then writes and can race.
The rule that matters most
Everything above collapses if the boundary is taken from the wrong place, so it is worth stating on its own: the boundary must be established from the credential presented when the request is admitted, never from a value inside the request. A request that can nominate its own tenant is a request that can nominate someone else's.
A second rule with the same character: a machine credential should not be able to create credentials. A key that can mint keys is a privilege escalation path, and the clean design is that minting requires a human session. Ours refuses key management from an API key entirely, with a specific error rather than a generic denial, and refuses cross-boundary minting unless a human platform administrator is behind the session.
Identity is not authorisation, and confusing them is common
Identity says who. Authorisation says what they may do. Both are needed and they fail differently.
An agent with a good identity and no authorisation model can do everything, attributably — you will know exactly who caused the incident. An agent with narrow authorisation and no identity is well-contained and unattributable — you will know the damage was limited and not who to talk to.
Build identity first, because authorisation without it has nothing to attach to. AI agent identity and authorisation covers the pair together, and workload identity for AI agents goes deeper on replacing shared secrets in a machine-to-machine context.
If you operate in a regulated industry
Attribution is usually the first thing asked for and it is the hardest to retrofit, because an inherited credential leaves no trace that distinguishes the agent's actions from anything else. Giving the agent its own credential is cheap now and impossible retrospectively for history already recorded. The audit trail requirements list covers what the record needs alongside it.
If you are a platform or engineering lead
The test that settles whether you have this: can you revoke one agent's access without a deploy, and without affecting anything else? Try it in a non-production environment and time it. That number is worth more than a design document. Workspace boundary access control covers where the boundary is enforced.
If you resell this to customers
Identity has to be scoped per customer, and the operation that proves it is revoking one customer's agent without touching anyone else's. That is also the operation your contracts will eventually depend on. Multi-tenant isolation for buyers covers what to verify in a platform.
Do this next
Answer one question about your most consequential agent: whose credential is it using? If the answer is "the application's", you have found the change with the best ratio of effort to risk reduction available to you, and it is not a large piece of work. Then read least privilege for AI agents for what to do once the agent has its own credential, or what breaks when agents get production access for the wider picture.
Questions people actually search for
- what is ai agent identity
A credential and a set of attributes belonging to the agent itself, rather than to the application it happens to run inside. It says which agent this is, which boundary it belongs to, who it acts on behalf of, and what it is permitted to reach. Without one, everything the agent does is indistinguishable from everything the application does in every downstream system - which makes actions unattributable, permissions un-narrowable and access un-revokable without a deploy.
- why do ai agents need their own identity
Three things become possible and are otherwise impossible. Attribution: you can say which actions were the agent and which were the application. Narrowing: you can scope the agent permissions to its job rather than to whatever the application needs. And revocation: you can cut its access in an incident without breaking the application. All three are properties of the credential rather than of the agent behaviour, which is why no amount of prompt work substitutes.
- is an api key an identity
Only if it identifies one actor and can be revoked on its own. A key shared by an application and everything running inside it identifies a system, not an actor, and revoking it takes down everything. The practical test is whether cutting off one agent is a configuration change or a deploy. If it is a deploy, the key is a shared secret rather than an identity, whatever it is called in the documentation.
- what is the difference between agent identity and user identity
A user identity says who a person is. An agent identity says which agent is acting and, usually, on whose behalf. The second part is what makes it distinct: an agent is rarely acting for itself, so the credential needs to carry both the agent and the human or team behind it. A model that only records the machine leaves you able to say a system did something and unable to say anyone was responsible for it.
- how do you give an ai agent an identity
Issue it a credential of its own, scoped to a boundary and a subject; establish the boundary from that credential when a request is admitted rather than from anything in the request; store the credential as a hash so a database read cannot recover a usable one; and make revocation a status change rather than a code change. None of that is AI-specific - it is ordinary machine identity practice, applied to a component that people often forget is a separate actor.