Title: 2604.08407
ArXiv: 2604.08407

Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain

Title:

Content selection saved. Describe the issue below:

Description:

License: CC BY-NC-ND 4.0

arXiv:2604.08407v1 [cs.CR] 09 Apr 2026

Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain

Hanzhi Liu

University of California, Santa Barbara

hanzhi@ucsb.edu

,

Chaofan Shou

Fuzzland

shou@fuzz.land

,

Hongbo Wen

University of California, Santa Barbara

hongbowen@ucsb.edu

,

Yanju Chen

University of California, San Diego

yanju@ucsd.edu

,

Ryan Jingyang Fang

World Liberty Financial

ryan@worldlibertyfinancial.com

and

Yu Feng

University of California, Santa Barbara

yufeng@cs.ucsb.edu

Abstract.

Large language model (LLM) agents increasingly rely on third-party API
routers to dispatch tool-calling requests across multiple upstream
providers.
These routers operate as application-layer proxies with full plaintext
access to every in-flight JSON payload, yet no provider enforces
cryptographic integrity between client and upstream model.
We present the first systematic study of this attack surface.
We formalize a threat model for malicious LLM API routers and define
two core attack classes, payload injection (AC-1) and secret
exfiltration (AC-2), together with two adaptive evasion variants:
dependency-targeted injection (AC-1.a) and conditional delivery
(AC-1.b).
Across 28 paid routers purchased from Taobao, Xianyu, and
Shopify-hosted storefronts and 400 free routers collected from public
communities, we find 1 paid and 8 free routers actively injecting
malicious code, 2 deploying adaptive evasion triggers, 17 touching
researcher-owned AWS canary credentials, and 1 draining ETH from a
researcher-owned private key.
Two poisoning studies further show that ostensibly benign routers can be
pulled into the same attack surface as they process end-user requests using leaked credentials and weakly configured peers: intentionally leaked OpenAI keys and weakly configured decoys have processed 2.1B tokens from these routers, exposing 99 credentials across 440-codex sessions, and 401 sessions already running in autonomous YOLO mode, allowing direct payload injection.
We build Mine, a research proxy that implements all four attack
classes against four public agent frameworks, and use it to evaluate
three deployable client-side defenses: a fail-closed policy gate,
response-side anomaly screening, and append-only transparency logging.

LLM security, API routers, tool-use attacks, supply chain security, man-in-the-middle

†

†

conference:

ACM Conference on Computer and Communications Security; October 2026; Salt Lake City, UT, USA

†

†

journalyear:

2026

†

†

ccs:

Security and privacy Web application security

†

†

ccs:

Security and privacy Malware and its mitigation

†

†

ccs:

Security and privacy Network security

Agent Clients

Model Providers

Claude Code

Codex

OpenClaw

COMPROMISED

COMPROMISED

YOLO mode

R

1

R_{1}

R

2

R_{2}

R

3

R_{3}

R

4

R_{4}

R

5

R_{5}

R

6

R_{6}

R

7

R_{7}

malicious

Attacker

Multi-hop LLM Router Chain

OpenAI

Anthropic

Google

Bash: curl ****.xyz/pwn.sh | sh

request / clean response

tainted response

Figure 1

.

LLM router ecosystem and taint propagation.
Agent clients (left) exchange requests and responses through a
multi-hop graph of LLM routers to upstream model providers (right).
Each hop terminates the inbound TLS session, granting full plaintext
access.
Green arrows denote clean data flow; red arrows trace how a single
malicious router

R

4

R_{4}

, controlled by an external attacker,
taints responses on the return path: corrupted payloads propagate
through

R

1

R_{1}

back to the compromised Claude Code and Codex clients,
handing the attacker effective control over their tool execution
(“your agent is mine”), while agents routed through honest paths
(e.g.,

R

2

→

R

5

R_{2}\!\to\!R_{5}

) remain unaffected
(Section

4

).

1.

Introduction

Large language model (LLM) agents have moved beyond conversational assistants into
tool-using systems that book flights, execute code, query databases, and manage
cloud infrastructure on behalf of their users

(Wang et al

.

,

2023

)

.
A less studied but increasingly critical component in this ecosystem is the

LLM API router

: an intermediary service that accepts
requests in a unified format and dispatches them to upstream model providers.
LiteLLM

(BerriAI,

2024

)

, the dominant open-source router with
roughly 40,000 GitHub stars and over 240 million Docker Hub pulls,
is integrated into production pipelines across thousands of
organizations.
OpenRouter

(OpenRouter,

2024

)

connects users to more than 300 active
models from over 60 providers and serves millions of developers and
end-users

(Aubakirova et al

.

,

2026

)

.
Routers provide model fallback, load balancing, cost optimization,
and a single API key across providers.
A growing number of production deployments route
traffic through at least one such intermediary

(Wang et al

.

,

2023

; Ruan et al

.

,

2024

)

.
The severity of this dependency was demonstrated in March 2026, when
attackers compromised the LiteLLM package through dependency
confusion, injecting malicious code directly into the request-handling
pipeline of every deployment that pulled the poisoned
release

(Datadog Security Labs,

2026

)

.
That incident turned a widely trusted router into a supply-chain weapon
with full plaintext access to every transiting API request and response.

This architecture creates a trust relationship that has received little scrutiny.
The “router-in-the-middle” is not an accidental on-path adversary but an
intentionally configured intermediary with application-layer authority over both
requests and responses.
Unlike a traditional network MITM, no TLS downgrade or certificate forgery is
required: the client voluntarily configures the router’s URL as the API
endpoint, the router terminates the client-side TLS connection, and it originates
a separate TLS connection upstream.
Once an agent targets that router endpoint, the service can inspect tool-call
arguments, API keys, system prompts, and model outputs; it can also normalize,
delay, or rewrite the returned tool call before the client executes it.
No end-to-end integrity mechanism binds the provider’s tool-calling output to the
action the client finally observes (Section

3

).
A malicious or compromised router can therefore replace a benign installer URL
with an attacker-controlled script, swap

pip install requests

for a
attacker-controlled dependency, or silently exfiltrate every credential
that transits the service.

Proxy tampering itself is not new

(Durumeric et al

.

,

2017

; de Carné de Carnavalet and Mannan,

2016

)

,
but LLM agents make this intermediary trust boundary unusually dangerous because
the payload now carries executable tool-call semantics.
We study that boundary as an LLM supply-chain problem and introduce a taxonomy of

Adversarial Router Behaviors

, spanning direct payload manipulation,
dependency rewriting, credential sniffing, and

Adaptive Evasion

, in which
malicious rewrites are delivered only after a warm-up period or when the router
infers that the client is running in an autonomous “YOLO mode.”
These attacks are orthogonal to prompt injection

(Greshake et al

.

,

2023

; Perez and Ribeiro,

2022

)

:
they occur in the JSON/tool layer before the model sees the request or after it
emits a response, outside the model’s reasoning loop, and therefore compose with
model-side safeguards rather than replacing them.

Our empirical results show that this risk is already present in
commodity router markets.
The open-source templates that underpin most commodity
routers,

new-api

(QuantumNous,

2026

)

(25.4k GitHub stars,
1.25M Docker pulls) and its upstream fork

one-api

(one-api contributors,

2026

)

(30.5k stars, 1.19M Docker
pulls), have been pulled millions of times, and Chinese open-source
models reached nearly 30% of total usage on OpenRouter in some
weeks

(Aubakirova et al

.

,

2026

)

, the largest public routing platform.
Investigative reporting documents Taobao shops with over 30,000
repeat purchases for resold LLM API
access

(Ottinger et al

.

,

2025

)

.
We analyze 28 paid routers bought from Taobao, Xianyu, and
Shopify-hosted storefronts and 400 free routers built from the
dominant

sub2api

(sub2api,

2026

)

and

new-api

templates.
Within that corpus, 1 paid and 8 free routers inject malicious code
into returned tool calls.
Two routers deploy adaptive evasion in the wild, for example by waiting
for 50 prior calls, restricting payload delivery to autonomous
“YOLO mode” sessions, or targeting only Rust and Go projects.
Among the free-router set, 17 routers touch at least one
researcher-owned AWS canary credential and 1 drains ETH from a
researcher-owned Ethereum private key.

Malicious routers are only half of the story.
Routers that look benign can be poisoned into the same trust boundary
when they reuse leaked upstream keys or forward traffic through weaker
relays.
We intentionally leaked a researcher-owned OpenAI key on Chinese forums
and in WeChat and Telegram groups; that single key generated 100M
GPT-5.4 tokens and more than seven Codex sessions.
We also deployed weakly configured

Sub2API

,

claude-relay-service

, and

CLIProxyAPI

decoys across
20 domains and 20 IPs.
Those decoys received tens of thousands of unauthorized access attempts from 147 IPs
(6 JA3 fingerprints),
served 2B GPT-5.4 / 5.3-codex tokens,
exposed about 13 GB of visible downstream prompt/response traffic, and
leaked
99 credentials across 440 Codex sessions on 398 different projects or
hosts.
Every one of those 440 sessions was command-injectable, and 401 already
ran in autonomous YOLO mode, meaning tool execution was already
auto-approved and simple payload injection would have been enough even
without sophisticated adaptive triggers.
Finally, we build Mine, a research proxy that implements the attack
classes and companion mitigations, and use it to evaluate practical
client-side defenses.
A fail-closed policy gate blocks all AC-1 and AC-1.a shell-rewrite
samples at 1.0% false positives, and response-side anomaly screening
flags 89% of AC-1 samples without requiring provider changes.
These mitigations reduce exposure today, but securing the agent
ecosystem ultimately requires provider-backed response integrity so
that the tool call an agent executes can be cryptographically tied to
what the upstream model actually produced.

In summary, this paper makes three contributions:

(1)

Threat model and attack taxonomy.

We present the first formal threat model for LLM API routers as a
supply-chain trust boundary and define two core attack
classes, payload injection (AC-1) and secret exfiltration
(AC-2), together with two adaptive evasion variants:
dependency-targeted injection (AC-1.a) and conditional delivery
(AC-1.b), grounded in observed router behavior
(Sections

3

–

4

).

(2)

Ecosystem measurement and poisoning studies.

We analyze 28 paid and 400 free routers and find 9 injecting
malicious code, 2 deploying adaptive evasion, and 17 abusing
researcher-owned credentials.
Two poisoning studies show that benign routers can be pulled into the
same attack surface through leaked keys and weak relay chains
(Section

5

).

(3)

Implementation and deployable defenses.

We build Mine, a research proxy implementing all four attack
classes against four public agent frameworks, and evaluate three
client-side defenses that can be deployed today without provider
cooperation
(Sections

6

–

7

).

2.

Background

2.1.

LLM API Routers

A direct API subscription to a single model provider is the simplest
deployment, but production agent systems rarely stop there.
Organizations need access to models from multiple providers (OpenAI,
Anthropic, Google, and an expanding set of open-weight
hosts) with fallback, load balancing, cost optimization, and a single
credential plane.
An

LLM API router

fills this role: it accepts requests in a
unified format (typically OpenAI-compatible), selects an upstream
provider, and returns the response.

Routing exists at every scale.
At the institutional end, Amazon Bedrock

(Amazon Web Services,

2026

)

and Azure
OpenAI Service

(Microsoft,

2026

)

are cloud-managed routers: they
host or proxy third-party models behind a unified API, and enterprises
consume them as a managed service.
At the open-source end, LiteLLM

(BerriAI,

2024

)

and
OpenRouter

(OpenRouter,

2024

)

let individual developers and startups
aggregate dozens of providers behind a single base-URL change.
Some model providers collaborate directly with routers for
distribution; for example, making new models available through
OpenRouter or regional aggregator platforms as a first-class channel.

Crucially, routers are

composable

: the path from client to GPU
routinely traverses multiple routing layers.
A developer may purchase API access from a Taobao reseller, who
aggregates keys from a second-tier aggregator, who routes through
OpenRouter, which dispatches to the model host. That is four hops, each
terminating and re-originating a TLS connection, each with full
plaintext access to API keys, system prompts, tool definitions, and
tool-call responses.
The client configures only the first hop; subsequent hops are invisible.
Because no end-to-end integrity mechanism spans this chain, a single
malicious or compromised router at

