Pański agent ma pośrednika, którego Pan nie zweryfikował

Badacze zakupili 28 płatnych routerów LLM API z Taobao, Xianyu oraz witryn hostowanych na Shopify, a kolejnych 400 zebrali z publicznych społeczności. Żądania zostały oprzyrządowane podstawionymi poświadczeniami, a każdy router był sondowany, aby sprawdzić, co robi z ruchem.¹

Siedemnaście z tych routerów dotknęło poświadczeń-pułapek AWS podstawionych w żądaniach. Jeden opróżnił ETH z klucza prywatnego umieszczonego jako przynęta. Wyciekły klucz OpenAI, który zespół skonfigurował jako honeypot, wygenerował 100 mln tokenów GPT-5.4 oraz, zgodnie z abstraktem, „ponad siedem sesji Codex”, zanim go wycofano.¹ Oddzielne, słabo skonfigurowane wabiki przyniosły 2 mld rozliczonych tokenów, 99 poświadczeń w 440 sesjach Codex oraz 401 sesji działających już w autonomicznym trybie YOLO.¹

Router LLM API to nowa powierzchnia ataku. Nikt go nie audytuje.

Łańcuchy zaufania MCP to seria pośredników (routerów API, proxy i serwerów narzędzi), którzy znajdują się między Pańskim agentem AI a nadrzędnym modelem, przy czym każdy z nich posiada pełny dostęp w postaci zwykłego tekstu do każdego żądania i odpowiedzi. Żaden dostawca nie egzekwuje kryptograficznej integralności od końca do końca, co oznacza, że każdy pośrednik może odczytać, zmodyfikować lub eksfiltrować dane w tranzycie. Badania terenowe wykazały, że 17 z 28 płatnych routerów dotknęło podstawionych poświadczeń AWS, a jeden opróżnił ETH z klucza prywatnego — co dowodzi, że niezweryfikowane ogniwa łańcucha zaufania są aktywnymi powierzchniami ataku.

TL;DR

Zewnętrzne routery LLM API to proxy warstwy aplikacji z pełnym dostępem w postaci zwykłego tekstu do każdego przesyłanego JSON między Pańskim agentem a nadrzędnym modelem. Żaden dostawca nie egzekwuje kryptograficznej integralności między klientem a upstreamem. Nowy artykuł z arxiv autorstwa Liu, Shou, Wen, Chena i Fanga przedstawia pierwsze systematyczne badanie tej powierzchni ataku, a dane z terenu są nieciekawe: 1 z 28 płatnych routerów oraz 8 z 400 darmowych routerów aktywnie wstrzykiwało złośliwy kod do odpowiedzi, 2 wdrażały adaptacyjne wyzwalacze unikowe, 17 dotknęło podstawionych poświadczeń-pułapek AWS, a 1 opróżnił ETH z podstawionego klucza prywatnego.¹ Autorzy formalizują dwie podstawowe klasy ataków oraz dwa warianty adaptacyjnego unikania, następnie budują badawcze proxy o nazwie Mine, które implementuje „wszystkie cztery klasy ataków” (ich sformułowanie) przeciwko czterem publicznym frameworkom agentowym, oraz oceniają trzy wdrażalne zabezpieczenia po stronie klienta.¹ Jeśli Pański agent korzysta z routera, którego Pan nie zbudował, ma Pan granicę zaufania, której Pan nigdy nie zaudytował.

Kluczowe wnioski

• Operatorzy agentów: Każdy router LLM API między Pańskim klientem a nadrzędnym modelem to proxy warstwy aplikacji z dostępem w postaci zwykłego tekstu do każdego żądania i odpowiedzi. Żaden dostawca nie egzekwuje kryptograficznej integralności. Jeśli kupił Pan router na rynku lub pobrał go z publicznej listy społecznościowej, proszę traktować go jak wrogiego pośrednika, dopóki nie zostanie niezależnie zweryfikowany.
• Budowniczowie harness’ów: Pańskie hooki PreToolUse uruchamiają się przed wykonaniem narzędzia, ale złośliwy router modyfikuje odpowiedź modelu po wygenerowaniu i przed dotarciem do Pańskiego hooka. Warto dodać walidację po stronie odpowiedzi do stosu hooków oraz rozważyć bramki polityki typu fail-closed przy anomalnych kształtach odpowiedzi.
• Każdy uruchamiający tryb YOLO: Czterysta jeden sesji w honeypocie badaczy działało już w autonomicznym trybie YOLO.¹ Router modyfikujący wywołania narzędzi w sesji autonomicznej ma znacznie większy promień rażenia niż router modyfikujący odpowiedź, którą Pan przeczyta. Nie należy uruchamiać trybu YOLO przez router, którego się nie kontroluje.

