Admin follow-up contextAPI keys
You navigated here via the admin Week 8 readiness summary. Continue the targeted onboarding, billing, verification, or go-live review for this workspace, capture the outcome on that surface, then return to the filtered admin readiness view. This is navigation-only context and does not change identity, impersonate a member, or automate remediation.
Audit export continuity
Reuse the same Latest export receipt from /settings so the filename, filters, and SHA-256 stay chained from settings through verification, go-live, and back into this admin handoff. This manual evidence relay is navigation-only; open the receipt, carry the proof in the workspace surfaces, and then return here to complete the queue or readiness loop.
Current workspace: default · Requested from admin: default · Week 8 focus: Demo run
Treat this as the manual admin → workspace surface → admin loop: follow the requested surface, capture evidence or outcome notes there, then use the return link below to restore the admin context and keep the focus state aligned.
Returning keeps the same admin filter state in place so the operator can continue the governance review without rerunning the drill-down manually.
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.