How agent sign-in works

How an AI agent gets an identity, a short-lived access token and permission for a single action, and which standard each step follows.

An AI agent in AuthFI is a first-class identity, like a person or an application. It has its own key, its own permissions and a named owner. It never shares a password or an API key with anything else.

AuthFI does not define a new protocol for this. The AuthFI Agent Profile is a profile of published standards: OAuth 2.0 and its extensions, OpenID CIBA and OpenID Shared Signals. Where no standard covers a step, AuthFI adds a small extension and names it as its own. Any client that speaks OAuth 2.0 can act as an agent. This page explains the model. To try it, follow Give an AI agent an identity.

From registration to an approved action

An agent goes through up to five stages. Most calls need only the first three.

1. Register. An administrator registers the agent in the console with a name, an owner and the agent's public key. The private key stays with the agent.
2. Sign in. The agent proves who it is by signing a short statement, a client assertion, with its private key. This is the private_key_jwt method (RFC 7523). An assertion is accepted once.
3. Get an access token. AuthFI returns an access token signed with the project's key. It lasts 15 minutes and follows the JWT access token profile (RFC 9068), so any service can validate it offline.
4. Bind a token to one action. Before a sensitive action, the agent exchanges its access token for a transaction token that names that one action and its details. It lasts 60 seconds.
5. A person decides. When your rules require it, the action waits until a named person approves or denies it. When an agent acts for a person who has no browser in front of them, such as a caller on the phone, the person approves on their own device through OpenID CIBA.

Why an agent holds a key and not a secret

A shared secret can be copied, and nothing shows that it was. An agent's private key never leaves the agent. AuthFI holds only the public half, which can verify a signature and cannot create one.

Each sign-in uses a fresh assertion that expires within 5 minutes and is accepted once. A captured assertion cannot be replayed.

Two types of agent

Every agent is one of two types. The type is set at registration and appears in every token as agent_type.

A delegated agent works on behalf of one person and can do only what that person approved. An autonomous agent works on its own, and a group of people is accountable for it.

What an agent is allowed to do

An agent starts with no permissions. It holds a permission through a role, as a person does, and an administrator grants it capabilities that can carry limits on that permission. A permission names an action on one kind of thing, such as transfer:accounts.

A limit is a condition on the details of an action.

A token carries the names of the agent's capabilities and never their limits. AuthFI keeps the limits and checks them each time the agent acts. Because of this, a changed limit applies to the agent's next call, with no need to issue a new token.

For the full rules, see Limit what an agent may do.

How a token is tied to one service

When an agent asks for a token, it names where it will use it with the resource parameter (RFC 8707). That value becomes the token's aud claim.

A service must accept a token only when aud names that service. This stops a token issued for one service from being used at another. An agent can name only the targets it has been granted. Any other target returns invalid_target.

How a client finds the endpoints

A client reads the endpoints from the project instead of hard-coding them.

curl https://acme.authfi.io/.well-known/oauth-authorization-server
curl https://acme.authfi.io/.well-known/agent-configuration

The first document is standard OAuth authorization server metadata (RFC 8414). The second adds what is specific to agents, such as the approval methods. Both are described in the discovery reference.

Next steps