Agenci AI wykazali podatność na ataki na routery

Zagrożenie krytyczne w łańcuchu agentów AI: routery

Routery (pośrednicy API), które łączą lokalne aplikacje agenta z chmurowymi modelami AI, stanowią mało znany, ale niezwykle niebezpieczny punkt ataku. Badacze z Uniwersytetu Kalifornijskiego w Santa Barbara udowodnili, jak łatwo można wykorzystać tę lukę.

Czym jest router AI?
* Rola – proxy pomiędzy aplikacją kliencką a dostawcą modelu (OpenAI, Anthropic, Google).
* Dostęp – pełny do każdego pakietu JSON przechodzącego przez niego.
* Bezpieczeństwo – większość dużych dostawców nie stosuje kryptograficznej integralności danych; router może zmieniać żądania bez wykrycia.

Jak badacze sprawdzali zagrożenie
Krok | Co zrobiono | Wynik
---|---|---
1 | Uzyskano dostęp do 28 komercyjnych routerów (Taobao, Xianyu, Shopify) i przeanalizowano 400 darmowych z otwartych społeczności. Zobaczyliśmy wiele potencjalnie niebezpiecznych punktów. |
2 | Wprowadzono payload, zastępując adres URL instalatora lub nazwę pakietu własnym kontrolowanym zasobem. Zmieniony JSON przechodził wszystkie automatyczne kontrole; jedna zmieniona komenda `curl` uruchamiała dowolny kod na kliencie. |
3 | Wykradono klucz API OpenAI i obserwowano, jak atakujący używają go do generowania 100 mln tokenów GPT‑5. |
4 | Odkryto dane uwierzytelniające w sesjach Codex. |
5 | Rozmieszczenie 20 specjalnie podatnych routerów na 20 adresach IP i monitorowanie ich aktywności. 40 000 prób nieautoryzowanego dostępu, ~2 miliardy opłaconych tokenów, 99 zestawów danych uwierzytelniających w 440 sesjach Codex (398 projektów). W 401 z 440 sesji włączono tryb autonomiczny YOLO, pozwalający agentowi wykonywać dowolne polecenia bez potwierdzenia. |

Dlaczego to tak niebezpieczne
* Prostota ataku – nie wymaga podszywania się pod certyfikaty; klient sam wskazuje końcowy punkt API.
* Brak weryfikacji integralności – złośliwy router może zmienić polecenie, które agent wykona.
* Niebezpieczne usługi – nawet „uczciwi” pośrednicy mogą stać się wektorem ataku.

Jak się zabezpieczyć bez udziału dostawcy
1. Podpisywanie odpowiedzi od modelu – idealne rozwiązanie, ale obecnie brak go u dużych dostawców (analog DKIM dla poczty).
2. Wielopoziomowa ochrona po stronie klienta – traktuj każdy router jako potencjalnego wroga:
* Walidacja struktury JSON i treści.
* Ograniczenia adresów URL, metod HTTP i payloadu.
* Logi i monitorowanie podejrzanej aktywności.
3. Ograniczenie dostępu do kluczy API – przechowuj klucze w bezpiecznych magazynach, stosuj rotację i minimalne uprawnienia.

Wnioski
Sprawdzenie pochodzenia polecenia od modelu AI jest niemożliwe bez podpisów odpowiedzi ze strony dostawcy. Dopóki takie mechanizmy nie pojawią się, użytkownicy muszą chronić się po stronie klienta, dokładnie sprawdzając wszystkie pośrednie usługi i wdrażając surowe polityki bezpieczeństwa.