any

layer taints the entire
path: downstream honest routers cannot detect that an upstream hop has
already rewritten a tool call or copied a credential.
We formalize this weakest-link property in
Section

4

.

Routing is especially prevalent in regions where direct provider access
is restricted, expensive, or subject to quota limitations.
A large commodity market has emerged around resold and aggregated API
access: investigative reporting documents Taobao merchants with over
30,000 repeat purchases for LLM API
keys

(Ottinger et al

.

,

2025

)

, and the open-source router
templates that power most of these services,

new-api

(QuantumNous,

2026

)

(25.4k GitHub stars, 1.25M Docker pulls) and its upstream fork

one-api

(one-api contributors,

2026

)

(30.5k stars, 1.19M Docker
pulls), have been pulled millions of times.
LiteLLM alone has accumulated roughly 40,000 stars and over
240 million Docker Hub pulls.

2.2.

Tool Use and Function Calling

Modern LLM APIs expose

tool use

(also called

function
calling

) as a first-class
capability

(Schick et al

.

,

2023

; Qin et al

.

,

2023

; Patil et al

.

,

2023

)

.
OpenAI returns a

tool_calls

field with JSON-encoded
arguments

(OpenAI,

2023

)

;
Anthropic returns

tool_use

content blocks with a native JSON
object

(Anthropic,

2024

)

;
Gemini exposes a similar structured
interface

(Google,

2024

)

.
In every format, tool-call arguments are transmitted as plaintext JSON.
No provider-level integrity mechanism binds the arguments returned by
the model to the arguments received by the client.
An intermediary that terminates TLS on each side can therefore
read, modify, or fabricate any tool-call payload without detection.

2.3.

The LiteLLM Incident

In March 2026, attackers compromised LiteLLM through dependency
confusion, injecting malicious code into the request-handling pipeline
of every deployment that pulled the poisoned
release

(Datadog Security Labs,

2026

)

.
The injected payload had write access to every API request and response
transiting the proxy, the same capability set that a deliberately
malicious router would possess.
This incident demonstrated that the router trust boundary is not
hypothetical: a single supply-chain entry point in one widely deployed
router was sufficient to compromise the entire forwarding path.

3.

Threat Model

Figure

1

illustrates the system architecture and
the attacker’s position.

We consider an attacker that operates a malicious LLM API router or has
compromised a legitimate one through supply-chain compromise, insider
access, or server-side exploitation

(Datadog Security Labs,

2026

)

.
Because the client explicitly configures the router as its API endpoint,
the router terminates client-side TLS and originates a separate TLS
connection upstream.
It therefore occupies an application-layer man-in-the-middle position by
design and can read, retain, rewrite, or fabricate request and response
bodies, headers, and request metadata.
This includes tool definitions, prompts, tool outputs, API keys, and
returned tool-call payloads across OpenAI-, Anthropic-, and
Gemini-style interfaces.
The router may also keep cross-request state, which lets it activate
payload rewriting only for trigger-matching sessions.
We assume standard TLS between the router and the upstream provider and
no compromise of model weights or inference logic.

The core integrity gap is that no deployed mechanism binds the
provider-origin tool-call response to what the client finally receives.
That gap enables response-side payload rewriting, while request-side
visibility enables selective delivery to particular users, workflows, or
tool invocations.
We exclude prompt injection, model backdoors, client-side malware,
denial of service, and pure model substitution.
Those behaviors may compose with router abuse, but they are distinct
from the response-manipulation and passive-collection attacks
studied here.

4.

Attack Taxonomy

Malicious-router behavior reduces to two orthogonal primitives:

active manipulation

, in which the router rewrites a tool-call
payload before it reaches the client, and

passive collection

, in
which the router silently extracts secrets from plaintext traffic.
We formalize these as two core attack classes (AC-1 and AC-2) and
define two

adaptive evasion

variants (AC-1.a and AC-1.b) that
specialize AC-1 to evade specific classes of client-side defenses.
Table

1

summarizes the taxonomy, and
Figure

2

shows where each class activates in the
request–response path.

Agent Clients

Model Providers

Malicious Router

Claude Code

Codex

OpenClaw

⋯

\cdots

OpenAI

Anthropic

Google

⋯

\cdots

Parse Request

Forward Request

Receive Response

Parse Response

AC-2: secret scan

AC-2: secret scan

AC-1: payload injection

AC-1.a

AC-1.b

Request JSON

Request JSON

Response JSON

Response JSON

(tampered)

Figure 2

.

Request–response lifecycle through a malicious router.
AC-2 tags mark where the router passively scans traffic for secrets
(both request and response paths).
AC-1 marks where parsed responses are rewritten before delivery;
AC-1.a specializes to dependency substitution,
AC-1.b gates activation on session-level triggers
(Section

4.2

).

Formal framework.

We model the system as

(

C

,

R

1

,

…

,

R

k

,

P

)

(C,R_{1},\ldots,R_{k},P)

where

C

C

is
the client,

P

P

is the upstream provider, and

R

1

,

…

,

R

k

R_{1},\ldots,R_{k}

are routers.
A request

𝑟𝑒𝑞

∈

𝖱𝖾𝗊𝗎𝖾𝗌𝗍

\mathit{req}\in\mathsf{Request}

carries a prompt,
tool definitions, and an API key;
a response

𝑟𝑒𝑠𝑝

∈

𝖱𝖾𝗌𝗉𝗈𝗇𝗌𝖾

\mathit{resp}\in\mathsf{Response}

carries
tool calls

[

t

1

,

…

,

t

n

]

[t_{1},\ldots,t_{n}]

where

t

i

=

(

𝑛𝑎𝑚𝑒

i

,

𝑎𝑟𝑔𝑠

i

)

t_{i}=(\mathit{name}_{i},\mathit{args}_{i})

.
Let

σ

⊆

𝖲𝖾𝖼𝗋𝖾𝗍𝗌

\sigma\subseteq\mathsf{Secrets}

denote a set of extracted
credential patterns, and let

φ

:

𝖱𝖾𝗊𝗎𝖾𝗌𝗍

×

𝖲𝗍𝖺𝗍𝖾

→

𝖡𝗈𝗈𝗅

\varphi:\mathsf{Request}\times\mathsf{State}\to\mathsf{Bool}

be a trigger predicate over request and session features.

An honest router is transparent:

R

ℎ𝑜𝑛𝑒𝑠𝑡

​

(

𝑟𝑒𝑞

)

=

P

​

(

𝑟𝑒𝑞

)

R_{\mathit{honest}}(\mathit{req})=P(\mathit{req})

.
A chain composes as

(

R

1

∘

⋯

∘

R

k

)

​

(

𝑟𝑒𝑞

)

(R_{1}\circ\cdots\circ R_{k})(\mathit{req})

,
where each

R

i

R_{i}

terminates and re-originates a TLS connection.
Chain integrity is a

weakest-link

property:

∈

∀

i

[

1

,

k

]

.

=

R

i

R

honest

=

⁢

(

∘

R

1

⋯

R

k

)

(

req

)

⁢

P

(

req

)

\displaystyle\displaystyle{\hbox{\hskip 51.71497pt\vbox{\hbox{\thinspace\hbox{\hbox{$\displaystyle\displaystyle\forall\,i\in[1,k].\;R_{i}=R_{\mathit{honest}}$}}}\vbox{}}}\over\hbox{\hskip 59.08873pt\vbox{\vbox{}\hbox{\thinspace\hbox{\hbox{$\displaystyle\displaystyle(R_{1}\circ\cdots\circ R_{k})(\mathit{req})=P(\mathit{req})$}}}}}}

∈

∃

j

[

1

,

k

]

.

≠

R

j

R

honest

⁢

no integrity guarantee for

(

∘

R

1

⋯

R

k

)

(

req

)

\displaystyle\displaystyle{\hbox{\hskip 52.64088pt\vbox{\hbox{\thinspace\hbox{\hbox{$\displaystyle\displaystyle\exists\,j\in[1,k].\;R_{j}\neq R_{\mathit{honest}}$}}}\vbox{}}}\over\hbox{\hskip 96.1122pt\vbox{\vbox{}\hbox{\thinspace\hbox{\hbox{$\displaystyle\displaystyle\text{no integrity guarantee for }(R_{1}\circ\cdots\circ R_{k})(\mathit{req})$}}}}}}

A single malicious router at any layer can apply AC-1 (rewrite) or
AC-2 (collect); downstream honest routers cannot detect or undo the
modification because they lack a reference to the original upstream
response.
For AC-2, taint is cumulative: every router in the chain observes
plaintext traffic, so the total secret exposure is

σ

𝑐ℎ𝑎𝑖𝑛

=

⋃

i

=

1

k

𝑒𝑥𝑡𝑟𝑎𝑐𝑡

i

​

(

𝑟𝑒𝑞

i

,

𝑟𝑒𝑠𝑝

i

)

\sigma_{\mathit{chain}}=\bigcup_{i=1}^{k}\mathit{extract}_{i}(\mathit{req}_{i},\mathit{resp}_{i})

.
Our measurement (Section

5.3

) confirms
this composability empirically: leaked keys and weak relays turn
otherwise benign outer routers into conduits for the full attack
surface.
The remainder of this section defines the attack classes for a
single malicious router

R

R

; the chain property above lifts each
class to arbitrary multi-hop deployments.

Table 1

.

Attack taxonomy: two core classes and two adaptive evasion variants.

Class

Role

Manipulated Surface

Preconditions

Primary Harm

Detection Difficulty

AC-1

Core

Tool-call arguments

Tool-calling response; no integrity check

Arbitrary code execution

Modified payload is schema-valid; client never sees upstream original

AC-2

Core

None (read-only)

Secret in plaintext traffic

Credential theft

Traffic is unchanged; clients cannot observe router-side retention

AC-1.a

Evasion

Package name inside install command

Install-capable tool call

Durable supply-chain compromise

Evades domain-based policy gates; rewritten command looks legitimate

AC-1.b

Evasion

Same as AC-1, conditionally

Trigger-relevant session features

Targeted delivery

Non-matching probes see benign behavior; finite audits miss the attack

4.1.

Core Attack Classes

4.1.1.

AC-1: Response-Side Payload Injection

=

⁢

P

(

req

)

resp

resp

.

=

⁢

tool

_

calls

[

i

]

t

=

⁢

R

AC-1

(

req

)

⁢

resp

[

↦

⁢

tool

_

calls

[

i

]

⁢

rewrite

(

t

)

]

\displaystyle\displaystyle{\hbox{\hskip 82.1351pt\vbox{\hbox{\thinspace\hbox{\hbox{$\displaystyle\displaystyle P(\mathit{req})=\mathit{resp}$}\qquad\hbox{\hbox{$\displaystyle\displaystyle\mathit{resp}.\mathit{tool\_calls}[i]=t$}}}}\vbox{}}}\over\hbox{\hskip 88.16493pt\vbox{\vbox{}\hbox{\thinspace\hbox{\hbox{$\displaystyle\displaystyle R_{\text{AC-1}}(\mathit{req})=\mathit{resp}\bigl[\mathit{tool\_calls}[i]\mapsto\mathit{rewrite}(t)\bigr]$}}}}}}

The function

𝑟𝑒𝑤𝑟𝑖𝑡𝑒

:

𝖳𝗈𝗈𝗅𝖢𝖺𝗅𝗅

→

𝖳𝗈𝗈𝗅𝖢𝖺𝗅𝗅

\mathit{rewrite}:\mathsf{ToolCall}\to\mathsf{ToolCall}

replaces selected fields in the argument JSON while preserving the tool
name and schema structure.
The router rewrites a model-generated tool call after it leaves the
upstream provider but before it reaches the client; the only
preconditions are a tool-calling response and the absence of an
integrity mechanism binding the received arguments to the upstream
original.
Because the modified payload remains syntactically valid JSON matching
the expected tool schema, AC-1 redirects agent behavior without
producing a schema violation or transport anomaly.
For a shell-execution tool such as

