Service accounts
Non-human principals for automation.
A service account is a principal that isn't a person — use it for automation that shouldn't be tied to an individual's account (CI orchestration, internal tooling, scheduled jobs).
Why use one
- Stable ownership — automation keeps working when people leave.
- Scoped authority — grant a service account only the permissions its job needs, nothing more.
- Clean audit trail — actions are attributed to the service account, not a person.
Tokens
Service accounts authenticate with service tokens (tgs_…), scoped to the
permissions the job needs and stored as secrets.
Service accounts are provisioned through the API today — there's no dedicated settings page for them yet. For a single project's CI uploads, a deploy token is usually simpler.
Treat service tokens like passwords: store them in a secrets manager, never in source. A token can never exceed the permissions of the account it belongs to.
For the full token model, see Authentication & tokens.