LiteLLM Proxy Security Guide: Master Key and Virtual Keys

A LiteLLM Proxy holds the API keys for every model provider an organisation uses, so whoever obtains its master key, or exploits one of its authentication flaws, inherits the organisation's entire AI spend and every credential stored behind it. In 2026 alone CISA added three LiteLLM vulnerabilities to the Known Exploited Vulnerabilities catalogue, Wiz found hundreds of internet-facing gateways still accepting the documentation example key, and malicious LiteLLM packages were published twice. This guide covers how authentication works in LiteLLM Proxy, the master key and salt key, virtual keys and roles, MCP server credentials, logging and audit, a hardening baseline and the supply chain controls specific to running LiteLLM. It is for platform, AI engineering and security teams who self-host the proxy. The architectural case for AI gateways in general is in the AI Gateway and LLM Gateway Guide; this page goes deep on one implementation.

Key takeaways

The master key is a root credential. It is the Proxy Admin key, the Admin UI password if UI_PASSWORD is unset, and, according to Wiz research reported on our breach page, the secret that signs session tokens; never use the documented example value.
Set LITELLM_SALT_KEY before adding models and never change it. It encrypts the provider credentials stored in the database; with it set, the master key becomes a pure authentication secret that can be swapped safely.
Give every caller its own virtual key. Scope keys with models, allowed_routes, max_budget, duration and rate limits, and block or regenerate them individually.
MCP is the newest attack surface. CVE-2026-59822 accepted any bearer token on the MCP endpoint and CVE-2026-42271 let any key holder spawn commands through MCP test endpoints; both are KEV-listed.
Treat the proxy as a supply chain dependency with secrets inside. Pin exact versions and image digests, and rotate everything it held if you ran a malicious build such as 1.107.0.

How identity and access work in LiteLLM Proxy

LiteLLM Proxy sits between applications and model providers. Callers authenticate to the proxy with a LiteLLM key; the proxy then calls OpenAI, Anthropic, Azure OpenAI, Amazon Bedrock, Vertex AI or other providers with the provider credentials it stores. That makes three distinct credential layers, each with different owners and failure modes.

Credential	Set by	What it does	If it leaks
Master key (`LITELLM_MASTER_KEY` or `general_settings.master_key`, must start with `sk-`)	Operator	Proxy Admin on every API; Admin UI login when `UI_PASSWORD` is unset	Full control: create keys, read spend, add pass-through routes, change models
Salt key (`LITELLM_SALT_KEY`)	Operator	Encrypts provider credentials, environment variables and MCP credentials stored in the database	With a database dump, stored provider keys can be decrypted
Virtual keys (`/key/generate`)	Admins, team admins or internal users	Per-caller access with budgets, models and route limits; stored as hashes	Spend and data access within that key's scope until blocked
Provider credentials	Config file, environment, database or secret manager	Upstream API keys or cloud roles used by the proxy	Direct provider abuse, bypassing the proxy (LLMjacking)
Upstream MCP credentials	Config or per-user variables	API keys, bearer tokens, OAuth clients or SigV4 for tool servers	Access to the tools and data behind each MCP server
Database URL (`DATABASE_URL`, Postgres)	Operator	Holds keys, teams, spend logs and encrypted credentials	Read access to spend logs and encrypted secrets; write access to keys

Database required for real access control: virtual keys, teams, budgets and rotation need a Postgres database. A proxy running with only a master key has one shared identity for every caller.
Virtual keys are hashed, not encrypted: the master key rotation documentation states this, which is why virtual keys survive a master key change. Spend logs record the SHA-256 hash (user_api_key_hash), not the key.
Headers: LLM routes use Authorization: Bearer with a LiteLLM key; the MCP endpoint uses x-litellm-api-key; upstream MCP credentials are passed per server as x-mcp-{server_alias}-{header_name}. Be careful with extra_headers, which can forward a client's Authorization header to an MCP server if you list it.

For provider key abuse patterns and detection, see the LLMjacking Guide.

Admin roles and privileged access

LiteLLM separates global proxy roles from team and organisation roles. Team and organisation administration requires an Enterprise licence; on the open source build most organisations rely on proxy_admin plus internal_user.

