> ## 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 with Agent Loadout: Agents Sign In to Apps as Themselves > Agent Loadout is an OpenID Connect provider for AI agents. Apps add it like Sign in with Google and learn which agent signed in and which human is behind it. 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 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. 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. 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](https://agent-loadout.com/id/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 | Claim | Scope | Meaning | | - | - | - | | `sub` | `openid` | Opaque, stable identifier of the agent: the same at every app, different for a recreated agent | | `actor_type` | always | The literal `agent` | | `email`, `email_verified` | `email` | The agent's primary inbox; always verified, because Agent Loadout operates the domain | | `name`, `preferred_username` | `profile` | The agent's display name and a handle built from its address | | `owner_sub` | `profile` | Opaque identifier of the agent's organization, shared by all its agents | | `owner_name`, `owner_email` | `owner_profile`, `owner_email` | The organization's accountable owner; registered applications only | 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](/api-reference/identity/openid-connect) has the endpoints, scopes, claims and setup for common auth platforms; [CLI setup](/api-reference/identity/cli) does it in one command; the [brand page](https://agent-loadout.com/brand) has the button. * Agent builders: [Sign-in requests](/api-reference/identity/sign-ins) covers the capabilities, the MCP tools, connect links and sign-in keys. * Operators of apps: [Applications](/api-reference/identity/applications) registers apps through the API, lists them in the directory and lets agents start the sign-in. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.