LiteLLM credential exposure response
When a LiteLLM-related credential is exposed, identify the credential's authority, contain that access, update legitimate workloads, and verify the result. Investigate earlier use separately. Rotation changes future access; it does not reconstruct the past.
Determine what was exposed
| Credential type | Scope to verify | Response dependency |
|---|---|---|
| Gateway virtual key | Permitted models, routes, owner, and team | Clients using that virtual key |
| Upstream provider credential | Provider-side projects, permissions, and workloads | Gateway routes and any direct users of that credential |
| Proxy administrative credential | Management authority and changes made through it | Administrative access and possibly newly created access |
Use the deployed configuration and authoritative records to establish scope. LiteLLM supports virtual-key model access and spend tracking; refer to its virtual-key documentation for your deployment. Do not assume a key's name proves its privilege.
Contain access while preserving existing evidence
- Record when exposure was discovered and the earliest plausible exposure time. Do not place the secret itself in the incident ticket.
- Revoke or rotate affected access using the appropriate gateway or provider administration process. For ongoing unauthorized use, prioritize containment.
- Update legitimate clients through the secret-management workflow and check service health.
- Preserve existing request, administrative, and deployment records alongside containment where practical. Do not delay revocation for a complete export.
Verify the old access is no longer effective
Check administrative state and, where authorized, perform a controlled validation against your own service. Confirm what response you expect and whether it reflects gateway authentication or an unrelated upstream failure. Check all relevant routes, replicas, and direct provider access paths within scope. A successful new credential does not prove the old credential stopped working.
Record verification time, the control point tested, and the outcome without logging secret values. If an administrative credential was involved, review changes to keys, users, routes, and permissions in the exposure window; replacing that credential alone may not remove access created earlier.
Reconstruct use before containment
Join the credential's pseudonymous reference to requests and authorized workload records. Compare timing, model mix, token use, observed networks, and cost with established activity. Reconcile unfamiliar traffic with owners. Track identity and retention gaps explicitly.
Synthetic example: an upstream key is replaced at 11:00, but a separate client used it directly before that time. Gateway logs alone cannot establish the complete scope. Provider-side records and the direct client's traces are needed. State that gap rather than reporting the gateway total as all affected usage.
Close with evidence and follow-up
Record the exposed authority, containment and verification times, affected workloads, reviewed requests, and unresolved questions. Label disputed cost separately from confirmed unauthorized consumption. Assign follow-up work for overly broad credentials, missing ownership, or incomplete request correlation.
Continue with API-key investigation and gateway provenance. This is a credential-response workflow, not a claim that a particular LiteLLM release is compromised.