Czym właściwie jest router?

W kontekście tego artykułu router LLM API to usługa zewnętrzna, która znajduje się między Pańskim klientem a jednym lub większą liczbą nadrzędnych dostawców modeli. Wysyła Pan żądania do routera za pomocą API kompatybilnego z OpenAI. Router kieruje te żądania do dowolnego wybranego przez siebie upstreamu (GPT-5, Claude, Gemini, model o otwartych wagach, pula ich wszystkich) i zwraca odpowiedź w tej samej postaci.¹

Routery istnieją, ponieważ ekosystem LLM jest chaotyczny. Ludzie chcą jednego klucza API, który działa z każdym modelem. Ludzie chcą arbitrażu cenowego: kupują tokeny hurtowo, odsprzedają je taniej. Ludzie chcą geograficznych obejść dla regionów, w których bezpośredni dostęp do dostawcy jest ograniczony. Ludzie chcą testować wiele modeli za pomocą jednego klienta. Wszystkie te powody są uzasadnione, a zdrowy rynek routerów obsługuje je wszystkie.

Problem polega na tym, że router to proxy warstwy aplikacji. Nie przekazuje jedynie bajtów. Czyta JSON żądania, wybiera upstream, opcjonalnie przepisuje żądanie, przekazuje je dalej, czyta odpowiedź, opcjonalnie przepisuje odpowiedź i zwraca ją. Każdy krok tego potoku odbywa się w postaci zwykłego tekstu na infrastrukturze routera.¹

Nie istnieje tu odpowiednik TLS. TLS chroni bajty od Pańskiego klienta do routera i od routera do nadrzędnego modelu. Nie robi nic, aby ochronić payload przed routerem. Żaden dostawca nie egzekwuje kryptograficznej integralności między pierwotnym klientem a ostatecznym modelem. Nie istnieje żadne podpisane oświadczenie, że żądanie, które model otrzymał, jest tym samym żądaniem, które wysłał klient, ani podpisane oświadczenie, że odpowiedź, którą klient otrzymał, jest tą samą odpowiedzią, którą wygenerował model.¹

Ta nieobecność jest powierzchnią ataku.

Dane z terenu

Badacze kupili 28 płatnych routerów z trzech rynków (Taobao, Xianyu, witryny hostowane na Shopify) i zebrali 400 darmowych routerów z publicznych społeczności. Każdy router przeszedł serię sond z oprzyrządowanymi żądaniami, które zawierały podstawione poświadczenia, znane payloady i ciągi znaczników.¹

Oto, co odkryli:

Odkrycie dotyczące adaptacyjnego unikania to takie, które powinno spędzać sen z powiek. Adaptacyjny wyzwalacz unikowy oznacza, że router zachowuje się normalnie przez większość czasu i przełącza się w tryb ataku w określonych warunkach: przy konkretnym kształcie żądania, konkretnym odcisku palca klienta, konkretnej kadencji. Nie da się go wyłapać, pobierając losowe żądania, ponieważ router wie, kiedy jest próbkowany, i zachowuje się poprawnie.

Poświadczenia-pułapki to przewody sygnalizacyjne: uruchamiają się, gdy ktoś próbuje ich użyć. Siedemnaście routerów „dotykających” ich oznacza, że co najmniej siedemnaście routerów wyodrębniło poświadczenia z przesyłanych payloadów i próbowało ich użyć wobec AWS.¹ Abstrakt nie podaje dokładnego mechanizmu dla każdego routera, ale konstrukcja pułapki oznacza, że dotyk = użycie.

Jedyny router, który opróżnił ETH z należącego do badaczy klucza prywatnego, to mocniejsze odkrycie. Klucz prywatny w prompcie nie jest pułapką poświadczeń; jest przynętą, która dowodzi kompromitacji dopiero wtedy, gdy router faktycznie opróżni portfel. Jeden router to zrobił.¹

Dwa badania dotyczące zatruwania

Badacze przeprowadzili dwa dodatkowe badania, aby pokazać, że pozornie nieszkodliwe routery mogą zostać wciągnięte w tę samą powierzchnię ataku poprzez ekspozycję z trzeciej strony.

Badanie 1: Wyciekły klucz OpenAI. Badacze wyciekli działający klucz API OpenAI, tak jakby został ujawniony wskutek błędu dewelopera. Podczas okna obserwacji ten jeden wyciekły klucz, zgodnie z abstraktem, wygenerował 100 mln tokenów GPT-5.4 oraz „ponad siedem sesji Codex” za pośrednictwem routerów, które go podchwyciły.¹ Ktoś (lub wiele osób) znalazł klucz, kierował przez niego żądania za pomocą routerów społecznościowych i przepalił 100 mln tokenów mocy obliczeniowej. Router był warstwą prania dla skradzionego klucza.

