Skip to main content
When an app shows Sign in with Agent Loadout, clicking it brings the agent’s browser to a waiting page with a sign-in request id (alsi_…). The agent approves that request with its own token, or a sign-in key it holds answers on its own. The page continues by itself; a headless agent follows the returned redirect.

​
Capabilities

Without identity:share_owner, an agent cannot approve a request from a registered application that asks for owner_profile or owner_email. An owner or admin of the workspace approves such a request in the dashboard instead.

​
MCP tools

Read the request first: will_share lists exactly what the app receives from this agent, and problems names what stands in the way (no_inbox, owner_share_not_permitted, owner_unavailable, not_pending). Approve only requests the agent itself started.

​
Approving a request

Read a sign-in request
Approve it
​
string
The app’s callback URL with the authorization code. The waiting page follows it within two seconds; an agent without a browser follows it with its own HTTP client, cookies included, to finish signing in at the app.
POST /api/v1/sign-ins/:id/deny ends the request without a token.
CLI

​
Starting a sign-in from the agent’s side

An agent does not have to find the app’s login page first. list_sign_in_apps (or GET /api/v1/sign-in-apps, or the public directory) lists apps that accept the sign-in; start_sign_in with an entry’s client_id grants that app now, with the same checks as approving, and returns two things:
  • url: a single-use connect link, valid five minutes. The browser that opens it generates a sign-in key for the agent and continues to the app’s login start, where the app begins its sign-in and the key completes it without anyone acting.
  • app_login_url: the app’s login start with iss and login_hint, for an agent without a browser. Follow it with an HTTP client; the app redirects to a new sign-in request, which the agent approves through approve_sign_in.
REST
Apps that set a login start URL show can_start_sign_in: true in the directory; for the others the link enrols the browser and sends it to the app’s website, where the agent clicks the button. Without client_id, the link only enrols a browser for the agent.
CLI

​
Sign-in keys

A sign-in key is a P-256 pair whose private half never leaves the place it was made. There are two kinds:
  • Browser keys. The browser that started an approved sign-in, or opened a connect link, generates a non-extractable WebCrypto key and registers the public half. From then on the browser signs in the agent to apps it already approved by signing a fresh challenge, and offers one click for a new app. Browser JavaScript cannot read or export the key; it can only sign with it.
  • Registered keys. An agent that signs for itself registers the public half of its own key with POST /api/v1/sign-ins/keys and then answers sign-ins without a browser: fetch a challenge from https://agent-loadout.com/id/challenge?purpose=sign-in&subject=alsi_…, sign it with ES256 and post { kid, challenge, signature } to https://agent-loadout.com/id/sign-ins/alsi_…/assert. Within the agent’s grant the request is approved at once; otherwise the answer is needs_approval, and a second assertion with "approve": true approves it.
A key may share the owner when the token that enrolled or registered it had identity:share_owner. Keys lapse after 30 days without use; every use extends them. The agent lists and revokes its keys with GET and DELETE /api/v1/sign-ins/keys, members do the same on the agent’s Sign-ins tab, and a browser forgets its own key at agent-loadout.com/id/sessions.
CLI

​
What the agent gives the app

The app receives an OpenID Connect id_token naming the agent: a stable sub, the agent’s inbox address, its name and username, and an identifier of its organization. A registered application that asked and was allowed to know also learns the organization’s accountable owner. The app never receives the agent’s Agent Loadout token, a password or access to its inbox. Everything the app sends to the agent arrives in the agent’s inbox, where it reads it. An agent needs a ready inbox to approve a request that asks for email.

​
Remembered approvals

An approval is remembered for 180 days per agent and app; a sign-in key completes later sign-ins at that app for the granted scopes without any call. A request for new scopes shows the waiting page again, where the browser’s key offers one click. Members see remembered apps on the agent’s Sign-ins tab in the dashboard: forgetting an app asks again next time, revoking a key stops its automatic sign-ins.