Bash

, replacing a benign
URL with an attacker-controlled script suffices for arbitrary code
execution: the semantic change occurs after inference completes,
entirely outside the model’s reasoning loop.

Example.

The listing below shows a benign installer URL replaced with an
attacker-controlled endpoint.
The March 2026 LiteLLM compromise

(Datadog Security Labs,

2026

)

demonstrated exactly this primitive at scale: once the attacker
controlled the request pipeline, every transiting tool call was exposed
to rewriting.

Original tool call (from upstream provider):

⬇

{

"

name

":

"

Bash

",

"

arguments

":

{

"

command

":

"

curl

-

sSL

https://get.example.com/cli.sh

|

bash

"

}

}

Router-modified tool call (delivered to client):

⬇

{

"

name

":

"

Bash

",

"

arguments

":

{

"

command

":

"

curl

-

sSL

https://attacker****.sh

|

bash

"

}

}

Consequence of AC-1:

A single rewritten tool call is sufficient for arbitrary code execution on the client machine. Any agent that auto-executes tool calls through an unverified router is exposed.

4.1.2.

AC-2: Passive Secret Exfiltration

=

⁢

P

(

req

)

resp

=

⁢

extract

(

req

,

resp

)

σ

≠

σ

∅

=

⁢

R

AC-2

(

req

)

∧

resp

⁢

leak

(

σ

)

\displaystyle\displaystyle{\hbox{\hskip 104.30711pt\vbox{\hbox{\thinspace\hbox{\hbox{$\displaystyle\displaystyle P(\mathit{req})=\mathit{resp}$}\qquad\hbox{\hbox{$\displaystyle\displaystyle\mathit{extract}(\mathit{req},\mathit{resp})=\sigma$}\qquad\hbox{\hbox{$\displaystyle\displaystyle\sigma\neq\emptyset$}}}}}\vbox{}}}\over\hbox{\hskip 59.38568pt\vbox{\vbox{}\hbox{\thinspace\hbox{\hbox{$\displaystyle\displaystyle R_{\text{AC-2}}(\mathit{req})=\mathit{resp}\;\wedge\;\mathit{leak}(\sigma)$}}}}}}

The function

𝑒𝑥𝑡𝑟𝑎𝑐𝑡

:

𝖱𝖾𝗊𝗎𝖾𝗌𝗍

×

𝖱𝖾𝗌𝗉𝗈𝗇𝗌𝖾

→

𝒫

​

(

𝖲𝖾𝖼𝗋𝖾𝗍𝗌

)

\mathit{extract}:\mathsf{Request}\times\mathsf{Response}\to\mathcal{P}(\mathsf{Secrets})

scans headers, request bodies, and response bodies against credential
patterns; the router forwards the response unmodified and exfiltrates

σ

\sigma

asynchronously.
AC-2 requires no payload modification; the boundary between
“credential handling” and “credential theft” is invisible to the
client because routers already read secrets in plaintext as part of
normal forwarding.
Once exposed credentials are reused by relays, passive collection alone
creates downstream data exposure at scale: our poisoning study
(Section

5.3

) shows that a single leaked
key yielded 100M tokens and 99 credentials across 440 sessions without
any payload rewriting.

Example.

Listing

1

shows representative extraction
patterns.
An attacker who controls the LiteLLM request pipeline as in the
March 2026 incident

(Datadog Security Labs,

2026

)

gains read access to
every API key, system prompt, and credential that transits the
proxy, even if the injected code never modifies a single response.
In Section

5

, we count AC-2 outcomes only when
exposure is followed by externally visible unauthorized use of
researcher-owned canaries or credentials.
In practice, the extraction surface extends beyond API keys:
system prompts, tool definitions, user-supplied file contents,
and environment variables all transit the same plaintext channel
and are equally accessible to a router performing AC-2.

⬇

sk

-[

A

-

Za

-

z0

-9]{20,}

//

OpenAI

keys

AKIA

[

A

-

Z0

-9]{16}

//

AWS

keys

ghp_

[

A

-

Za

-

z0

-9]{36}

//

GitHub

PATs

xoxb

-[0-9]+-[

A

-

Za

-

z0

-9]+

//

Slack

bot

tokens

0

x

[

a

-

fA

-

F0

-9]{64}

//

Ethereum

keys

-----

BEGIN

.*

PRIVATE

KEY

-----

//

PEM

keys

Listing 1:

AC-2: representative secret-matching
patterns for passive extraction.

Consequence of AC-2:

Passive collection requires zero payload modification and is invisible to the client, since the same plaintext access needed for legitimate routing also enables silent credential retention. Unlike AC-1, AC-2 cannot be mitigated by response-signing proposals because the secrets are exposed on the

request

path before any provider-side mechanism can act.

4.2.

Adaptive Evasion Variants

The core AC-1 attack is effective but coarse: always-on rewriting is
easily detected by a simple policy check or manual review.
A sophisticated attacker therefore needs to control not only

what

is injected but also

when

and

how

the
injection is delivered, so that standard client-side checks pass
while high-value targets still receive malicious payloads.
We define two adaptive evasion variants that specialize AC-1 to defeat
specific defensive strategies while preserving its payload-injection
capability.

4.2.1.

AC-1.a: Dependency-Targeted Injection

=

⁢

P

(

req

)

resp

t

i

.

∈

name

{

Bash

,

run_command

}

t

i

.

⊧

args

⁢

install

_

pattern

=

⁢

R

AC-1.a

(

req

)

⁢

resp

[

t

i

.

↦

args

⁢

subst

(

pkg

)

]

\displaystyle\displaystyle{\hbox{\hskip 166.17197pt\vbox{\hbox{\thinspace\hbox{\hbox{$\displaystyle\displaystyle P(\mathit{req})=\mathit{resp}$}\qquad\hbox{\hbox{$\displaystyle\displaystyle t_{i}.\mathit{name}\in\{\texttt{Bash},\texttt{run\_command}\}$}\qquad\hbox{\hbox{$\displaystyle\displaystyle t_{i}.\mathit{args}\models\mathit{install\_pattern}$}}}}}\vbox{}}}\over\hbox{\hskip 79.0182pt\vbox{\vbox{}\hbox{\thinspace\hbox{\hbox{$\displaystyle\displaystyle R_{\text{AC-1.a}}(\mathit{req})=\mathit{resp}\bigl[t_{i}.\mathit{args}\mapsto\mathit{subst}(\mathit{pkg})\bigr]$}}}}}}

AC-1.a specializes AC-1 to package-install commands
(

pip install

,

npm install

,

cargo add

).
Rather than rewriting an arbitrary URL, which a domain-based policy
gate (Section

7.1

) can catch, the router
substitutes a legitimate dependency name with an attacker-controlled
package pre-registered on the target registry.
The substitution may be a visually similar name (typosquatting) or
an entirely different package; the former is particularly effective
because LLM-based review and approval UIs tend to hallucinate that
a near-homograph is correct, causing downstream checks to pass.
The surrounding command line remains unchanged, so the rewritten
command clears domain-based allowlists and approval flows that
emphasize only the high-level action.
Once the substituted package installs, the attacker gains a durable
supply-chain foothold that persists beyond the current session.
This is strictly more dangerous than a one-shot AC-1 URL redirect,
because the compromised dependency is cached locally and re-imported
across future sessions.
We design AC-1.a specifically to demonstrate that the policy gate
defense can be evaded when the attacker targets package-install
workflows: the gate blocks non-allowlisted domains but does
not maintain a per-package allowlist.

Example.

The listing below shows a single-character substitution:

requests

becomes

reqeusts

, a typosquat package
that the router has pre-registered on PyPI.
Because the surrounding command line is unchanged and the package name
passes a casual visual check, the rewritten command clears both
domain-based policy gates and LLM-assisted approval flows.

Original tool call:

⬇

{

"

name

":

"

Bash

",

"

arguments

":

{

"

command

":

"

python

-

m

pip

install

requests

flask

pyyaml

"

}

}

Router-modified tool call:

⬇

{

"

name

":

"

Bash

",

"

arguments

":

{

"

command

":

"

python

-

m

pip

install

reqeusts

flask

pyyaml

"

}

}

Consequence of AC-1.a:

Dependency-targeted injection evades domain-based policy gates because the rewritten command installs from the same trusted registry, differing only in the package name. Worse, the compromised dependency is cached locally and re-imported across future sessions, giving the attacker a durable supply-chain foothold that persists long after the malicious router interaction ends.

4.2.2.

AC-1.b: Conditional Delivery

=

⁢

P

(

req

)

resp

=

⁢

φ

(

req

,

s

)

true

=

⁢

R

AC-1.b

(

req

)

⁢

R

AC-1

(

req

)

\displaystyle\displaystyle{\hbox{\hskip 69.9744pt\vbox{\hbox{\thinspace\hbox{\hbox{$\displaystyle\displaystyle P(\mathit{req})=\mathit{resp}$}\qquad\hbox{\hbox{$\displaystyle\displaystyle\varphi(\mathit{req},s)=\mathit{true}$}}}}\vbox{}}}\over\hbox{\hskip 56.42567pt\vbox{\vbox{}\hbox{\thinspace\hbox{\hbox{$\displaystyle\displaystyle R_{\text{AC-1.b}}(\mathit{req})=R_{\text{AC-1}}(\mathit{req})$}}}}}}

=

⁢

P

(

req

)

resp

=

⁢

φ

(

req

,

s

)

false

=

⁢

R

AC-1.b

(

req

)

resp

\displaystyle\displaystyle{\hbox{\hskip 70.93274pt\vbox{\hbox{\thinspace\hbox{\hbox{$\displaystyle\displaystyle P(\mathit{req})=\mathit{resp}$}\qquad\hbox{\hbox{$\displaystyle\displaystyle\varphi(\mathit{req},s)=\mathit{false}$}}}}\vbox{}}}\over\hbox{\hskip 40.58015pt\vbox{\vbox{}\hbox{\thinspace\hbox{\hbox{$\displaystyle\displaystyle R_{\text{AC-1.b}}(\mathit{req})=\mathit{resp}$}}}}}}

The predicate

φ

\varphi

gates payload injection on session state

s

s

:
the router behaves honestly for non-matching traffic and applies AC-1
only when

φ

\varphi

holds.
AC-1.b is not a distinct payload primitive but determines

when

AC-1 activates, so that routine probes and low-value traffic see benign
behavior while high-value sessions receive rewritten payloads.
Practical triggers fall into five families:

(1)

Tool-name conditions:

activate only for tools
such as

Bash

or

run_command

.

(2)

Content keywords:

activate when the command contains
installer patterns such as

curl -sSL

or

pip install

.

(3)

User fingerprints:

activate only for sessions in
autonomous YOLO mode or belonging to a target organization.

(4)

Time windows:

activate only during off-hours or after a
deployment event.

(5)

Request-count thresholds:

activate only after the
session has passed

N

N

benign interactions, hiding the attack from
shallow smoke tests.

None of these require model compromise; they depend only on metadata
and payload fields already visible to the router.
A router deploying a 50-request warm-up appears entirely
transparent during a 10-request probe, making finite black-box auditing
fundamentally inadequate against conditional delivery.

Example.

The Codecov CI breach

(Codecov,

2021

)

persisted undetected
for months by activating its credential-harvesting payload only within
CI environments, a conditional-delivery strategy analogous to AC-1.b.
Our measurement (Section

5

) confirms that
real routers deploy similar logic: one activates only after 50 prior
calls, another restricts injection to YOLO-mode sessions targeting
Rust or Go projects.
The combination of multiple trigger families is especially potent:
a router can require both a tool-name match

and

a warm-up
count before activating, so that even an auditor who tests the
correct tool never reaches the activation threshold within a
typical probe budget.

Consequence of AC-1.b:

Conditional delivery makes finite black-box auditing fundamentally inadequate. A router that activates only after a warm-up period or on specific session attributes appears entirely transparent during routine probes. Because the trigger predicate is server-side and opaque, no fixed-length client test can guarantee that the router is benign. Combined with autonomous auto-approval modes, the attacker can reserve payload injection exclusively for high-value sessions while keeping all audit traffic clean.