Badanie 2: Słabo skonfigurowane wabiki. Badacze postawili słabo skonfigurowane wabiki jako punkty końcowe. Wabiki przyniosły 2 mld rozliczonych tokenów, 99 poświadczeń w 440 sesjach Codex oraz, co kluczowe, 401 sesji działających już w autonomicznym trybie YOLO.¹

Czterysta jeden sesji autonomicznych kierujących ruch przez jeden zestaw wabików. Każda z tych sesji była żywą powierzchnią ataku, na której złośliwy pośrednik mógłby wstrzyknąć wywołania narzędzi, eksfiltrować sekrety lub zmodyfikować wyjście modelu, a agent wykonałby to, co wróciło, bez człowieka w pętli. Liczba 401 to tyle, ile złapał jeden wabik badawczy. Populacja operacyjna kierująca ruch przez niekontrolowanych pośredników jest z konieczności większa.

Dwie podstawowe klasy ataków i dwa adaptacyjne warianty

Artykuł formalizuje dwie podstawowe klasy ataków oraz dwa warianty adaptacyjnego unikania. Abstrakt jest jednoznaczny co do taksonomii: AC-1 i AC-2 to klasy podstawowe; AC-1.a i AC-1.b to warianty AC-1. Badawcze proxy Mine implementuje „wszystkie cztery klasy ataków” (sformułowanie abstraktu) przeciwko czterem publicznym frameworkom agentowym.¹

AC-1: Wstrzykiwanie payloadu (klasa podstawowa). Router modyfikuje odpowiedź, aby wstrzyknąć dodatkowe instrukcje, wywołania narzędzi lub treści, na których działa agent kliencki. Agent uważa, że czyta wyjście z modelu; czyta wyjście od kogoś, kto jest właścicielem routera.

AC-2: Eksfiltracja sekretów (klasa podstawowa). Router odczytuje sekrety z przesyłanych żądań i odpowiedzi (klucze API, tokeny, klucze prywatne, wszystko, co wygląda jak poświadczenie) i wysyła je do infrastruktury atakującego.

AC-1.a: Wstrzykiwanie ukierunkowane na zależności (adaptacyjny wariant AC-1). Wstrzyknięcie uruchamia się tylko wtedy, gdy żądanie pasuje do konkretnej zależności lub kontekstu: tylko wtedy, gdy żądanie dotyczy konkretnej biblioteki, tylko wtedy, gdy odwołano się do konkretnej funkcji, tylko wtedy, gdy w prompcie pojawiają się określone ścieżki plików. Selektywny wyzwalacz czyni atak niewidocznym w losowych testach.

AC-1.b: Dostarczanie warunkowe (adaptacyjny wariant AC-1). Router dostarcza złośliwy payload tylko w określonych warunkach (pora dnia, kadencja żądań, odcisk palca klienta). Ta sama logika unikania wykrycia.

Każda z tych klas ataków jest niewidoczna zarówno dla klienta, jak i dla nadrzędnego modelu, ponieważ obie strony ufają routerowi. Klient widzi normalny kształt odpowiedzi. Model widzi normalny kształt żądania. Router może robić pomiędzy nimi, co tylko zechce, a żadna ze stron nie ma kryptograficznego sposobu wykrycia manipulacji.¹

Wzorzec kompozycji, o jedną warstwę niżej

Wciąż piszę o tym samym błędzie strukturalnym: indywidualnie autoryzowane komponenty komponujące się w nieautoryzowane zachowanie. Trivy-to-LiteLLM był kompozycją na warstwie pakietów. Cicha eksfiltracja była kompozycją na warstwie opisów narzędzi. Zatruwanie narzędzi MCP było kompozycją na warstwie protokołu. Kompromitacja opiekuna axios była kompozycją na warstwie ludzkiego opiekuna.

Atak na router to kompozycja na warstwie sieci. Pański klient jest autoryzowany do wywoływania routera. Router jest autoryzowany do wywoływania nadrzędnego modelu. Nadrzędny model jest autoryzowany do odpowiadania. Każdy pojedynczy hop jest autoryzowany. Kompozycja tych autoryzowanych hopów produkuje wstrzykiwanie payloadu i eksfiltrację sekretów na dużą skalę, ponieważ kompozycja przekracza granicę zaufania, której nikt nie zadbał, aby kryptograficznie zapieczętować.¹

