Casualty Report No. 03 — LiteLLM supply chain, March 2026

1. What happened

LiteLLM is a Python library providing a unified interface to more than a hundred model providers. It sits inside a large share of the world's agent frameworks, MCP servers, and inference pipelines, frequently holding provider API keys and cloud credentials. Public figures put it in the range of millions of downloads per day.

On March 24, 2026, a threat actor group known as TeamPCP obtained the maintainer's PyPI publishing credentials — reportedly through an earlier compromise of Trivy, a security scanner used in LiteLLM's own CI pipeline — and published two backdoored releases, 1.82.7 and 1.82.8, directly to PyPI, bypassing the project's normal release workflow.

LiteLLM's own disclosure states the malicious versions were live for approximately forty minutes before PyPI quarantined them. In that window, independent analysis counted roughly 47,000 downloads.

The payload ran in three stages: credential harvesting, attempted lateral movement across Kubernetes clusters, and installation of a persistent backdoor polling for further instructions. Targets included cloud platform credentials, SSH keys, and Kubernetes configurations.

One figure defines this report. Analysis of the PyPI dependency graph found 2,337 packages depending on LiteLLM, of which 2,054 — 88% — had version specifications permitting the compromised releases at the time of the attack.

The malicious versions were withdrawn. The stolen credentials remained valid until someone rotated them.

2. What FleetRegistry would not have done

FleetRegistry would not have detected the backdoor. It does not scan packages, inspect payloads, monitor egress, or evaluate dependency trees. It would not have known the maintainer's publishing credentials had been taken over, would not have flagged that a release appeared on PyPI without a corresponding repository tag, and would not have blocked the install.

Every one of those is a security or supply-chain function, and capable products exist for each. Several published excellent analyses of this incident within twenty-four hours.

There is a second limit worth stating plainly. FleetRegistry would not have told anyone what was exfiltrated. That is a forensic question answered from network and host evidence, not from a service record.

3. What the record would have contained

This incident is the clearest public illustration of lineage and inherited risk, which is why it is in this series despite the agents being victims rather than actors.

The composition of a worker is part of its identity.

A digital worker is not only an identity and a set of permissions. It is also a substrate: the runtime, the libraries, the tooling it was assembled from. When a registry records that composition as a versioned attribute of the worker rather than an implementation detail, the question "which of my workers were built on litellm 1.82.7 or 1.82.8" is a query against the register.

The industry's actual experience of that question in the days after March 24 was different: a scramble through dependency manifests, CI logs, and container images, in organizations that in many cases did not have a list of which agents existed, let alone what they were made of.

Contamination travels forward, and a new identity is not a clean slate.

Here is the part that matters most, and the reason this concept is called inherited risk rather than dependency scanning.

An agent that ran the compromised package must be treated as a full-credential exposure event. But agents are not static. They are cloned, forked, promoted from staging, and superseded. A successor built from a contaminated predecessor's image, or issued the predecessor's credentials, or inheriting its stored state, carries the exposure forward under a brand-new identity that looks clean by every conventional measure.

Registered lineage — predecessor and successor edges carrying a manifest of what actually transferred: artifacts, credentials, state, configuration — is what makes that population enumerable. Without it, "which of my agents are affected" is answered by inspection of what exists today, which systematically misses everything that inherited from something that no longer does.

Credential rotation becomes bounded work.

The remediation instruction issued across the industry was to treat any host that installed the affected versions as a full credential compromise and rotate everything. "Everything" is a frightening word to an operator who cannot enumerate which non-human identities hold which grants. A register of workers, their sponsors, and their credential scopes converts an unbounded rotation into a finite list.

4. What the record still could not have answered

Whether a given credential was actually used by the attacker. The register establishes exposure scope. It does not establish exploitation.
The state of any unregistered agent. A worker nobody registered is invisible to this reasoning entirely — and shadow agents are, by every available survey, a large fraction of the population.
Composition it was never told. If a worker's substrate is declared by its owner and never independently observed, the record holds a claim at declared rung, not a verified fact. In this incident that distinction is not academic: the compromised package was frequently a transitive dependency, present in agents whose owners did not know it was there.

That last point is a genuine limit on the value of this report's central claim, and we would rather write it down than let a reader discover it.

5. Metrics this incident touches

Lever	Metric
Loss avoidance	Credential-exposure count · incident rate per 1,000 actions
Investigation	MTTR for agent incidents · e-discovery and investigation cost
Governance	Provenance completeness % · shadow-worker count
Compliance	% of actions reconstructable from evidence · attestation coverage

6. Sources

LiteLLM project security disclosure, March 24, 2026
Snyk, Datadog Security Labs, Trend Micro, ARMO, Cycode and BleepingComputer analyses of the TeamPCP campaign, March 2026
FutureSearch dependency-graph analysis of affected downstream packages
PyPI quarantine notices for litellm 1.82.7 and 1.82.8