Service accounts

Production AI calls aren't people. A nightly summarisation job, a customer-facing chatbot, an evaluation harness — they should be governed differently from a developer at their keyboard. Service accounts give each one its own identity, scope statement, and signal trail.

This page lives at Settings → AI → AI Service Accounts. Admin-only.

What a service account is

An AI service account is a named, environment-scoped principal that production AI traffic authenticates as. Each one carries:

Field	Meaning
Name	Human-readable label (e.g. support-bot-prod)
Environment	production, staging, development — drives signal severity
Description	What this workload does
Intended scope	A sentence stating what the account is allowed to do — used in audits and by the abuse-pattern detectors
Abuse detection	On / off — whether the off-topic-production and abuse-pattern detectors run against this account
Linked project	Optional Flowstate project for cost-attribution rollups

When you create one, Flowstate provisions a dedicated API key bound to the account. Production traffic uses that key to identify itself through the Flowstate SDK.

The list

The page is a flat table of every service account in the org:

Column	What it shows
Name	Account name
Environment	Pill — production, staging, development
Spend (30d)	Trailing 30-day spend
Open signals	Count of unresolved signals against the account, with the top categories on hover
Last seen	Most recent ingest timestamp — Never if no traffic yet
Abuse detection	On / off

Creating one

The Create button at the top opens a dialog. The form requires name and environment. Description and intended-scope are optional but recommended — both feed into audit and signal context.

After save, a one-time reveal modal shows the raw API key with the visible prefix for record-keeping. This is the only time the full key is shown. Copy it into your secrets manager immediately. The prefix is searchable later for incident response.

WARNING

The raw key is shown once. Lose it and you have to rotate. Don't paste it into a chat window.

The detail drawer

Click a row to open the account's drawer. It shows the key's prefix, created and last-used timestamps, and whether the key is active or revoked. Only the prefix is retained after provisioning; the full key was shown once. If the key leaks, rotate it from the drawer's key controls to issue a new one and revoke the old.

The drawer also carries ready-to-paste SDK integration snippets: curl (push a raw trace payload), the Node SDK, and the Python SDK. Wire one of them to the account's key and usage starts flowing.

Editing

The edit drawer lets you change name, environment, description, intended scope, the linked project, and the abuse-detection toggle. The key itself is only ever replaced by rotation, never edited.

Deleting

Deleting revokes the account's key, and in-flight SDK calls fail. The row is preserved for audit history, and past ingest data is retained.

The deployment link: Agents, plan vs actual

An AI service account is the production runtime identity a planned Agent links to. The Agent is the plan: an owner, a catalogue model, and a forecast of expected runs. The service account is the actual: real sessions and real spend reported through the SDK.

Link the two and the account's actual sessions and spend reconcile against the Agent's forecast runs: plan versus actual, exactly like a person's actual cost against their planned cost. An Agent with no deployment link shows "Not deployed" and carries forecast only. See Forecast for how run-based forecasts are built.

Creating a Custom workflow agent (a bespoke workflow you build and run yourself) provisions its service account and SDK key in one step, shown once at creation.

Why these are separate from human keys

Three reasons:

1. Scoped policy. A BLOCK rule that's right for engineers ("no PII in prompts") might break the customer-facing summariser that legitimately processes PII. Service accounts let policy target each one explicitly.
2. Cleaner signals. Behavioural-signal categories like personal_use_company_account make no sense for a service workload. The signal stream filters them automatically when the subject is a service account.
3. Audit clarity. When forecast_breach fires on the nightly digest job, you want to see "service: nightly-digest-summariser / production" — not "subject: nobody".

What lands on Alerts

Behavioural signals raised against service accounts show up on Alerts and signals with the service badge in the drawer. The drawer surfaces the account name and environment alongside the signal details.

Empty state

If you've never created a service account, the page shows a friendly empty card with a CTA. Most orgs start with one or two — typically a production summariser and a staging counterpart — and grow from there.