An AI agent identity is a record that names one specific agent. The record says who owns the agent, how the agent proves who it is, and what the agent may do. Every token that the agent receives points back to that record, so every action can be traced to it. “One agent, one record” means exactly that: however many credentials an agent uses, they all lead to the same record. Permissions, budgets, approvals, audit entries and revocation all refer to that one record.
TL;DR
- An AI agent is a third kind of principal, next to people and OAuth clients. It acts for a person, runs as software, and chooses its next step at runtime.
- Borrowing the user’s token hides the agent from the audit log. A shared API key hides which agent acted, and nobody owns it.
- The record for an agent holds an owner, an identity type, credentials, a capability list, a delegation setting, a status and usage data.
- “One agent, one record” means every credential resolves to the same record, so one suspend action can end every token and grant that the agent holds.
What is an AI agent identity?
In identity systems, a principal is anything that can be authenticated and given permissions. For twenty years there were two kinds. People sign in with a password, a passkey or single sign-on. Applications authenticate as OAuth clients with a client ID and a secret or a key.
An AI agent fits neither. Like an application, it is software. Like a person, it makes choices: a language model reads a goal, picks a tool, reads the result and picks the next tool. It often acts for a specific person, with that person’s data. And it takes instructions from text that it reads, including text that an attacker wrote.
An agent identity treats the agent as its own principal. It answers four questions that security teams ask after any incident:
- Which agent was this? Not “the API key” or “the integration”, but one named agent.
- Who is responsible for it? A named owner, who answers for its configuration.
- What was it allowed to do? A fixed list of capabilities, checked on every request.
- For whom was it acting? The person whose authority it used, recorded next to the agent.
If your system cannot answer all four from its logs, your agents do not have identities yet. They have credentials.
Why can’t an agent use the user’s login or a service account?
These are the two shortcuts that most teams take first. Both work in a demo, and both fail in production.
Borrowing the user’s token. The agent receives the user’s access token and calls APIs with it. Every request appears to come from the user. The audit log records that the person issued a refund, and has no record of the agent. The agent also gets everything that the user can do, for as long as the token is valid. A research assistant that only needs to read tickets can then also close accounts.
A shared service account or API key. The team creates one key and puts it in an environment variable. Soon three agents, a cron job and a staging deployment use the same key. When something goes wrong, the log says “the key did it”. Rotating the key breaks every program that uses it, so it rarely gets rotated. Nobody owns it, so nobody reviews what it can do.
The cost of these shortcuts shows up in three places:
- Attribution. You cannot tell which agent acted, or for whom.
- Blast radius. A hijacked agent holds broad, long-lived access. Prompt injection turns that access into the attacker’s access.
- Revocation. You cannot stop one agent without breaking others, and you cannot be sure that every copy of its secret is gone.
What does “one agent, one record” mean?
It means that each agent has exactly one record, and everything about the agent is attached to it. An agent may authenticate in several ways over its life. Each way still resolves to the same record.
| How the agent authenticates | What it presents | Resolves to |
|---|---|---|
| OAuth client credentials | Client ID and a hashed secret or a private key | The agent record |
| Workload identity | A signed token from GitHub Actions, Kubernetes, a cloud or SPIFFE | The agent record |
| Signed requests (AAuth) | Requests signed with the agent’s own key (RFC 9421) | The agent record |
| Agent API key | An agk_ key, hashed at rest |
The agent record |
Because there is one record, every other control can refer to it:
- Permissions name the agent, not a key: “agent
agt_…may read invoices”. - Approvals show the reviewer which agent is asking, who owns it, and for which person.
- Budgets count calls and spend per agent, across all of its credentials.
- Audit entries carry the agent’s identifier as the actor, so one filter shows everything that it did.
- Revocation acts on the record. Suspend it, and every token, grant and key that points at it stops working.
The opposite model is “one credential, one identity”. There, an agent with a client secret and a workload binding looks like two principals. Permissions must be granted twice and revoked twice, and the audit trail splits in two.
What belongs on an agent’s record?
The fields below are what an agent identity needs, whichever product you use. The right-hand column shows why each one matters.
| Field | Example | Why it matters |
|---|---|---|
| Identifier | agt_3f9c… |
A stable name for logs, policies and tokens |
| Owner | A person in your organization | Someone answers for the agent and reviews it |
| Identity type | Workload, client credentials, AAuth, API key | Sets how the agent may prove who it is |
| Credentials or bindings | A workload binding such as github:acme/support-bot |
Ties the record to something that the agent can prove |
| Capabilities | tickets.read, refunds.* |
The upper limit of what the agent may ever do |
| Acting for people | On or off | Whether the agent may use a person’s authority |
| Budget | 1,000 calls a day, $50 a month | A hard stop on runaway loops and cost |
| Status | Active, suspended, revoked | One switch that every check reads |
| Usage | Last used, last attested | Finds dormant agents and stale credentials |
Two rules make these fields useful. First, capabilities should only narrow. A token for one task carries a subset of the agent’s capabilities, never more. Second, nobody should grant an agent more than they hold. If you cannot issue refunds, you should not be able to create an agent that can.
Why should you care now?
Three trends make agent identity urgent.
Agents call real APIs. The Model Context Protocol (MCP) gives agents a standard way to call tool servers. That makes it easy to connect an agent to a CRM, a payment system or a code repository. Each connection is an access decision, and each one needs a principal to decide about.
Agents run without a person watching. Background agents work through queues at night. If one goes wrong at 2 a.m., the on-call engineer needs to know which agent it is, who owns it and how to stop it. Those answers should come from a record, not from searching a Slack channel.
Auditors ask about agents. Access reviews, incident reports and privacy requests all ask the same question: who accessed this data, and why? “An API key” is not an answer that an auditor accepts. “Agent agt_…, owned by the support team, acting for this customer, approved by this reviewer” is.
How is agent identity different from workload identity?
They solve different problems, and agents usually need both.
| User identity | Workload identity | Agent identity | |
|---|---|---|---|
| Names | A person | Where code runs | One agent and its purpose |
| Proves itself with | Passkey, password, SSO | A token from its platform | Any of its bound credentials |
| Typical standards | OpenID Connect, WebAuthn | SPIFFE, platform OIDC tokens | OAuth 2.1, token exchange, HTTP message signatures |
| Acts for others | No | No | Often, and the token says so |
| Decides at runtime | Yes | No | Yes |
Workload identity is the best way for an agent to prove who it is, because it removes the stored secret. The platform signs a short-lived token that says “this code runs in this repository” or “this pod runs as this service account”. The agent identity is what that proof resolves to: the record with the owner, the capabilities and the budget.
When an agent acts for a person, a third piece joins: delegation. OAuth token exchange (RFC 8693) issues a token whose subject is the person and whose act claim names the agent. The API that receives the token sees both, and so does the audit log. Agents that call other agents add one level to the act chain at each step.
How LumoAuth does it
LumoAuth puts every agent in one registry. In the Organization Portal, go to Agents (/portal/agents) and register an agent with the three-step wizard:
- Who is this agent: the name, description, owner and framework.
- How it proves its identity: one of seven identity types (
workload,api_key,client_secret,client_credentials,certificate,aauth,custom). The type is fixed after registration. - What it may do: capabilities, whether it may act on behalf of users, and its budget and limits.
The agent receives an identifier such as agt_3f9c…. Client credentials, workload attestation and AAuth signed requests all resolve to that record. The rest of the product reads the same record:
- Capabilities are stored in one standard form (lower-case, with
.as the separator). Wildcards are limited to*andprefix.*. The person creating an agent cannot grant capabilities that they do not hold. - Acting for people is off by default. Turn on May act on behalf of users before the agent may request a person’s authority.
- Status is
active,inactive,suspendedorrevoked. Revoked is final. - The kill switch suspends, revokes or deactivates the agent in one step. It revokes the agent’s OAuth and AAuth tokens, its pending and approved just-in-time requests, and its token vault grants. It can also send a CAEP event to your other systems and revoke the agent’s AI-gateway keys.
- Dormancy is checked daily. By default, an agent that nobody has used for 90 days becomes
inactive. - Audit records every action with the agent’s identifier as the actor, including the full
actchain when the agent acts for a person. - End users see the agents that act for them at My agents (
/account/my-agents) and can revoke each one.
The docs for the agent registry cover the wizard and the API. The architecture overview shows how one request flows from attestation to audit.
Standards involved
- OAuth 2.1 for client credentials and access tokens
- OAuth 2.0 token exchange, RFC 8693, including the
actclaim for delegation - HTTP message signatures, RFC 9421, used by AAuth to sign agent requests
- SPIFFE JWT-SVIDs and platform OIDC tokens for workload identity
- Shared Signals Framework with CAEP, to tell other systems when an agent is revoked
- The Model Context Protocol authorization specification, for agents that call MCP servers
The full list is on the standards reference.
FAQ
Is an AI agent identity the same as a service account? No. A service account names a workload and is often shared by many programs. An agent identity names one agent, has a named owner and a fixed list of capabilities, and can act for a person while the record keeps both names.
Should each running copy of an agent get its own identity? Usually not. Register one identity per agent, meaning one purpose and one owner. Ten replicas of the same support agent share one record, and the audit log tells them apart by request data such as the IP address and trace ID. A different purpose or a different owner is a different agent.
Does an agent identity need a secret? Not when the agent runs on a platform that can vouch for it, such as GitHub Actions, Kubernetes or a major cloud. The agent exchanges the platform’s signed token for its own token. A signing key that never leaves the agent is the next best option. A long-lived API key is the last resort.
What happens to the user’s identity when an agent acts for them?
It stays in the token. With OAuth token exchange (RFC 8693), the subject is the person and the act claim names the agent. The API that receives the token can check both, and the audit log records both.
How do I revoke an agent? Suspend or revoke its record. Because every credential and grant points at that one record, one action ends all of them. In LumoAuth this is the kill switch.
Related: AI agent identity on the solutions pages, and why we built LumoAuth on this blog.
Register your first agent at app.lumoauth.dev/register.