Why automation should use one
When a script, a build job, or an integration calls the platform, having it act as a service account rather than as a person buys three things:- It is not tied to anyone’s membership, so it keeps working when people join or leave.
- Its actions are attributed to the integration in runs and in the audit log, not to whoever happened to create it.
- It holds its own roles, so automation can be granted exactly the access it needs and nothing more.
Creating one
Choose New service account, give it a descriptive name, and assign it at least one role — a service account holds no capabilities until it has one. Its roles, and any attributes that label-scoped grants match against, stay editable afterwards. Once it exists, issue access for it from the API keys screen by creating a key that acts as that service account. One service account can back several keys.Managed and per-key service accounts
The screen lists two kinds, and the difference matters when you go to edit one:Disabling and restoring
Disabling takes effect immediately — every API key bound to that service account stops authenticating — and it is reversible. Disabling never deletes history: past runs and audit records stay attributed to it, and its keys resume working on restore.Next steps
API keys
How a service account is actually used to call the API.
Roles & permissions
The roles and attributes a service account holds.
Agent identity
The other non-human identity, and how it differs.
Audit log
Service-account changes are recorded there.