Nine of 428 LLM API routers caught injecting malicious code into agent tool calls

A study published in April 2026 and summarized in a dev.to write-up tested 428 LLM API routers — intermediary services that accept requests in one format and forward them to many model providers — and found nine of them rewriting traffic in flight, injecting malicious code into the tool instructions that AI agents execute.

The intermediary you configured yourself

Routers are popular for convenience and price: one bill, access to models from many vendors. The catch is architectural. To forward a request, the router terminates the encrypted connection from the client and opens a fresh one to the provider. Because the client deliberately points its endpoint at the router, the intermediary sees everything in readable form — user prompts, API keys, the full list of tools the agent may call. Unlike traditional eavesdropping, which requires spoofing certificates or weakening encryption and can be detected, no deception is involved here: the router holds full application-level authority by design, and today's payloads carry operational meaning, not just data.

Typosquats and patient evasion

The clearest example from the research: an instruction to install a package named requests came back with the name changed to reqeusts, a look-alike an attacker had registered in advance. Domain checks pass because the trusted destination is untouched; only the package name differs. The hostile package then persists on the machine and is imported again in later sessions.

The sample combined 28 paid routers purchased from Chinese marketplaces and Shopify storefronts with 400 free ones gathered from public communities. One paid service and eight free ones injected code. Two of them evaded detection adaptively: one fired only after fifty requests, the other only in sessions where the user had switched on full-auto mode without confirmation prompts, so short tests look clean. Another seventeen routers touched test credentials the researchers had planted after those credentials passed through, and one siphoned money from a crypto private key left as bait. Early commentary by one of the researchers counted 26 malicious intermediaries; the dev.to article attributes the difference to a broader sample definition.

Routers do not need to be hostile to be dangerous

The team also measured how ordinary-looking infrastructure gets pulled into abuse. An OpenAI key known to belong to the researchers, left in Chinese forums and chat groups, was picked up and used to generate 100 million tokens across more than seven sessions. A deliberately sloppy test server spread over 20 domains and 20 IP addresses drew unauthorized access attempts from 147 IP addresses, carried roughly 2 billion tokens of traffic, exposed about 13 GB of visible data and leaked 99 credentials across 440 sessions. Every one of those 440 sessions permitted shell execution, and 401 already ran in automatic mode — a plain, unmodified injection would simply have worked.

Defenses and their price

Three client-side defenses were measured. A deny-by-default filter for high-risk commands blocked 100 percent of direct code injections, at the cost of wrongly blocking about 1 percent of legitimate installs. Response-side anomaly screening, relying only on locally visible signals such as risky command patterns, tool-name frequency and structural oddities, caught 89 percent of direct injections at a 6.7 percent false-positive rate — but only about half of package-name swaps. Append-only audit logging stops nothing, yet each entry costs roughly 1.26 KB, making it cheap enough to keep running everywhere, and it tells you after the fact how far a router or a credential traveled.

None of these verifies where an instruction came from. A router inside the allow-list that behaves unremarkably can still change what a command means. The researchers argue the gap closes only when model providers cryptographically sign their responses so clients can confirm an instruction reached them unmodified — a mechanism no provider currently offers. A comment quoted by dev.to frames the deadlock: a defense placed in the router means the suspect investigates itself, while a defense in the agent runtime cannot know what the provider actually sent.

The dev.to piece also flags limits worth keeping in mind: the numbers come from controlled experiments on specific marketplaces, so 428 routers describe one market, not an industry average; externally verifying what a router reads or alters is hard, which makes router selection a trust decision rather than a testable technical one; and self-hosted or private-cloud routers were out of scope, so neither safer nor riskier can be claimed for them. Some router providers have meanwhile started marketing added protection layers.

Why it matters

Agent deployments route through intermediaries because switching one costs a single line of configuration and a key swap — and that same ease is why so few teams audit what the router can see. The honeypot numbers show the blast radius of a modified instruction is close to total: every compromised session allowed shell execution and most ran with no human confirmation. Until providers sign model outputs, defenders can only pattern-match, and the strongest filter still misses half the quiet package-name swaps. For production agents the practical floor is unglamorous: log every request and response, deny risky commands by default, and treat the choice of router as a decision about who you trust with your keys and your agent's hands.