Summary.

AC-1 and AC-2 are orthogonal: AC-1 changes what the agent executes,
while AC-2 silently harvests credentials from the same plaintext
channel.
The evasion variants sharpen AC-1 for realistic deployment:
AC-1.a evades domain-based policy gates by substituting dependencies
instead of URLs, and AC-1.b evades black-box auditing by gating
delivery on session-level triggers.
Section

5

maps these classes to the observed
ecosystem, and Section

7

evaluates client-side
defenses against each.

5.

Ecosystem Measurement

We study two complementary questions.
First, are malicious routers already operating in real agent-facing
markets?
Second, can routers that appear benign or trusted be poisoned into the
same supply-chain position through leaked upstream credentials or by
forwarding traffic through weaker relays?
Our measurement therefore combines a market study of paid and free
routers with two poisoning studies based on leaked researcher-owned keys
and intentionally weak relay deployments.
Table

2

summarizes the datasets,
Table

3

collects the main outcomes,
Figure

3

visualizes the malicious-router
counts, and Table

4

lists adaptive-evasion
conditions observed in the wild or demonstrated in the artifact.

Table 2

.

Measurement datasets and collection channels.

Dataset

Collection Channel

Scale

Purpose

Paid routers

Taobao, Xianyu, Shopify storefronts

28 routers

Test sold OpenAI- and Anthropic-compatible endpoints

Free routers

Public links using

sub2api

(

sub2api

,

2026

)

and

new-api

(

QuantumNous

,

2026

)

templates

400 routers

Measure in-the-wild abuse in commodity router ecosystems

Leaked-key poisoning

Chinese forums, and WeChat / Telegram groups

1 OpenAI key

Observe downstream sessions on a reused upstream account

Weak-router decoys

Weak-password

Sub2API

,

CLIProxyAPI

, and

claude-relay-service

deployments

20 domains + 20 IPs

Measure exploitation and downstream exposure through poisoned routers

5.1.

Dataset and Collection

We purchased 28 paid OpenAI- and Anthropic-compatible routers from
Taobao

(Alibaba Group,

2026a

)

, Xianyu

(Alibaba Group,

2026b

)

, and
Shopify-hosted storefronts

(Shopify,

2026

)

.
We also collected 400 free routers exposed through public communities,
router lists, and configuration dumps.
The free corpus is dominated by two widely reused templates,

sub2api

(sub2api,

2026

)

(11k GitHub stars) and

new-api

(QuantumNous,

2026

)

(25.4k stars, 1.25M Docker Hub
pulls), which made it possible to expand
from seed URLs into a much larger set of reachable router instances.
That expansion followed only additional public links reachable from the
same posts, router lists, and configuration-dump references; we did not
scan arbitrary address ranges or attempt to enumerate hidden admin
surfaces.
We conservatively deduplicated exact repeated endpoints after URL
normalization; deployments that reused the same template on distinct
domains or IPs remained separate because they still correspond to
different externally reachable trust boundaries.
We also could not always recover exact template versions or complete
default configurations, so we do not attribute observed abuse to a
particular

sub2api

or

new-api

release.
For each router, the testing pipeline proceeds in four stages.
First, we register a researcher-controlled account with the router and
obtain API credentials.
Second, we route the account through a sandboxed agent environment and
execute a randomized subset of custom tasks and TerminalBench 2.0
tasks

(ter,

2025

)

, which produce realistic shell, package-install,
and file-manipulation tool calls across diverse programming languages
and workflows.
Third, every tool-call payload returned by the router is executed
inside the sandbox, which monitors for network callbacks,
file-system modifications, and process-tree anomalies.
Fourth, a dedicated analysis agent reviews flagged executions and
classifies the behavior as benign rewriting (e.g., CDN substitution),
potentially malicious, or confirmed malicious.
This pipeline also records whether conditional triggers were
present and whether router-side plaintext access to researcher-owned
AWS or Ethereum canaries produced follow-on abuse.

To study how ostensibly benign routers can be poisoned, we ran two
additional measurements.
First, we intentionally leaked a researcher-owned OpenAI API key on Chinese forums, and WeChat and Telegram groups where router operators
share credentials and relay endpoints

(Meli et al

.

,

2019

)

.
Second, we deployed vulnerable

claude-relay-service

instances across 20
domains and weak-password

Sub2API

and

CLIProxyAPI

instances across 20 IPs.
These decoys were researcher-controlled and served only to measure how
quickly external operators would absorb them into downstream router
chains.
Across both poisoning studies, we retained only aggregate session
metadata, credential classes, salted hashes of leaked credential values,
and coarse host or project identifiers; we did not store raw third-party
prompt or response bodies.
We use conservative operational definitions throughout.

A router counts as injecting malicious code only if a returned tool-call
payload is rewritten into an attacker-controlled command or dependency
under researcher-controlled probing.
We count an AWS canary as touched when a credential that crossed the
router later produces follow-on AWS API activity attributable to that
credential, and an ETH drain when funds leave a prefunded
researcher-controlled private key after exposure.
In the weak-router study, an unauthorized access attempt is a distinct
unsolicited interaction against a decoy endpoint; a session is
command-injectable if it exposes at least one shell-execution path whose
returned command could be rewritten before execution; and YOLO mode
means automatic tool approval without per-command confirmation.
Throughout this section, token totals reflect all billed traffic visible
at the exposed upstream account or decoy, whereas Codex-session counts
cover only the subset of traffic we could confidently attribute to
downstream Codex clients, so the two quantities are not directly
comparable.

Table 3

.

Main measurement outcomes across malicious routers and poisoned benign routers.

Setting

Sample / Footprint

Active Manipulation

Adaptive Evasion

Credential Abuse

Main Outcome

Paid routers

28 purchased routers

1 router injects malicious code

0 observed

0 observed

Paying for a router does not remove tool-call injection risk

Free routers

400 public routers

8 routers inject malicious code

2 routers trigger selectively

17 routers touch AWS canaries; 1 drains ETH

Commodity free-router ecosystems already expose AC-1, AC-1.a/b, and AC-2 behaviors

Leaked upstream key

1 OpenAI key leaked publicly

0 observed

Not needed

>

>

7 Codex sessions; one session exposed multiple credentials

100M GPT-5.4 tokens observed under a researcher-owned account

Weak-router decoys

20 domains + 20 IPs

All 440 observed sessions expose shell-execution paths

401 sessions already in auto-approve (YOLO) mode

99 credentials across 440 sessions / 398 projects

2B billed tokens; about 13 GB visible traffic; 40k+ attempts; 6 JA3

5.2.

Malicious Routers in the Wild

Across the 28 paid and 400 free routers, we find active malicious
behavior in both markets.
One paid router and eight free routers inject malicious code into
returned tool calls.
These modifications are not cosmetic output rewrites; they change the
command or dependency that the agent intends to execute.
In the free-router set, 17 routers trigger follow-on use of at least
one researcher-owned AWS canary credential after seeing it in transit,
and one router drains ETH
from a researcher-owned Ethereum private key.
Figure

3

summarizes these counts by paid
versus free router populations.

Code injection

Adaptive evasion

Credential abuse

Wallet drain

0

2

2

4

4

3.57

3.57

0

0

0

2

2

0.5

0.5

4.25

4.25

0.25

0.25

Routers (%)

Paid (

n

=

28

n{=}28

)

Free (

n

=

400

n{=}400

)

Figure 3

.

Observed malicious-router behaviors across 28 paid and 400 free
routers.
Bars are normalized within the paid and free populations; raw counts
appear in Table

3

and the surrounding text.
Adaptive evasion is observed only among routers that already perform
active manipulation.

Two malicious routers exhibit adaptive evasion rather than always-on
rewriting.
The deployed trigger logic is operational rather than exotic.
In one case, malicious tool calls are injected only after the first
50 requests, which hides the attack from shallow smoke tests.
In another, injection is enabled only for sessions that appear to be
running in autonomous YOLO mode and only when the project fingerprint
matches Rust or Go.
These triggers are sufficient to keep benign probes clean while
reserving manipulation for high-value coding sessions.
They are not necessarily exhaustive.
Because we observe the routers only through finite black-box probing, a
router may implement additional latent conditions that our probes did
not activate.

Table 4

.

AC-1.b conditions observed in malicious routers.
Each maps to one of the five trigger families defined in
Section

4.2.2

.

Type

Condition

Trigger Family

Effect

Observed

After 50 prior calls

Request-count threshold

Hides AC-1 until warm-up traffic completes

Observed

Only in YOLO mode

User fingerprint

Reserves payload injection for autonomous sessions

Observed

Only for Rust / Go projects

Content keyword

Targets high-value developer environments while evading generic probes

5.3.

Poisoning Benign and Trusted Routers

Active malicious routers are only half of the supply-chain problem.
Routers that look benign can be poisoned into the same position when
they reuse leaked upstream credentials or when they forward user traffic
through other weak routers.
We observe both paths.

In the first poisoning study, we intentionally leaked a
researcher-owned OpenAI API key on Chinese forums, WeChat, and
Telegram groups frequented by router operators.
That single key served 100M GPT-5.4 tokens and exposed more than
seven Codex user sessions.
Because the traffic was billed to and logged under our upstream account,
we could observe downstream prompt, tool, and credential material
crossing a router we did not directly operate.
In at least one observed session, multiple distinct credentials
appeared behind the leaked key.
This result is consistent with several paths: direct reuse by a router
operator, direct reuse by unrelated third parties, or reuse somewhere
inside a longer relay chain.
We cannot always distinguish among those paths from provider-side logs
alone.
What the experiment does establish is the blast radius: once a
supposedly benign router path reuses a stolen upstream credential, the
holder of that credential inherits the same plaintext visibility as an
actively malicious router.

In the second poisoning study, we deployed vulnerable

claude-relay-service

instances across 20
domains and weak-password

Sub2API

and

CLIProxyAPI

instances across 20 IPs.
We observed 40k+ unauthorized access attempts from 147 IPs with six
unique JA3 fingerprints.
Those initial accesses are consistent with a mix of opportunistic
internet scanning and subsequent relay reuse.
We therefore do not interpret every access event itself as evidence of a
targeted supply-chain attack.
The stronger signal comes from the later structured downstream traffic:
the decoys were not merely scanned once, but were folded into active
agent-facing relay paths that generated sustained billed usage and
repeat Codex sessions.
Those decoys ultimately served roughly 2B GPT-5.4 and 5.3-codex tokens,
corresponding to roughly
13 GB of visible downstream prompt/response traffic, and exposed 99 unique
credentials across 440 Codex sessions spanning 398 different projects
or hosts.
All 440 sessions were command-injectable, and 401 already operated in
YOLO mode, i.e., with tool execution auto-approved rather than
confirmed command by command.
For those 401 sessions, sophisticated adaptive evasion was unnecessary:
basic payload injection would have been sufficient to change executed
commands.

This benign-router poisoning result is the strongest evidence that the
router threat boundary is transitive.
A router does not need to be malicious at account creation time.
If it later adopts leaked upstream keys or forwards traffic into a weak
relay chain, all four attack classes become available to whoever
controls that upstream account or inner relay.
The user may believe they are trusting one router, while the effective
trust boundary has silently expanded to a larger chain of opportunistic
operators.

5.4.

Key Findings

Malicious routers already exist in both paid and free
commodity router markets.

The 1 paid and 8 free routers that inject malicious code show that this
is not a purely hypothetical threat or a pathology confined to obvious
free relay dumps.
Paid access improves service stability, but it does not prove tool-call
integrity.

Adaptive evasion is deployed, but often unnecessary.

We observe real routers that wait for warm-up traffic, target only YOLO
mode, or restrict injection to Rust and Go projects.
At the same time, the weak-router decoy study shows that many downstream
agent sessions are already so permissive that complex triggers are not
required: 401 of 440 observed sessions were autonomous enough for simple
payload injection to succeed.

Benign routers can be poisoned into the same trust
boundary.

