API Keys

Credential lifecycle

Manage API keys, ownership metadata, scopes, and rotation windows for the control plane.

Credential sequence

Treat the first API key as a narrow, manual credential artifact for default. Issue the key, keep the secret, run the demo in Playground, confirm the usage signal, then record the same run context in verification before widening scope.

Current session context: Environment fallback (non-production). These links only preserve workspace handoff context across the console.

Step 1: Review service account Step 3: Run playground demo Step 4: Confirm usage Step 5: Record verification evidence

This sequence stays navigation-only between surfaces. Creating the key happens here, but the follow-up run, usage confirmation, and evidence capture are all still manual operator steps.

Manual governance checkpoint

New keys are easy to create, but they should still follow the plan-limit and billing lane. If the workspace is already under usage pressure, confirm that first so you do not widen access for a path that is already close to a plan boundary.

Check usage pressure Check plan and billing

This remains a manual governance checkpoint. It does not block key creation automatically or perform any support-side change for you.

Onboarding context

You arrived here while following the onboarding path. Generate a `runs:write` key, keep its secret safe, then immediately run the first demo via the Playground so Usage and Verification can capture the trace before widening scope.

After that first run, add the additional scopes (replay/cancel, approvals, A2A, MCP) only when the verified trace justifies them, and rotate the key once you need new audit evidence.

Open playground Open verification

Create key

Manual preflight reminder

Confirm the target service account, current usage pressure, and any manual billing follow-up before generating a new secret. This lane stays navigation-only and does not auto-block issuance for you.

Review service account Review usage pressure Confirm plan and billing

New API keys are only revealed once at creation time. Store the secret before navigating away.

Rotation creates a replacement key and revokes the previous secret immediately, which is the safest path for routine rollover.

Recommended first-run scope

Start with `runs:write` for the first workspace demo flow. Add broader scopes only when the key also needs replay, cancel, approvals, MCP, or A2A actions.

After the first run queues via `/playground`, revisit `/usage` to capture run pressure and `/verification` to log the evidence before extending scope.

After key creation

The normal next lane is: keep the secret in your own vault, run the governed demo in Playground, confirm the meter in Usage, then carry the same run ids into Verification and later the mock go-live drill if readiness is still on track.

Existing keys

Loading API keys...

Audit export continuity

After you pair an API key with a service account, reopen the Latest export receipt in/settings?intent=upgrade, capture the filename, filters, and SHA-256, and carry that same proof through verification, the go-live drill, and the eventual admin handoff.

Navigation-only manual relay: these links preserve the workspace context but do not automatically attach the audit export or finish rollout steps for you.

Reopen audit export receipt Capture verification evidence Reopen go-live drill

First-run governance path

Pair the key with a workspace service account, then use `/playground` to submit the first `runs:write` request. Capture the `run_id` and reference it in `/usage` or `/verification` so the Week 8 checklist sees the trace.

Once the demo evidence looks clean, rehearse the go-live drill or confirm verification evidence before bouncing back to admin readiness; this keeps the entire chain auditable.

When you need replay, cancel, approval, A2A send/cancel, or MCP calls, incrementally add the matching scopes (`runs:manage`, `approvals:write`, `a2a:write`, `mcp:call`) for the same key or rotate to a new one. Keep the scope list narrow—each permission should align with a real workflow.

Review service accounts Run a verification demo Capture Week 8 evidence

Status semantics

`active` means the key can still participate in a governed workspace flow. `revoked` means the key is historical only and should not back new traffic. Any other state should be treated as manual-review territory before it is used again.

Onboarding handoff

After key setup, invoke Playground to create or confirm the first successful demo run.

Open Playground

Current blockers

Baseline bootstrap is not complete yet.

Service account is still missing.

API key is still missing.