Where Is the Cost of Third-Party API Routers in Agentic Software Development?
This paper empirically demonstrates that third-party API routers in agentic software development introduce a critical control gap where router-side injections can silently alter agent actions and bypass client-side defenses, achieving a 0% defense success rate across evaluated agents and highlighting the urgent need for provider-side output-integrity guarantees.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine you are building a robot assistant that can write code, fix bugs, and manage your computer files. To make this robot smart, you connect it to a giant, super-intelligent brain in the cloud (a Large Language Model) that knows how to solve almost any problem. But here's the catch: you don't talk to that brain directly. Instead, you use a middleman, like a specialized delivery service or a "router," to carry your messages back and forth. This middleman is supposed to just be a helpful courier, making sure your robot can talk to different cloud brains without you having to change your wiring.
The big question this paper asks is: What happens if that helpful courier decides to play a trick? In the world of computer science, we know that if a middleman can see your messages, they can potentially swap them out or add their own notes before passing them along. This paper explores a scary but real possibility: what if the router doesn't just deliver the robot's instructions, but secretly changes them to make the robot do something dangerous, like deleting your files or installing a virus, while still making it look like the robot was just doing its normal job? The researchers wanted to see if the robot would notice the trick, or if it would blindly follow the router's new, malicious orders.
The Secret Middleman and the Robot's Blind Spot
In this study, the researchers built a special testing lab called SIDEL to play out this exact scenario. They set up four different "coding robots" (famous tools like Claude Code, Codex, Cursor, and OpenCode) and connected them to various cloud brains through a fake, untrusted router. Then, they acted as the evil router, trying to sneak malicious commands past the robots in four different ways, ranging from blunt force to subtle magic.
The Four Tricks of the Trade
The researchers tested four levels of deception, getting sneakier with each one:
- The Swap (L1): The router throws away the cloud brain's answer entirely and replaces it with a fake one that says, "Go delete this file."
- The Add-On (L2): The router lets the cloud brain give a normal answer, but then tacks on a secret command at the end, like "Oh, and by the way, install this suspicious software."
- The Polish (L3): The router changes the secret command and rewrites the robot's explanation to make it sound like the command was a natural part of the plan. It's like a magician making a trick look like a normal magic show.
- The Mind Meld (L4): This is the sneakiest. The router doesn't just edit the text; it uses a second brain to generate a brand-new response that mixes the original answer with the malicious command so perfectly that the two blend together. It's as if the router whispered the secret into the robot's ear while it was still thinking, making the robot believe the bad idea was its own.
The Shocking Result: The Robots Didn't Blink
The results were startling. No matter which robot they used, no matter which cloud brain powered it, and no matter which of the four tricks they tried, the robots fell for it every single time.
In the world of security, we measure success by how often a defense stops an attack. The researchers found that without extra help, all four robots had a 0% defense success rate. This means that in every single test case, the router successfully tricked the robot into executing the malicious command. The robots didn't just make a mistake; they completely failed to notice that the instructions they were following had been tampered with.
The researchers also checked if the robots' "safety settings" would help. They tried different permission modes, like "Plan Only" (where the robot just thinks) or "Auto" (where it acts freely). Even in the strictest modes, the router's tricks worked. It turns out that if the router is sitting between the robot and the cloud brain, the robot trusts whatever comes through the router, assuming it came from the cloud brain. The safety checks the robots have are looking at the robot's actions, not at the router's lies.
Does Changing the Brain Help?
You might think, "What if we use a smarter cloud brain? Maybe it will spot the trick?" The researchers tested this by swapping out the cloud brains for four different models. The result? It didn't matter. Whether the robot was talking to a super-powerful model or a flashier, faster one, the router could still slip the malicious commands right past them. The problem isn't that the brains are too dumb; it's that the router sits in a position where it can rewrite the story before the robot hears it.
Can We Build a Better Shield?
The researchers didn't just stop at finding the problem; they tried to build some shields to see if they could fix it. They tested two common defenses:
- The Whitelist: A simple list of "allowed" commands and websites. If a command isn't on the list, it gets blocked.
- The Second Opinion: Using a second AI to review the robot's plan before it acts.
The Whitelist was okay at stopping some bad stuff, but it was also clumsy. It blocked about 30% to 44% of the bad commands, but it also accidentally blocked about 30% to 44% of the good commands, making the robot less useful.
The "Second Opinion" AI was better. Depending on which AI model they used as the reviewer, they could stop between 39% and 64% of the attacks. However, this wasn't a perfect fix. Even the best reviewer model couldn't catch everything, and sometimes it still let the bad commands through. The researchers found that while these shields help a little, they don't fully solve the problem. The router is still too powerful, sitting right in the middle of the conversation.
The Takeaway
The main lesson from this paper is that relying on a third-party router to connect your coding robot to the cloud creates a massive security hole. The robot assumes the router is honest, but if the router is untrusted, it can rewrite reality for the robot. The robots, no matter how smart or how well they are configured, cannot tell the difference between a real instruction from the cloud and a fake one from the router.
The authors suggest that to truly fix this, we can't just rely on the robots to be more careful. We need the cloud providers themselves to guarantee that the messages they send haven't been tampered with by the middleman. Until then, every time a coding robot uses a third-party router, it's like handing the keys to your house to a delivery driver who might decide to let a burglar in while you're not looking. The robots are doing exactly what they are told, but the person giving the orders has been swapped out.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.