In March 2026, a threat group called TeamPCP did something that should concern every organization running AI workloads. They did not break into a system. They poisoned the tool your security team uses to confirm nothing is broken.
Trivy is one of the most widely deployed open source vulnerability scanners in the world. TeamPCP compromised it on March 19. Four days later they used credentials stolen from Trivy to compromise KICS, a security policy scanner for infrastructure-as-code. The time between the Trivy takedown and their next target was 8.5 hours.
That next target was LiteLLM.
Why LiteLLM Changes the Story
LiteLLM is not a library most security teams think about. It is the layer where organizations route requests to AI models, enforce policies at runtime, and generate the audit trail that governance programs depend on. It concentrates API keys for every AI provider an organization uses. OpenAI keys alongside Anthropic keys alongside AWS credentials alongside database passwords. All of it in one place.
It was not directly compromised. It did not need to be.
LiteLLM's CI/CD pipeline ran Trivy without pinned versioning. When the pipeline next triggered, the malicious trivy-action extracted the PyPI publish token directly from the GitHub Actions runner environment. No one broke into LiteLLM. LiteLLM's own build process handed the attacker the key.
The payload landed in proxy_server.py. That is LiteLLM's core routing and logging module.
The persistence mechanism placed in Python site-packages triggers on every Python interpreter startup. It survives LiteLLM uninstallation. The 40-minute public exposure window that got reported understates the real exposure significantly.
The Scan Said Clean
Trivy ran. The scan completed. The results came back clean. Credentials were already being extracted.
Unit 42 confirmed it: the malicious binary fetched its payload from a typosquatted domain while the legitimate Trivy scanner ran beside it, producing clean results in real time.
The scan log showed a clean environment. The scan log was produced during an active exfiltration.
This is the TanStack pattern from Accountability Report Six, one layer deeper. That piece drew the line between attestation and authorization: the authorization record was absent. That was the gap. Here the gap is different and harder. The record exists. The infrastructure that produced it was under adversarial control.
The Record You Cannot Trust
LiteLLM's disclosure was better than most. They engaged Mandiant. They released a clean version through a new pipeline. They provided checksums and implemented image signing. That matters and it should be acknowledged.
None of it resolves this: the module that was compromised handled logging. Organizations cannot confirm that AI usage records from the exposure window were unaltered. Not because the logs are missing. Because the logs were produced by a module operating under adversarial control and there is no independent mechanism to verify them.
No standard currently requires you to verify the integrity of that log. No standard defines where the governance perimeter for an AI workload ends. NIST AI RMF governs the model. ISO 42001 anchors to management responsibility. Neither reaches the gateway that routes requests to the model, logs what the model did, or enforces policy at runtime.
Every organization running LiteLLM with unpinned dependencies during March 2026 is in the same position: they cannot confirm what their AI systems did during that period.
Accountable by Design means the integrity of the record is a design requirement, not an assumption. Right now, for most organizations running AI workloads, it is an assumption.
Where in your organization right now is a tool running ahead of the rule designed to govern it? That gap is what we are here to map.
Vordan publishes the Gap Alert when the intelligence warrants it. The Accountability Report publishes every Sunday. The doctrine is Accountable by Design.
Wiz -- Trivy Compromised by TeamPCP | https://www.wiz.io/blog/trivy-compromised-teampcp-supply-chain-attack
Wiz -- KICS GitHub Action Compromised | https://www.wiz.io/blog/teampcp-attack-kics-github-action
Snyk -- How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM | https://snyk.io/blog/poisoned-security-scanner-backdooring-litellm/
LiteLLM -- Security Update: Suspected Supply Chain Incident | https://docs.litellm.ai/blog/security-update-march-2026
Unit 42 -- Weaponizing the Protectors: TeamPCP's Multi-Stage Supply Chain Attack | https://unit42.paloaltonetworks.com/teampcp-supply-chain-attacks/
Microsoft Security Blog -- Guidance for detecting, investigating, and defending | https://www.microsoft.com/en-us/security/blog/2026/03/24/detecting-investigating-defending-against-trivy-supply-chain-compromise/