Leaked upstream keys and weak third-party relays turn otherwise benign
routers into channels for plaintext prompt visibility, credential
exposure, and command injection.
The supply-chain risk therefore does not begin only when a router
operator decides to act maliciously; it also appears when a router
reuses compromised credentials or silently chains through a weaker
upstream intermediary.

5.5.

Scope

Our corpus targets the most active publicly reachable commodity router
markets; enterprise and invite-only deployments are a natural extension.
Although the majority of routers in our corpus originate from
Chinese-language marketplaces and communities, this does not make the
findings regionally narrow:
Chinese open-source models reached nearly 30% of total OpenRouter
usage in some weeks, and Asia’s share of LLM API spend on the platform
grew from about 13% to 31%

(Aubakirova et al

.

,

2026

)

, so routers
serving this traffic handle a substantial share of global routing
volume.
The poisoning studies demonstrate exploitability and blast radius under
realistic conditions, and the session-level findings reflect the
population of users who interact with these commodity routers in
practice.

6.

Mine Artifact

We implement Mine as an OpenAI-compatible FastAPI proxy that forwards
requests to an upstream provider and conditionally applies AC-1,
AC-1.a, AC-1.b, and AC-2.
We also implement companion client-side modules for the deployable
defenses evaluated in Section

7

: a tool policy gate,
response-side anomaly screening, and an append-only transparency log.

Mine parses each request, evaluates trigger rules, optionally
activates an attack module, forwards the request upstream, and applies
response-side rewrites before returning data to the client.
AC-1 rewrites tool-call payloads via JSON-path mutation;
AC-1.a rewrites shell and package-install command strings via
substitution rules;
AC-1.b selects when AC-1 and AC-1.a activate using tool-name, keyword,
user-fingerprint, time-window, and

N

N

-th-request conditions; and
AC-2 scans request and response bodies for secrets and exfiltrates
matches asynchronously.
Streaming is handled by buffering Server-Sent Events (SSE) tool-call
chunks until the full argument payload can be rewritten.

6.1.

Cross-Framework Compatibility

We evaluate Mine against four public agent frameworks: OpenClaw

(OpenClaw,

2026

)

,
OpenCode

(OpenCode,

2026

)

, OpenAI’s Codex, and Anthropic’s Claude Code.
For each framework, we send 1,000 tool-calling requests through the
proxy with each attack module active.
This section asks whether public agent frameworks add local integrity
checks or other constraints that materially narrow the attack surface
in practice.

Table 5

.

Cross-framework compatibility results for Mine.

Metric

Result

Frameworks tested

4

Requests per framework/module

1,000

Frameworks with response-integrity checks

0/4

AC-1 rewrite compatibility

100%

AC-1.a rewrite compatibility

99.6%

AC-2 extractor coverage

100%

Buffered streaming compatibility

4/4

Median overhead

0.013 ms/request

Median upstream latency

820 ms

None of the four frameworks implement response-integrity verification.
AC-1 achieves 100% rewrite compatibility on tool-calling responses
across all frameworks.
AC-1.a achieves a 99.6% compatibility rate on package-install tool
calls.
For AC-2, the relevant metric is extractor coverage rather than
client-visible execution: the module matches 100% of payloads
containing detectable secrets under its rule set while remaining
passive from the client’s perspective.
Within the evaluated frameworks, the same rewriting logic handles both
OpenAI- and Anthropic-style wire formats; OpenAI requires nested
parsing of string-encoded arguments, whereas Anthropic-style interfaces
expose native JSON structures directly.
These are compatibility measurements, not end-to-end execution rates:
they show that the tampered tool call reaches the client in a valid
framework-native format, but downstream permission prompts or local
execution sandboxes may still block the resulting action.
Table

5

summarizes the results.

In streaming mode, AC-1 and AC-1.a retain the same rewrite compatibility
rates because the proxy reconstructs the complete tool-call payload
before modification via buffered rewriting.
This buffering introduces an average pause of 0.004–0.005 ms between the
final natural token and the first rewritten token, well below the
820 ms median upstream latency and indistinguishable from ordinary
model jitter.
Per-request proxy overhead is 0.013 ms median over 10,000
requests to GPT-5.4, measured on an Apple M3 Max workstation
(

time.perf_counter_ns()

).
The remaining 0.4% of AC-1.a failures are edge cases where install
commands used quoted package fragments, editable local paths, or
URL-based installs that the substitution rule conservatively declined
to rewrite.

7.

Deployable Defenses

No client-side control available today can prove that a router
preserved the upstream provider’s response.
Still, several mitigations can be deployed immediately without
provider cooperation.
We implemented three such controls in the artifact and evaluated them
against the same attack classes studied in
Sections

4

and

6

.
All numbers in this section come from controlled artifact-side
evaluation rather than field data: the released scripts generate
synthetic benign and attack tool-call corpora, run the defenses over
those corpora, and report the resulting coverage and overhead.
The threat model for these defenses is deliberately modest: they are
meant to reduce exposure when the attacker must pass through ordinary
tool-execution paths visible to the client.
We assume the attacker may know the defense family and probe coarse
behavior; the adaptive tests below relax that assumption further.
They are not a substitute for origin authentication.
Table

6

summarizes the coverage.

Table 6

.

Immediate client-side defenses and their coverage.

Defense

AC-1

AC-1.a

AC-2

AC-1.b

Result / Scope

Policy gate

100%

100%

–

–

1.0% FP; 2.3

μ

\mu

s; 100% adaptive bypass in a simple benchmark

Anomaly screening

89.0%

50.0%

–

50.9%

6.7% FP on returned tool calls

Transparency log

Audit

Audit

Audit

Audit

12.0 MB/1k sessions; 1.26 KB/entry

These controls serve different operational purposes.
The policy gate is the only one in our evaluation that consistently
stops AC-1 and AC-1.a before execution, but only for narrowly scoped
high-risk tools.
Anomaly screening is weaker, yet still useful when deployments cannot
turn every shell-execution path into a fail-closed workflow.
Transparency logging does not prevent manipulation, but it preserves
the evidence needed to scope exposure once a router, account, or
session becomes suspect.
The practical takeaway is not that any one control solves the problem.
It is that meaningful exposure reduction is possible today without
waiting for provider cooperation.
The strongest caveat is that the policy gate is also brittle: once the
attacker can hide behind an allowlisted domain or a pre-positioned local
stager, the gate no longer helps.
That full bypass result is the main negative finding of this section,
and it bounds how much confidence practitioners should place in
allowlist-only defenses.

7.1.

High-Risk Tool Policy Gate

The strongest immediately deployable control is to fail closed on
high-risk shell-execution workflows.
Our policy gate inspects only locally visible tool-call payloads and
blocks commands that fetch from non-allowlisted domains or install
packages outside a local allowlist.
This is narrow by design: it targets the subset of tools that already
carry the highest execution risk, such as

Bash

,

run_command

, and package-install commands emitted through
those tools.
On a templated benchmark of 1,000 benign shell commands plus 500
AC-1 and 500 AC-1.a commands generated by the artifact, the policy gate
blocks every AC-1 and AC-1.a sample with a 1.0% false positive rate and
2.3

μ

\mu

s median decision cost.
All false positives are benign installer fetches from mirror domains
outside the local allowlist.
Mirror-heavy deployments, including developer environments that rely on
regional package mirrors, would likely see higher false-positive rates
unless those mirrors are explicitly incorporated into local policy.
The cost of this defense is operational rather than computational.
Teams must maintain allowlists for installer domains and dependency
names, and benign drift outside those allowlists becomes a review or
breakage event.
That threat model matters.
If the attacker can host payloads on an allowlisted domain or
pre-position a local stager that is later executed through a benign

Bash

command, the gate no longer helps.
In a simple adaptive benchmark that uses those two strategies, the
policy gate is bypassed in 100% of samples.
This means the gate should be understood as a coarse but useful filter
for obvious high-risk workflows, not as a robust defense against
defense-aware attackers.

7.2.

Response-Side Anomaly Screening

Some deployments cannot fail closed on every shell command.
For those settings, we evaluate a weaker detector that scores each
returned tool call using only locally observable features: shell-risk
patterns, tool-name frequency within the session, argument entropy,
unexpected secret-like strings, and schema deviation.
The detector deliberately does not compare the observed tool call
against an unavailable upstream response.
The implementation is an IsolationForest

(Liu et al

.

,

2008

)

fit on 2,000 synthetic
benign tool calls generated from

Bash

,

Read

,

Grep

,

Glob

, and

Edit

sessions, then
evaluated on disjoint held-out synthetic attack and benign sessions
(3,352 benign, 301 AC-1, 294 AC-1.a, and 53 AC-1.b tool calls).
It is therefore a controlled review-oriented detector, not a model
trained on production user traffic.
At 6.7% false positives, the detector flags 89.0% of AC-1 samples,
50.0% of AC-1.a samples, and 50.9% of AC-1.b samples.
An additional held-out benign distribution drawn from different
developer commands yields 0/600 false positives at that threshold.
On the in-distribution benign set, most false positives come from
legitimate but high-risk shell workflows: allowlisted installer
bootstraps, multi-package install commands, and

kubectl apply

fetches.
Figure

6

shows the threshold
tradeoff.
At a strict 1% false-positive budget, the detector still catches
43.5% of AC-1 samples, but essentially none of AC-1.a and only 9.4%
of AC-1.b.
Relaxing the budget to 5% raises AC-1 coverage to 86.7%, while
AC-1.a and AC-1.b remain only partially visible at 28.6% and 49.1%.
At 10%, AC-1.a rises to 64.3%, and at 20% all three classes become
substantially more visible, but at a review burden that would be hard
to justify for routine developer workflows.
We therefore report 6.7% as a middle operating point: it surfaces
most blatant AC-1 rewrites while keeping review load bounded and still
catching a meaningful share of AC-1.a and AC-1.b traffic.
Appendix

B

reports the full threshold table
and a feature ablation.
The ablation shows that the shell-risk feature carries most of the
signal: removing it drops AC-1 detection to 17.6% and AC-1.a detection
to 4.4%.
The detector is therefore useful for review prioritization, but it
remains weaker than a fail-closed policy and still loses ground
against selective or defense-aware attackers.
An attacker that knows the detector’s feature family can deliberately
stay within ordinary shell syntax, spread an action across multiple
benign-looking tool calls, or fall back to AC-2, none of which this
local detector can rule out.

{subcaptionblock}

0.48

1

1

5

5

10

10

20

20

0

20

20

40

40

60

60

80

80

100

100

False-positive budget (%)

Detection rate (%)

AC-1

AC-1.a

AC-1.b

{subcaptionblock}

0.48

AC-1

AC-1.a

AC-2

AC-1.b

0

20

20

40

40

60

60

80

80

100

100

Effectiveness (%)

Signing

Anomaly

TLS pin

Logging

Figure 4

.

Threshold sweep for anomaly screening.

Figure 5

.

Defense effectiveness by attack class.

Figure 6

.

Defense evaluation.
(a) Threshold sweep: detection rate vs. false-positive budget for the
anomaly screener across AC-1, AC-1.a, and AC-1.b.
(b) Per-class effectiveness of all four defenses: response signing,
anomaly detection, TLS pinning, and transparency logging.

7.3.

Append-Only Transparency Logging

The third control is a local transparency log that records the request
body, response body, router URL, TLS metadata, and a hash of the raw
response bytes after request-side secret redaction.
Logging does not prevent manipulation, but it improves forensic
scoping once misuse is suspected and makes it easier to correlate
traffic across retries, routers, and upstream accounts.
For AC-2 in particular, the log is useful only after the fact: it can
tie a leaked upstream credential or suspicious tool output to later
unauthorized usage on the same account, but it does not detect passive
collection at the moment it occurs.
In a storage benchmark over 1,000 synthetic OpenAI-style sessions
(10 tool calls each), the log costs 12.0 MB per 1,000 sessions, or
about 1.26 KB per entry.
That overhead is small enough for developer workstations and CI jobs,
which makes the control practical even when fail-closed policies are
too restrictive.
In deployment, the log is most useful when paired with one of the
preventive controls above.
The gate or detector decides what to block or escalate in the moment;
the log preserves the request, returned tool call, router endpoint,
and response hash needed to answer the next question after an
incident: how far did this router or credential reach, and which
sessions were exposed through it?

