Service accounts

A service account is an identity the team owns, for CI, scripts and headless agents. Its keys (omp_sa_…) don't depend on anyone staying on the team: the team's owners and admins are responsible for it. Use one for anything that runs unattended, instead of a person's API key.

Team owners and admins manage them under Service accounts; members and platform staff can see them. Only owners, admins and platform staff see an account's keys.

Create oneCopy Anchor Link

Service accounts › Create service account:

• Name: 1 to 64 lower-case letters, digits and dashes, such as ci-release-bot, unique in the team. Calls show it as who called.
• Description: what it's for and where its keys are deployed, so the next owner knows.
• Role: Member (reaches the capabilities open to every member of the team; enough for most automation) or Editor (also reaches capabilities that need editors or above). The role only counts for capabilities' minimum roles. It never makes the account an owner or admin, and it can't change anything in the team.
• Enabled: turned off, its keys are refused on their next request, until it's turned on again.

A team can have up to 100 service accounts.

What it can useCopy Anchor Link

A service account can use:

• the team's own gateways, with its role for minimum roles; and
• platform gateways granted to its team. Grants to people or SSO groups don't cover it, and a platform gateway can't be granted to one service account.

The account's Overview › Access lists the gateways its keys reach now, with how many capabilities it reaches on each.

Service accounts can't use tools that act as a person: capabilities with a user authorization requirement and tools of servers in OAuth mode. Their calls are refused with JSON-RPC -32010 (service_account). Those capabilities stay listed, marked "Service accounts can't use this".

KeysCopy Anchor Link

On the Keys tab, Create key:

• Name: where it's deployed, for example "GitHub Actions release workflow". Call records show it.
• Expires after (days): keys always expire, from 1 to 365 days (90 by default).
• Limit to gateways (optional): the key works only on these gateways (at most 50, each one the account can use now).

The secret is shown once. Send it like a personal key: Authorization: Bearer omp_sa_…. See Use from your own agents.

Rotating a keyCopy Anchor Link

An account has at most two active keys, so you can rotate without downtime:

1. Create a new key. The dialog then shows "Next: finish the rotation".
2. Deploy the new key wherever the old one runs.
3. Revoke the old key. Whatever still uses it stops working on its next request.

What servers seeCopy Anchor Link

MCP servers get an identity token with principal_type: service_account, sub set to the account's ID, name set to its name, teams set to its own team, and no email. See The identity token.

RecordsCopy Anchor Link

Calls are recorded under the account's name and the key used. In the web app, a team gateway's Activity tab (owners and admins) can be filtered by service account, and platform staff can filter Admin › Calls by any team's service account (Calls in Admin on the account's page). The team's call list in the management API (GET /v1/teams/{team}/calls) includes every call of the team's service accounts through any gateway, including platform gateways granted to the team and refusals on other teams' gateways.

When keys stop workingCopy Anchor Link

The next request is refused (401) when the account is turned off or deleted, its team is archived, or the key is revoked or expired. Deleting the account deletes its keys; its call records keep its name.