Security Best Practices

Security is a top priority at LiteLLM. Use the following practices for production and enterprise deployments.

1. Monitor security emails and upgrade promptly

Monitor the email address associated with your LiteLLM Enterprise account for CVE alerts and security updates. For large or major security updates, LiteLLM notifies Enterprise customers by email 7 days before public disclosure. Use this window to test and deploy the updated version, and reply with any upgrade issues.

Make sure these emails reach both your security and platform teams.

2. Run a supported stable release

Stay on the latest stable release and include LiteLLM upgrades in your regular patching process. Pin an exact version or image digest instead of using latest, and verify the Docker image signature before deployment.

See the LiteLLM release cycle for the current release schedule.

3. Use least-privilege access

Assign the minimum required RBAC role and keep the number of proxy administrators small.

Applications and users should use scoped Virtual Keys, not the LiteLLM master key. Use a separate service account key for each production workload so access can be revoked without affecting other services.

4. Connect your enterprise identity provider

SSO

Enable SSO for the Admin UI so authentication, MFA, and sign-in policies remain centralized in your identity provider.

JWT

Enable JWT authentication for API traffic so workloads can use signed identities from your OIDC provider instead of shared, long-lived API keys. JWT claims can also map requests to LiteLLM users, teams, models, and spend controls.

SCIM

Enable SCIM to automatically provision and deprovision users and teams. When a user is removed from your identity provider, LiteLLM removes their associated keys and access tokens, reducing stale access.

5. Restrict network access

Run the LiteLLM Gateway on a private network when possible and expose only the routes clients need. Review public route settings before deployment.

Use TLS for client-to-gateway and gateway-to-provider traffic. Keep certificate verification enabled; if your organization uses a private CA, configure a custom CA bundle.

6. Protect secrets and review audit logs

Store provider credentials, the master key, and the salt key in your platform's secret store or a supported secret manager. Do not commit secrets to config.yaml or source control. Follow the master key rotation guide, and do not rotate LITELLM_SALT_KEY after credentials have been stored.

Enable audit logs and review administrative changes such as key creation, key deletion, role changes, and team updates.

7. Add guardrails for sensitive workloads (optional)

If your workloads handle sensitive or regulated data, add guardrails to screen prompts and responses. We recommend Bedrock Guardrails for content filtering, PII detection, and denied-topic policies, and the LiteLLM content filter for lightweight, regex-based blocking of specific words or patterns. Guardrails can be applied per key, team, or model so you can enforce stricter controls where they are needed.

8. Configure Secure cookies behind a TLS-terminating reverse proxy

The proxy's session, SSO, and SAML cookies are marked Secure whenever the public-facing origin is HTTPS. When TLS terminates at a reverse proxy or load balancer in front of LiteLLM, LiteLLM only sees the plain-HTTP hop from that proxy, so it needs one trusted signal to know the public origin is actually HTTPS:

• Set PROXY_BASE_URL to the exact https:// origin your users see in their browser. This is the simplest option and takes precedence over everything else.
• Otherwise, set general_settings.use_x_forwarded_for: true and general_settings.mcp_trusted_proxy_ranges to your reverse proxy's CIDR range(s). LiteLLM then honors X-Forwarded-Proto: https from that proxy, but only when the request's direct peer address falls inside one of those CIDRs: an untrusted caller cannot spoof this header to strip Secure from its own cookies.

general_settings:
  use_x_forwarded_for: true
  mcp_trusted_proxy_ranges:
    - "10.0.0.0/8" # your reverse proxy / ingress controller's network

Without one of these configured, a deployment behind TLS termination gets cookies without Secure, since LiteLLM has no trusted way to tell it is being reached over HTTPS. Neither setting is MCP-specific despite the mcp_ prefix; both are the general request trust boundary LiteLLM uses for X-Forwarded-* headers.