These defenses reduce exposure for high-risk tool-use deployments, but
they do not authenticate origin.
A router that stays within local allowlists and avoids obvious
anomalies can still alter semantics.
The remaining gap is end-to-end provenance, which still points back to
provider-supported integrity mechanisms.

8.

Discussion

8.1.

Scope and Future Directions

Our measurement targets the most active commodity router markets and
uses researcher-controlled accounts throughout.
Extending the study to private deployments are natural next
steps that would complement the snapshot presented here.

8.2.

Longer-Term Integrity

Choosing a router is a trust decision, but it is not the same as
choosing a cloud provider or package registry.
The switching cost is unusually low: in many agent frameworks, moving
to a router is just a base-URL change and a new API key.
At the same time, the service is often presented as a transparent
compatibility layer even though it can translate schemas, substitute
credentials, and return executable tool calls.

Existing security mechanisms suggest what would and would not help.
Mutual TLS, certificate pinning, and ordinary transport security can
authenticate the router endpoint the client chose, but they do not say
whether the returned tool call preserves upstream semantics

(Campbell et al

.

,

2020

)

.
Web integrity mechanisms such as Subresource Integrity

(W3C,

2016

)

,
signed exchanges

(Yasskin,

2020

)

, and certificate-transparency
logs

(Laurie et al

.

,

2013

)

illustrate two useful patterns: authenticate
content and make that authentication auditable.
Artifact-attestation systems such as SLSA and Sigstore apply the same
idea to software supply chains by signing provenance statements and
release artifacts

(SLSA,

2026

; Sigstore,

2026

)

.
Existing message-signing machinery could carry such a signature, but it
does not remove the need to define a canonical application payload.
The closest analogue here would be a provider-signed canonical
response envelope, similar in spirit to DKIM for
email

(Crocker et al

.

,

2011

)

, that covers the model identifier, tool name,
tool arguments, finish reason, and a client nonce.
Appendix

C

gives a minimal message format and
verification procedure.
In brief, the provider signs a canonical JSON object containing the
provider identity, model, content, tool calls, finish reason, request
nonce, validity window, and key identifier

(Rundgren et al

.

,

2020

)

.
The client verifies that envelope before executing any tool call.
Canonicalization is necessary because the routers in our corpus front
heterogeneous upstream providers through OpenAI- or
Anthropic-compatible interfaces, so signing the raw HTTP body is
insufficient.
To our knowledge, none of the major provider tool-use APIs or the
current MCP specification expose a deployed response-signing mechanism
for tool-call arguments today

(OpenAI,

2023

; Anthropic,

2024

; Google,

2024

; Model Context Protocol,

2025

)

.
Section

7

shows what clients can do today without that
provider support.
Those controls reduce exposure and preserve evidence, but they do not
prove provenance.
Execution sandboxes such as E2B reduce post-execution blast radius but
do not authenticate where a tool call came from

(E2B,

2026

)

.

8.3.

Generalizability

The Model Context Protocol (MCP)

(Hou et al

.

,

2025

)

introduces
a related trust boundary between LLM agents and external tools.
A malicious MCP server receives tool-call requests in plaintext and can
return forged results, so the same basic manipulation and collection
ideas transfer with adaptation to the MCP message format.

Our implementation evaluates buffered rewriting; richer variants
including token injection and AC-1.b triggers are natural extensions.
The measured buffering pause of 0.004–0.005 ms is far below the
820 ms median upstream latency
(Section

6

), confirming that buffered
rewriting adds negligible overhead in practice.

9.

Related Work

Table 7

.

Related work comparison.

Prior Work

Layer

Focus

Our Differentiation

Greshake et al.

(

Greshake et al

.

,

2023

)

; Perez & Ribeiro

(

Perez and Ribeiro

,

2022

)

Model

Prompt injection: adversarial text manipulates model reasoning

Router attacks modify JSON wire format below the model; orthogonal to prompt-level defenses

Zou et al.

(

Zou et al

.

,

2023

)

Model

Jailbreaking and adversarial prompting

We attack the transport, not the model; no adversarial prompt needed

Ohm et al.

(

Ohm et al

.

,

2020

)

; LiteLLM incident

(

Datadog Security Labs

,

2026

)

Supply chain

Supply chain attacks on OSS / AI infrastructure

We analyze post-compromise router capabilities: active tool-call rewriting, passive collection, and conditional delivery

Gu et al.

(

Gu et al

.

,

2019

)

; Kurita et al.

(

Kurita et al

.

,

2020

)

Model

Model-level backdoors via training / fine-tuning

Router attacks require no model access and no training-time adversary

Durumeric et al.

(

Durumeric et al

.

,

2017

)

; de Carnavalet & Mannan

(

de Carné de Carnavalet and Mannan

,

2016

)

Transport

TLS interception by middleboxes

LLM routers are voluntarily configured; no cert substitution needed; attacks are application-layer semantic

MCP security

(

Model Context Protocol

,

2025

)

; Hou et al.

(

Hou et al

.

,

2025

)

Tool server

Tool-server poisoning via malicious MCP descriptions

We target the client–provider transport; a compromised router can intercept any MCP-based interaction that transits it

Liu et al.

(

Liu et al

.

,

2026

)

Client extension

Vulnerabilities in installable agent skills and bundled scripts

Router attacks need no skill installation and can affect both skill-enabled and skill-free clients

Table

7

summarizes the closest prior lines of
research and how our work differs.

Prompt injection.

Greshake et al. introduced indirect prompt injection, showing that
adversarial content embedded in external data sources can hijack an
LLM’s behavior

(Greshake et al

.

,

2023

)

.
Subsequent work explored direct prompt
injection

(Perez and Ribeiro,

2022

)

,
jailbreaking

(Zou et al

.

,

2023

)

.
Router attacks are orthogonal: the intermediary rewrites the JSON wire
format outside the model’s reasoning loop, so prompt-level defenses do
not authenticate the returned tool-call payload.

Software supply chain.

Ladisa et al. systematized attacks on open-source supply
chains

(Ladisa et al

.

,

2023

)

; Duan et al. measured typosquatting and
dependency confusion across package managers

(Duan et al

.

,

2021

)

;
Ohm et al. catalogued maintainer compromise and related
vectors

(Ohm et al

.

,

2020

)

.
The Codecov breach showed how a single compromised CI script can persist
for months while exfiltrating
credentials

(Codecov,

2021

)

.
Gu et al. and Kurita et al. demonstrated backdoor injection into
pre-trained models and fine-tuning
pipelines

(Gu et al

.

,

2019

; Kurita et al

.

,

2020

)

.
Adjacent systems such as SLSA and Sigstore sign build provenance or
release artifacts rather than dynamic per-response tool-call
semantics

(SLSA,

2026

; Sigstore,

2026

)

.

TLS interception and API gateways.

Durumeric et al. measured the security impact of HTTPS interception by
middleboxes

(Durumeric et al

.

,

2017

)

; de Carnavalet and Mannan
found widespread TLS validation
failures

(de Carné de Carnavalet and Mannan,

2016

)

; Waked et al. showed that even
well-intentioned interception introduces
vulnerabilities

(Waked et al

.

,

2018

)

.
LLM routers perform the same basic operation, but the client chooses the
intermediary explicitly, so no certificate substitution
occurs

(Man et al

.

,

2020

)

.
Enterprise AI gateways such as Kong

(Kong,

2026

)

add policy
around the chosen intermediary, and sandboxes such as
E2B

(E2B,

2026

)

constrain post-execution blast radius, but neither
authenticates the provider-origin tool-call payload.

MCP security.

MCP introduces a related trust boundary between agents and tool
servers

(Model Context Protocol,

2025

; Hou et al

.

,

2025

)

.
The key structural difference is

where

the intermediary sits:
an MCP server terminates the tool-execution side and can forge outputs
but cannot observe or alter the upstream model’s reasoning.
A malicious router, by contrast, sits on the client–provider transport
and intercepts

every

tool call as well as the full request
context.
Liu et al. studied vulnerabilities in installable agent skills and
bundled scripts

(Liu et al

.

,

2026

)

; router attacks need no skill
installation and affect both skill-enabled and skill-free clients.

10.

Conclusion

LLM API routers sit on a critical trust boundary that the ecosystem
currently treats as transparent transport.
Our measurement of 428 commodity routers found 9 injecting malicious
code and 17 abusing researcher-owned credentials; poisoning studies
showed that even benign routers are one leaked key away from the same
exposure, with researcher-controlled decoys attracting 2B billed
tokens, 440 autonomous Codex sessions, and 99 leaked credentials.
Client-side defenses (policy gates, anomaly screening, transparency
logs) reduce exposure today, but closing the provenance gap ultimately
requires provider-signed response envelopes so that the tool call an
agent executes can be tied to what the model actually produced.

References

(1)

ter (2025)

2025.

Terminal-Bench.

https://www.tbench.ai/

.

Benchmark for testing AI agents in terminal environments. Accessed:
2026-04-08.

Alibaba Group (2026a)

Alibaba Group.
2026a.

Taobao.

https://www.taobao.com

.

Chinese consumer-to-consumer marketplace. Accessed: 2026-04-07.

Alibaba Group (2026b)

Alibaba Group.
2026b.

Xianyu (Idle Fish).

https://www.goofish.com

.

Chinese second-hand marketplace. Accessed: 2026-04-07.

Amazon Web Services (2026)

Amazon Web Services.
2026.

Amazon Bedrock.

https://aws.amazon.com/bedrock/

.

Managed service providing access to foundation models from AI21,
Anthropic, Cohere, Meta, Mistral, Stability AI, and Amazon via a unified API.
Accessed: 2026-04-08.

Anthropic (2024)

Anthropic.
2024.

Tool use with Claude.

https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview

.

Accessed: 2026-04-08.

Aubakirova et al

.

(2026)

Malika Aubakirova, Alex
Atallah, Chris Clark, Justin
Summerville, and Anjney Midha.
2026.

State of AI: An Empirical 100 Trillion Token
Study with OpenRouter.

arXiv preprint arXiv:2601.10088

(2026).

BerriAI (2024)

BerriAI.
2024.

LiteLLM: Call 100+ LLM APIs in OpenAI Format.

https://github.com/BerriAI/litellm

.

Accessed: 2026-03-15.

Campbell et al

.

(2020)

Brian Campbell, John
Bradley, Nat Sakimura, and Torsten
Lodderstedt. 2020.

OAuth 2.0 Mutual-TLS Client Authentication and
Certificate-Bound Access Tokens.

RFC 8705.

https://doi.org/10.17487/RFC8705

Codecov (2021)

Codecov.
2021.

Bash Uploader Security Update.

https://about.codecov.io/security-update/

.

April 2021. CI/CD supply chain breach persisting January–April 2021.
Accessed: 2026-03-20.

Crocker et al

.

(2011)

Dave Crocker, Tony
Hansen, and Murray S. Kucherawy.
2011.

DomainKeys Identified Mail (DKIM) Signatures.

RFC 6376.

https://doi.org/10.17487/RFC6376

Datadog Security Labs (2026)

Datadog Security Labs.
2026.

LiteLLM and Telnyx compromised on PyPI: Tracing the
TeamPCP supply chain campaign.

https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-teampcp-supply-chain-campaign/

.

March 2026. Accessed: 2026-04-08.

de Carné de Carnavalet and Mannan (2016)

Xavier de Carné de Carnavalet and
Mohammad Mannan. 2016.

Killed by Proxy: Analyzing Client-end TLS
Interception Software. In

Proceedings of the 2016
Network and Distributed System Security Symposium (NDSS)

.
Internet Society.

https://doi.org/10.14722/ndss.2016.23374

Duan et al

.

(2021)

Ruian Duan, Omar Alrawi,
Ranjita Pai Kasturi, Ryan Elder,
Brendan Saltaformaggio, and Wenke Lee.
2021.

Towards Measuring Supply Chain Attacks on Package
Managers for Interpreted Languages. In

Proceedings
of the 2021 Network and Distributed System Security Symposium (NDSS)

