Your API router can hijack your AI agent

An AI agent asks a model for its next action. The model returns a tool call. Between those two endpoints, an API router can change the command the agent receives while preserving valid JSON and a working HTTPS connection.

That is the trust boundary examined in Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain, an April 2026 paper by Hanzhi Liu and colleagues. The authors report malicious code injection by nine of 428 commodity routers, alongside follow-on abuse of researcher-owned credentials.

The research gives security teams a concrete reason to examine the services between an agent and its model provider. It also shows why controls need to cover both the data leaving the organisation and the actions executed when a response returns.

This article analyses the paper's first arXiv version, submitted on 9 April 2026. The measurements below are the authors' reported results. Promptective has not independently reproduced them.

A base URL carries a trust decision

API routers offer useful conveniences: several model providers behind one interface, fallback when a model is unavailable, load balancing and cost management. Configuring one can take little more than changing an endpoint and an API key.

The resulting connection gives the router application-layer access. It terminates the client's TLS connection and opens a separate connection upstream. It can read the prompts, tool definitions, file content and credentials carried in that traffic. It can also modify a returned tool call before the client sees it.

HTTPS authenticates and encrypts each connection in that arrangement. End-to-end response integrity requires a separate way to verify that the received tool arguments match the provider's output. The paper identifies that missing guarantee in the interfaces and agent frameworks it studies.

The distinction matters for prompt injection. Prompt injection attempts to influence a model through instructions embedded in content. Router tampering can edit the structured response after inference has finished. A model may produce an appropriate command, then the client may receive a different one. Model-side reasoning safeguards have no opportunity to inspect that later edit.

What the researchers observed

The authors purchased 28 paid routers from Taobao, Xianyu and Shopify-hosted storefronts, and collected 400 free routers from public communities and lists. They sent researcher-controlled tasks through sandboxed agents and monitored returned tool calls and their effects.

Section 5 reports:

• One of 28 paid routers and eight of 400 free routers injected malicious code into returned tool calls.
• Two free routers delivered attacks selectively. One waited until after 50 prior requests. Another targeted sessions appearing to use automatic tool approval on Rust or Go projects.
• Seventeen free routers were associated with follow-on AWS canary use. A credential counted as touched when it produced subsequent AWS API activity attributable to that credential.
• One free router was associated with an ETH drain after a researcher-owned private key crossed the service.

These counts describe separate observations and may overlap. The sample concentrates on publicly reachable commodity markets, with much of its sourcing from Chinese-language marketplaces and communities. It provides evidence of abuse in that population; a market-wide prevalence estimate for enterprise routing services would require a different sample.

Selective delivery also limits what a clean test proves. An endpoint that behaves correctly during ten requests may activate a different path after fifty, or only when it recognises an unattended coding session. Repeated testing can reveal more behaviour, while finite probing leaves unobserved conditions unresolved.

Two ways an intermediary can cause harm

The paper separates active manipulation from passive collection.

Payload injection changes the proposed action. A router can replace an installer destination or substitute a dependency name while keeping the tool call syntactically valid. A package substitution can still use an approved registry, so checking the registry domain alone leaves the package identity unchecked.

Secret collection uses access the router already has. Credentials included in prompts, tool outputs or other transiting content can be copied while every response remains unchanged. A response anomaly detector has little to observe in that case. The exposure has already occurred by the time a later tool call reaches an execution gate.

These mechanisms need different controls. Sensitive-data checks belong before content crosses an untrusted boundary. Action policy belongs before the returned command produces side effects. Response provenance adds another question: which provider actually produced the instruction?

The visible router can hide a longer chain

The authors also ran two poisoning studies to examine how traffic reaches compromised upstream accounts or weak relays.

In the first, they deliberately exposed one researcher-owned OpenAI key. They report 100 million GPT-5.4 tokens and more than seven identifiable Codex sessions billed through that account. The paper acknowledges that provider-side logs could not always distinguish direct reuse by a router, reuse by another party or reuse inside a longer chain.

