What happens when the component you installed specifically to find vulnerabilities becomes the vulnerability? That question is no longer hypothetical. In 2026, a supply-chain attack exposed terabytes of credentials belonging to more than 2,500 organizations, including major tech firms. The entry point was a compromised open-source security tool. The group behind it, identified in reporting as a financially motivated crew called TeamPCP, began the operation on March 24, 2026. The scale of the leak became public months later.
One detail in the available reporting deserves a flag before anything else. Coverage of this incident names two different pieces of software as the compromised link. Some accounts point to Trivy, the open-source scanner that checks images and repositories for known vulnerabilities. Ars Technica’s write-up names LiteLLM, the open-source proxy that standardizes calls across AI model providers. I am not going to resolve that discrepancy from secondary sources, and neither should you. But the ambiguity is itself instructive, because both candidates share a structural property that matters more than which one turns out to be correct.
Two very different tools, one identical risk profile
A vulnerability scanner and a model-routing proxy do unrelated jobs. Architecturally, they occupy the same position in a modern stack. Both are unglamorous plumbing. Both run with credentials far broader than their function would suggest. And both are trusted precisely because nobody thinks of them as attack surface.
A scanner in a CI pipeline typically holds registry credentials, repository read access, and often write access to post results back. A model proxy holds provider API keys, and in most deployments it holds all of them, because centralizing keys is the entire reason teams adopt a proxy in the first place. Ask yourself which single process in your infrastructure could hand an attacker the largest set of usable secrets in one read. In a lot of agent deployments, the answer is the thing sitting between your agents and the outside world.
Credential concentration is an architectural decision
The reason terabytes of credentials were available to leak is that somebody, in thousands of separate organizations, decided to put them within reach of one process. That decision was rational at the time. Key sprawl is a real operational problem. Rotating secrets across forty microservices is miserable. A gateway that owns the keys and enforces policy centrally is a genuine improvement over each service carrying its own.
The tradeoff is that you have converted a distributed problem into a concentrated one. Concentration is fine when the concentrating component is small, well-audited, and slow-moving. It is dangerous when that component is a fast-evolving open-source project pulling dozens of transitive dependencies and shipping frequent releases, which describes essentially every useful piece of AI infrastructure right now.
Why agent systems make this worse
Agent architectures compound credential concentration in ways that traditional services do not. Three reasons stand out.
- Agents need breadth by design. An agent that can only call one API is barely an agent. The value proposition is tool access, which means credentials for many systems, held somewhere the agent can reach.
- Scopes drift upward. Nobody starts an agent with admin rights. But every failed action produces pressure to widen permissions, and widening is easier than debugging. Over months, agent credentials ratchet toward maximum privilege.
- Provenance gets fuzzy. When a human commits code, you know who did it. When an agent writes and merges changes, and another agent reviews them, the chain of accountability for a malicious dependency addition becomes genuinely hard to reconstruct.
Combine those with a compromised piece of shared infrastructure and the blast radius stops being one organization. It becomes every organization that installed the same package, which is what the 2,500-plus figure represents.
What actually reduces exposure
Nothing here is exotic. It is just unpopular, because it costs convenience.
- Treat every proxy, scanner, and orchestrator as a privileged component with a threat model, not as tooling.
- Pin dependencies by hash, not version range, and verify build provenance for anything that touches secrets.
- Issue short-lived credentials to agent infrastructure. If a leaked key expires in fifteen minutes, terabytes of exfiltrated secrets lose most of their resale value.
- Log egress from components that hold keys. A scanner that suddenly makes outbound connections to an unfamiliar host is a detectable event, if anyone is watching.
- Segment by trust boundary rather than by team. Your production keys and your experimental agent sandbox should not share a secret store.
The uncomfortable part
The AI tooling ecosystem grew fast because it was open, composable, and easy to adopt. Those same properties are what made a single compromise reach thousands of organizations. There is no version of this where we keep the velocity and drop the exposure.
What we can change is where we place trust. Right now, most agent stacks extend maximum trust to the components with the least scrutiny. March 24, 2026 is a reasonable date to start treating that as a design flaw rather than a fact of life.
🕒 Published: