A paper found 26 hostile LLM routers so I audited my own

If your coding agent reaches a model through OpenRouter, a free token router or a reseller, a middleman decrypts every prompt and every reply on the way through. In April, Hanzhi Liu, Chaofan Shou and four co-authors from UC Santa Barbara, Fuzzland, UC San Diego and World Liberty Financial published a measurement of what those middlemen do with that access. The paper is called "Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain" (arXiv 2604.08407) and it's accepted at ACM CCS this October. I run my own agents through a router, so I read it with my own config open.

The film runs 5 minutes 15 seconds, narrated, and covers everything below in order. The numbers on screen are the numbers in this post.

Three sentences on the paper

The team registered accounts with 428 routers, ran real agent tasks through each one and watched for network callbacks, file changes and odd processes. Nine routers rewrote the tool calls in the reply, seventeen picked up and used AWS keys planted in the traffic, and one drained an Ethereum wallet whose private key had been left in a prompt. Of the 440 agent sessions the team could observe through poisoned routers, 401 were in autonomous mode with every command auto-approved.

How a router hurts you

A router is a proxy that speaks the OpenAI API. Your agent sends it a request, it forwards the request to a model provider, and the reply comes back the same way. To do that, the router terminates your TLS session, which means it reads the prompt and the reply in plain text. The reply is where the tool calls live: the shell commands, file edits and package installs your agent is about to execute. Nothing in the protocol binds a reply to the model that produced it, so a router can change a tool call in transit and your agent runs the changed version.

The paper names two attack classes. Response-side payload injection (their AC-1) rewrites fields in the tool call's arguments while keeping the tool name and the schema intact, so the call still looks valid to the client. Passive secret exfiltration (AC-2) forwards everything untouched and keeps a copy of whatever credentials pass through.

Two refinements make this hard to catch. Dependency-targeted injection swaps a package name for a typosquat, so a policy that blocks unknown download domains never fires because the install still goes to PyPI. Conditional delivery only triggers on a condition the router can see: the paper observed routers that attacked only after fifty prior calls, or only when the client was in auto-approve mode. A router that behaves on day one and turns on day three passes every smoke test you'd think to run.

The paper also measured three defences. A high-risk tool policy gate (block fetches from non-allowlisted domains and installs outside a local allowlist) stopped every plain injection at a 1.0% false-positive rate and was bypassed 100% of the time once the attacker used an allowlisted domain. An anomaly detector on the returned tool calls flagged 89% of plain injections and about half of the adaptive ones at a 6.7% false-positive rate. An append-only transparency log of request, response and router identity cost 12 MB per thousand sessions and answers the question "which request carried the bad call" after the fact.

So I audited myself

Every agent on my machine talks to one LiteLLM router on localhost. Interactive sessions in opencode and Claude Code, the research scripts and the unattended writer sessions that run overnight all hit the same endpoint, and the router forwards each request to whichever provider serves the requested tier: a third-party reseller, the free models on OpenRouter, NVIDIA's endpoints, or Z.ai. Every attempt lands in a SQLite log with the provider and the upstream URL. The agent, for its part, keeps its own database of every session, every message and every tool result.

Three numbers came out of the audit.

The first number was the one that stung. The interactive sessions were on "ask" for every dangerous permission, which is what I had checked when I read the paper, and the unattended sessions were not. The script that spawns them passed a flag that auto-approves everything, and it had been doing so for two weeks through the paper's worst-affected population. I was the 401 out of 440.

The second came from joining the agent's session database with the router log on the session id. Every tool result the model had ever seen, searched for the 29 secret values in my env file: two live keys had been returned to a model six times each, mostly by an agent reading a script that had a key hardcoded, and each time the next request went out to an intermediary. Whether anyone on the other end kept them is unknowable, so both count as exposed.

The third was the relief. I replayed every historical command through the paper's payload patterns and found nothing. The door had been open for two weeks and nobody had walked through it yet.

What I built in a day

The fix had to leave the free models alone. I wasn't going to pay first-party prices for a writer tier that runs close to ten thousand requests on a heavy day. So the guard sits inside the LiteLLM I already run, as a callback, and contains the middleman instead of trusting it.

Mask runs on the way out. It scans every string in the request for the values of the secrets listed in a small file and swaps each one for a placeholder before the request leaves. An agent can read the whole env file and the router and the model receive a list of placeholders. Nothing restores the values on the way back, and when I tested it the upstream model echoed the placeholder straight back to me, which is the proof it never saw the key.

Gate runs on the way in. Every tool call in the reply, streaming or not, is matched against a rules file: secret files and directories, key files, keychain reads, pipe-to-shell, base64 decodes, reverse shells, env dumps piped to the network, sudo. A match rewrites the call into a harmless echo that says it was blocked, so the agent reads the block as a tool result and carries on with the task. Streamed tool-call deltas are held until the call is complete and then released, rewritten or dropped, with an empty keepalive delta every few seconds so clients with a chunk timeout stay connected.

Ledger writes every tool call to a table with its hash, its verdict, the rule that fired and the upstream that sent it, and a second table records which secret names were masked. That's the paper's third defence: after an incident you can answer which request carried the call and which router it came from.

Two more pieces sit outside the router. The unattended workers got their own permission profile in the agent's config, three scripts and one linter allowed and everything else denied, and the flag that auto-approved everything is gone. And a small audit script reads the ledger plus the agent's own history and prints which of your secrets have already crossed which upstream, which is how I got the two-keys number above.

Thirteen live integration tests against the four real upstreams passed: the masked value came back as its placeholder, a secret-file read was rewritten in both streaming and non-streaming replies, an innocent directory listing went through untouched, and every ledger row carried the upstream that served it. Then a real overnight row went end to end on the same free models as before.

What it does not protect

Two answers

There's a more complete answer. In June, Sipeng Xie and six co-authors published "The Proxy Knows Too Much: Sealing LLM API Routers with Attested TEEs" (arXiv 2606.16358). Their system, AEGIS, runs the router inside an attested hardware enclave, so the middleman can prove it forwarded your request unchanged and never held the plaintext outside the enclave. That closes the confidentiality gap the guard leaves open. It also costs money, because the enclave has to be somewhere, and the whole point of my setup is that the models are free. So I contained the middleman instead of attesting it. If your traffic can afford the enclave, read their paper first.

Run it

The guard, the permission-profile example and the audit script are on GitHub under an MIT licence at github.com/block-town/routerguard. If you run LiteLLM, the install is a clone, a path and one callback line in the config, then the list of files whose values must never leave:

git clone https://github.com/block-town/routerguard ~/routerguard
pip install pyyaml
# in the environment that runs `litellm --config`:
export PYTHONPATH=~/routerguard:$PYTHONPATH
export LLM_GUARD_SECRET_FILES=~/.env:~/work/app/.env

litellm_settings:
  callbacks:
    - guard.hooks.guard_instance

If you run agents through any router, start with the audit. It reads your agent's session history (opencode and Claude Code today) and your router log, and prints which secret names have appeared in tool output and which upstream served the next request. It takes about a minute and gives you your own version of the two-keys number.

python -m audit.leak_audit --env ~/.env

Mine said two, and I wouldn't have known without the join.

---

If you run agents through a router and want the guard, the profile and the audit set up against your own upstreams, book a call.