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.
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.
This remains a manual governance checkpoint. It does not block key creation automatically or perform any support-side change for you.
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.
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.
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.
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 PlaygroundCurrent blockers
Baseline bootstrap is not complete yet.
Service account is still missing.
API key is still missing.