API router security holes

An artificial intelligence router is a middleman that takes your app’s request, picks a model provider, and forwards the answer back. The new problem is that this middleman can read and rewrite everything in plain text before your software sees it. (arxiv.org) That sounds abstract until you remember what modern agents do with model output. If an agent sees “run this shell command” or “use this private key,” it may obey automatically, which turns one altered response into code execution or theft. (arxiv.org) Researchers from the University of California, Santa Barbara, the University of California, San Diego, and Fuzzland tested 428 of these routers. Their sample included 28 paid routers bought from Taobao, Xianyu, and Shopify-hosted storefronts, plus 400 free routers collected from public communities. (arxiv.org) They found 9 routers that actively injected malicious code into responses. They also found 17 routers that touched researcher-owned Amazon Web Services canary credentials, which are fake secrets planted to catch theft. (arxiv.org) One router went further and drained Ether from a wallet controlled by the researchers. The paper says the theft used a researcher-owned private key, which is the secret string that gives whoever holds it control over the crypto wallet. (arxiv.org) The attacks were not limited to obvious scam services. The paper describes two adaptive tricks: one router changed behavior only for specific software dependencies, and another delivered malicious payloads only under certain conditions to avoid detection. (arxiv.org) The researchers also ran what they call poisoning studies. In those tests, leaked OpenAI keys and weakly configured decoy systems let routers process 2.1 billion tokens, exposing 99 credentials across 440 Codex sessions, including 401 sessions already running in autonomous “You Only Live Once” mode with direct execution power. (arxiv.org) That detail matters because many developers treat a router like a harmless traffic cop. The paper’s model is closer to a package-forwarding warehouse worker who can open every box, swap the contents, and reseal it before delivery. (arxiv.org) Today’s application programming interfaces from major model companies document how to send requests and receive responses, but the researchers say providers do not enforce cryptographic integrity between the client and the upstream model. In plain English, the client has no built-in way to prove that the answer really came back untouched from the model provider. (arxiv.org) (developers.openai.com) (platform.claude.com) The paper tested three client-side defenses: a fail-closed policy gate, response-side anomaly screening, and append-only transparency logging. Those can catch some bad behavior, but they do not remove the core trust problem if the proxy in the middle can still alter traffic. (arxiv.org) So the fix getting the most attention is signed responses from the upstream provider. If the model company cryptographically signs each response, a client could verify the signature the way a browser verifies a secure website certificate and reject anything a router tampered with on the way back. (arxiv.org)