Most engineering teams put a router (LiteLLM, OpenRouter, or something similar) in front of their coding agent to manage API keys, control cost, and fail over between providers. It's a plumbing choice, made once and rarely revisited. But that plumbing sits between the agent and the model. It can see, and quietly change, everything passing through: the agent's instructions, its view of the codebase, every command it's about to run.
"In effect, third-party routing makes the user's device and execution environment transparent to the router, creating serious confidentiality, integrity, and device-security risks."
Researchers built a tool to test what happens when that router lies. They replayed real sessions from four widely used coding agents (Claude Code, Codex, Cursor, and OpenCode) with one of 400 fake malicious commands slipped in, disguised at levels running from an obvious swap to a rewrite so smooth it left no trace. None of the four agents caught a single one of the fake commands, at any level of disguise. The crude fakes worked just as well as the polished ones. The agents weren't fooled by camouflage; they simply never checked.
Every one of Claude Code's own safety settings failed too, including its "read-only" planning mode, which is meant to hold back any action before it happens. That mode enforces its rule by telling the model how to behave, not by inspecting what the router actually delivers. A tampered instruction slides past it untouched.
"Once a malicious action is injected via the API router, the agent processes it as a legitimate tool call and executes it regardless of the prompt-level constraints, resulting in a 0% defense rate."
Add-on defenses only partly helped. A simple allow-list of approved domains and packages caught roughly a third of the fake commands, while wrongly flagging a similar share of harmless work. A second AI model reviewing every command caught more, but its accuracy fell by roughly half once the fakes were dressed up as legitimate work. Even that number flatters the defense: the reviewer contacted the AI provider directly, skipping the router, a shortcut no real deployment gets. In one case, a routine bug-fix session ended with the agent piping a downloaded script into a shell a few steps in, and nothing caught it.
None of this makes coding agents untrustworthy. They executed what looked like a legitimate instruction from a model they trust. A router sits in a position of total trust that most teams never treat as a security decision. Whoever picks a router for cost or reliability is also choosing who can rewrite what runs on a developer's machine. That's reason to audit routing infrastructure the way any other privileged network position gets audited, not treat it as an interchangeable line behind an API key. It also means being skeptical of a vendor's claim that an AI reviewer closes this gap: here, the reviewer's own traffic passed through the same compromised router, erasing its value in a way no product page would show. The exact catch rates shouldn't be read as a scorecard for any router product. The tests covered a handful of coding tasks and hand-built fake attacks, not real-world routers.
"Our central claim is narrower: once a router can rewrite the agent's consumed response, meaningful control failures can emerge in realistic workflows."
What should generalize is the shape of the problem: once something between the agent and the model can rewrite the response, no permission setting downstream can be trusted to catch it.
Sources
- Fu, D., Li, J., Jiang, X. et al., "Where Is the Cost of Third-Party API Routers in Agentic Software Development?" — https://arxiv.org/abs/2607.23624