> ## Documentation Index > Fetch the complete documentation index at: https://langwatch.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Governance overview > One control plane for every AI tool in your enterprise — virtual keys, SSO, per-user identity, policy, and budgets across Claude Code, Codex, Cursor, Gemini CLI, and your custom agents. LangWatch Governance is the layer above the AI Gateway that gives your organization a single, auditable view of every LLM call your teams make — from a developer's IDE all the way to your production agents. It does three things at once: Devs sign in via your company SSO. Their CLIs (Claude Code, Codex, Cursor, Gemini CLI) talk to the gateway with a per-user virtual key. Per-user attribution, per-user budgets, one revoke kills it everywhere. Connect providers once, publish routing policies once, define budgets once. Users inherit it all without picking a model provider, an order, or a fallback chain. The langwatch binary wraps every coding-assistant CLI. langwatch login handles SSO; langwatch claude exec's Claude Code with the right env vars pre-injected. ## What problem this solves Enterprises rolling out AI tooling hit the same wall, in this order: 1. **Devs use Claude Code, Codex, Cursor, Gemini CLI.** Each tool wants its own API key. Ops are now distributing dozens of long-lived raw keys via tickets and Slack DMs. 2. **Per-engineer cost attribution becomes impossible.** Anthropic's admin console shows one big workspace bill; you can't tell if it was your senior engineer or a runaway loop. 3. **Off-boarding is a manual sweep.** When someone leaves, who tracks down all the keys they had? 4. **Security gets uncomfortable.** A key on someone's laptop is one stolen laptop away from being the company's API bill. LangWatch Governance fixes the whole sequence by making the dev's identity (via SSO) the credential. The dev never sees a raw provider key. Their gateway-issued virtual key inherits the organization's policy automatically. Revoking access is one click. ## Architecture at a glance ``` ┌─────────────────┐ SSO ┌──────────────────┐ │ Dev terminal │──────────▶│ Your IdP (Okta) │ │ $ langwatch │ └────────┬─────────┘ │ login │ │ SAML │ claude │ ▼ └────────┬────────┘ ┌──────────────────┐ │ │ LangWatch app │ │ short-lived │ /api/auth/cli/* │ │ bearer (vk-lw-*) │ │ ▼ └────────┬─────────┘ ┌──────────────────┐ │ trust │ AI Gateway │◀──────────────────┘ (virtual key │ gateway.lw.ai │ issued) └────────┬─────────┘ │ │ resolves VK → org's │ policy + provider creds │ ▼ Anthropic / OpenAI / Gemini / Bedrock / Vertex / Azure ``` The dev's CLI never sees a real provider key. The gateway holds the upstream credentials, owned by the organization, paid by the organization, governed by LangWatch policy. The dev's identity is preserved end-to-end via JWT claims (`organization_id`, `project_id`, `principal_id`, `personal: true`) so dashboards, audit, and budgets attribute usage to the right person without leaking tokens. ## What stays the same vs the existing AI Gateway * **Virtual keys still drive every request.** Personal VKs are the same shape as service VKs — same `vk-lw-…` secret format, same gateway code path. The discriminator is the project the VK lives in (`Project.isPersonal=true`). * **The OpenAI-compatible API at `/api/v1/*` is unchanged.** Any tool that already speaks the gateway speaks personal keys with no code change. * **Existing project + service-account flows keep working.** Personal keys are an addition, not a replacement. ## What's new * Routing policies decouple the credential from the provider chain — see [Routing policies](/docs/ai-gateway/governance/routing-policies). * The dispatcher now filters the credential chain by the request's resolved model so a personal VK with multiple providers doesn't waste fallback budget hitting wrong-provider creds first. * Per-user JWT claims and trace attribution land everywhere automatically. ## Rollout & permissions On SaaS, the AI Gateway nav surface (virtual keys, providers, routing policies) and the Governance surface (`/governance`, ingestion sources, anomaly rules, compliance export) roll out per organization, independently of each other. When a gateway is wired up, the chrome is **persona-aware**: admins land on the org switcher + governance KPIs; engineers using a CLI land on personal-key management; LLMOps users (the majority) see the existing dashboard with zero chrome change. See [Personal IDE keys](/docs/ai-gateway/governance/personal-keys) for the full storyboard. Permissions are governed by an RBAC catalog (not by ADMIN/MEMBER role alone): `governance:view/manage`, `ingestionSources:manage`, `anomalyRules:manage`, `complianceExport:manage`, `activityMonitor:view` — assignable via the existing `CustomRolePermissions` JSON column for delegation. Default role attachments + delegation surface are documented in [Compliance architecture](/docs/ai-gateway/governance/compliance-architecture#3-rbac--permission-driven-not-role-driven). ## Where Personal IDE keys sit in the bigger picture Personal IDE keys are **Tier 1** — the proxy tier — of LangWatch's five-tier control plane. The same primitives feed audit-log ingestion, OpenTelemetry, BYOK endpoint routing, and the sandboxed runtime. See [Control plane & integration tiers](/docs/ai-gateway/governance/control-plane) for the full taxonomy and where each enterprise platform (Claude Code, Copilot Studio, Cowork, Workato, …) fits. ## Where to next * For a dev who just wants to use the CLI: [Personal IDE keys](/docs/ai-gateway/governance/personal-keys) * For the broader 5-tier control-plane story: [Control plane & integration tiers](/docs/ai-gateway/governance/control-plane) * For an admin onboarding their org: [Admin setup](/docs/ai-gateway/governance/admin-setup) * For the full CLI reference: [`langwatch` CLI](/docs/ai-gateway/cli/overview) * For the model-aware routing policy: [Routing policies](/docs/ai-gateway/governance/routing-policies)