Tokens & deployments

A deployment token is the entire identity of an Exo Operator instance. There is no per-resource scoping, no role bundle, no IP allowlist. The token grants one right and one only: to be the deployment it was minted for. That simplicity is deliberate; user authorisation lives in the control plane where the permission catalog can evolve, not on a string you've sealed into a Secret.

What's in a token

A deployment token is an opaque, prefixed string. The prefix exists so support and log scrubbers can identify the token type without revealing the secret half.

1exo_dpl_8a4b9f3e2d1c0a7b6e5f4d3c2b1a09f8
2 │       └────────────────────────────── opaque entropy (16 random bytes, 32 hex chars)
3 └────────────────────────────────────── product + type prefix ("exo_dpl_" = deployment)

We persist sha256(token) plus the visible prefix, never the raw secret. A leaked token cannot be recovered from the database — only rotated away.

Minting a token

Tokens are minted from Deployments → New in the dashboard. The token is shown exactly once on the creation screen. After that the dashboard shows only the prefix and the issuance timestamp; the secret half is unrecoverable.

Rotation

The right way to rotate is to mint, deploy, and let the old token expire:

• Mint. Click Rotate on the deployment row. Copy the new token from the modal.
• Deploy. Update the AGENTKUBE_AUTH_TOKEN secret in your cluster. The pod's environment refreshes on next restart — either trigger a rollout, or let your secret-reloader handle it.
• Let it land. The new connection presents the new token; the old token is rejected on its next reconnect attempt. The dashboard shows a singleDeploymentReconnected event.

Unlike API key rotation in some systems, there is no overlap window on deployment tokens. The control plane enforces single-active-connection per deployment, so you cannot run the old and new connections concurrently. In practice this is fine because the reconnect is fast and your dashboard sees one deployment, not two competing identities.

Revocation

Revocation is rotation without a successor. Click Revoke on the deployment row; the token's hash is removed from the database, the active connection is closed, and Exo Operator's next handshake is rejected with a token_revoked close code.

One-to-one binding

A token is bound 1:1 to a deployment. The control plane rejects a second active connection presenting the same token, with a configurable last-writer-wins grace window. This means:

• You cannot share a token across clusters. Multi-cluster tenants must mint one token per cluster. This is a feature: each cluster gets its own dashboard identity, its own audit trail, its own rotation cadence.
• Leader election needs no extra config. Multiple replicas of one deployment compete for the single connection slot; whoever holds the lease holds the connection.
• Disaster recovery is just rotation. When the primary cluster comes back, rotating the token cleanly hands ownership to the new replica.