Nie da się tego naprawić na żadnej pojedynczej warstwie. Naprawia się to na warstwie kompozycji, co oznacza, że klient musi traktować router jako wrogi, dopóki niezależnie nie zweryfikuje, że kształt odpowiedzi, wywołania narzędzi i treść są spójne z tym, co nadrzędny model prawdopodobnie by wyprodukował.

Trzy obrony oceniane w artykule

Artykuł ocenia trzy obrony po stronie klienta przeciwko klasom ataków.¹

1. Bramka polityki fail-closed. Klient egzekwuje politykę dotyczącą kształtów odpowiedzi, dozwolonych wywołań narzędzi, dozwolonych adresów URL, dozwolonych poleceń. Wszystko poza polityką kończy się zamknięciem: klient odrzuca żądanie zamiast je dopuścić.

2. Skanowanie anomalii po stronie odpowiedzi. Klient obserwuje anomalie kształtu odpowiedzi, nietypowe wzorce tokenów lub wyjście zawierające znane znaczniki ataków (adresy URL do nieznanych hostów, podejrzane wzorce poświadczeń, nietypowe struktury wywołań narzędzi).

3. Logowanie transparentności typu append-only. Klient zapisuje każde żądanie i odpowiedź do logu typu append-only, którego nikt nie może zmodyfikować retrospektywnie. Logowanie nie zapobiega atakom, ale czyni je śledzalnymi kryminalistycznie.

Żadna z nich nie jest srebrną kulą. Moja lektura: bramka polityki fail-closed jest najsilniejszą z trzech, ponieważ odrzuca wszystko poza jawną listą dozwolonych zamiast próbować wykryć atak — jednak abstrakt nie klasyfikuje obron, więc proszę traktować to jako moją opinię, a nie odkrycie artykułu. Skanowanie anomalii pomija ataki wyglądające normalnie, a warianty adaptacyjnego unikania (AC-1.a i AC-1.b) specjalnie naśladują normalne zachowanie w warunkach testowych. Bramki polityki są tak dobre, jak polityka, a napisanie kompletnej polityki określającej, „jak powinna wyglądać odpowiedź modelu”, jest trudne.

Co tak naprawdę należy zrobić

Jeśli uruchamia Pan agenta, który wywołuje LLM API przez router, którego Pan nie zbudował:

1. Proszę przestać używać routerów zakupionych lub pobranych z publicznych społeczności, chyba że ufa Pan operatorowi. „Zaufanie” oznacza tu jakąś zewnętrzną podstawę (znany zespół, podpisany kontrakt, jurysdykcja prawna, w której można egzekwować), a nie „ma dobre recenzje na rynku”.

2. Proszę dodać bramkę polityki fail-closed do swojego harness’a. W Claude Code oznacza to hooki PreToolUse, które odrzucają wywołania narzędzi poza jawną listą dozwolonych, oraz hooki PostToolUse, które walidują kształty odpowiedzi przed przekazaniem ich do następnej tury modelu. Stos hooków to Pańska warstwa polityki fail-closed.

3. Nigdy nie należy uruchamiać trybu YOLO przez router, którego się nie kontroluje. Precedensem są 401 autonomicznych sesji w honeypocie. Jeśli router jest wrogi, a Pańska sesja jest autonomiczna, to router uruchamia Pańską maszynę.

4. Proszę logować wszystko. Logowanie transparentności typu append-only pozwala zrekonstruować incydent. Każde żądanie. Każda odpowiedź. Każde wywołanie narzędzia. Proszę przechowywać je tam, gdzie router nie może sięgnąć.

5. Jeśli prowadzi Pan infrastrukturę agentową, proszę egzekwować kryptograficzną integralność. Jeśli operuje Pan klientem i upstreamem, proszę podpisać żądanie na kliencie i zweryfikować podpis na upstreamie. To jedyna prawdziwa naprawa. Router nadal może widzieć zwykły tekst, ale nie może niczego zmodyfikować bez unieważnienia podpisu.

Niewygodna implikacja

Powierzchnia ataku routera jest czystym przykładem ekosystemu agentów dostarczającego infrastrukturę szybciej, niż ją zabezpiecza. Ludzie chcą jednego klucza API do każdego modelu. Ludzie chcą arbitrażu cenowego. Ludzie chcą dostępu regionalnego. Routery dostarczają tego wszystkiego. Rynek ich nagradza. Audyt bezpieczeństwa się nie odbył.