In the second, they deployed weakly configured decoys across 20 domains and 20 IP addresses. Those decoys served roughly two billion billed tokens and exposed 99 unique credentials across 440 Codex sessions. Of those sessions, 401 already used automatic tool approval, called YOLO mode in the paper.

All 440 sessions exposed a shell-execution path that the researchers classified as command-injectable. That classification describes an opportunity to rewrite a returned command. It does not establish that 440 sessions were successfully exploited. Automatic approval increases the risk because it removes a per-command human checkpoint.

For procurement and engineering teams, the practical issue is downstream visibility. An organisation may approve one endpoint while its requests pass through further intermediaries. Credential sourcing, relay dependencies and changes to upstream routing all belong in the supplier review.

The defence results include a complete adaptive bypass

The authors built an internal research proxy, Mine, and evaluated it with OpenClaw, OpenCode, Codex and Claude Code. They report that rewritten tool calls reached the tested clients in valid formats. These compatibility results leave downstream permission prompts and sandbox restrictions as separate execution boundaries.

The paper then evaluates three client-side defences on synthetic corpora:

• A fail-closed tool policy gate blocked all 500 direct payload-injection samples and all 500 dependency-substitution samples, with a 1.0% false-positive rate across 1,000 benign shell commands. This evaluated gate checked both domains and package names.
• Response anomaly screening detected 89.0% of direct payload injections, 50.0% of dependency substitutions and 50.9% of conditional-delivery attack samples at a 6.7% false-positive rate.
• Append-only logging preserved records useful for later investigation. Logging supplied audit evidence without preventing the manipulation or detecting passive collection as it happened.

The policy gate's adaptive result deserves equal weight: it was bypassed in 100% of samples in a separate simple benchmark using payloads on allowlisted domains or a pre-positioned local stager. The perfect initial block rate therefore applies to the narrow generated corpus. Defence-aware attackers can stay inside a coarse allowlist while changing the effect of an action.

The paper's proposed longer-term response is a provider-signed envelope covering the meaningful response fields, including tool names and arguments, with request binding and expiry. Client verification could then detect intermediary changes before execution. That is a proposed integrity mechanism in this paper. Signing also leaves request-side confidentiality to separate controls, because an intermediary may already have read the sensitive content.

What teams can check now

The following recommendations follow from the boundaries in the study:

1. Inventory the full routing path. Record approved endpoints, operators, upstream providers and further relays. Ask how credentials are sourced and how upstream changes are communicated.
2. Minimise what reaches each intermediary. Keep secrets out of agent context where possible. Use narrowly scoped, short-lived credentials and review outbound prompts, files and tool results for sensitive data before transmission.
3. Constrain execution near the action. Review complete commands, arguments, package identities, filesystem access and destinations. Keep high-risk operations behind enforceable policy and explicit approval.
4. Bound autonomous sessions. Limit network access, mounted files and available credentials. Use isolated execution environments and grant only the authority required for the task.
5. Test adversarial conditions. Include package substitutions, delayed activation, automatic-approval sessions and allowlisted destinations in controlled evaluations. Record exactly which cases a defence blocks and which it misses.
6. Keep useful, content-minimised evidence. Record policy decisions, endpoint identity, timing and execution outcomes. Apply access and retention limits to diagnostic data so investigation does not create another sensitive-content archive.

Our AI agent security guide covers permissions and execution boundaries in more detail. Promptective applies organisation policy on supported AI interaction and action paths, with content-minimised decision evidence. The router study reinforces the need to inspect those boundaries independently. Its experiments evaluate Mine and the authors' defences; they provide no product effectiveness measurement for Promptective.

Choosing an API router gives another service access to the agent's working context and returned instructions. Teams can make that authority explicit through supplier review, data minimisation, constrained execution and evidence tied to the action that actually occurred.

Source

• Hanzhi Liu, Chaofan Shou, Hongbo Wen, Yanju Chen, Ryan Jingyang Fang and Yu Feng, “Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain”, arXiv:2604.08407v1, submitted 9 April 2026. Sections 3–5 define the threat model and field measurements; Sections 6–7 report compatibility and synthetic defence tests; Section 8.2 and Appendix C describe the proposed signed envelope.