When you send a request to an LLM, you probably imagine a direct line: your application, the API, the model. The reality is often a multi-hop chain of intermediaries — API routers, aggregators, resellers — each terminating and re-originating TLS, each with full plaintext access to your API keys, system prompts, tool definitions, and every word the model returns. A research team at UC Santa Barbara and UC San Diego just published the first systematic study of what an attacker inside that chain can do. The answer is alarming. And the LiteLLM incident that occurred three weeks earlier proved that this attack surface is not theoretical.

The paper, “Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain,” formalises a threat model that most AI engineering teams have not seriously considered: the router-in-the-middle. Not an accidental network interception — a deliberately configured intermediary that your application sends every request to, that can read, modify, or fabricate any payload that passes through it, and against which there is currently no cryptographic defence at any layer of the major AI provider stack.

How the Routing Layer Became an Invisible Trust Boundary

Modern AI production deployments rarely use a single model provider directly. Organisations need access to GPT-5, Claude, Gemini, and a growing range of open-weight models, with model fallback, load balancing, cost optimisation, and a single credential plane. LLM API routers fill this role: they accept requests in a unified format — typically OpenAI-compatible — select an upstream provider, and return the response.

The dominant open-source router, LiteLLM, has approximately 40,000 GitHub stars and over 240 million Docker Hub pulls. OpenRouter connects users to more than 300 active models from over 60 providers and serves millions of developers. Beyond these platforms, a large commodity market has emerged around resold and aggregated API access — particularly in regions where direct provider access is restricted or expensive. Investigative reporting documents Taobao merchants with over 30,000 repeat purchases for LLM API keys.

The critical architectural fact, which the paper formalises for the first time, is this: routers are composable, and the client configures only the first hop. A developer may purchase API access from a Taobao reseller, who aggregates keys from a second-tier aggregator, who routes through OpenRouter, which dispatches to the model host. That is four hops, each with full plaintext access. The client has no visibility into intermediate hops. And because no end-to-end integrity mechanism exists anywhere in this chain, a single malicious or compromised router at any layer taints everything downstream — without any honest router being able to detect that a preceding hop has already rewritten a tool call or exfiltrated a credential.

Four Attack Classes — From Credential Theft to Code Execution

The researchers define a formal taxonomy of Adversarial Router Behaviours, grounded in the attacks they observed in the wild. Two core attack classes and two adaptive evasion variants.

428 Routers, 9 Injecting Malicious Code, 1 Draining a Crypto Wallet

The empirical measurement study is the paper’s most striking contribution. The researchers purchased 28 paid routers from Taobao, Xianyu, and Shopify-hosted storefronts, and collected 400 free routers built on the dominant open-source templates — sub2api and new-api, which together have accumulated over 2.4 million Docker pulls. They equipped each router with instrumented canary credentials: AWS keys, API tokens, and an Ethereum private key, designed to trigger observable external signals if accessed.

The finding that 17 free routers accessed researcher-owned AWS canary credentials is particularly significant. AWS canary credentials are honeypot keys specifically designed to trigger an alert on any access — they have no legitimate use, so any access is definitionally malicious. 17 out of 400 free routers — 4.25% — exfiltrated and used these credentials. One router went further and drained ETH from a researcher-owned Ethereum private key that transited the service.

The adaptive evasion findings are equally alarming. Two routers in the wild were observed deploying AC-1.b conditional delivery — specifically targeting sessions in YOLO mode and waiting until a warm-up period elapsed before activating. This means the malicious behaviour is specifically engineered to be invisible during any testing period that precedes production deployment. A security team that tests a router before onboarding it — and finds it clean — may still be deploying a router that will activate its payload 50 calls into production.

What Happened on March 24 2026 — and Why It Validates Every Finding

Three weeks before the paper’s publication, everything the researchers had formalised in theory was demonstrated at scale in production. On March 24 2026, threat actor group TeamPCP published versions 1.82.7 and 1.82.8 of LiteLLM to PyPI — having obtained the maintainer’s publishing credentials through a prior supply-chain compromise of Trivy, an open-source security scanner used in LiteLLM’s CI/CD pipeline.

The attack was multi-stage. Version 1.82.7 embedded a double base64-encoded payload in litellm/proxy/proxy_server.py. Version 1.82.8, published thirteen minutes later, escalated: it included a .pth file — a Python path configuration file that executes automatically on every Python interpreter startup, requiring no explicit import. Simply having the package installed meant every python, pytest, or pip install command in the environment triggered the payload. The malware harvested SSH private keys, AWS/GCP/Azure credentials, Kubernetes configs, API keys, and database passwords — then encrypted and exfiltrated them to an attacker-controlled domain.

The attack chain that produced the LiteLLM incident began on February 27 2026, when TeamPCP exploited a misconfigured pull_request_target GitHub Actions workflow in Aqua Security’s Trivy repository to exfiltrate a Personal Access Token. After credential rotation was imperfect, TeamPCP used still-valid credentials to force-push 76 of 77 release tags in the trivy-action repository to malicious commits. Any CI/CD pipeline using standard Trivy version tags — rather than immutable SHA hashes — was unknowingly executing credential-stealing code for weeks. LiteLLM was the downstream target. The paper’s authors note that this incident demonstrated “the router trust boundary is not hypothetical: a single supply-chain entry point in one widely deployed router was sufficient to compromise the entire forwarding path.”

Three Things You Can Deploy Today — Without Provider Cooperation

The researchers built a research proxy called Mine that implements all four attack classes against Claude Code, Codex, and two other public agent frameworks. They then used Mine to evaluate three client-side defences that can be deployed without changes to the model provider. The good news: two of the three perform strongly against the core attack classes.

The researchers are clear that these defences reduce exposure but do not solve the underlying problem. The fail-closed policy gate requires maintaining an allowlist of legitimate tool patterns — an operational burden that scales with application complexity and breaks when new tools are introduced. The anomaly screener has an 11% miss rate on the core AC-1 attack class, which is inadequate for high-stakes autonomous deployments. The transparency log is detective rather than preventive.

The ultimate solution — and the authors are explicit about this — is provider-backed response integrity: a cryptographic mechanism that binds the tool call an agent executes to what the upstream model actually produced, making any router-level tampering immediately detectable. No major AI provider currently implements this. It requires changes at the API layer that, to date, no provider has committed to shipping.