Service users — API access for tools and scripts your account owns¶

A service user is a non-human user inside your Account. You create one when a tool, script, or third-party integration needs to call FlexGalaxy.AI APIs on behalf of your Account but should not be tied to any one person’s identity.

This page is for Account root users and account admins. If you are an external developer wiring a CI/CD pipeline (GitHub Actions, GitLab CI) to FlexGalaxy.AI, don’t create a service user for that — use a workload identity instead. The decision matrix below explains which is which.

Which credential to pick¶

You are setting up	Use	Why
Your own laptop / tenant CLI work	Workforce STS	Uses temporary `ASIA` signed credentials bounded by your workforce assignment; the CLI never stores your browser bearer token.
A long-running tool, cron job, or third-party integration owned by the Account	A service user with an access key	The credential belongs to the Account, not a person. It survives staff changes.
A GitHub Actions, GitLab CI, or other CI/CD job	A workload identity with federated OIDC	Short-lived (15 min) tokens; no long-lived secret in CI; per-job audit. See your developer team’s workload federation guide.

Service-user keys held in CI as long-lived secrets leak more often than fresh short-lived tokens. Workload identities are the preferred CI/runtime shape; workforce STS is the interactive tenant CLI shape.

What a service user is¶

A service user is created by the Account root (or an account admin with the right permission) and is part of your Account, not a person’s Profile. It:

has an access key (ID + secret) the Account uses to call FlexGalaxy.AI APIs;
cannot sign in to the web console — service users are programmatic-only by design (see Why service users can’t sign in below);
is subject to Account roles and permission policies, without becoming a human or console identity;
shows up in TraceBook audit events under its own identity, so you can trace which automation took which action.

Creating a service user¶

You must be the Account root, or an account admin granted the right to create service users.

Sign in to https://console.flexgalaxy.ai/account.
Open the Service users tab.
Click Create service user.
Give it a descriptive name — typically the name of the tool that will use it (e.g. nightly-export-job, gitlab-runner-bazaar-publish, acme-vision-integration). Account-wide names are easier to audit than person-flavored names.
Save. The service user is created with no access keys and no policies attached yet. If a brand-new user briefly does not appear in the list, refresh the page — creation writes the account’s own store and the list follows it.

Right after creation, two things to do:

Attach an IAM policy that grants the service user the actions it needs — open the service user’s Access policies section and attach. Default to least privilege: grant service:Action patterns rather than * wildcards. Platform-managed policies are read-only-but-attachable (you cannot edit them; you can attach them). ⚠ A broad administrator policy does not imply product capabilities: some products require their own capability policy to be attached explicitly (for example TrustMint’s ThingMakeEnrollAccess before a first device enrollment). Attach those when the product’s setup asks for them.
Create an access key for the service user (next section).

Creating an access key for a service user¶

From the Service users tab, click the row for the service user.
Open the Access keys sub-tab.
Click Create access key, give it a name describing where the key will live (e.g. prod-runner-01, aws-lambda-export-2026), and copy both the key ID and the secret value when shown.
The secret value is shown once. Store it immediately in your secrets manager (AWS Secrets Manager, HashiCorp Vault, GitLab CI variables, etc.). If you lose it, delete the key and create a new one.

A service user can hold up to two access keys at once. The two-key allowance exists precisely so you can rotate without downtime: create the new key, deploy it everywhere, then delete the old key.

Using service-user keys from the CLI¶

The FGAI CLI can store a service-user access key as a local credential profile for scripts that call FlexGalaxy.AI APIs. This is still API access only. It does not make the service user a console user and it does not bypass Account permissions.

For example, an operator can configure a CLI profile for an Account-owned automation user:

fgai auth service-user configure \
  --profile production \
  --account-id <account-id> \
  --access-key-id <access-key-id> \
  --secret-access-key <secret> \
  --name nightly-export

Three names, three jobs — they are easy to conflate:

--name is the name of the stored credential you just configured (nightly-export here).
--auth <name> on every later command selects that credential — it must match the --name you chose. This is what a first call looks like:
```
fgai account get --account <account-id> --auth nightly-export
```
A 200 with your account’s own details means the credential, the signing, and the clock are all correct. A 401 means the credential did not resolve — re-check --auth against fgai auth status.
--profile selects the environment (for example production), not the credential.

Use your secrets manager for real deployments. The CLI profile is convenient for local scripts and testing, but production automation should load the key from managed secrets rather than copying it into multiple laptops.

Rotating an access key¶

Rotate any service-user access key at least every 90 days. The platform flags keys older than 90 days on the service user’s security page.

The rotation sequence:

Create a second access key on the same service user.
Deploy the new key to every place that holds the old one (CI variables, secrets manager, cron jobs, etc.).
Wait one full operational cycle (e.g. one day for a nightly job, one week for a weekly job) so any in-flight work finishes.
Verify the old key has not been used recently — the service user’s Access keys page shows last-used timestamps.
Delete the old key.

If you suspect a key was leaked, skip the gentle rotation: delete the leaked key immediately, then create a replacement.

Revoking and deleting a service user¶

Two distinct actions:

Delete an access key — revokes one specific credential. The service user still exists and can still call APIs with its other key (if any). Use this when you rotate or detect a leak.
Delete the service user — removes the identity entirely. All its access keys are invalidated immediately and all attached policies are detached. Audit-log entries the service user produced before deletion are preserved (per platform retention policy).

Delete the service user when the tool that used it is decommissioned. Don’t leave orphan service users around — they are surface area.

Why service users can’t sign in¶

This is by design, not a bug.

A service user is a programmatic identity. It has an access key, no password, no MFA enrollment, and no Profile. Service users are programmatic-only and are blocked from the web console by design — the platform denies console sign-in to a service user regardless of any IAM policy that might appear to grant it. This is the security feature, not an oversight.

If you find yourself wanting a service user that can sign in, what you actually want is a human user — create a workforce user in Identity Center and assign them a permission set instead.

Service users vs workforce CLI sessions¶

A workforce CLI session uses temporary STS AK/SK plus a signed session token and follows that person’s permission-set authorization. It does not store or send the workforce user’s browser bearer token. A service-user access key represents an Account-owned non-human principal. Platform administrators have no CLI profile and operate only in the admin-console web app. Never attach console access to a service user or use a human browser session as an automation secret.

Service users vs workload identities¶

This is the most common confusion. Both are non-human; both are Account-owned; neither can sign in to the console. The difference is the credential model.

	Service user	Workload identity
Authenticates with	Long-lived access key (ID + secret)	Short-lived (15 min) DotID-issued JWT from token exchange
Where the secret lives	In a secrets manager / CI variable / config file	Nowhere — there is no long-lived secret
Originating trust root	DotID’s own access-key authentication	External OIDC IdP (GitHub Actions, GitLab CI)
Rotation cadence	You rotate every 90 days	Every CI job, automatically
Best for	Long-running tools, third-party integrations, scripts that already have a secret manager	CI/CD pipelines, ephemeral workloads, runtime services

Rule of thumb: if the thing using the credential is a CI/CD pipeline, use a workload identity. For everything else where you’d reach for a service user, a service user is correct.

The setup for a workload identity also lives in your Account console (under Workload identities), but the federation wiring happens on the external CI side. Hand the workload federation guide to your developer team if you’re not the one wiring it.

The FGAI CLI stores only service-user AK/SK or workforce STS credentials. Workload token exchange is a runtime helper, not a stored CLI command profile. Do not convert a CI/CD workload into a service user just because both can call APIs.