Twój agent ma pośrednika, którego nie zweryfikowałeś

Badacze kupili 28 płatnych routerów LLM API z Taobao, Xianyu oraz sklepów hostowanych na Shopify, a także zebrali 400 kolejnych ze społeczności publicznych. Oprzyrządowali żądania podstawionymi poświadczeniami i badali każdy router, aby sprawdzić, co robi z ruchem.¹

Siedemnaście z tych routerów sięgnęło po poświadczenia-pułapki AWS umieszczone w żądaniach. Jeden opróżnił portfel ETH z klucza prywatnego podłożonego jako przynęta. Wyciekły klucz OpenAI, przygotowany przez zespół jako honeypot, wygenerował 100 mln tokenów GPT-5.4 oraz — zgodnie z abstraktem — „ponad siedem sesji Codex”, zanim został wycofany.¹ Osobne, słabo skonfigurowane przynęty przyniosły 2 mld rozliczonych tokenów, 99 poświadczeń w 440 sesjach Codex oraz 401 sesji już działających w autonomicznym trybie YOLO.¹

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

TL;DR

Zewnętrzne routery LLM API są proxy warstwy aplikacji z pełnym dostępem w postaci jawnej do każdego JSON przesyłanego między agentem a modelem źródłowym. Żaden dostawca nie wymusza integralności kryptograficznej między klientem a modelem źródłowym. Nowy artykuł z arxiv autorstwa Liu, Shou, Wen, Chen i Fang przedstawia pierwsze systematyczne badanie tej powierzchni ataku, a dane z terenu są niepokojące: 1 z 28 płatnych routerów i 8 z 400 darmowych routerów aktywnie wstrzykiwało złośliwy kod do odpowiedzi, 2 wdrażały adaptacyjne wyzwalacze unikania detekcji, 17 sięgnęło po podstawione poświadczenia-pułapki AWS, a 1 opróżnił portfel ETH z podłożonego klucza prywatnego.¹ Autorzy formalizują dwie podstawowe klasy ataków oraz dwa warianty adaptacyjnego unikania detekcji, a następnie budują badawcze proxy o nazwie Mine, które implementuje „wszystkie cztery klasy ataków” (ich sformułowanie) przeciwko czterem publicznym frameworkom agentowym, i oceniają trzy możliwe do wdrożenia mechanizmy obronne po stronie klienta.¹ Jeśli agent korzysta z routera, którego nie zbudowałeś samodzielnie, masz granicę zaufania, której nigdy nie poddałeś audytowi.

Najważniejsze wnioski

• Operatorzy agentów: Każdy router LLM API między klientem a modelem źródłowym to proxy warstwy aplikacji z dostępem w postaci jawnej do każdego żądania i odpowiedzi. Integralność kryptograficzna nie jest wymuszana. Jeśli korzystasz z routera kupionego na marketplace lub pobranego z publicznej listy społecznościowej, należy traktować go jako wrogiego pośrednika, dopóki nie udowodnisz inaczej.
• Twórcy harnessów: Twoje hooki PreToolUse wykonują się przed uruchomieniem narzędzia, ale złośliwy router modyfikuje odpowiedź modelu po jej wygenerowaniu, a przed dotarciem do hooka. Warto dodać walidację po stronie odpowiedzi do stosu hooków i rozważyć bramki polityki fail-closed dla anomalnych kształtów odpowiedzi.
• Każdy korzystający z trybu 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 zasięg rażenia niż router modyfikujący odpowiedź, którą i tak przeczytasz. Nie należy uruchamiać trybu YOLO przez router, którego nie kontrolujesz.

Czym właściwie jest router?

W kontekście tego artykułu router LLM API to usługa zewnętrzna, która umieszcza się między klientem a jednym lub wieloma źródłowymi dostawcami modeli. Żądania wysyłasz do routera, używając API zgodnego z OpenAI. Router kieruje te żądania do dowolnego wybranego źródła — GPT-5, Claude, Gemini, modelu open-weights, puli wszystkich naraz — i zwraca odpowiedź w tym samym kształcie.¹

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 i odsprzedają taniej. Ludzie chcą obejść ograniczenia geograficzne w regionach, gdzie bezpośredni dostęp do dostawcy jest zablokowany. Ludzie chcą testować wiele modeli z 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 po prostu bajtów. Odczytuje JSON żądania, wybiera źródło, opcjonalnie przepisuje żądanie, przekazuje je dalej, odczytuje odpowiedź, opcjonalnie przepisuje odpowiedź i ją zwraca. Każdy krok tego potoku odbywa się w postaci jawnej na infrastrukturze routera.¹

