Create Organization-level identities for pipelines, scripts, and agents that persist independently of individual users.
Service Accounts let you run automated workloads against the Sift API without tying credentials to a Sift User or Group. Use a Service Account when you need an identity that persists across employee changes, such as for CI/CD pipelines, data ingestion scripts, or autonomous agents.Personal API keys remain available for interactive or ad-hoc use. Service Accounts do not replace them.
A Service Account is a Sift Organization-level identity for automated workloads. Unlike a personal API key, which belongs to the Sift User who created it, a Service Account belongs to the Sift Organization and continues to function if the Sift User leaves.Service Accounts authenticate using API keys. A Service Account has no login credentials and cannot sign in to the Sift UI.A Service Account belongs to one Sift Organization. If you need to use a Service Account in more than one Sift Organization, create a separate Service Account in each Organization.
When you create a Service Account, Sift adds it to a Group named Service Account Read-only, which has the View-Only role.To change a Service Account’s permissions, an Admin (a User in a Group with the Admin role) can remove the Service Account from its current Group and add it to a Group that does not have the Admin role.When a Service Account belongs to multiple Groups, its effective permissions are the union of all Groups. If a Service Account is in a Group with limited permissions, that does not remove the access granted by its membership in a Group with more permissions.Service Accounts have the following restrictions:
A Service Account cannot be a member of a Group with the Admin role.
A Service Account cannot manage Sift Users because it cannot belong to a Group with the Admin role.
A Service Account can receive User attributes and Group attributes. Attribute-Based Access Control (ABAC) policies apply to Service Accounts the same way they apply to Users. For more information, see Set up attribute-based access policies.
In the Name box, enter a name that identifies the workload (for example, ci-pipeline or data-ingestion).
Select Create.
Store the API key securely: The API key is displayed once and cannot be retrieved later. Copy and store it in a secret management tool before closing the dialog.
A new Service Account belongs to the Service Account Read-only Group. To change its permissions, move it to a different Group or remove it from its current Group.
Select your profile icon.
Select Manage.
Select the Service Accounts tab.
In the row for the Service Account, select the User group list in the Groups column.
Select a Group to add it, or select × next to a Group to remove it.
If a Service Account’s API key is lost or compromised, rotate it to generate a new one.
Select your profile icon.
Select Manage.
Select the Service Accounts tab.
In the row for the Service Account, select Menu.
Select Rotate API Key.
In the Rotate API Key dialog, select Rotate.
Key revocation: The new key is issued immediately, but the previous key can continue working for up to a few minutes while cached credentials expire. Update your pipelines promptly.
The new API key is displayed once. Copy and store it in a secret management tool, then select Done.
Disable a Service Account when it is no longer needed. The Service Account’s status changes from Active to Inactive. Sift keeps the disabled Service Account in your records, so past activity remains attributed to it.
