Most AI agents in production today run on a credential that belongs to someone else: an API key copied from a developer's laptop, a service account shared by five automations, or a person's own access token pasted into a config file. That works until you need to answer three questions. Which agent did this? What was it allowed to do? How do we stop that one agent without breaking everything else?

Agent identity is the set of mechanisms that lets you answer those questions. This post explains what it is, what it is made of, and how it differs from the identities you already manage for people and services.

Why borrowed credentials fail

There are two common shortcuts, and each fails in its own way.

Borrowing a person's token

If an agent runs with a person's token, every system it calls sees that person. The audit log says a developer deleted the branch when a model decided to delete it. The agent also inherits everything that developer can do, which is almost always far more than the task needs. And when the developer leaves, or their session is revoked, the agent stops with no warning.

Sharing an API key

A shared static key has the opposite problem. Nobody is accountable for it. It does not expire. Every copy is equally valid, so you cannot tell which holder made a call, and you cannot revoke one holder without rotating the key for all of them. If an agent leaks it through a prompt injection, the attacker has the same standing as the agent, indefinitely.

Both shortcuts share a root cause: the agent has no identity of its own, so nothing can be said or decided about it specifically.

What an agent identity consists of

An identity for an agent is not a single field. It is a small set of things that together let other systems recognise the agent, decide for it and hold someone to account.

  • A stable identifier. A name that means this agent and no other, and that stays the same across restarts and redeployments. The SPIFFE ID format (spiffe://trust-domain/path) is a common choice for workloads and fits agents well.
  • A credential only the agent holds. Ideally a private key generated where the agent runs, with only the public half registered. A key pair cannot be copied out of a database the way a stored secret can, and proving possession does not require sending the secret anywhere.
  • An accountable party. A named person or group that answers for the agent. Without one, approvals have nowhere to go and incidents have no owner.
  • Permissions that belong to the agent. What it may call, and with what limits, recorded against the agent rather than inherited from whoever started it.
  • Short-lived tokens. What the agent presents to an API should expire in minutes and name the API it is meant for.
  • A record. Every sign-in, call and refusal attributed to the agent's own identifier.

How an agent proves itself

The standard way to authenticate a client with a key pair is the JWT client assertion defined in RFC 7523. The agent signs a short statement with its private key, and the authorisation server checks the signature against the registered public key. The claims look like this:

{
  "iss": "agt_7f3a9c21",
  "sub": "agt_7f3a9c21",
  "aud": "https://auth.example.com/token",
  "jti": "b1f6c0de-41a7-4a39-9d6e-2f6f5c9a7e10",
  "iat": 1790000000,
  "exp": 1790000060
}

The assertion lives for seconds, and the jti value lets the server refuse a second use. A stolen assertion is close to worthless. In exchange the agent receives an ordinary OAuth access token.

Acting as itself or acting for a person

Agents work in two modes, and an identity system has to tell them apart.

Acting as itself

A nightly agent that reconciles invoices has no user in the conversation. It authenticates with its own credential (the OAuth client credentials grant) and acts under its own permissions. Its accountable party is the team or group that operates it.

Acting on behalf of a person

A coding assistant or a support copilot works for whoever is using it. Here the right pattern is delegation, not impersonation. The person signs in through a normal authorisation code flow, and the agent obtains a token that names both parties. OAuth token exchange (RFC 8693) expresses this with an act claim:

{
  "sub": "user_4821",
  "act": { "sub": "agt_7f3a9c21" },
  "aud": "https://api.example.com",
  "exp": 1790000900
}

The API can now see that the request is for user 4821 and is being made by a specific agent. The important rule for delegation is an intersection: the agent should be able to do only what both the person and the agent itself are permitted to do. Delegation must never be a way for a person to gain an agent's rights, or for an agent to gain all of a person's.

The lifecycle of an agent identity

Identities for people have joiner, mover and leaver processes. Agents need the same, on a faster clock.

  1. Register. Someone with authority creates the agent, records its owner and registers its public key.
  2. Grant. Permissions are added one at a time, each with its limits. The default is nothing.
  3. Operate. The agent signs in, receives short tokens and makes calls. Each is recorded.
  4. Rotate. Keys are replaced on a schedule or after a suspected exposure, without changing the identifier.
  5. Review. Owners change jobs. An agent whose owner has left needs a new one, or it should be retired.
  6. Revoke. One action stops the agent: no new tokens, and enforcement points refuse the tokens it still holds.

The last step is the test of whether you have agent identity at all. If stopping one agent means rotating a key that other things depend on, you do not.

How AuthFI does it

AuthFI's AI Auth gives each agent its own identity using published OAuth standards.

An admin registers the agent with its public key and a named owner. No secret is issued. The agent is either delegated, with an owning person, or autonomous, with a group that answers for it. Each agent is also assigned one identifier in SPIFFE form.

To sign in, the agent signs a short assertion with its own key (RFC 7523). The assertion is good once, and only for a short time. In return it receives a 15-minute access token signed by the project's key, carrying only what the agent was granted. An agent acting for a person gets only what that person approved, and never more than the agent itself was granted.

Revocation is one switch. No new token is issued, the tool gateway refuses the agent's next call, and enforcement points are told. Every sign-in, grant, approval and refusal lands on the same audit record that people's actions do.

Agents registering themselves is in development; today registration is an admin action.

Identity is only the first step. Once an agent is recognisable, you can decide what it may touch and when it must ask a person.

Key takeaways

  • An agent running on a person's token or a shared key cannot be limited, audited or stopped individually.
  • An agent identity is an identifier, a credential only the agent holds, an accountable owner, its own permissions, short tokens and a record.
  • Use delegation with an explicit actor claim when an agent works for a person, and let it do only what both parties are allowed to do.
  • Treat revocation of a single agent as the acceptance test for your design.