Rolling out to an enterprise workspace

A practical walkthrough for standing up roles, budgets, guardrails, and governance before opening the workspace to a whole organization.

Do this in order — each step is easier before the next one adds more members and keys to reason about.

1. Set the workspace-level spend cap first, before any project or team key exists. See Setting spend controls.
2. Define roles from the permission taxonomy — members, keys, billing, budgets, models, policies, plus audit:read for anyone in security who needs visibility only. See Roles, audit log, and model governance.
3. Turn on the model allowlist and PII redaction under Guardrails — the two guardrails worth enabling before any project keys are minted, since they protect you from code you don't directly control.
4. Turn on the model request/approve flow so new models entering the catalog don't become callable in production until someone with approval permission signs off.
5. Provision one scoped key per project or service (not a shared workspace key), sized and capped independently — see API key scopes and Relixr for platform teams.
6. Point each project at Usage analytics, filtered to its own key, as its cost and activity dashboard — see Usage analytics.
7. Check the audit log under Team → Audit log a week in, to confirm the actions you'd want a record of are actually showing up the way you expect.