Nie istnieje tu odpowiednik TLS. TLS chroni bajty od klienta do routera i od routera do modelu źródłowego. Nie robi nic, aby chronić payload przed samym routerem. Żaden dostawca nie wymusza integralności kryptograficznej między pierwotnym klientem a ostatecznym modelem — nie ma podpisanej asercji, że żądanie, które otrzymał model, jest tym samym żądaniem, które wysłał klient, ani podpisanej asercji, że odpowiedź otrzymana przez klienta 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 marketplace’ów (Taobao, Xianyu, sklepy hostowane na Shopify) i zebrali 400 darmowych routerów ze społeczności publicznych. Każdy router przepuścili przez serię prób z oprzyrządowanymi żądaniami zawierającymi podstawione poświadczenia, znane payloady i łańcuchy znacznikowe.¹

Oto, co znaleźli:

To odkrycie adaptacyjnego unikania detekcji powinno spędzać sen z powiek. Adaptacyjny wyzwalacz unikania oznacza, że router zachowuje się normalnie przez większość czasu i przechodzi w tryb ataku pod specyficznymi warunkami — przy określonym kształcie żądania, konkretnym odcisku klienta, określonej kadencji. Nie wychwycisz go próbkowaniem losowych żądań, ponieważ router wie, kiedy jest próbkowany, i zachowuje się grzecznie.

Poświadczenia-pułapki to zasadzki: uruchamiają się, gdy ktoś spróbuje z nich skorzystać. Siedemnaście routerów „sięgających” po nie oznacza, że co najmniej siedemnaście routerów wyekstrahowało poświadczenia z przesyłanych payloadów i próbowało użyć ich przeciwko AWS.¹ Abstrakt nie precyzuje dokładnego mechanizmu dla każdego routera, ale zasada pułapki oznacza: dotknięcie = użycie.

Jeden router, który opróżnił portfel ETH z klucza prywatnego należącego do badaczy, to jeszcze mocniejsze odkrycie. Klucz prywatny w prompcie nie jest zasadzką poświadczeń — to przynęta, która dostarcza dowodu kompromitacji tylko wtedy, gdy router faktycznie opróżni portfel. Jeden router to zrobił.¹

Dwa badania zatruwania

Badacze przeprowadzili dwa dodatkowe badania, aby pokazać, że pozornie łagodne routery mogą zostać wciągnięte w tę samą powierzchnię ataku poprzez ekspozycję osób trzecich.

Badanie 1: Wyciekły klucz OpenAI. Badacze upublicznili działający klucz API OpenAI, jakby został ujawniony przez błąd dewelopera. W okresie obserwacji ten jeden wyciekły klucz — zgodnie z abstraktem — wygenerował 100 mln tokenów GPT-5.4 i „ponad siedem sesji Codex” przez routery, które go podjęły.¹ Ktoś — albo wiele osób — znalazł klucz, skierował żądania przez społecznościowe routery, używając go, i spalił 100 mln tokenów obliczeń. Router był warstwą prania skradzionego klucza.

Badanie 2: Słabo skonfigurowane przynęty. Badacze postawili słabo skonfigurowane endpointy-przynęty. Przynęty przyniosły 2 mld rozliczonych tokenów, 99 poświadczeń w 440 sesjach Codex oraz — i to jest kluczowa linia — 401 sesji już działających w autonomicznym trybie YOLO.¹

Czterysta jeden autonomicznych sesji już kierowanych przez jeden zestaw przynęt. Każda z tych sesji była żywą powierzchnią ataku, gdzie złośliwy pośrednik mógł wstrzyknąć wywołania narzędzi, wyekstrahować sekrety lub zmodyfikować wyjście modelu, a agent wykonałby to, co otrzymał, bez człowieka w pętli. Liczba 401 to tyle, ile złapała jedna badawcza przynęta — operacyjna populacja kierowana przez niekontrolowanych pośredników jest z konieczności większa.

Dwie podstawowe klasy ataków i dwa warianty adaptacyjne

Artykuł formalizuje dwie podstawowe klasy ataków i dwa warianty adaptacyjnego unikania detekcji. 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: Wstrzyknięcie payloadu (klasa podstawowa). Router modyfikuje odpowiedź, aby wstrzyknąć dodatkowe instrukcje, wywołania narzędzi lub treść, na podstawie których agent klienta działa. Agent myśli, że czyta wyjście z modelu; czyta wyjście od właściciela 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 na poświadczenie — i wysyła je do infrastruktury atakującego.

AC-1.a: Wstrzyknięcie ukierunkowane na zależność (wariant adaptacyjny AC-1). Wstrzyknięcie uruchamia się tylko wtedy, gdy żądanie pasuje do konkretnej zależności lub kontekstu — na przykład tylko wtedy, gdy żądanie dotyczy określonej biblioteki, gdy przywoływana jest konkretna funkcja lub gdy w prompcie pojawiają się pewne ścieżki plików. To sprawia, że atak jest niewidoczny w losowych testach.