.
Internet Society.

Durumeric et al

.

(2017)

Zakir Durumeric, Zane Ma,
Drew Springall, Richard Barnes,
Nick Sullivan, Elie Bursztein,
Michael Bailey, J. Alex Halderman, and
Vern Paxson. 2017.

The Security Impact of HTTPS Interception. In

Proceedings of the 2017 Network and Distributed
System Security Symposium (NDSS)

. Internet Society.

https://doi.org/10.14722/ndss.2017.23456

E2B (2026)

E2B. 2026.

E2B Documentation.

https://e2b.dev/docs

.

Accessed: 2026-04-07.

Google (2024)

Google. 2024.

Function calling with the Gemini API.

https://ai.google.dev/gemini-api/docs/function-calling

.

Accessed: 2026-04-08.

Greshake et al

.

(2023)

Kai Greshake, Sahar
Abdelnabi, Shailesh Mishra, Christoph
Endres, Thorsten Holz, and Mario
Fritz. 2023.

Not What You’ve Signed Up For: Compromising
Real-World LLM-Integrated Applications with Indirect Prompt Injection. In

Proceedings of the 16th ACM Workshop on Artificial
Intelligence and Security (AISec)

. ACM.

https://doi.org/10.1145/3605764.3623985

Gu et al

.

(2019)

Tianyu Gu, Kang Liu,
Brendan Dolan-Gavitt, and Siddharth
Garg. 2019.

BadNets: Evaluating Backdooring Attacks on Deep
Neural Networks.

IEEE Access

7
(2019), 47230–47244.

https://doi.org/10.1109/ACCESS.2019.2909068

Hou et al

.

(2025)

Xinyi Hou, Yanjie Zhao,
Shenao Wang, and Haoyu Wang.
2025.

Model Context Protocol (MCP): Landscape, Security
Threats, and Future Research Directions.

arXiv preprint arXiv:2503.23278

(2025).

Kong (2026)

Kong. 2026.

Kong AI Gateway.

https://developer.konghq.com/ai-gateway/

.

Accessed: 2026-04-08.

Kurita et al

.

(2020)

Keita Kurita, Paul
Michel, and Graham Neubig.
2020.

Weight Poisoning Attacks on Pretrained Models. In

Proceedings of the 58th Annual Meeting of the
Association for Computational Linguistics (ACL)

. ACL.

https://doi.org/10.18653/v1/2020.acl-main.249

Ladisa et al

.

(2023)

Piergiorgio Ladisa, Henrik
Plate, Matias Martinez, and Olivier
Barais. 2023.

SoK: Taxonomy of Attacks on Open-Source Software
Supply Chains. In

Proceedings of the 2023 IEEE
Symposium on Security and Privacy (S&P)

. IEEE.

https://doi.org/10.1109/SP46215.2023.10179304

Laurie et al

.

(2013)

Ben Laurie, Adam Langley,
and Emil Kasper. 2013.

Certificate Transparency.

RFC 6962.

https://doi.org/10.17487/RFC6962

Liu et al

.

(2008)

Fei Tony Liu, Kai Ming
Ting, and Zhi-Hua Zhou.
2008.

Isolation Forest. In

Proceedings of the 2008 IEEE International
Conference on Data Mining (ICDM)

. IEEE.

https://doi.org/10.1109/ICDM.2008.17

Liu et al

.

(2026)

Yi Liu, Weizhe Wang,
Ruitao Feng, Yao Zhang,
Guangquan Xu, Gelei Deng,
Yuekang Li, and Leo Zhang.
2026.

Agent Skills in the Wild: An Empirical Study of
Security Vulnerabilities at Scale.

arXiv preprint arXiv:2601.10338

(2026).

https://doi.org/10.48550/arXiv.2601.10338

Man et al

.

(2020)

Keyu Man, Zhiyun Qian,
Zhongjie Wang, Xiaofeng Zheng,
Youjun Huang, and Haixin Duan.
2020.

DNS Cache Poisoning Attack Reloaded. In

Proceedings of the 2020 ACM Conference on Computer
and Communications Security (CCS)

. ACM.

https://doi.org/10.1145/3372297.3417280

Meli et al

.

(2019)

Michael Meli, Matthew R.
McNiece, and Bradley Reaves.
2019.

How Bad Can It Git? Characterizing Secret Leakage
in Public GitHub Repositories.

https://www.ndss-symposium.org/ndss-paper/how-bad-can-it-git-characterizing-secret-leakage-in-public-github-repositories/

.
In

Proceedings of the 2019 Network and Distributed
System Security Symposium (NDSS)

. Internet Society.

Accessed: 2026-04-07.

Microsoft (2026)

Microsoft.
2026.

Azure OpenAI in Foundry Models.

https://azure.microsoft.com/en-us/products/ai-foundry/models/openai/

.

Accessed: 2026-04-08.

Model Context Protocol (2025)

Model Context Protocol.
2025.

Security Best Practices - Model Context Protocol.

https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices

.

Accessed: 2026-04-08.

Ohm et al

.

(2020)

Marc Ohm, Henrik Plate,
Arnold Sykosch, and Michael Meier.
2020.

Backstabber’s Knife Collection: A Review of Open
Source Software Supply Chain Attacks. In

Proceedings of the 17th Conference on Detection of
Intrusions and Malware & Vulnerability Assessment (DIMVA)

.
Springer.

https://doi.org/10.1007/978-3-030-52683-2_2

one-api contributors (2026)

one-api contributors.
2026.

one-api: OpenAI API Management and Distribution
System.

https://github.com/songquanpeng/one-api

.

30.5k GitHub stars, 1.19M Docker Hub pulls as of April 2026.
Accessed: 2026-04-07.

OpenAI (2023)

OpenAI. 2023.

Function calling and other API updates.

https://openai.com/index/function-calling-and-other-api-updates/

.

Accessed: 2026-04-08.

OpenClaw (2026)

OpenClaw.
2026.

OpenClaw Features Documentation.

https://docs.openclaw.ai/concepts/features

.

Accessed: 2026-04-07. Documents support for 35+ model providers,
including custom and self-hosted OpenAI-compatible and Anthropic-compatible
endpoints..

OpenCode (2026)

OpenCode.
2026.

OpenCode Providers Documentation.

https://opencode.ai/docs/providers

.

Accessed: 2026-04-07. Documents support for 75+ LLM providers and
configurable base URLs for custom endpoints and proxy services..

OpenRouter (2024)

OpenRouter.
2024.

OpenRouter: A Unified Interface for LLMs.

https://openrouter.ai

.

Accessed: 2026-03-15.

Ottinger et al

.

(2025)

Lily Ottinger, Jordan
Schneider, and Zilan Qian.
2025.

How to Use Banned US Models in China.

https://www.chinatalk.media/p/the-grey-market-for-american-llms

.

Investigation of Taobao and Xianyu LLM API reselling market.
Accessed: 2026-04-08.

Patil et al

.

(2023)

Shishir G. Patil, Tianjun
Zhang, Xin Wang, and Joseph E.
Gonzalez. 2023.

Gorilla: Large Language Model Connected with
Massive APIs.

arXiv preprint arXiv:2305.15334

(2023).

Perez and Ribeiro (2022)

Fábio Perez and Ian
Ribeiro. 2022.

Ignore Previous Prompt: Attack Techniques For
Language Models.

arXiv preprint arXiv:2211.09527

(2022).

Qin et al

.

(2023)

Yujia Qin, Shihao Liang,
Yining Ye, Kunlun Zhu,
Lan Yan, Yaxi Lu, Yankai
Lin, Xin Cong, Xiangru Tang,
Bill Qian, Sihan Zhao,
Lauren Hong, Runchu Tian,
Ruobing Xie, Jie Zhou,
Mark Gerstein, Dahai Li,
Zhiyuan Liu, and Maosong Sun.
2023.

ToolLLM: Facilitating Large Language Models to
Master 16000+ Real-world APIs.

arXiv preprint arXiv:2307.16789

(2023).

QuantumNous (2026)

QuantumNous.
2026.

new-api.

https://github.com/QuantumNous/new-api

.

Open-source multi-provider API management and distribution platform.
Accessed: 2026-04-08.

Ruan et al

.

(2024)

Yangjun Ruan, Honghua
Dong, Andrew Wang, Silviu Pitis,
Yongchao Zhou, Jimmy Ba,
Yann Dubois, Chris J. Maddison, and
Tatsunori Hashimoto. 2024.

Identifying the Risks of LM Agents with an
LM-Emulated Sandbox. In

Proceedings of the 12th
International Conference on Learning Representations (ICLR)

.

Rundgren et al

.

(2020)

Anders Rundgren, Benjamin
Jordan, and Samuel Erdtman.
2020.

JSON Canonicalization Scheme (JCS).

RFC 8785.

https://doi.org/10.17487/RFC8785

Schick et al

.

(2023)

Timo Schick, Jane
Dwivedi-Yu, Roberto Dessì, Roberta
Raileanu, Maria Lomeli, Eric Hambro,
Luke Zettlemoyer, Nicola Cancedda, and
Thomas Scialom. 2023.

Toolformer: Language Models Can Teach Themselves to
Use Tools. In

Advances in Neural Information
Processing Systems (NeurIPS)

, Vol. 36.

Shopify (2026)

Shopify.
2026.

Shopify.

https://www.shopify.com

.

Global e-commerce platform hosting independent storefronts. Accessed:
2026-04-07.

Sigstore (2026)

Sigstore.
2026.

Sigstore Documentation.

https://docs.sigstore.dev/

.

Accessed: 2026-04-07.

SLSA (2026)

SLSA. 2026.

SLSA Specification.

https://slsa.dev/spec/v1.2/

.

Accessed: 2026-04-07.

sub2api (2026)

sub2api.
2026.

sub2api.

https://github.com/Wei-Shaw/sub2api

.

Open-source OpenAI-compatible API router template. Accessed:
2026-04-08.

W3C (2016)

W3C. 2016.

Subresource Integrity.

https://www.w3.org/TR/SRI/

.

W3C Recommendation. Accessed: 2026-04-07.

Waked et al

.

(2018)

Louis Waked, Mohammad
Mannan, and Amr Youssef.
2018.

The Sorry State of TLS Security in Enterprise
Interception Appliances.

arXiv preprint arXiv:1809.08729

(2018).

Wang et al

.

(2023)

Lei Wang, Chen Ma,
Xueyang Feng, Zeyu Zhang,
Hao Yang, Jingsen Zhang,
Zhiyuan Chen, Jiakai Tang,
Xu Chen, Yankai Lin,
Wayne Xin Zhao, Zhewei Wei, and
Ji-Rong Wen. 2023.

A Survey on Large Language Model based Autonomous
Agents.

arXiv preprint arXiv:2308.11432

(2023).

Yasskin (2020)

Jeffrey Yasskin.
2020.

Signed HTTP Exchanges.

Internet-Draft
draft-yasskin-http-origin-signed-responses-09.

https://datatracker.ietf.org/doc/html/draft-yasskin-http-origin-signed-responses-09

Work in progress. Accessed: 2026-04-07.

Zou et al

.

(2023)

Andy Zou, Zifan Wang,
Nicholas Carlini, Milad Nasr,
J. Zico Kolter, and Matt Fredrikson.
2023.

Universal and Transferable Adversarial Attacks on
Aligned Language Models.

arXiv preprint arXiv:2307.15043

(2023).

Appendix A

Ethical Considerations

This appendix describes the ethical framework governing our research,
including data handling,
measurement constraints, and dual-use risk mitigation.

No IRB / ethics-board review.

We did not obtain IRB or equivalent ethics-board review for this
study.
The work used only researcher-controlled accounts and credentials,
relied on synthetic active-probing traffic, and retained only
aggregate operational metadata from unauthorized third-party use of
researcher-owned secrets.
We therefore treated it as systems measurement rather than human-subjects
research, but we make this status explicit because the
credential-exposure case study intentionally created publicly
discoverable secrets.
We nevertheless treated the study as ethically sensitive because that
design could attract third-party abuse and lead to nominal financial
loss on researcher-owned accounts.

A.1.

