Sign in with Agent Loadout: let agents sign into your app

A service account can have an email address without telling an application that an agent operates it. The app sees another signup. The team running the agent still needs a way to identify it and decide who is responsible for its access.

Sign in with Agent Loadout gives an agent an OpenID Connect identity. Your app receives a stable subject for the agent and can request information about its owning organization. The inbox stays useful for receipts and support messages but the sign-in flow no longer depends on copying an email code.

What a sign-in establishes

The identity provider’s issuer is https://id.agent-loadout.com. Apps use its discovery document to locate the authorization and token endpoints and signing keys:

https://id.agent-loadout.com/.well-known/openid-configuration

The agent’s sub is the account identifier. Use the issuer and subject together as the external identity in your application. Email is useful contact information but it should not replace the subject as your account key.

The email scope provides the agent’s inbox address and its verified status. The profile scope adds profile information including owner_sub, an opaque identifier for the organization. Registered applications can also request the accountable owner’s name or email.

This sign-in proves an identity. It does not grant your application access to the agent’s mailbox or vault. Decide separately what an authenticated account may do in your own product.

Register an application you control

The dashboard’s Sign-in apps area lets you register your application and its callback URLs. For a project that uses one of the supported authentication platforms, the CLI can prepare the configuration:

npx @agent-loadout/cli app init
npx @agent-loadout/cli app doctor

app init needs an organization key with applications:manage in AGENT_LOADOUT_KEY. It detects the auth platform, registers the app and writes client values into .env.local. Read its remaining setup steps before treating the integration as complete. Keep that file out of version control.

app doctor checks discovery and client configuration. With an organization key it can also check the registered callback. Passing it does not replace a real browser sign-in test.

Use the CLI reference for an explicit callback URL or a platform override. Registered applications support loopback callbacks for development. Open clients use an HTTPS origin as their client ID and have a different set of restrictions.

Follow one login from start to finish

Your application begins its normal OIDC authorization-code flow. Agent Loadout presents a sign-in request. The agent can approve with a token that has identity:sign_in or an authorized team member can approve it in the dashboard.

The app exchanges the returned code and validates the identity token with its OIDC library. Verify the signature, issuer, audience and expiry. Apply the library’s state and nonce checks for the flow you configured. Open clients require PKCE with S256.

Only then create or look up the application account. Decide whether the agent may use the same feature set as a human account. For example, your app might allow reading project status while requiring an operator for billing changes.

Ask for the owner only when the app needs it

A registered application that requests owner_email does not receive a successful sign-in with that claim silently missing. Sharing it needs the agent’s identity:share_owner capability or approval by an authorized owner or admin.

For a limit such as “three agents per organization”, owner_sub may be enough. It groups agents by their Agent Loadout organization without requiring an owner’s email. It is not a claim that two different organizations have different humans behind them.

Document why your application requests each claim. Store only what it needs to operate the account. Avoid logging whole identity tokens or callback URLs with live authorization codes.

Revocation has to reach your app’s session

Forgetting an approved app or revoking a sign-in key stops the corresponding future sign-ins. Your app still owns sessions it already issued. A long-lived application session does not disappear merely because the identity provider’s approval changed.

Keep agent sessions appropriately short and recheck /userinfo before sensitive actions when you need current authorization state. Test this by signing in, removing access in Agent Loadout and checking how your app responds.

Once the integration works, registered apps can be listed in the application directory. The OIDC reference covers claims, client tiers and revocation. Our brand page provides the original mark for your sign-in button.