Role	Can do	Cannot do	Assign to
`proxy_admin`	Everything: organisations, teams, users, any key, all spend, budgets, models	Nothing is out of scope	Two or three platform operators
`proxy_admin_viewer`	Sign in, view all keys and spend	Create or delete keys, add users, change settings	Finance, audit and security reviewers
`org_admin` (Enterprise)	Create teams and users in its organisation, create keys for its users, view organisation spend	Change organisation budgets, rate limits or allowed models	Business unit leads
`team_admin` (Enterprise)	Manage members, member budgets and keys within editable fields enabled by a proxy admin	Create teams; raise `max_budget` unless allowed; add global models	Application owners
`internal_user`	Create keys where team permissions allow, delete its own keys, view own spend	Add users; see others' items	Developers
Team member (`user`)	View key information and health; further key routes per team member permissions	Act outside its team	Default for team members

Stop using environment credential login: by default the Admin UI at /ui accepts UI_USERNAME (default admin) and UI_PASSWORD, or the master key, and anyone signing in that way is a proxy admin. Create a named proxy_admin database user, then set disable_env_credential_login: true. Keep the /fallback/login break-glass account documented and vaulted.
Use SSO for people: configure SSO for the Admin UI and set disable_password_login_when_sso_enabled once it works, so administrators inherit the IdP's MFA and leaver process.
Login rate limiting: the UI blocks a source address for five minutes after more than 10 failed sign-ins in 60 seconds. Behind a load balancer set trusted_proxy_ranges so the real client address is used, and do not set LITELLM_DISABLE_LOGIN_RATE_LIMIT.
No UI where none is needed: set DISABLE_ADMIN_UI="True" on data-plane instances that only serve API traffic.
Least privilege for low-privilege keys matters: CVE-2026-42271 showed that holders of low-privilege internal-user keys could run commands on the host through MCP test endpoints. Role checks are only as good as the version you run.

Integrations, API tokens and service accounts

Master key and salt key handling

Generate a long random master key (prefix sk-) and a separate long random salt key. Store both in a secret manager, inject them as environment variables, and never commit them to config.yaml.
Set LITELLM_SALT_KEY before the first model is added to the database. The production documentation warns not to change it afterwards, because stored credentials become unreadable.
If a proxy is already running without a salt key, the master key is also the encryption key. The documented path is to set LITELLM_SALT_KEY to the current master key value first, so later master key rotations become simple swaps.
To rotate the master key with a salt key set: replace it in the environment and restart all instances. Without a salt key: back up the database, call POST /key/regenerate with new_master_key, update every place the key is stored, and restart. Either way, the Admin UI logs everyone out.

Virtual key design

One key per workload: issue a key per application, agent or pipeline with key_alias naming the owner (enforce a key_alias_pattern), team_id and metadata for ownership.
Scope tightly: models limits which models a key can call; allowed_routes limits which proxy routes it can reach (keep LLM keys off management and MCP routes unless needed); max_budget with budget_duration caps spend; tpm_limit, rpm_limit and max_parallel_requests cap throughput.
Expire and rotate: set duration so keys expire. Regeneration with a grace_period and scheduled rotation (auto_rotate, rotation_interval, LITELLM_KEY_ROTATION_ENABLED) are Enterprise features; on the open source build, rotate by issuing a new key and blocking the old one.
Revoke fast: POST /key/block disables a key immediately and /key/unblock restores it.

Provider and MCP credentials

Secret manager integration: LiteLLM can read provider credentials from AWS Secrets Manager, AWS KMS, Azure Key Vault, Google Secret Manager, Google KMS, HashiCorp Vault and CyberArk Conjur through general_settings.key_management_system. In config.yaml, reference secrets as os.environ/VAR_NAME rather than literal values.
Prefer workload identity for cloud providers: where the proxy runs in the same cloud as Bedrock or Vertex AI, use the platform's role-based identity instead of static keys, and restrict the role to model invocation. The LiteLLM supply chain incident showed stolen instance role credentials tested against Amazon Bedrock within hours.
MCP servers: avoid allow_all_keys, which exposes a server to every key; grant MCP servers per key, team or organisation. Prefer OAuth 2.0 client credentials or token exchange over static auth_value strings. Leave LITELLM_ENABLE_MCP_STDIO unset unless you need local stdio servers, because stdio means the proxy spawns processes. See the MCP Gateway and MCP Server Governance Guide.
Log content is a credential store too: LiteLLM's October 2026 incident analysis found that GitHub CLI OAuth tokens embedded in logged response bodies ended up in the logs of an internet-exposed internal deployment, and attackers used them to ship a malicious release. See the LiteLLM Supply Chain Attack 2026.

