Skip to content

Access tokens

A personal access token (PAT) lets you sign tessera-cli in on a machine with no browser or desktop app — a server, a WSL distribution, or a CI runner. The token authenticates as you and inherits all your access grants.

In the console, open Access keys → New token, give it a name, and optionally set an expiry. The secret (tpat_…) is shown once — copy it immediately. Then:

Terminal window
tessera-cli login --url https://tessera.example.com --token tpat_xxxxxxxx
  • One token per account. Each account has a single active access token at a time. If one already exists, creating another is refused — revoke the existing token first.
  • Device-bound. A token binds to the first machine that uses it. The same token won’t work from a second machine — for another person or host, use a separate account.
  • Meant for the CLI. Access tokens are intended for tessera-cli on headless machines; the desktop app uses interactive sign-in. This is a convention, not a hard server-side block.
  • Inherits your grants. A token can do exactly what you can, no more. It respects RBAC, read-only mode, and JIT expiry.

These rules keep a token from being copied around and shared — it’s tied to you and to one machine.

Revoke a token any time under Access keys; the CLI using it stops working immediately. Set an expiry when you create it so short-lived automation cleans up after itself.

Access tokens are self-service: each user creates and revokes their own under Access keys.

When a token is first used from a new source IP, Tessera records an audit event. Admins can see per-token use count and last-used IP, so a token that’s being passed around is easy to spot.

  • this access token is bound to another device — it was first used on a different machine. Revoke and recreate it, or use a separate account for the second machine.
  • 401 — the token expired or was revoked; create a new one.