Service accounts
Give deployed automation a workspace-owned identity.
A service account represents a process rather than a person. It is useful when automation must continue after an employee changes roles or leaves the workspace.
When to use one
| Use a service account when… | Use a personal token when… |
|---|---|
| the process is owned by the workspace | the script is owned and run by one person |
| credentials are managed in deployment infrastructure | the tool runs locally for a member |
| audit history should name a non-human actor | actions should be attributed to the member |
The current public release supports service-account keys only on operations that explicitly allow a machine actor. Check the operation’s authentication section in the API reference.
Safe setup
- Ask a workspace administrator to create one service account per integration.
- Select the minimum scopes and, when possible, restrict it to named teams.
- Issue a key with a practical expiry and move the show-once value directly to your secret manager.
- Rotate before expiry. Use the bounded overlap only long enough to deploy the replacement safely.
- Disable the account when the integration is retired.
Service accounts cannot grant themselves permissions or manage other service accounts. Disabling the account or revoking its key takes effect on the next authentication attempt.