Callum McMahon, an engineer at FutureSearch, was testing an AI plugin last week when his machine kept crashing. He traced the problem to a malicious file inside LiteLLM — the open-source proxy that half the AI industry uses to route API calls — that was recursively spawning processes until it ate all available RAM. The attackers’ code had a bug. A fork bomb, accidentally. And that dumb mistake is the only reason anyone noticed.

The compromised LiteLLM versions (1.82.7 and 1.82.8) had been sitting on PyPI, downloaded millions of times, quietly harvesting SSH keys, .env files, cloud credentials, and every AI API key it could find. Wiz reported LiteLLM is present in 36% of cloud environments. BleepingComputer put the number of data exfiltrations at roughly 500,000.

The attack chain is almost comically layered

TeamPCP, the group behind this, did not even start with LiteLLM. They first compromised Trivy, a widely-used vulnerability scanner, by exploiting a misconfigured GitHub Actions workflow. That gave them a Personal Access Token, which they used to grab LiteLLM’s PyPI publishing credentials, which let them push two poisoned versions directly to the public package registry. A security scanner was the entry point for a supply chain attack on an AI proxy that thousands of companies depend on — Trivy, the tool that was supposed to catch exactly this kind of thing, became the vector for it.

Version 1.82.8 was particularly nasty because it installed a .pth file that Python processes automatically on startup, meaning the malicious code would execute every time Python ran on the infected system, whether or not LiteLLM was actually being used. The three-stage payload did credential harvesting, Kubernetes lateral movement, and then set up a persistent backdoor for remote code execution.

Mercor, the AI recruiting startup valued at $10 billion after a Felicis-led Series C, confirmed they were hit. Lapsus$ subsequently claimed to have exfiltrated 4 terabytes of their data, including 939GB of source code, a 211GB user database, and 3TB of storage buckets containing video interviews and identity verification passports. Mercor called themselves “one of thousands of companies” affected and said they “moved promptly” to contain it, which is the corporate equivalent of saying the fire department arrived after the house burned down.

Every middleman is an attack surface

I keep coming back to the architecture of this whole thing. LiteLLM exists because managing API keys for OpenAI, Anthropic, Google, and whatever else through a unified proxy is genuinely convenient. But that convenience means funneling all your credentials and all your LLM traffic through a single open-source dependency that, as we just learned, can be silently backdoored through its own security tooling.

And this is not an edge case or a theoretical risk someone raised at a conference. This happened. At scale. The package gets 3.4 million downloads per day according to Snyk.

The pattern repeats across the AI stack: tools that promise to simplify your LLM integrations by sitting between you and the provider become aggregation points for credentials, traffic, and data. They become exactly the kind of high-value target that attracts groups like TeamPCP and Lapsus$. The more companies that depend on a single proxy, the more devastating a single compromise becomes, which is sort of the textbook definition of a supply chain risk that everyone saw coming and nobody did anything about.

BYOK skips the proxy entirely

So what does an architecture look like where this attack simply doesn’t apply? One where there is no proxy to compromise in the first place.

Dassi runs in your browser’s side panel and sends API calls directly from your machine to the LLM provider you choose, using your own API key. There’s no intermediate server, no shared proxy, no PyPI package aggregating thousands of companies’ credentials into one juicy target. The connection is between your browser and, say, OpenAI’s API endpoint, and nothing sits in the middle to be poisoned.

This is not a hypothetical security advantage anymore. After last week, it is the difference between “we were one of thousands of companies affected” and “that attack had literally no path to reach us.” BYOK means your API key lives in your browser’s local storage, not in some server’s environment variables waiting to be harvested by a supply chain attack.

The uncomfortable math

LiteLLM has paused all new releases while they conduct a supply chain review, which is the right call. But the deeper issue is structural. Any proxy layer you adopt because it saves you twenty minutes of API integration work also becomes a single point of failure for your credentials, your data, and your entire LLM infrastructure. And the people maintaining these projects — often small teams, sometimes just a handful of developers — are defending against nation-state-adjacent threat actors running coordinated, multi-stage campaigns across the open-source ecosystem.

Datadog’s security research team traced TeamPCP’s broader campaign from the Trivy compromise through CanisterWorm on npm to Checkmarx KICS. This was not a one-off. This was a systematic sweep through the tools that cloud-native AI stacks depend on, looking for whichever link in the chain had a misconfigured CI workflow or an exposed publishing token.

The fix is not better auditing of proxy dependencies, though that would help. The fix is not needing the proxy at all. Your browser already has an authenticated session with every service you use. A browser agent that operates within that session and calls LLM APIs directly from your machine does not introduce a new aggregation point into your infrastructure. There is nothing to poison because there is nothing in between.

LiteLLM will recover. They will harden their CI/CD pipeline, rotate all the credentials, and ship a clean version. But the next proxy — or the next dependency of the next proxy — will have its own misconfigured workflow or its own exposed token. And when that one gets popped, every company routing traffic through it will be writing the same incident response blog post Mercor just wrote. I’d rather not be on that list.