Skip to main content
Sign in with Agent Loadout gives every agent its own verified identity at third-party apps. The agent is the subject of a standard OpenID Connect sign-in: the app receives a stable identifier, the agent’s inbox address and, when it asks and is allowed to know, the human owner behind the agent. No password and no Agent Loadout token ever reaches the app.

​
Why agents need their own sign-in

Agents that borrow a human’s login make every account look like that human. The app cannot tell one person’s ten agents from ten customers, cannot enforce per-human limits, and can only cut the agent off by changing the human’s password. With its own sign-in, an agent is a principal of its own: it has its own account at the app, receives the app’s email in its own inbox, and the human travels as a claim the app can read.

​
How a sign-in works

1

The app redirects

The app shows Sign in with Agent Loadout next to its other sign-in buttons. Clicking it redirects the agent’s browser to the issuer https://id.agent-loadout.com with an ordinary authorization code request.
2

The agent approves

The browser lands on a waiting page that shows what the app asks for. The agent approves with its own Agent Loadout token: the approve_sign_in MCP tool, agent-loadout sign-ins approve, or one REST call. The page continues on its own. A member of the agent’s workspace can approve in the dashboard instead, and a browser that holds one of the agent’s sign-in keys completes later sign-ins without asking.
3

The app verifies the token

The app exchanges the authorization code for an ES256-signed id_token and verifies it against the published keys, like any OpenID Connect provider. It keys the account on sub and reads the other claims it requested.
Agents do not need a browser of their own. Approving through the API returns the app’s redirect, which a headless agent follows itself. Agents can also start from their side: the list_sign_in_apps tool shows the directory of apps that accept the sign-in, and start_sign_in grants an app and returns a connect link that takes a browser straight into it.

​
What the app learns

Claims a scope did not unlock are left out, never sent empty.

​
Two kinds of apps

  • Open clients need no registration. Their client_id is the HTTPS origin they control, such as https://yourapp.com; the redirect URI sits on that origin; PKCE is mandatory. They may request openid, email and profile.
  • Registered applications are created under Sign-in apps in the dashboard or through the API. They get an opaque client_id, a client secret, up to ten redirect URIs including http://localhost for development, a sign-in history, the owner scopes, and a cap on sign-ups per owner.

​
The owner behind an agent

A registered application that requests owner_email receives the email address of the agent’s organization’s accountable owner, and never a successful sign-in without it. Agents can only share the owner when their token carries identity:share_owner; otherwise an owner or admin approves the sign-in in the dashboard. When an organization has several owners, the longest-standing one is reported unless an owner chooses someone else under Settings → Agent sign-ins. Even without the owner’s address, every app can key per-owner limits on owner_sub, which identifies the organization without naming anyone.

​
Remembered approvals and sign-in keys

An approval is remembered for 180 days per agent and app. The browser that started an approved sign-in, or opened a connect link, generates a sign-in key for the agent: a P-256 key WebCrypto keeps non-extractable, so scripts can sign with it but never read it. Every later sign-in is a fresh signature over a challenge; within the agent’s approvals it completes without anyone acting, and for a new app the browser offers one click. Agents that sign for themselves register a key of their own through the API. Keys lapse after 30 days without use. Both appear on the agent’s Sign-ins tab, where members forget an app or revoke a key. Forgetting an app asks again next time; the app’s own session is the app’s to end. A browser forgets its own key at agent-loadout.com/id/sessions.

​
Where to go next

  • App builders: OpenID Connect for apps has the endpoints, scopes, claims and setup for common auth platforms; CLI setup does it in one command; the brand page has the button.
  • Agent builders: Sign-in requests covers the capabilities, the MCP tools, connect links and sign-in keys.
  • Operators of apps: Applications registers apps through the API, lists them in the directory and lets agents start the sign-in.