AC-1.b: Dostawa warunkowa (wariant adaptacyjny AC-1). Złośliwy payload jest dostarczany pod określonymi warunkami (pora dnia, kadencja żądań, odcisk klienta). Ta sama logika unikania detekcji.

Każda z tych klas ataków jest niewidoczna dla klienta i dla modelu źródłowego, ponieważ oba końce ufają routerowi. Klient widzi normalny kształt odpowiedzi. Model widzi normalny kształt żądania. Router ma swobodę robić pośrodku, co chce, a żadna ze stron nie ma kryptograficznego sposobu wykrycia manipulacji.¹

Wzorzec kompozycji, o warstwę niżej

Wciąż piszę o tym samym strukturalnym błędzie: indywidualnie autoryzowane komponenty składają się w nieautoryzowane zachowanie. Trivy-do-LiteLLM to była kompozycja na warstwie pakietu. Cichy wyciek to była kompozycja na warstwie opisu narzędzia. Zatruwanie narzędzi MCP to była kompozycja na warstwie protokołu. Kompromitacja maintainera axios to była kompozycja na warstwie ludzkiego maintainera.

Atak na router to kompozycja na warstwie sieci. Klient ma uprawnienie do wywołania routera. Router ma uprawnienie do wywołania modelu źródłowego. Model źródłowy ma uprawnienie do odpowiedzi. Każdy pojedynczy skok jest autoryzowany. Kompozycja tych autoryzowanych skoków produkuje wstrzyknięcie payloadu i eksfiltrację sekretów na dużą skalę, ponieważ kompozycja przekracza granicę zaufania, której nikt nie zadbał, aby kryptograficznie zapieczętować.¹

Nie można tego naprawić na żadnej pojedynczej warstwie. Naprawia się to na warstwie kompozycji, co oznacza, że klient musi traktować router jako wrogiego, dopóki niezależnie nie zweryfikuje, że kształt odpowiedzi, wywołania narzędzi i treść są wszystkie spójne z czymś, co model źródłowy prawdopodobnie by wyprodukował.

Trzy mechanizmy obronne oceniane w artykule

Artykuł ocenia trzy mechanizmy obronne po stronie klienta przeciwko tym klasom ataków.¹

1. Bramka polityki fail-closed. Klient wymusza politykę na kształtach odpowiedzi, dozwolonych wywołaniach narzędzi, dozwolonych URL-ach, dozwolonych poleceniach. Wszystko poza polityką zawodzi zamknięciem — żądanie jest odrzucane zamiast dopuszczone.

