Why automation should use one
A service account gives a script, CI job, or integration:- Its own role assignments and resource scopes
- Attribution under the automation’s identity in the audit log
- A lifecycle independent from the person who created it
- The option to use several API keys without sharing personal credentials
Create a managed service account
Choose New service account, enter a descriptive name, and assign at least one role. You can edit the roles and principal attributes later. Attributes can participate in label-scoped grants such asteam = $principal.team.
After creation, open API keys and create a
key that acts as the service account. One service account can have multiple keys, which lets you
rotate or revoke one integration without changing the others.
Managed and per-key accounts
The service-accounts list includes two types:
A per-key service account receives its roles when the API key is created. Revoking that key also
disables its per-key account. For permissions that should evolve independently from one key, create
a managed service account instead.
Disable and restore
Disabling a managed service account prevents its keys from authenticating without deleting the identity or its history. Restore it to allow still-valid, non-revoked keys to authenticate again. Past audit records and run attribution remain associated with the service account throughout. Review dependent keys before disabling an account, and use Last used on the API keys screen to identify active callers.Next steps
API keys
Issue a bearer token for a service account.
Roles & permissions
Grant only the capabilities and scopes automation needs.
Agent identity
Compare service accounts with runtime agent principals.
Audit log
Review service-account and key lifecycle events.