Service tokens

Service tokens are credentials for machines — CI jobs, Docker builds, Kubernetes workloads, and agent sandboxes. Each is an independent principal that can be granted access to specific environments and revoked on its own.

How they work

A service token is self-contained: the token string carries its own private key. The server stores only a SHA-256 hash of the token (to authenticate it) and its public key (to wrap environment keys to it). This means a machine holding the token can unwrap any environment DEK granted to it entirely offline — the server never had the token's private key.

Because tokens are generated on the client, the full token is shown once at creation. Copy it then; it cannot be retrieved later.

Creating a token

In the web dashboard: Organization → Service tokens → Mint token. Copy the skt_… value from the one-time dialog.

With the CLI, from a linked project directory, optionally granting it the current environment at the same time:

seekrit token create --name ci-deploy --grant
# prints:  skt_XXXXXXXX_...    (save it now)

Without --grant, mint the token, then grant it environments explicitly:

seekrit token create --name ci-deploy
seekrit grant --token skt_XXXXXXXX

Using a token

Set it as SEEKRIT_TOKEN and use any read command:

export SEEKRIT_TOKEN=skt_XXXXXXXX_...
export SEEKRIT_API_URL=https://api.your-seekrit.example

seekrit export --format dotenv
seekrit run -- ./deploy.sh

Service tokens never need a passphrase — their private key is in the token string.

Granting and revoking

Grants are per-environment. Grant a token from any environment's Key access panel, or with seekrit grant --token <id> from a linked directory. When a token is retired:

seekrit token revoke skt_XXXXXXXX

Revocation stops the token from authenticating immediately. As with any principal, revoking the grant doesn't rotate the key — see Access & key grants.

Listing tokens

seekrit token list

Shows each token's id, name, status (active / expired / revoked), and last-used time.