Logging and detection

LiteLLM produces three useful record types: spend logs per request (with key hash, model, tokens and cost), application logs (set LITELLM_LOG="ERROR" and json_logs: true in production, with set_verbose: False), and audit logs of changes to keys, teams, users and models (store_audit_logs: true, Enterprise, viewable under Logs > Audit Logs and exportable to object storage). Decide deliberately whether to log prompt and response bodies: they help investigations but can contain personal data and, as the 2026 incident showed, secrets.

Signal	Source	What it can indicate	Mapping
Requests with an unknown or malformed Authorization header, SQL error spikes on key verification	Proxy and reverse proxy logs	CVE-2026-42208 probing	T1190 Exploit Public-Facing Application
Calls to `/mcp/` from unexpected clients, or with very short bearer tokens	Reverse proxy logs	CVE-2026-59822 style bypass attempts	T1190
Calls to `/mcp-rest/test/connection` or `/mcp-rest/test/tools/list`	Reverse proxy logs	CVE-2026-42271 command execution attempts	T1059 Command and Scripting Interpreter
New keys, users, models or pass-through routes created outside change control	Audit logs	Persistence by someone holding admin access	T1098 Account Manipulation
Spend spike per key, new model families, off-hours bursts	Spend logs, budget alerts	Stolen virtual key or LLMjacking	T1496 Resource Hijacking; OWASP LLM10:2025 Unbounded Consumption
Proxy process spawning shells or miners; outbound traffic to non-provider hosts	EDR, container runtime, egress logs	Host compromise after exploitation	T1059, T1496
Provider console showing usage from addresses other than the proxy	Provider logs	Provider key copied off the proxy	T1552 Unsecured Credentials

Metrics that show the controls are working:

Shared key ratio: share of traffic made with the master key or shared keys rather than per-workload virtual keys (target near zero).
Key hygiene: percentage of virtual keys with an owner alias, a budget and an expiry.
Version currency: days behind the latest patched release, and days to patch any KEV-listed LiteLLM CVE.
Exposure: count of proxy instances, Admin UIs and MCP routes reachable from the internet (target zero without an identity-aware proxy).
Spend anomaly time to block: minutes from a budget or anomaly alert to the key being blocked.

Hardening baseline

