Auth model overview
The credential types Exo uses, each scoped to a different actor and lifecycle. Who they're for, where they're minted, and which one to use.
Exo authenticates four kinds of caller: people (a User JWT), the Exo Operator (a deployment token), a service endpoint (a per-resource SCIM token), and agents, which never sign in and act under their own governed identity. Each is scoped to a different actor and lifecycle.
Credential types
| Credential | Subject | Where it comes from |
|---|---|---|
| Deployment token | one Exo Operator | Dashboard → Deployments |
| SCIM bearer token | one IdP | Dashboard → Identity provider |
Deployment tokens
The credential the Exo Operator presents to the control plane. A deployment token (exo_dpl_ + 32 hex) authenticates one Exo Operator instance and carries no per-resource permissions of its own. The control plane enforces user authorisation for what happens through a deployment (shell attach, agent invoke) at request time. Full lifecycle in Exo Operator · Tokens; wiring it up in Connecting.
Service tokens
Per-resource tokens that authenticate a single inbound endpoint. Each is minted in the dashboard, shown once, and optionally paired with an HMAC signing secret.
- SCIM bearer tokens are minted per identity provider for the SCIM 2.0 server under
/api/v1/scim/v2/..., used by your IdP to push users and groups. See SCIM provisioning.
Agent identity
Agents hold no login credential. A run pod authenticates as the agent itself, what it may reach is granted per resource on access lists, and every action it takes is recorded. There is no separate service-account login in Exo: people are users, machines hold tokens, and agents have their own identity.