llmgw
Docs/Governance

Identity and policy

Every key acts as someone, inside a project.

Identity, private and shared credentials, membership, policy, usage, and alerts stay attached to each request.

The gateway uses trusted reverse-proxy SSO for humans and scoped gateway keys for CLIs and services. It remains a single-node control plane.

Identity model

  • Human: SSO-provisioned and able to own private provider connections.
  • Service: administrator-created workload identity that cannot own human subscriptions.
  • System: built-in owner for gateway-managed credentials.
  • Project: membership and aggregate-policy boundary.
  • Roles: owner, admin, member, and viewer.

Authentication boundaries

Admin APIs accept a static recovery/administrator key (LLMGW_API_KEY or LLMGW_API_KEYS) or verified admin-group SSO. Portal APIs require verified human SSO and same-origin mutation. Data-plane APIs accept project keys; the static administrator keys also work there but bypass key and project allowlists and quotas, so give clients project keys. Project keys are never administrator credentials.

Provider connections

Humans can own named encrypted connections. Generic API-key resolution is private default, system connection, then legacy config seed. Copilot services require an exact active project/provider/service binding. Codex OAuth is experimental and human-private.

Narrow binding claimThe exact binding requirement applies to the supported Copilot shared-service path. Generic system API-key fallback is not project-binding-gated today.

Gateway keys

Keys authenticate by SHA-256 hash and belong to one principal/project. If encryption was configured at issuance, an encrypted copy can be revealed by its human owner or an administrator. Older hash-only keys return 409 on reveal. Reveal responses are no-store and audited.

Policy and quotas

Project and key policy intersect across model/provider allowlists, RPM, daily/monthly requests, tokens, estimated cost, and model credits. The key editor exposes every key quota field for creation and later edits. Zero means no additional limit at that key layer; project limits still apply independently.

Every limit is checked, and the request counted, in one SQLite transaction after request validation and just before provider dispatch, so request counts are strict and a request the gateway refuses itself consumes no quota. Token, estimated-cost, and credit counters settle only after a response completes, and a request is admitted while they are below their limit, so concurrent requests can together exceed it. Quota windows are fixed UTC calendar minutes, days, and months, not rolling windows.

A model with no known price records zero estimated cost, so cost limits never stop it. Keys from an external key document (LLMGW_EXTERNAL_KEYS_FILE or LLMGW_EXTERNAL_KEYS_URL) have no quota limits of their own but count against their project's limits.

These are gateway limits, not provider subscription quota scheduling.

Usage, audit, and alerts

Usage records request attribution, status, latency, requested and served model, provider, tokens, estimated cost, credits, and errors. Audit is append-only during its configured retention period; the project does not claim every management mutation is covered.

Quota and key-expiry rules create a durable outbox. An external worker performs delivery.