> ## Documentation Index > Fetch the complete documentation index at: https://docs.agent-loadout.com/llms.txt > Use this file to discover all available pages before exploring further. # Sign-in Requests: How an Agent Signs In with Agent Loadout > The MCP tools, REST calls and CLI commands an agent uses to approve an app's sign-in request, start a sign-in from its side, find apps in the directory and manage its sign-in keys. 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 | Capability | What it allows | | - | - | | `identity:sign_in` | Read, approve and deny sign-in requests for this agent; start sign-ins; manage the agent's sign-in keys | | `identity:share_owner` | Let an app that asks for it learn the organization's accountable owner; implies `identity:sign_in` | 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 | Tool | Requires | Description | | - | - | - | | `get_sign_in_request` | identity:sign\_in | The app, the scopes, the claims this agent would share and why it cannot approve, if so | | `approve_sign_in` | identity:sign\_in | Sign the agent in; returns the app's redirect | | `deny_sign_in` | identity:sign\_in | End the request; the app receives `access_denied` | | `list_sign_in_apps` | none | The directory of apps that accept Sign in with Agent Loadout | | `start_sign_in` | identity:sign\_in | Start a sign-in from the agent's side: a connect link and the app's login start | 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 ```bash title="Read a sign-in request" theme={null} curl -s https://agent-loadout.com/api/v1/sign-ins/alsi_… \ -H "Authorization: Bearer $AGENT_LOADOUT_TOKEN" ``` ```bash title="Approve it" theme={null} curl -s -X POST https://agent-loadout.com/api/v1/sign-ins/alsi_…/approve \ -H "Authorization: Bearer $AGENT_LOADOUT_TOKEN" ``` 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. ```bash title="CLI" theme={null} agent-loadout sign-ins get alsi_… agent-loadout sign-ins approve alsi_… agent-loadout sign-ins deny alsi_… ``` ## 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](https://agent-loadout.com/id/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`. ```bash title="REST" theme={null} curl -s -X POST https://agent-loadout.com/api/v1/sign-ins/connect \ -H "Authorization: Bearer $AGENT_LOADOUT_TOKEN" \ -H "Content-Type: application/json" \ -d '{"client_id":"alap_…","scope":["openid","email","profile"]}' ``` 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. ```bash title="CLI" theme={null} agent-loadout sign-ins apps agent-loadout sign-ins connect alap_… --scope openid,email,profile ``` ## 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](https://agent-loadout.com/id/sessions). ```bash title="CLI" theme={null} agent-loadout sign-ins keys agent-loadout sign-ins revoke-key alsk_… ``` ## 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.