AI × Crypto · Analysis
The $500,000 Isn't in the Paper
A study of 428 AI API routers found nine of them quietly rewriting what agents do — and one draining a wallet. The number going around this week isn't the study's, and the finding that should actually worry anyone building agent wallets is duller and much worse.
A research paper about malicious AI infrastructure has been moving through crypto media this week under some version of the headline "26 malicious LLM routers linked to crypto theft," usually attached to a $500,000 wallet drain. Both numbers are worth pausing on, because neither is a measured result in the paper being cited — and the paper's real findings are more alarming than the headline it is generating.
The work is "Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain," by Hanzhi Liu, Hongbo Wen and Yu Feng of UC Santa Barbara, Yanju Chen of UC San Diego, Chaofan Shou of Fuzzland, and Ryan Jingyang Fang of World Liberty Financial. It was posted to arXiv on April 9 and covered by CoinDesk four days later. It is, in other words, four months old. What changed this week is not the research; it is the recirculation.
What an LLM router is, and why it is a trust boundary
When a developer builds an AI agent, they can call OpenAI or Anthropic or Google directly, or they can go through a router — a third-party service that sits in the middle, takes one API key, and dispatches requests across multiple upstream providers. Routers are popular because they are cheaper, sometimes dramatically so, and because they simplify multi-model setups.
The structural problem is that a router terminates the TLS connection. It is not a dumb pipe. It is an application-layer proxy with full plaintext access to every request and every response — every prompt, every API key that passes through, and critically, every tool call the model produces. And as the authors put it, "no end-to-end integrity mechanism binds the provider's tool-calling output to the action the client finally observes."
Read that again with an agent wallet in mind. The model says "transfer 0.1 ETH to address A." The router can hand your agent "transfer 4 ETH to address B" instead, and there is no signature anywhere in the stack that would let the client notice.
The actual numbers
The researchers bought 28 paid routers from Taobao, Xianyu and Shopify-hosted storefronts, and collected 400 free ones from public developer communities — 428 in total. Their measured findings:
What 428 routers were doing
Nine routers — one paid, eight free — were actively injecting malicious code. Two deployed adaptive evasion, meaning they behaved themselves until conditions were right. Seventeen touched researcher-planted AWS canary credentials, which is how you prove exfiltration rather than assume it. And one drained ETH from a private key the researchers controlled and had deliberately exposed.
That last one is the "$500,000 wallet." It was a honeypot. Cointelegraph reports the experimental drain came to less than $50, with transaction details undisclosed. The half-million-dollar figure traces back to CoinDesk's April write-up, which attributed to the researchers a real-world incident in which a client's wallet was emptied — plausible, and separate from the controlled experiment. The "26" figure appears to come from co-author Chaofan Shou's public summary rather than the paper's measured count of nine. Neither number is invented. Both have been flattened, in the retelling, into results the study does not claim.
The four ways a router turns on you
The paper's taxonomy is the part practitioners should actually take away. AC-1 is response-side payload injection: the router rewrites a model-generated tool call after it leaves the provider but before it reaches the client. AC-1.a is dependency-targeted injection — swapping a package name in an install command for a typosquat, so requests becomes reqeusts and the domain-based allowlist never fires. AC-1.b is conditional delivery: stay clean for the first 50 requests, or only attack when the client is running in autonomous "YOLO mode," or only target certain project types. AC-2 is passive secret exfiltration — no modification at all, just quietly reading credentials out of traffic.
Two companion poisoning studies are, if anything, grimmer. A deliberately leaked OpenAI key was used to generate 100 million tokens and more than seven Codex sessions. Weakly configured decoys pulled in 2 billion billed tokens and 99 credentials across 440 Codex sessions — of which 401 were already running in autonomous mode.
Why this lands on crypto harder than on anyone else
Most industries running agents through a shady router lose credentials and cloud spend. Both are recoverable. Crypto is the one vertical where a rewritten tool call executes an irreversible transfer, and this desk has spent the last month covering products built precisely on that pattern — MetaMask's Agent Wallet, with its spending limits and allowed-protocol lists, and Binance's Agent OS, which pipes ChatGPT, Claude and Cursor straight to exchange rails.
Those guardrails are real and they help. But note what they constrain: they bound how much damage a tool call can do. They do not verify that the tool call is the one the model produced. A spending limit turns an unbounded loss into a bounded one — which is genuinely valuable and is not the same thing as integrity.
The researchers tested three client-side defenses. A fail-closed policy gate blocking shell commands that fetch from non-allowlisted domains caught 100% of AC-1 and AC-1.a at a 1.0% false-positive rate — but is bypassed by payloads that use allowlisted domains. Anomaly screening caught 89.0% of AC-1 samples and only half of the AC-1.a variants. Append-only transparency logging catches nothing in real time; it costs about 1.26 KB per entry and exists so you can reconstruct what happened afterward.
Their actual recommendation is upstream: provider-signed response envelopes, a canonical object carrying provider identity, model, content and tool calls, cryptographically bound. The authors note that to their knowledge, no major provider tool-use API — and not the current MCP specification — exposes a deployed response-signing mechanism for tool-call arguments today.
The Take
Two things are true and they pull in opposite directions. This research is important and under-covered on the merits: the trust boundary it identifies is real, unsigned, and sitting underneath a product category that is being shipped to retail right now. And this week's coverage is a small case study in how a careful paper becomes a bad headline — a honeypot wallet holding under $50 becomes a $500,000 theft, a measured nine becomes a quoted 26, and a four-month-old preprint becomes breaking news. You do not need the inflated version. "Nine of 428 routers were rewriting agents' tool calls, and nothing in the stack would let you detect it" is a serious enough sentence on its own. Practically: don't route agent traffic that touches keys through a discount proxy, keep private keys and seed phrases out of agent sessions entirely as the authors advise, and treat spending limits as a blast-radius control rather than a correctness guarantee. The signature that would make this problem go away does not exist yet, and until a provider ships it, every agent wallet is trusting its middleman completely.