2. Skanowanie anomalii po stronie odpowiedzi. Klient obserwuje anomalie kształtu odpowiedzi, nietypowe wzorce tokenów lub wyjście zawierające znane znaczniki ataku (URL-e 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 append-only, którego nie można zmodyfikować wstecznie. Nie zapobiega to atakom, ale sprawia, że są one śledzalne kryminalistycznie.

Żaden z nich nie jest srebrną kulą. Moja ocena: bramka polityki fail-closed jest najmocniejsza z trzech, ponieważ nie polega na wykrywaniu ataku — odrzuca wszystko poza jawną listą dozwolonych — ale abstrakt nie szereguje mechanizmów obronnych, więc należy traktować to jako moją opinię, a nie wniosek z artykułu. Skanowanie anomalii przepuszcza ataki, które wyglądają normalnie, a warianty adaptacyjnego unikania detekcji (AC-1.a i AC-1.b) są zaprojektowane specjalnie po to, aby wyglądać normalnie w warunkach testowych. Bramki polityki są tak dobre, jak ich polityka, a napisanie kompletnej polityki dla „jak powinna wyglądać odpowiedź modelu” jest trudne.

Co należy właściwie zrobić

Jeśli prowadzisz agenta, który wywołuje LLM API przez router, którego nie zbudowałeś samodzielnie:

1. Należy przestać używać routerów kupionych lub pobranych ze społeczności publicznych, chyba że ufasz operatorowi. „Zaufanie” oznacza tu, że masz zewnętrzną podstawę — znany zespół, podpisaną umowę, jurysdykcję prawną, wobec której możesz dochodzić roszczeń — a nie „ma dobre opinie na marketplace”.

2. Warto dodać bramkę polityki fail-closed do swojego harnessa. W Claude Code oznacza to hooki PreToolUse, które odrzucają wywołania narzędzi spoza jawnej listy dozwolonych, oraz hooki PostToolUse, które walidują kształty odpowiedzi przed przekazaniem ich do następnej tury modelu. Stos hooków to warstwa polityki fail-closed.

3. Nigdy nie uruchamiać trybu YOLO przez router, którego nie kontrolujesz. Prezentowane 401 autonomicznych sesji w honeypocie to precedens. Jeśli router jest wrogi, a sesja autonomiczna, to router prowadzi twoją maszynę.

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

5. Jeśli prowadzisz infrastrukturę agentową, wymuszaj integralność kryptograficzną. Jeśli operujesz klientem i operujesz źródłem, podpisuj żądanie po stronie klienta i weryfikuj podpis po stronie źródła. To jedyna realna naprawa. Router nadal widzi tekst jawny, ale nie może niczego zmodyfikować bez unieważnienia podpisu.

Niewygodna implikacja

Powierzchnia ataku routera to czysty przykład ekosystemu agentowego wysyłającego infrastrukturę szybciej, niż ją zabezpiecza. Ludzie chcą jednego klucza API dla każdego modelu. Ludzie chcą arbitrażu cenowego. Ludzie chcą dostępu regionalnego. Routery dostarczają wszystko to. 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 ciągu tygodnia przeszła przez pięć ekosystemów. Powierzchnia cichego wycieku ma Clinejection i benchmark MCPTox. Teraz dochodzi powierzchnia ataku routera: 428 przebadanych routerów, 9 aktywnie wstrzykujących złośliwy kod, 17 sięgających po podstawione poświadczenia, 1 opróżniający portfel ETH, 401 autonomicznych sesji już działających na wrogiej infrastrukturze.¹

Wzorzec jest za każdym razem ten sam. Budujemy nową warstwę stosu agentowego. Nowa warstwa zostaje zaadaptowana, zanim zostanie poddana audytowi. Pojawiają się atakujący. Pojawiają się badacze. Społeczność spisuje wnioski. Operatorzy, którzy byli uważni, łatają swoje wdrożenia. Operatorzy, którzy nie byli uważni, dowiadują się o tym w bolesny sposób.

Powierzchnia ataku routera jest na etapie „badacze właśnie ją spisali”. Masz jeszcze moment, aby załatać swoje wdrożenie. Należy go wykorzystać.

FAQ

Czym jest router LLM API w tym kontekście?

Usługa zewnętrzna, która umieszcza się między klientem a źródłowymi dostawcami modeli, udostępnia API zgodne z OpenAI i kieruje żądania do jednego lub wielu modeli źródłowych. To proxy warstwy aplikacji z dostępem w postaci jawnej do każdego żądania i każdej odpowiedzi.¹

Dlaczego to coś innego niż CDN lub zwykłe proxy HTTP?

CDN przekazuje bajty bez odczytywania payloadu aplikacyjnego. Router LLM API odczytuje JSON, wybiera źródło, opcjonalnie przepisuje żądanie, przekazuje je dalej, odczytuje odpowiedź i opcjonalnie ją przepisuje. Wykonuje przetwarzanie na poziomie aplikacji na twoich danych, nie tylko transport.¹

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

Nie. TLS chroni bajty od klienta do routera i od routera do modelu źródłowego. Router kończy TLS, odczytuje tekst jawny i ponownie szyfruje po drugiej stronie. TLS nie robi nic, aby chronić payload przed samym routerem.¹

Jak mogę wykryć router, który aktywnie wstrzykuje odpowiedzi?

Nie wykryjesz, w sposób niezawodny, jeśli router używa adaptacyjnego unikania. Klasy ataków AC-1.a i AC-1.b z artykułu celują specjalnie w unikanie detekcji, uruchamiając się tylko w warunkach operacyjnych.¹ Najlepszym wyborem jest bramka polityki fail-closed — odrzucająca wszystko poza jawną listą dozwolonych — zamiast próby wykrycia ataków post factum.

Uruchamiam Claude Code bezpośrednio przeciwko api.anthropic.com. Czy mnie to dotyczy?

Nie, nie w kontekście klasy ataku na router opisanej w tym artykule, ponieważ wywołujesz Anthropic bezpośrednio bez pośrednika. Powierzchnia ataku dotyczy specyficznie zewnętrznych routerów. Jeśli kierujesz Claude Code przez proxy z dowolnego powodu — korporacyjna bramka, obejście limitów, agregator modeli — warto przeprowadzić audyt tego proxy.

A co z OpenRouter, LiteLLM lub innymi znanymi agregatorami?

Artykuł bada 28 płatnych routerów kupionych z konkretnych marketplace’ów (Taobao, Xianyu, sklepy hostowane na Shopify) i 400 darmowych routerów z publicznych list społecznościowych.¹ Nie publikuje konkretnej listy nazwanych produktów. Sens artykułu jest strukturalny: każdy router jest niezaufanym pośrednikiem, dopóki nie masz odrębnej podstawy do zaufania. Znani agregatorzy nie są automatycznie bezpieczniejsi — są po prostu bardziej widoczni, co jest inną właściwością.

Co należy zrobić z 401 autonomicznymi sesjami, które znaleźli badacze?

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

Bibliografia