Patch to a fixed release and stay current: 1.83.7 or later fixes CVE-2026-42208 and CVE-2026-42271; 1.84.0 or later fixes CVE-2026-59822. Watch the project's GitHub security advisories, which in 2026 also included a Host header authentication bypass and MCP OAuth passthrough bypass.
Keep it private: serve the proxy on a private network, behind an identity-aware proxy or API gateway, with TLS. Block /mcp/ and /mcp-rest/test/* at the edge unless used. Do not enable allow_requests_on_db_unavailable outside a VPC that the internet cannot reach.
No default secrets: unique master key and salt key from a secret manager; check every deployment for the documentation example key.
Run as non-root: set LITELLM_NON_ROOT="true", and in Kubernetes runAsNonRoot: true, a fixed non-root UID, readOnlyRootFilesystem: true with only the writable paths LiteLLM needs, and all capabilities dropped.
Pin what you run: use an exact version tag, never :latest, and preferably the image digest; for pip installs, pin with hashes. This is what protected users from the malicious 1.107.0 release and the earlier 1.82.7 and 1.82.8 packages.
Restrict the proxy's own identity: its cloud role should only invoke models; block instance metadata access from workloads that do not need it; egress only to configured providers and MCP servers.
Reduce error and body logging: disable_error_logs: true (also the documented workaround for CVE-2026-42208) and a deliberate decision on request and response body logging.
Disable unused features: DISABLE_ADMIN_UI on data-plane pods, stdio MCP off, no pass-through endpoints that are not reviewed.

Rolling it out

Inventory: find every LiteLLM deployment, including developer laptops and notebooks running the proxy, with version and exposure. See the Unsanctioned AI Agents and MCP Servers Guide.
Emergency items first: patch, remove internet exposure, replace default master keys, rotate provider keys on any instance that was exposed or vulnerable.
Introduce virtual keys in a pilot team, with budgets in monitoring mode (soft budgets and alerts) before hard limits, so you learn real usage.
Migrate callers off the master key application by application; keep the old shared key for a defined cut-over window, then block it.
Enforce: hard budgets, disabled environment login, SSO only. Roll back by unblocking keys or raising budgets, not by re-sharing the master key.

Decision guidance

Open source or Enterprise: the open source build covers master key, salt key, virtual keys, budgets and blocking. Audit logs, team and organisation admin roles, scheduled key rotation and storing virtual keys in a secret manager require an Enterprise licence. Regulated or multi-team estates usually need the audit logs; a single team may manage with change-controlled config and reverse proxy logs.
Database-stored or config-file models: store_model_in_db lets admins change models at run time and syncs pods, but puts encrypted credentials in Postgres and makes the salt key critical. Config-file models with os.environ/ references keep secrets in the secret manager and changes in version control.
Self-hosted or managed gateway: self-hosting puts patch speed and supply chain verification on you, which 2026 showed is a real operational cost.

Common misconfigurations

Documentation example key in production: Wiz found 294 of 3,074 internet-facing gateways (9.6 per cent) accepting the example key and 191 with no authentication at all, as described in the LiteLLM MCP Auth Bypass 2026 page.
Everyone shares the master key: no attribution, no per-caller budget and no way to revoke one caller without breaking all of them.
Changing the salt key: rotating LITELLM_SALT_KEY after models are stored makes the stored provider credentials unreadable and causes an outage; it is not a rotation mechanism.
Floating image tags: deployments that pulled latest or main-stable during the 21 October 2026 window received the malicious build. Rotation of every credential the proxy held is the only safe response after running it.
Internal deployment exposed to the internet: the October 2026 incident began, according to LiteLLM, with logs on an internal deployment reachable from the internet.
Provider keys usable from anywhere: if a provider key works outside the proxy, a stolen key bypasses every budget. Use provider-side network restrictions or workload identity where available.

Framework mapping

Control	OWASP Top 10 for LLM Applications 2025	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ATT&CK / ATLAS
Master key, salt key and provider keys in a secret manager	LLM02 Sensitive Information Disclosure	IA-5, SC-28	PR.AA-01, PR.DS-01	T1552, AML.T0055 Unsecured Credentials
Per-workload virtual keys, roles, allowed_routes	LLM06 Excessive Agency	AC-6, AC-2	PR.AA-05	T1078 Valid Accounts
Budgets and rate limits per key	LLM10 Unbounded Consumption	SC-5	PR.IR-04	T1496 Resource Hijacking
Version pinning, digest verification, patching	LLM03 Supply Chain	SI-2, SR-3, SI-7	ID.RA-01, GV.SC-07	T1195.002 Compromise Software Supply Chain
Private exposure, MCP route blocking	LLM06 Excessive Agency	SC-7, CM-7	PR.IR-01	T1190
Spend, audit and proxy logs to SIEM	LLM10 Unbounded Consumption	AU-2, AU-12, SI-4	PR.PS-04, DE.CM-09	T1098

Practitioner checklist

Inventory every LiteLLM Proxy and its version; upgrade to a release that fixes all KEV-listed LiteLLM CVEs.
Replace any example or shared master key with a unique secret from a secret manager; set LITELLM_SALT_KEY once and never change it.
Issue one virtual key per workload with owner alias, models, allowed_routes, budget, rate limits and expiry.
Create named proxy_admin users, enable SSO, set disable_env_credential_login, and vault the break-glass account.
Keep the proxy and Admin UI off the internet; block /mcp/ and /mcp-rest/test/* where unused; leave MCP stdio disabled.
Avoid allow_all_keys on MCP servers and prefer OAuth or token exchange to static upstream tokens.
Run as non-root with a read-only root file system; restrict the proxy's cloud role and egress.
Pin image digests or hashed pip requirements; never deploy floating tags.
Forward spend, audit and proxy logs to the SIEM; alert on spend spikes, new admin objects and MCP test endpoint calls.
Keep a rotation runbook covering master key, provider keys, MCP credentials and database credentials.

LiteLLM Proxy Security Guide: Master Key, Virtual Keys, MCP and Supply Chain