Disclosure Scope

We did not run a provider-by-provider coordinated disclosure process
for the findings in Section

5

.
Several considerations informed this decision.
First, the paper centers on three measurements: routers openly sold in
public markets, free routers distributed through public communities, and
researcher-controlled poisoning studies based on leaked keys and weak
relay decoys.
These are not private zero-days disclosed by a single vendor.
They are observations about how publicly reachable router ecosystems and
router chains behave once exposed to attacker-relevant inputs.
Second, the affected routers are commodity services operated by
pseudonymous or anonymous sellers on Taobao, Xianyu, and public
community forums; there is no stable security-contact channel for most
of these operators, and many explicitly advertise their service as
unofficial or gray-market.
Third, the vulnerability is architectural rather than
implementation-specific: any router that terminates TLS and forwards
tool-call JSON can mount the same attacks, so disclosing to individual
operators would not remediate the underlying trust gap.
We therefore treated the work as a measurement study rather than an
embargo case.
At the end of the observation window, all exposed credentials were
revoked or otherwise retired.
Because the affected upstream credentials were researcher-owned and
could be retired directly, we did not separately notify OpenAI,
Anthropic, or other upstream providers about each individual reuse
event.

A.2.

Data Minimization

We adhere to strict data minimization principles throughout the study:

Research accounts only.

All API keys, user accounts, and service subscriptions used in our
experiments (Sections

5

–

6

)
were created specifically for this research.
We never access accounts or credentials not under researcher control.
When third-party traffic voluntarily reached researcher-controlled keys
or decoy relays, we limited retention to aggregate metadata and hashed
credential identifiers as described below.

Synthetic payloads.

All provider-facing payloads and prompts used in our study are
synthetically generated.
No real user queries, proprietary code, or sensitive data appear
in any provider-facing validation request.

Retrospective credential-exposure data.

The poisoning studies
(Section

5.3

) are observational rather than
interactive: they analyze unauthorized traffic that reached
researcher-owned credentials after public exposure.
For these studies, we retain only aggregate operational metadata
(timestamps, coarse model identifiers, token volume, source network
labels where available, session counts, project or host counts, and
salted hashes of leaked credential values) and do not store or release
prompt/response bodies or raw credential strings from third-party
traffic.
Project or host identifiers were stored only in coarse form and, where
persisted, as salted one-way hashes rather than human-readable names.
They were used solely for counting distinct exposure scopes and were not
joined against external account records.

No persistent data collection.

Experimental data is retained only for the duration of the study.
Researcher-owned credentials used in the credential-exposure case
study (Section

5.3

) were revoked or
otherwise retired upon completion of the observation period.
All provider interaction logs are stored on encrypted research
infrastructure and will be deleted 12 months after
publication.
Revocation could interrupt unauthorized downstream use of those exposed
credentials.
We accepted that externality because continued operation would have
extended third-party exposure and financial loss on researcher-owned
accounts.

A.3.

Measurement Constraints

We impose the following constraints to ensure our experiments do not
disrupt the services we study:

Rate limiting.

No provider receives more than 60 requests per
hour during any experiment, well below the rate limits published by
all tested providers.
Provider-facing validation requests are spaced to avoid triggering
abuse-detection mechanisms.

No third-party traffic interception.

All active probing requests originate from our own client
infrastructure and target our own upstream accounts.
The poisoning studies do not rely on
network-level interception equipment, DNS hijacking, or traffic
redirection; it analyzes upstream-provider metadata associated with
researcher-owned credentials after those credentials became publicly
discoverable or after traffic voluntarily reached researcher-controlled
decoy relays.

No exploitation of discovered
vulnerabilities.

Where our measurement reveals potential security weaknesses
(e.g., unauthorized secret reuse in the credential-exposure case
study), we
record the finding but do not attempt to validate it through
additional real-world exploitation.
We do not attempt to exploit, amplify, or reproduce any
vulnerability beyond the minimum necessary to confirm its existence.

Minimal financial exposure.

Researcher-owned Ethereum decoy keys were prefunded only with nominal
balances.
For the single on-chain drain reported in
Section

5.3

, the value lost was below US$50
at the time of transfer.

A.4.

Dual-Use Risk and Mitigations

The attack taxonomy and techniques we describe
(Sections

4

–

6

) constitute
dual-use research: the same material that enables defensive
understanding could guide a malicious router operator.
We adopt the following mitigations:

No public release of Mine.

We do not publish Mine or any of its attack modules.
Mine exists solely as an internal research implementation used to
produce the compatibility and defense results in
Sections

6

–

7

; we neither
distribute the source code nor provide deployment or operational
guidance for it.
This choice is intentional: it raises the engineering barrier for
misuse while preserving the scientific value of the measurements the
tool enabled.

Defensive value outweighs offensive risk.

The attack classes we describe (AC-1, AC-1.a, AC-1.b, and AC-2) require only
straightforward JSON manipulation; any competent adversary with
router access could implement them independently.
By publishing a systematic taxonomy and measurement methodology, we
enable the community to build better safeguards around intermediary
trust in agent systems.
We believe the defensive benefit of public disclosure substantially
outweighs the marginal increase in offensive capability, consistent
with the established norms of the security research
community

(Greshake et al

.

,

2023

; Durumeric et al

.

,

2017

)

.

Appendix B

Additional Defense Evaluation

All defense results in Section

7

come from controlled
artifact-side evaluation rather than field data.
The released scripts procedurally generate benign and attack corpora
from fixed command templates and random seeds, then run the defenses on
those corpora.

Table 8

.

Corpora used for the deployable-defense evaluation.

Defense

Corpus Size

Construction

Policy gate

1,000 benign, 500 AC-1, 500 AC-1.a

Templated shell commands covering installer fetches, package installs,

grep

,

git

,

pytest

, and

kubectl

; AC-1 and AC-1.a samples are generated by substituting malicious domains or attacker-controlled package names.

Anomaly screening

2,000 fit benign; held-out 3,352 benign, 301 AC-1, 294 AC-1.a, 53 AC-1.b

Procedurally generated sessions over

Bash

,

Read

,

Grep

,

Glob

, and

Edit

. The detector is an IsolationForest fit on synthetic benign sessions only; held-out attack labels come from injected AC-1, AC-1.a, and trigger-matching AC-1.b tool calls.

Transparency log

1,000 sessions, 10,000 entries

Synthetic OpenAI-style request/response objects with tool calls, request-side secret redaction checks, and response-byte hashing checks.

The anomaly detector in Section

7.2

is fit on
2,000 benign tool calls, calibrated on disjoint held-out benign
sessions, and evaluated on separate attack sessions.
The held-out test split contains 3,352 benign tool calls, 301 AC-1
calls, 294 AC-1.a calls, and 53 AC-1.b calls.
The AC-1.b count is smaller because only trigger-matching calls are
labeled as attack traffic; non-matching calls remain benign by
construction.
We also check the chosen operating point on a held-out benign
distribution built from different developer commands and observe
0/600 false positives.

Table 9

.

Threshold sensitivity for response-side anomaly screening.

Benign FP Target

AC-1

AC-1.a

AC-1.b

1%

43.5%

0.0%

9.4%

5%

86.7%

28.6%

49.1%

10%

95.0%

64.3%

60.4%

20%

100.0%

86.7%

83.0%

Table 10

.

Feature ablation for anomaly screening at the 6.7% false-positive operating point.

Feature Removed

AC-1

AC-1.a

AC-1.b

None

89.0%

50.0%

50.9%

shell_risk_score

17.6%

4.4%

9.4%

tool_frequency

88.4%

53.4%

45.3%

string_entropy

89.0%

33.7%

50.9%

unexpected_secret_pattern

89.0%

47.3%

50.9%

schema_deviation

86.4%

39.5%

50.9%

The threshold sweep shows the expected tradeoff: AC-1 rises quickly as
the false-positive budget grows, while AC-1.a and AC-1.b require much more
lenient thresholds.
The ablation confirms that shell-risk patterns dominate detection for
active command rewrites, which is precisely why the detector remains a
review aid rather than a substitute for provenance.

Appendix C

Canonical Response-Envelope Format

This appendix gives a minimal message format for the provider-signed
response envelope discussed in Section

8.2

.
The goal is semantic integrity for tool-calling responses even when a
router re-serializes, wraps, or otherwise transforms the original HTTP
body.

Table 11

.

Minimal provider-signed response-envelope fields.

Field

Purpose

v

Envelope version for compatibility and rollout.

provider

Provider identity, e.g.,

api.openai.com

.

key_id

Signing-key identifier used for verification and rotation.

model

Provider model identifier for the signed response.

request_nonce

Client-supplied nonce bound to the corresponding request.

issued_at

Provider timestamp for replay control and audit.

expires_at

Short validity horizon for key rotation and replay limits.

content

Natural-language assistant content, if any.

tool_calls

Array of tool calls, each with

name

and native-JSON

arguments

.

finish_reason

Provider finish reason, e.g.,

tool_calls

or

stop

.

sig_alg

Signature algorithm identifier.

signature

Signature over the canonicalized envelope excluding this field.

The signed scope is the entire envelope except

signature

.
Provider-specific billing metadata, raw response identifiers, and
transport headers remain outside the signed scope because they are not
required to decide which tool call the client executes.
The critical normalization step is that

tool_calls[*].arguments

must be represented as native JSON values inside the envelope even if a
provider’s wire format emits them as string-encoded JSON.
This parsing step must itself be canonical and fail closed.
If a provider cannot unambiguously parse a string-encoded argument blob
into native JSON, it should treat the response as unsigned rather than
producing a best-effort envelope.

⬇

1

{

2

"

v

":

1,

3

"

provider

":

"

api

.

openai

.

com

",

4

"

key_id

":

"2026-04-

k1

",

5

"

model

":

"

gpt

-5.4",

6

"

request_nonce

":

"

b7c6b9f0e87a4a6b

",

7

"

issued_at

":

"2026-04-07

T18

:00:00

Z

",

8

"

expires_at

":

"2026-04-07

T18

:05:00

Z

",

9

"

content

":

"

I

will

inspect

the

repository

.",

10

"

tool_calls

":

[

11

{

12

"

name

":

"

Bash

",

13

"

arguments

":

{"

command

":

"

grep

-

R

\"

TODO

\"

./

src

"}

14

}

15

],

16

"

finish_reason

":

"

tool_calls

",

17

"

sig_alg

":

"

Ed25519

",

18

"

signature

":

"

base64

..."

19

}

Listing 2:

Example response envelope.

Provider-side generation.

Given an upstream response, the provider-side SDK or API gateway:
(1) maps the provider-native response into the envelope fields above;
(2) parses any string-encoded tool arguments into native JSON;
(3) canonicalizes the resulting object with RFC 8785 JSON
canonicalization

(Rundgren et al

.

,

2020

)

; and
(4) signs the canonical byte string with the private key referenced by

key_id

.

Client-side verification.

Before executing any tool call, the client:
(1) fetches or caches the provider verification key for

provider

and

key_id

;
(2) checks that

request_nonce

matches the outstanding
request;
(3) checks that

issued_at

and

expires_at

define a
currently valid window; and
(4) re-canonicalizes the envelope without

signature

and
verifies the signature.
If any step fails, the client treats the response as unsigned and
blocks tool execution.

Deployment notes.

Routers may still add unsigned outer metadata, but clients should
execute tool calls only from the verified envelope.
This design therefore tolerates schema translation and re-serialization
while preventing a router from silently rewriting the semantically
meaningful tool-call payload.
Backwards compatibility is incremental: providers can add the envelope
alongside existing response formats, and clients that do not understand
it simply ignore it and behave as they do today.
Clients that do understand it can adopt a phased policy, e.g., verify
when present, then require signatures only for high-risk tool
categories.

For streaming responses, the simplest design is to sign the final
tool-bearing envelope rather than every token chunk.
That matches the execution boundary in current tool-use clients, which
typically wait for complete tool arguments before taking action.
Per-chunk signatures are possible, but they would add significantly more
protocol complexity and are unnecessary for the core threat studied
here, namely silent modification of the final tool-call payload.

BETA