Service accounts

A service account is a non-personal identity for automation: CI/CD pipelines, provisioning scripts, and third-party integrations. Its access tokens work everywhere a personal access token does — the REST API, leanctl, and the MCP endpoint — but they authenticate as the account, not as a person, so they keep working when people change teams or leave.

Service accounts live under Settings → Service accounts and are admin-only: creating accounts, minting tokens, and revoking them all require the admin role.

Create an account

1. Go to Settings → Service accounts and click New service account.

2. Name it after the automation it represents — e.g. github-actions or terraform — and describe what it is for.

3. Pick the account’s role:

   • viewer — its tokens are always read-only.
   • editor — its tokens may additionally carry write scopes.

   admin is deliberately not offered: automations must not manage users or the tenant.

Tokens

Click Tokens on an account to view, mint, and revoke its tokens.

When minting a token, pick a name (e.g. deploy-pipeline), an expiry — 90 days, 1 year, or never — and its scopes:

Scope	What it allows
(default)	Read-only: query metrics, logs, traces, and the demand set.
Allow writes	Create and update demands, dashboards, alerts, rules, and channels as this account.
Also allow deletes	Deletes too. Deleting a demand object purges the stored telemetry only it covered, so this is gated behind its own switch.

Write scopes require the account to have the editor role — a viewer account can only ever mint read-only tokens.

Copy the token immediately — it is shown only once. The list afterwards shows only each token’s prefix, scopes, creation date, last use, and expiry.

Revoking a token deletes it permanently and cuts off any automation still using it, immediately. Deleting the account revokes all of its tokens the same way.

Using a token in CI

Store the token as a secret in your CI system and pin the endpoint, so the job never goes through an interactive login:

export LEANCTL_TOKEN=lsp_…        # the service-account token, from a CI secret
export LEANCTL_API_URL=https://<tenant>-api.eu11.leansignal.io
leanctl demands list

The same token authenticates plain REST calls (Authorization: Bearer lsp_…) and MCP clients — the AI access guide shows the client configuration.

Attribution

Everything a service-account token does is attributed to the account, not to the admin who minted the token: the account’s name appears in provenance fields and in the audit log, so an automation’s changes stay reviewable as its own trail. Minting and revoking tokens is audit-logged too, under the admin who did it.

Service account or personal token?

• Personal access token (Preferences → Access tokens) — for tooling you supervise: your IDE’s AI client, your laptop’s leanctl. Acts as you; dies with your account.
• Service account token — for automation the team owns: CI/CD, integrations, scheduled jobs. Acts as the account; survives people leaving; managed by admins in one place.