Two stories, six weeks apart, about the same piece of infrastructure.
On April 9, 2026, a team from UC Santa Barbara published a measurement study most teams evaluating an LLM router have never seen. They bought 28 paid LLM API routers from Taobao, Xianyu, and Shopify storefronts, pulled 400 more free ones from GitHub and public developer communities, and ran all 428 through live and decoy traffic. Nine of them actively rewrote payloads in transit, one swapping a legitimate package-installer URL for an attacker-controlled script mid-request. Seventeen reached into a planted AWS credential the moment it crossed their proxy. One drained a researcher's Ethereum wallet from a private key that was never supposed to leave the request. Source: Liu, Shou, Wen, Chen, Fang, and Feng, "Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain," arXiv:2604.08407, April 9, 2026
Six weeks earlier, on March 24, 2026, someone using the handle "TeamPCP" compromised the Trivy security scanner wired into LiteLLM's own CI/CD pipeline, used it to exfiltrate the project's PyPI publishing tokens, and pushed two backdoored releases, versions 1.82.7 and 1.82.8, straight into a package that pulls roughly 95 million downloads a month. The backdoor ran in three stages: harvest every AI provider key and cloud credential it could find, attempt lateral movement inside any reachable Kubernetes cluster, and install a persistent systemd service for command-and-control. Security researcher Callum McMahon flagged a crash at 11:48 AM caused by a fork-bomb side effect; the attacker tried to suppress the report by closing the GitHub issue at 12:44 PM; PyPI administrators quarantined the whole package at 1:38 PM. Roughly 40,000 downloads happened in the window before that. Source: Cycode, "Shedding The Lite: Unfolding The Dramatic Turn of Events With the LiteLLM Compromise," March 2026
These are not two unrelated security incidents. They're the same component of the stack, studied two different ways: an LLM router, the thing that sits between an application and a model provider deciding where each request goes, has to read every prompt, every tool call, and every provider API key in plaintext to do its job. That's not a bug in a specific router. It's the job description.
Why a router is the one thing in your stack that sees everything.
A router's entire function requires plaintext visibility: it reads the request to decide which model or provider handles it, and it reads provider credentials to make the call on your behalf. A reverse proxy in front of a web app can be zero-knowledge about the payload it forwards. An LLM router structurally cannot be, unless it's built specifically to avoid that. A March 2026 IETF-adjacent research note from the Cloud Security Alliance put it plainly: a compromised proxy in this position can simultaneously exfiltrate LLM provider keys, cloud credentials across AWS, GCP, and Azure, Kubernetes service tokens, SSH keys, git credentials, and cryptocurrency wallet files, because all of it routinely passes through the same plaintext channel on the way to a model call. Source: Cloud Security Alliance, "LLM Proxy Router Risk," Research Note, April 16, 2026
The UC Santa Barbara paper catalogs four distinct attack classes a malicious router can run once it has that visibility, and the poisoning experiment attached to it shows how fast the damage compounds once one goes live:
- Payload injection. Direct rewriting of tool-call parameters mid-flight, including swapping a legitimate package name for a typosquatted one (the paper's example: silently substituting
requestsforreqeusts) so a downstream agent installs something it never asked for. - Credential theft. Passive harvesting of API keys, tokens, and secrets from plaintext traffic with zero modification to what the application sees, which is what makes it the hardest of the four to notice: nothing about the app's behavior changes.
- Dependency injection. The same payload-rewriting idea aimed at package or tool-schema names specifically, so the compromise happens one dependency install away from the actual request.
- Conditional, delayed delivery. Malicious behavior gated behind a trigger, after 50 calls, only when the router detects an agent running in auto-approval mode, only for certain languages, so a security review that only samples the first handful of requests never sees it.
The researchers then ran a single leaked OpenAI key through their own decoy mesh to see how far one exposed credential travels. It generated 100 million GPT-5.4 tokens across seven Codex sessions before anyone acted on it. Twenty decoy routers logged more than 147,000 unauthorized access attempts. Across 440 downstream agent sessions touched by the leak, 99 distinct credentials were exposed, and 401 of those 440 sessions, 91%, were running with tool-call auto-approval turned on, meaning nothing in the loop was checking what the router handed back before the agent acted on it.
The defense that actually held up, and the one that's coming.
The same paper didn't just measure the attack surface, it tested three defenses against it. A fail-closed policy gateway blocked payload and dependency injection outright, at a 1% false-positive rate. Behavioral anomaly detection caught 89% of injection attempts, at a 6.7% false-positive cost. Append-only logging added forensic traceability at roughly 1.26KB per entry. All three help. None of them close the underlying gap, because all three still require the router to hand you accurate information about itself, and a sufficiently patient conditional trigger can wait out a detector tuned to catch fast, obvious tampering.
A companion paper published two months later goes after the structural fix instead of a better detector. "The Proxy Knows Too Much: Sealing LLM API Routers With Attested TEEs" proposes AEGIS, running the router inside a hardware-attested trusted execution environment so that even the operator of the routing service cannot read the plaintext passing through it, and reports that this blocks all four attack classes from the first paper, not by detecting them better, but by removing the plaintext visibility the attacks depend on. Source: "The Proxy Knows Too Much: Sealing LLM API Routers with Attested TEEs," arXiv:2606.16358, June 2026 That's the honest state of the field right now: detection is real and worth deploying, but the paper that actually closes the gap is a June 2026 research proposal, not a shipped product every router on the market has adopted.
What to actually check before you trust a router with your keys.
| Signal | What it tells you | Why it matters |
|---|---|---|
| Corporate identity, published security docs, disclosure process | Whether there's anyone accountable if something goes wrong | The UC Santa Barbara sample skewed toward anonymous marketplace sellers on Taobao, Xianyu, and gray-market Telegram channels, exactly the profile with nothing to lose from a bad actor operating it |
| Where the routing engine actually runs | Whether your prompts and provider keys leave your network boundary at all | A router that runs inside your own VPC against your own provider keys has no third-party plaintext path to compromise in the first place |
| CI/CD signing, SBOM, pinned dependency hashes | Whether a supply-chain compromise like TeamPCP's can reach you silently through an auto-upgrade | LiteLLM's compromise didn't require any user to do anything wrong; it moved through the project's own build pipeline into an ordinary version bump |
| Tool-call auto-approval defaults | Whether a compromised or tampered router response gets acted on without review | 91% of the poisoned sessions in the study had auto-approval on; it was the single largest amplifier of damage across the whole experiment |
| Whether the routing decision itself is auditable | Whether you can tell a legitimate model swap from an injected one after the fact | Append-only, tamper-evident logging caught issues the other two defenses missed, at a real but modest storage cost |
None of this is a reason to route every model call through hand-written, unaudited glue code instead. Direct SDK calls to a single provider dodge the multi-hop risk entirely but give up everything a router buys you: cost-aware model selection, failover when a provider has an outage, a single interface across a fleet of models. The fix isn't avoiding routers, most teams running more than one model genuinely need one, it's treating the choice of router with the same scrutiny you'd apply to picking an identity provider or a payments processor, because it now sits in a structurally equivalent position: the one component with plaintext access to your most sensitive traffic and your credentials for everything downstream of it.
What to ship this week.
- Check whether any coding agent or internal tool has ever pointed at a router you can't name the operator of. Marketplace and community-sourced routers were the entire population that produced malicious hits in the UC Santa Barbara sample; branded services with a published security process were not zero-risk, but they weren't where the 9-out-of-428 came from either.
- Turn off tool-call auto-approval, at least for anything that touches credentials, payments, or infrastructure. It was the single biggest amplifier in the poisoning experiment, turning one leaked key into 99 leaked credentials across 440 sessions instead of one contained incident.
- Pin your router and proxy library versions, and don't let CI auto-upgrade them without a review step. The LiteLLM compromise reached 40,000 downloads through the project's own build pipeline, not through any action a downstream user took.
pip install --require-hashesand a generated SBOM for your AI infrastructure turn a silent auto-upgrade into something a diff can catch. - Ask where the routing decision actually executes. If the answer is "inside a hosted service run by someone else," that's the same plaintext-in-the-middle position the research is describing, whether or not anything has gone wrong there yet. Nadir's routing engine self-hosts inside your own VPC, against your own provider keys and your own Postgres or Supabase instance; for a self-hosted deployment there is no managed routing service sitting between your traffic and the provider to compromise, and prompt storage can be turned off entirely so the logs hold a SHA-256 hash instead of the text. That's not a claim that self-hosting makes you immune to the next thing researchers find, it's the same structural fix the TEE paper is chasing: fewer parties in the plaintext path.
- If you're already running a verification step before a router's answer gets acted on, the same discipline that catches a cheap model's wrong answer catches a tampered one: a check that runs regardless of source is a check that doesn't care whether the bad output came from a weak model or an injected payload.
Conclusion.
Cost has been the framing for almost everything written about LLM routing this year, which model to escalate to, which cache to keep warm, which price cut actually reaches the bill. The UC Santa Barbara study and the LiteLLM compromise are a reminder that a router's cost function and its trust function are two separate problems, and the second one has gotten almost no attention because most of the routing conversation in 2026 has been about savings. Nine malicious routers out of 428 tested is a small percentage. Ninety-five million monthly downloads exposed to a supply-chain compromise for roughly ninety minutes is not a small number, and the mechanism that made both possible is identical: something in your stack has plaintext access to every prompt, tool call, and provider key you send it, and almost nobody asks who operates that thing or what happens if it's wrong before they wire it in.
Related reading.
- OpenRouter charges a base fee whether or not it saves you anything, and every request still passes through its hosted mesh. Here's the actual fee-model and architecture comparison against a self-hosted router.
- vLLM Semantic Router cuts tokens 48% and ships as open source. It also needs a platform team to run and secure it yourself.
- Anthropic cut its jailbreak-classifier overhead from 24% to 1% without weakening it, using the same verify-before-you-trust mechanism that catches a tampered router response.
- Provider prompt caches are keyed to a specific model and a byte-stable prefix. Here's what a router that doesn't respect that costs you, before any malicious intent enters the picture.
Sources: [Liu, Shou, Wen, Chen, Fang, and Feng, "Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain," arXiv:2604.08407, April 9, 2026](https://arxiv.org/abs/2604.08407). ["The Proxy Knows Too Much: Sealing LLM API Routers with Attested TEEs," arXiv:2606.16358, June 2026](https://arxiv.org/abs/2606.16358). [Cycode, "Shedding The Lite: Unfolding The Dramatic Turn of Events With the LiteLLM Compromise," March 2026](https://cycode.com/blog/lite-llm-supply-chain-attack/). [Cloud Security Alliance, "LLM Proxy Router Risk," Research Note, April 16, 2026](https://labs.cloudsecurityalliance.org/research/csa-research-note-llm-proxy-router-risk-20260416-csa-styled/).