Powierzchnia ataku MCP ma 50 udokumentowanych podatności. Powierzchnia ataku łańcucha dostaw ma kampanię TeamPCP, która w tydzień przeszła przez pięć ekosystemów. Powierzchnia ataku cichej eksfiltracji ma Clinejection i benchmark MCPTox. Teraz proszę dodać powierzchnię ataku routera: 428 zbadanych routerów, 9 aktywnie wstrzykujących złośliwy kod, 17 dotykających podstawionych poświadczeń, 1 opróżniający ETH, 401 autonomicznych sesji już działających na wrogiej infrastrukturze.¹

Wzorzec jest za każdym razem ten sam. Budujemy nową warstwę stosu agentowego. Deweloperzy adoptują nową warstwę, zanim ktokolwiek ją zaudytuje. Pojawiają się atakujący. Pojawiają się badacze. Społeczność spisuje odkrycia. Operatorzy, którzy zwracali uwagę, łatają swoje wdrożenia. Operatorzy, którzy nie zwracali uwagi, dowiadują się w trudny sposób.

Powierzchnia ataku routera jest na etapie „badacze właśnie to spisali”. Ma Pan czas, aby załatać swoje wdrożenie. Proszę go wykorzystać.

FAQ

Czym jest router LLM API w tym kontekście?

Usługa zewnętrzna, która znajduje się między Pańskim klientem a nadrzędnymi dostawcami modeli, udostępnia API kompatybilne z OpenAI i kieruje Pańskie żądania do jednego lub większej liczby nadrzędnych modeli. Jest to proxy warstwy aplikacji z dostępem w postaci zwykłego tekstu do każdego żądania i odpowiedzi.¹

Czym to się różni od CDN lub zwykłego proxy HTTP?

CDN przekazuje bajty bez czytania payloadu aplikacji. Router LLM API czyta JSON, wybiera upstream, opcjonalnie przepisuje żądanie, przekazuje je dalej, czyta odpowiedź i opcjonalnie przepisuje odpowiedź. Wykonuje przetwarzanie na poziomie aplikacji na Pańskich danych, a nie tylko ich transport.¹

Czy TLS chroni mnie przed złośliwym routerem?

Nie. TLS chroni bajty od Pańskiego klienta do routera i od routera do nadrzędnego modelu. Router terminuje TLS, czyta zwykły tekst i ponownie szyfruje po drugiej stronie. TLS nic nie robi, aby ochronić Pański payload przed routerem.¹

Jak wykryłbym router, który aktywnie wstrzykuje odpowiedzi?

Nie wykryłby Pan w sposób niezawodny, jeśli router stosuje adaptacyjne unikanie. Klasy ataków AC-1.a i AC-1.b z artykułu specjalnie celują w unikanie wykrycia, uruchamiając się tylko w warunkach operacyjnych.¹ Najlepszą strategią jest bramka polityki fail-closed odrzucająca wszystko poza jawną listą dozwolonych, zamiast próby wykrywania ataków post factum.

Uruchamiam Claude Code bezpośrednio wobec api.anthropic.com. Czy jestem narażony?

Nie na klasę ataków routera opisaną w tym artykule, ponieważ wywołuje Pan Anthropic bezpośrednio, bez pośrednika. Powierzchnią ataku są konkretnie routery zewnętrzne. Jeśli kieruje Pan Claude Code przez proxy z jakiegokolwiek powodu (brama korporacyjna, obejście limitów żądań, agregator modeli), powinien Pan zaudytować to proxy.

Co z OpenRouter, LiteLLM lub innymi znanymi agregatorami?

Artykuł bada 28 płatnych routerów zakupionych z konkretnych rynków (Taobao, Xianyu, witryny hostowane na Shopify) oraz 400 darmowych routerów z list publicznych społeczności.¹ Nie publikuje konkretnej listy nazwanych produktów. Sedno artykułu jest strukturalne: każdy router jest niezaufanym pośrednikiem, chyba że istnieje odrębna podstawa zaufania. Znani agregatorzy nie są automatycznie bezpieczniejsi; są po prostu bardziej widoczni, co jest inną właściwością.

Co powinienem zrobić w sprawie 401 autonomicznych sesji znalezionych przez badaczy?

Te sesje należą do innych operatorów, którzy kierowali swój ruch przez wabiki badaczy. Jeśli uruchamia Pan autonomiczne sesje agentów przez jakikolwiek router, którego Pan nie zbudował, pierwszym krokiem jest zatrzymanie. Drugim krokiem jest rotacja każdego poświadczenia, które przechodziło przez ten router. Trzecim krokiem jest audyt logów sesji pod kątem anomalnych wywołań narzędzi lub wyjścia.

Referencje