Liu et al. measured third-party LLM API routers — OpenAI-compatible relays that a client points its base URL at — as an application-layer intermediary in agent traffic. TLS protects the hop to the router but proves nothing about origin: the router terminates client traffic and can replace an argument in a returned tool call, for example substituting an attacker-controlled installer or package name into an otherwise benign Bash call, while preserving valid JSON and schema shape. Everything crossing the router is plaintext to it — API keys, cloud credentials, system prompts, tool definitions, file contents and environment variables — so exfiltration requires no visible tampering. The authors report malicious paid and free routers in the wild, AWS canary triggering, ETH theft, adaptive per-session triggers and 440 command-injectable Codex sessions reached through weak-router decoys. The paper's conclusion is that client-side policy gates, anomaly screening and append-only logs reduce exposure today, while provider-signed response envelopes are the longer-term integrity answer.
ASSESSED SYSTEM
The client-side agent deployment the paper measured: a tool-executing coding or workflow agent (IDE assistant, CI job or internal platform agent) whose OpenAI-compatible base URL points at a third-party LLM API router, running with shell, run_command and package-install tools available, in auto-approve mode, in a workspace holding API keys, cloud credentials and file contents. This is a representative configuration rather than one named victim: the paper reached 440 command-injectable Codex sessions through weak-router decoys and found malicious paid and free routers in the ecosystem, and those sessions share the configuration described here.
OUT OF SCOPE
First-party model providers and their APIs, whose behaviour is not implicated; the upstream models themselves, which produced benign tool calls in the tampering scenario; the researchers' own decoy and canary infrastructure; and any individual router operator, none of which is assessed by name here.
Architecture: Agentic / MCP System (decision tree Q2) — Q1 is NO — the paper describes single-agent client sessions, not agents coordinating with each other. Q2 is YES: these are agents that plan and execute multi-step workflows and invoke tools (Bash, run_command, package installation, file writes, cloud CLI actions) without explicit human approval for each action, which the paper measures directly in finding 440 command-injectable sessions 'most already running in auto-approve mode'. Agentic intra-axis weights apply. Tier 3: Tier 3 Internal: the assessed deployment is developer and CI agent tooling operating inside an organisational boundary with controlled users, which the tier table lists explicitly under Tier 3 (code assistants, workflow automation); the financial losses the paper observed in the wild (AWS canary use, ETH theft) arise from credentials that happened to be present in those workspaces rather than from a designed transaction function, though an individual routed deployment holding production cloud or wallet authority would justify Tier 1 on its own facts.
Documented attack or failure path
- An operator points an agent, IDE, CI job or internal platform at a third-party router by changing a base URL and API key — a configuration change small enough to escape review.
- All agent traffic traverses the router in plaintext: system prompts, tool definitions, file contents, environment variables and credentials (the paper's passive AC-2 exfiltration class).
- The upstream model returns a benign tool call; the router rewrites one argument — an installer URL or package name — while preserving valid JSON and the declared schema (the active AC-1 class).
- The client cannot detect the substitution: TLS terminates at the router and no provider-signed response envelope covers model identity, tool name, arguments or nonce.
- The agent executes the rewritten call. In auto-approve mode no per-action gate intervenes, so shell execution or package installation runs with the workspace's full authority.
- Credentials captured in transit are used downstream, which the researchers observed directly through AWS canary triggering and ETH theft.
Observed controls and bounded outcomes
Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.
- Canary credentials worked as designed: the paper's AWS canary fired when the stolen key was used downstream, demonstrating that this detection class does catch the otherwise-invisible passive exfiltration path.
- Transport security held for its actual scope — TLS protected the client-to-router hop against network eavesdroppers; the failure is misplaced trust in the endpoint, not broken cryptography.
- Schema validation on the client side remained effective as a structural check, which is why the attacker had to preserve valid JSON and schema shape rather than injecting free-form content.
- The paper credits client-side policy gates, response-side anomaly screening and append-only session logging with reducing exposure today where they are deployed — the failure in the measured population is that they were largely not deployed, not that they do not work.
Layer 1 — Intrinsic Vulnerability Profile
Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.
| Sub-metric | Score | Rubric basis | Evidence |
|---|---|---|---|
| Robustness (Ro) — scenario interval 0.06–0.81 (midpoint 0.44), Tier 3 MVT 0.40 indeterminate | |||
| Ro-4Poisoning Attack Resistance | 0.25w 0.25 | Ro-4 = 0.25 — basic validation exists in the form of JSON and tool-schema conformance checks, which is precisely what the attacker preserves, but there is no adversarial screening of the content, so manipulation of the tool-metadata and installed-dependency channel succeeds with limited effort. | The executable content the agent acts on is manipulated in transit with no integrity check: the router 'can replace one argument with an attacker-controlled installer or package name while preserving valid JSON and schema shape', and the client has no way to verify what the upstream model produced. Typosquat package names and installer fetches then enter the developer environment through the package channel. The paper's fix — provider-signed response envelopes — does not yet exist in the ecosystem.source: researcher |
| Fairness (Fa) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.45 indeterminate | |||
| Transparency (Tr) — scenario interval 0.11–0.66 (midpoint 0.39), Tier 3 MVT 0.45 indeterminate | |||
| Tr-3Audit Trail Completeness | 0.25w 0.25 | Tr-3 = 0.25 — partial logging exists (agent clients keep local session and tool-call records, and the paper lists append-only logs among controls that help today) but the critical fields for this boundary are omitted: router identity, response hashes, model provenance and approval mode, so an exposed session cannot be reconstructed or scoped. | AID-D-005.004 is mapped because session records must be made to bind 'router URL, TLS metadata, request/response hashes, tool names, authenticated principal, and approval mode' into append-only logs — the fields needed to answer, after the fact, which router, account, request and tool call were exposed. The paper notes that for the passive exfiltration class 'traffic looks normal until a canary or stolen credential is used downstream', which is a statement that existing records do not distinguish the compromised sessions.source: brief |
| Tr-4Model Lineage Disclosure | 0.25w 0.20 | Tr-4 = 0.25 — limited lineage artifacts exist for the nominal base model (a configured model name) but that lineage is asserted rather than attested, and material configuration lineage for the route itself has no version, approval or change record. | The client knows only what the router asserts about which upstream model served the request; the paper's proposed remedy is a provider-signed canonical envelope covering 'model identity, tool name, tool arguments, finish reason, nonce, and validity window', which does not exist today. Route configuration itself is ungoverned — the paper asks that base URL and key be moved into signed, reviewed, canaried route policy bundles because today they can drift silently.source: researcher |
| Privacy (Pr) — scenario interval 0.00–0.65 (midpoint 0.33), Tier 3 MVT 0.50 indeterminate | |||
| Pr-3Data Minimization Compliance | 0.00w 0.35 | Pr-3 = 0.00 — no data-minimization review governs the boundary: the full prompt, tool and environment context is transmitted to a third party without documented necessity, retention limit or field-level control, and the propagation path itself was never authorized. | 'API keys, cloud credentials, system prompts, tool definitions, file contents, and environment variables all cross the router in plaintext.' Nothing is stripped, redacted or classified before leaving the trust boundary; the paper's remediation is to 'strip secrets from prompts, tool outputs, and logs before they cross untrusted routers', and the measured outcome is downstream use of stolen credentials.source: researcher |
| Containment (Cn) — scenario interval 0.07–0.34 (midpoint 0.20), Tier 3 MVT 0.50 confirmed breach | |||
| Cn-1Scope Enforcement | 0.25w 0.12 | Cn-1 = 0.25 — basic boundaries exist (these clients are nominally workspace-scoped) but are enforced inconsistently: the shell and package-install tool classes escape the workspace scope, long-lived secrets are readable in-process, and egress is unconstrained, so simple parameter manipulation exceeds intended scope. | The paper's fail-closed remediation list — block shell execution, package installation, file writes outside the workspace, cloud CLI actions and outbound network fetches from routed sessions, and run those sessions in low-secret sandboxes with constrained egress — enumerates boundaries that were not enforced in the measured sessions, which is why a rewritten argument reaches an interpreter or shell at all.source: brief |
| Cn-2Escalation Prevention | 0.00w 0.16 | Cn-2 = 0.00 — no effective escalation control: an unauthorized party can invoke restricted tools and bypass the approval workflow entirely. This scores the assessed configuration, not the client software: these agents do offer an approval mode, and the measured population had it disabled. | A third party with no legitimate authority over execution — the router — determines what the agent runs, and in auto-approve mode there is no approval workflow left to consult: the paper found 440 command-injectable sessions, 'most already running in auto-approve mode'. Credential separation is equally absent: a key copied from one relay authenticates everywhere, which is why the remediation asks for a distinct service identity, short-lived audience-bound credential and exact route binding per path.source: researcher |
| Cn-3Output Filtering Robustness | 0.00w 0.18 | Cn-3 = 0.00 — no output or policy enforcement stands between the returned model output and execution: unsafe and unauthorized tool calls are acted on directly, with no keyword, pattern, schema-deviation or secret-string screening in the path. | Returned tool calls pass to execution unscreened. AID-H-025.001 is rated High because pre-execution scans for dangerous command patterns, installer fetches, typosquat package names and shell passthrough wrappers 'give the client a deterministic stop before the modified payload runs', and AID-D-003.003 describes the paper's response-side anomaly screener as a control to be added — both describe absent controls, and the measured outcome is that rewritten calls reached interpreters and shells.source: brief |
| Cn-5Agent Identity Integrity | 0.25w 0.14 | Cn-5 = 0.25 — basic API key or shared-secret authentication with no peer verification in the return direction, weak scoping and rotation, and limited auditability; there is no cryptographic binding of the response to an upstream identity at all, so the identity spoofing success rate for the intermediary is effectively total. | The client authenticates to the router with an API key and receives responses it cannot attribute: 'TLS protects the hop to the router but does not prove that the returned tool call is what the upstream model produced.' The recommended fixes name the gap precisely — a distinct service identity per router-to-provider path, short-lived audience-bound credentials, exact route binding so 'a key copied from one relay cannot authenticate everywhere', and eventually provider-signed response envelopes verified before any tool call executes.source: researcher |
| Cn-6Action Reversibility Classification Rate | 0.00w 0.12 | Cn-6 = 0.00 — no reversibility classification is performed before execution and automated actions execute ungated (ARCR = 0). The distinction from Cn-2 is deliberate: Cn-2 records that the approval boundary can be bypassed by an unauthorized party, while Cn-6 records that no class-based reversibility determination is made for the action at all, and therefore no chain-composition rule can exist either. | In the measured auto-approve sessions, actions that are plainly irreversible outside the deployment boundary — installing an attacker-named package into the environment, writing files outside the workspace, running cloud CLI actions with workspace credentials — execute with no pre-execution classification and no gate. The paper's first-line remediation is a fail-closed policy gate for high-risk tools such as Bash, run_command and package installs, i.e. the gating that does not exist in the assessed configuration.source: researcher |
Unknown, not N/A: 14 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.
Layer 2 — Operational Risk Posture
| Dimension | Score | Justification |
|---|---|---|
| AaAutonomy Amplification | 0.90w 0.20 | Above the supervised-autonomy anchor and short of full autonomy. Within a routed session in auto-approve mode every action — shell execution, package installation, file write, cloud CLI call — executes with no human confirmation, which is the paper's measured condition for most of the 440 sessions; what keeps it below 1.00 is that a human still initiates the task and can observe or interrupt the session, so oversight is asynchronous rather than absent by design. elevated |
| AsAttack Surface Exposure | 1.00w 0.25 | The maximum-exposure anchor is met on its own terms: the assessed configuration routes its entire model channel through an untrusted internet-hosted third party that can rewrite executable content, and the paper documents that channel being adversarial in practice (malicious paid and free routers, adaptive per-session triggers). The agent additionally fetches from public package registries and the network. This is not partially trusted external ingestion; the untrusted party sits inside the control path. elevated |
| CpCascade Potential | 1.00w 0.30 | No System Dependency Graph is published, so the worst-case default applies, and the 1.00 anchor is independently corroborated by the observed path: from the entry-exposed origin (the router, which controls the L2 orchestration input) an ungated path reaches the L3 tool layer and then L4 external systems — package registries, cloud APIs and, in the observed cases, wallet and AWS resources. The terminal nodes are credential-bearing and permission-issuing (P4) and the actions are delegated-irreversible (package installation into the environment, funds movement), with no gate anywhere on the path in auto-approve mode. Propagation was demonstrated end to end, not inferred: the AWS canary fired and ETH was stolen.GDCP: corroborated by the observed path elevated |
| RfRemediation Feasibility | 0.40w 0.25 | Between the infrastructure-fix and retraining anchors, and justified in both directions. The operator-side fix is deterministic and fast — revert the base URL to an approved provider, move route configuration into reviewed and signed policy bundles, issue per-router scoped short-lived credentials, and enable fail-closed tool gates and sandboxes, all days of work with no model change. But the property that makes the attack possible has no available fix: the paper states plainly that client-side controls 'help, but do not prove origin', and provider-signed response envelopes do not yet exist, so any deployment that continues to use an intermediary can only bound the residual through external layers. Scored 0.40 to record a fast deterministic remediation for the specific deployment sitting on top of an unresolved ecosystem-level integrity gap; not elevated. |
Nelevated = 3 (dimensions strictly above 0.75) → CRM = 1.35.
Compound Risk Alert. Two or more dimensions are simultaneously elevated (spec 3.2.2); architectural decomposition is recommended before deployment.
Layer 3 — Public-evidence confidence diagnostic
| Component | Score | Basis |
|---|---|---|
| Pc — Public provenance evidence | 0.20 | Below the minimal anchor. The tool surface of the assessed configuration is partly enumerable (Bash, run_command, package installation, file writes, cloud CLI) and the client software is identifiable, but provenance is exactly what the architecture destroys: the upstream model actually serving a request is unverifiable, the router operator is frequently anonymous, no signed envelope or attestation exists anywhere in the path, and no deployment owner or route approval record is available for the measured sessions. |
| Ec — Public evaluation coverage | 0.37 | coverage 0.39 (9 of 23 applicable sub-metrics) × independence 1.00 × fidelity 0.95. No Full, Standard, or Lite pathway is claimed for a retrospective article. |
| Tf — Public-evidence freshness | 0.24 | Evidence dated 2026-04-09; age 126 days on the workpaper reference date. Components: T_behavior 0.24 · C_event 0.35 · T_containment 0.38 · T_calendar 0.62 · C_monitor 0.65 · C_evidence 0.85. Binding term: T_behavior. dt_days = 126, measured from the paper's disclosure date 2026-04-09 (arXiv 2604.08407) to the assessment date 2026-08-13. agentic = true: an Agentic/MCP deployment whose permission boundary is mutable at runtime — tools are enabled per session, approval mode is toggled, and the route and its credentials can be changed with a one-line edit — so the containment staleness floor applies. baw = true on the closed-feedback-loop item of the applicability checklist: the agent writes state into its own workspace and environment (files, installed dependencies) that it and later steps re-read and act on in the same decision path, so behavioural evidence about what the deployment does goes stale faster than the calendar. C_monitor = 0.65 because the incident is a detection failure by construction — the paper's own framing is that for the passive class 'traffic looks normal until a canary or stolen credential is used downstream', and routed sessions lacked the transparency logging that would have distinguished them. C_event = 0.35 because this is a confirmed compromise event, not merely a change: malicious routers were operating in production with credential theft and ETH theft observed. C_evidence = 0.85 because the identity and tool-origin gaps are open and unresolved — no provider-signed response envelope exists, so no targeted evidence can currently close them. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.26 — diagnostic status: Invalid as assessment-of-record evidence. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.
Indicative ERS — normalized-assurance scenario
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief (retrieved 2026-08-13); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.08.05. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-H-018.004 | Intent-Based Dynamic Capability ScopingParent AID-H-018 (Tool Authorization & Capability Scoping). Both mapped legs are scored here and both are at or near zero: the fail-closed policy gate for Bash, run_command and package installs is the control whose absence sets Cn-6 = 0.00 and holds Cn-1 at 0.25. | Very High | Cn-1 Cn-6 Cn-7 |
| AID-H-018.005 | Value-Level Capability Metadata & Data Flow Sink EnforcementParent mapping is Cn-1/Cn-6 in the 2026.08.05 catalogue. In this case the technique's operational target is the passive exfiltration class scored under Pr-3 = 0.00 — tracking value provenance and blocking secrets from crossing into external sinks — which is recorded here rather than mapped. | Very High | Cn-1 Cn-6 Cn-7 |
| AID-H-033.004 | Route Policy Bundle Versioning, Approval, Canary & RollbackParent AID-H-033 (AI Gateway Routing Integrity & Policy-Preserving Failover) — the closest catalogue match to this incident's core boundary. Five of its six mapped sub-metrics are scored in this case; only Ro-3 is not exercised. | High | Cn-1 Cn-2 Cn-3 Cn-7 Pr-3 Ro-3 Tr-3 |
| AID-H-004.002 | Service & API AuthenticationParent AID-H-004 (Identity, Access & Trusted Communication for AI Systems). Direct evidence for Cn-5 = 0.25: distinct service identity, short-lived audience-bound credentials and exact route binding are the missing controls behind 'a key copied from one relay can authenticate everywhere'. | High | Cn-5 Tr-3 |
| AID-H-025.001 | Pre-Execution Static Analysis & Dangerous Construct BlockingParent AID-H-025 (Unsafe Code Execution Prevention). The deterministic stop before a rewritten payload runs — its absence is the direct basis for Cn-3 = 0.00. | High | Cn-3 |
| AID-I-001.003 | Ephemeral Single-Use Sandboxes for ToolsParent AID-I-001 (AI Execution Sandboxing & Runtime Isolation) maps to Pr-2 in the catalogue; Pr-2 is not evidenced by this incident. The technique's effect here is on the blast radius scored under Cn-1 and on secret exposure scored under Pr-3, recorded rather than mapped. | High | Cn-7 Pr-2 |
| AID-D-003.003 | Agentic Tool Use & Action Policy MonitoringParent AID-D-003 (AI Output Monitoring & Policy-Violation Detection). The Cn-3 leg carries the paper's response-side anomaly screener: inspecting returned tool calls for shell-risk patterns, unusual arguments, secret-like strings and schema deviation before execution. | Medium | Cn-1 Cn-3 Cn-7 Ro-3 |
| AID-D-005.004 | Specialized Agent & Session LoggingParent AID-D-005 (AI Activity Logging, Monitoring & Threat Hunting). Direct evidence for Tr-3 = 0.25 — the specific missing fields are router URL, TLS metadata, request and response hashes, authenticated principal and approval mode. | Medium | Cn-7 Tr-3 |
WHAT THIS CASE TEACHES
The trust boundary that fails here is neither the model nor the tool but the transport intermediary between them, and AITBM localises it precisely — Cn-5 = 0.25 for an unverifiable response origin under API-key-only identity and Cn-6 = 0.00 for ARCR = 0 under auto-approve — a failure that no model-layer sub-metric and no prompt-injection test would have surfaced.
Sources: AIDEFEND in Action brief: Your Agent Is Mine: Malicious LLM API Routers as an Agent Supply-Chain Boundary (2026-04-25) · Liu, Shou, Wen, Chen, Fang and Feng, Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain (arXiv, 2026-04-09)