Token Types
AgentTrust ID uses several distinct credentials, each answering a different question. They are easy to confuse because more than one carries an agent’s identity. This page maps them. The short version:
- Org API key: which tenant is calling.
- Admin session: which human is using the dashboard.
- Agent Access Token (
at_…): revocable runtime access for an agent, with scopes, right now (opaque; not an identity claim). - Workload Identity Token (WIMSE): which workload is calling (signed workload identity).
- Runtime Session: the authorization source of truth: scope ceiling, allowed actions, mode, elevation, Guardian routing.
- DPoP proof is not a token. It is a per-request proof presented alongside a sender-constrained token.
Agent Access Tokens grant revocable access to AgentTrust; Workload Identity Tokens (WIMSE) prove workload identity; Runtime Sessions enforce what an agent can do.
At a glance
| Credential | Looks like | Proves | Issued / obtained | Presented in | Lifetime | Revocable | Verifiable offline |
|---|---|---|---|---|---|---|---|
| Org API key | sk_live_… | The calling organization (tenant) | Dashboard → Settings → API Keys | X-API-Key header | Long-lived | Yes (deactivate) | No (hashed lookup) |
| Admin session | ati_session cookie | A logged-in human/operator | POST /api/v1/admin/login | Cookie (+ CSRF token) | Session | Yes (logout) | No |
| Agent Access Token | at_… | Revocable access for an agent + scopes | POST /api/v1/agent-tokens/issue | Authorization: Bearer | Short (default 1h) | Yes, instantly | No, introspection required |
| Workload Identity Token (WIMSE) | EdDSA JWT (spiffe://…) | An agent’s workload identity | POST /api/v1/wimse/token | Authorization: Bearer | Short (≤1h) | Via revocation/expiry | Yes (signed) |
| DPoP proof | compact JWS (RFC 9449) | Possession of the agent’s key, for this request | Minted client-side per request | DPoP header | One request | n/a (single use) | Yes |
| AgentCard | signed EdDSA card | An agent’s published identity (A2A) | POST /api/v1/agents/{id}/card | A2A exchange / .well-known | Per publish | Re-publish | Yes (signed) |
| Federation ID token | OIDC ID token | An identity from a trusted external org | A registered federation provider | Federation bridge | Short | n/a | Yes (against provider JWKS) |
The two that get confused: at_ vs WIMSE
One grants access; the other proves workload identity. It’s worth being explicit:
Agent Access Token (at_…) is a random string stored server-side in Redis. It is not a JWT and not verifiable offline. It grants revocable runtime access to AgentTrust. It may reference an agent internally, but it is not a workload-identity claim. Verification always calls back to the service (the “service-as-authority” model). That is what makes it instantly revocable. It carries agent_id, org_id, scopes, an optional bound session_id, and an optional cnf_jkt (DPoP binding). Use it as the agent’s everyday bearer credential when you want central control and immediate revocation.
Workload Identity Token (WIMSE) is a signed (EdDSA) JWT with a SPIFFE URI (spiffe://<trust-domain>/agent/<id>). It carries agent_id, org_id, capabilities, and an optional cnf (DPoP binding). Use it as the workload-identity token on the runtime path where a self-describing, signed identity or sender constraint is required.
They can be bound to the same agent key (cnf_jkt / cnf) and to the same Runtime Session. The rule of thumb: at_ = revocable access; WIMSE = signed workload identity. Neither alone decides what an agent may do. Authorization comes from the Runtime Session plus Guardian.
Exchanging a Workload Identity Token for an Agent Access Token
In the session-first model, the workload chains the two credentials. It first proves who it is with a WIMSE, then trades that WIMSE for an at_ that grants revocable runtime access:
- The workload obtains a Workload Identity Token (WIMSE) via
POST /api/v1/wimse/token(optionally with proof-of-possession, so the token carriescnf.jkt). - It calls
POST /api/v1/agent-tokens/exchangepresenting the WIMSE asAuthorization: Bearer <WIMSE>, not the org API key. Core verifies the WIMSE and mints anat_bound to the same agent and org the token already proves. The agent/org come from the verified token, never from the request body. If the WIMSE is sender-constrained, the issuedat_inherits itscnf.jkt, so the binding carries through. - An optional JSON body
{ "ttl": <seconds>, "scopes": ["…"] }can narrow the resulting access token (shorter lifetime, fewer scopes). It cannot widen beyond what the WIMSE allows. - The workload then uses the
at_as its everyday bearer credential for product API calls.
The response matches /agent-tokens/issue ({ token, expires_in, expires_at }). The exchange returns 401 missing_workload_identity_token / invalid_workload_identity_token when no valid WIMSE is presented, and 501 exchange_not_configured where the endpoint is not wired. Product APIs prefer at_; a WIMSE is accepted directly only where offline identity verification is needed.
Where attestation and DPoP fit
- Attestation is a WIMSE issuance policy controlled by
attestation_policy. The API accepts attestation evidence and exposes trusted-issuer management. Public SDKs expose WIMSE and DPoP, but they do not collect, attach, or verify attestation evidence. See WIMSE Workload Attestation. - DPoP (RFC 9449) is a per-request proof of key possession, sent in the
DPoPheader alongside a sender-constrained token (Agent Access Token or WIMSE) whosecnf.jktit must match. Gated per-org byrequire_sender_constrained_tokens. See Authorization Model.
Quick decision guide
- Authenticating an SDK or service to the platform → org API key (
sk_live_…). - Acting as the dashboard as a person → admin session cookie.
- Giving an agent revocable runtime access with scopes → Agent Access Token (
at_…). - Needing a signed workload identity or DPoP → Workload Identity Token (WIMSE).
- Deciding what an agent may do at runtime → the Runtime Session (scope ceiling, mode, elevation) plus Guardian.
- Proving where an agent runs → API-level attestation on the WIMSE issuer path.