Skip to main content

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.

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:

Personal IDE keys

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.

Admin policy plane

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.

LangWatch CLI

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.
  • 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

Governance ships behind two independent feature flags so pilots can turn on the data plane (gateway) without committing to the full governance UI surface:
  • release_ui_ai_gateway_menu_enabled — exposes the AI Gateway nav surface (virtual keys, providers, routing policies). Ships first.
  • release_ui_ai_governance_enabled — unlocks the Governance home (/governance), ingestion sources, anomaly rules, compliance export. Ships after gateway adoption is proven in the org.
Both flags are PostHog-controlled. Self-hosted deployers can force either one on with FEATURE_FLAG_FORCE_ENABLE=release_ui_ai_gateway_menu_enabled in langwatch/.env. 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 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.

​
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 for the full taxonomy and where each enterprise platform (Claude Code, Copilot Studio, Cowork, Workato, …) fits.

​
Where to next