Service accounts
⚠️
Preview — this feature is being built; the design below is the spec.
A service account is an identity for software rather than for a person. Keys and workload-identity tokens that belong to a service account keep working when people join or leave, and every request they make is logged under the account’s name.
Why not use a member’s key
| Member’s key | Service account |
|---|---|
| Stops working when the member leaves | Unaffected by staff changes |
| Usage appears under a person | Usage appears under the system, such as ci-billing |
| Has whatever the person can do | Limited to inference, agents and/or files |
| Can reach the Admin API if the person can | Never has Admin API access |
Create one
Console: Settings → Workspaces → (workspace) → Service accounts → New, or Create a service account with an Admin key. Then either:
- create an API key owned by it in the Console (Create key → Owner: service account), or
- add a trust rule so your CI or cloud workload can exchange its own identity token, with no stored key at all. See Workload identity.
Naming
Name accounts after the system and environment, such as support-bot-prod or ci-billing. Names appear in usage, cost and audit reports, so a clear name saves detective work later.
Lifecycle
- Narrow permissions as soon as you know what the system needs.
- Archive instead of deleting when a system is retired: keys stop working, history stays.
- Review quarterly with Usage by API key and
include_idle=trueto find accounts nothing uses.
Was this page helpful?