LiteLLM security

After the LiteLLM Supply Chain Attack: What Changes

In early 2025, security researchers documented a supply chain attack targeting LiteLLM, one of the most widely used open-source LLM proxy libraries. The attacker group, tracked as TeamPCP, compromised a dependency in the LiteLLM package ecosystem and used it to exfiltrate API keys from applications running the library.

The attack was not a novel technique. Supply chain compromises via dependency injection have taken down major infrastructure before. What made this incident notable was the target: the proxy layer that thousands of teams trusted to sit between their applications and their LLM provider credentials.

If you run LiteLLM in production, or if you were evaluating it, this incident is worth examining closely. Not to pile on a library that has since responded, but because the architectural questions it raises apply to every team running LLM infrastructure.

What Happened: A Timeline

The attack exploited the trust relationship at the core of how most teams consume open-source software.

LiteLLM is installed as a dependency in production environments. The library handles authentication and request routing to LLM providers. Because it sits between the application and the provider, it has legitimate access to API keys. A compromised version of the library -- or a malicious dependency it pulls in -- can use that access silently.

The specific vector in the TeamPCP attack was a transitive dependency. Not LiteLLM itself, but a package that LiteLLM depends on. This is a harder problem than a direct compromise of the library:

Most teams audit direct dependencies. Almost none audit the full dependency tree.
Transitive dependencies update more frequently and with less scrutiny than direct dependencies.
A malicious transitive dependency can be introduced and removed quickly, making attribution harder after the fact.

Teams that had locked their LiteLLM version but not their full dependency lockfile were exposed without knowing it. Teams that relied on LiteLLM's managed cloud offering had a different attack surface. But the key lesson was the same: the proxy layer has privileged access to credentials, and that privilege needs to be treated seriously.

The Structural Risk in Proxy Architecture

The LiteLLM incident highlights a tension that is inherent to the proxy pattern: the layer you insert to improve control and visibility is also the layer that concentrates risk.

Every LLM proxy -- whether self-hosted or managed -- must hold provider credentials to do its job. This is unavoidable. The design question is not whether the proxy has privileged access, but how that privilege is scoped, monitored, and protected.

In a naive deployment, the proxy holds root-level API keys with no usage scoping. A compromised proxy can exfiltrate those keys and use them with no rate limit or detection mechanism. The credentials represent unbounded financial and data exposure.

The attack also exposed a gap in how many teams think about their AI infrastructure. LLM spend, for some companies, now exceeds their compute spend. The credentials that authorize that spend should be treated like payment credentials -- not like development API keys that get rotated occasionally if someone remembers to.

What Should Change

The response to the TeamPCP attack is not to avoid proxy layers. The proxy pattern solves real problems. The response is to apply the same security rigor to AI infrastructure that mature teams already apply to payment infrastructure and database access.

Credential scoping. Provider API keys should be scoped to the minimum necessary. OpenAI and Anthropic both support project-level or usage-limited keys. If your proxy holds a key that can only be used for specific models with a monthly spend cap, a compromised proxy is a bounded problem, not an unlimited one.

Dependency pinning and auditing. If you run a self-hosted proxy, pin the full dependency lockfile, not just the direct dependency version. Review dependency updates before shipping them to production. This is table stakes for any software that handles credentials.

Key rotation cadence. Treat LLM provider keys like database passwords. Rotate them on a schedule, automate the rotation, and have a runbook for emergency rotation when a compromise is suspected.

Audit logs. Every request that uses a provider credential should produce an audit log. Anomalous request patterns -- unusual volumes, unexpected models, off-hours spikes -- should generate alerts. If you cannot detect unusual usage of your LLM credentials, you cannot detect a compromise.

Blast radius reduction. The goal is to make a compromised credential a bounded incident rather than a catastrophic one. Separate keys per environment (dev, staging, production). Separate keys per service or team where provider plans allow. Spend caps per key. Each of these limits the damage a single compromised credential can cause.

Architectural Lessons From the Incident

The TeamPCP attack points to a few architectural decisions that teams building on LLM infrastructure should revisit.

The library-vs-service boundary matters. A library that runs inside your application process shares your process's memory and network access. A managed service that runs separately has a defined API surface and does not share your application's runtime. These are meaningfully different threat surfaces. Teams that chose self-hosted LiteLLM as a library absorbed a risk they may not have fully evaluated.

Separation of credentials from applications. Applications should never hold LLM provider API keys directly. Credentials should live in a dedicated secrets manager or inside the proxy control plane -- not in environment variables that application code can read. If your application code can read the key, so can any compromised dependency.

Real-time cost monitoring doubles as anomaly detection. Per-request cost tracking isn't just a billing feature. Unusual spend spikes are often the first visible sign of credential misuse. Teams with real-time cost attribution were able to identify the TeamPCP exfiltration faster than teams looking at aggregate monthly invoices.

How SteadIO Approaches This

When we built SteadIO, the TeamPCP attack was part of the context. We treat credential security as a first-class requirement, not an afterthought.

Applications authenticate to SteadIO using short-lived tokens scoped to specific permissions. The proxy holds provider credentials, but each application token is scoped to the features, models, and budgets it needs. A compromised application token cannot access resources outside its defined scope.

Every request produces an immutable audit record. Anomalous usage patterns trigger alerts in real time. Budget enforcement at the proxy layer means a compromised token cannot drive unbounded spend -- it hits the configured limit and stops.

The supply chain concern is also why we run SteadIO as a managed service with a hardened, audited deployment rather than a library you install as a dependency. Your application never touches provider credentials directly; credential management stays inside SteadIO's control plane.

The Takeaway

The LiteLLM supply chain attack is a reminder that AI infrastructure carries real security risk, and that risk scales with adoption. As LLM spend grows, the credentials that authorize it become higher-value targets.

Teams running LLM proxies should review their credential scoping, audit logging, and dependency management practices now, before an incident forces the review. The fixes are not complicated. They require treating AI infrastructure with the same security maturity that production infrastructure deserves.

Jon Hutchins is the founder of SteadIO, an LLM cost control plane built for teams that take AI infrastructure security seriously. Reach him at [email protected].

Learn how SteadIO handles credential security and per-request attribution. Visit steadio.ai.