Autonomiczni agenci AI zarządzają kodem i finansami. Badanie z Kalifornii ujawnia, jak pośrednicy w dostępie do LLM-ów potrafią przejąć nad nimi kontrolę.
W skrócie:
- Specjalistyczne routery API, które łączą użytkowników z modelami OpenAI czy Google, mogą potajemnie modyfikować polecenia i zamieniać agentów AI w narzędzia dla atakujących.
- Naukowcy zbadali setki takich usług – dziewięć aktywnie wstrzykiwało złośliwy kod, a siedemnaście doprowadziło do przechwycenia i nieautoryzowanego użycia poświadczeń chmurowych AWS.
- W jednym z testów złośliwy router wykorzystał prywatny klucz Ethereum, co pozwoliło mu na błyskawiczne opróżnienie cyfrowego portfela należącego do badaczy.
Agenci, czyli autonomiczne boty oparte na sztucznej inteligencji, coraz śmielej wkraczają do świata realnych zadań. Uruchamiają skrypty, zarządzają zasobami w chmurze, a nawet obsługują operacje finansowe. To już nie jest science fiction. Aby jednak połączyć aplikację użytkownika z potężnymi modelami od OpenAI, Anthropic czy Google, deweloperzy często sięgają po usługi pośredniczące – tak zwane routery API dla LLM-ów. I właśnie tam, w tym pozornie niewinnym ogniwie, czai się zagrożenie. Jak pokazuje badanie “Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain”, przeprowadzone przez zespół z University of California, Santa Barbara, ta strefa jest słabo chroniona. Jeśli pośrednik okaże się złośliwy, może zmienić treść promptu w locie, a agent – ślepo wykonujący polecenia – nawet tego nie zauważy.
Jak niewinny pośrednik staje się bronią?
Routery dla LLM-ów działają jak tłumacz na poziomie aplikacji, co daje im pełny dostęp do treści żądań i odpowiedzi w postaci nieszyfrowanego pliku JSON. Widzą wszystko: prompty, parametry, nazwy wywoływanych narzędzi, a często także klucze dostępu, które użytkownicy bezrefleksyjnie przekazują dalej. I tu niektórym mogłoby przyjść do głowy skojarzenie z klasycznym atakiem man-in-the-middle, ale jest pewna istotna różnica. Atakujący nie musi fałszować certyfikatów TLS ani łamać szyfrowania. Router sam w sobie jest punktem końcowym – kończy połączenie z klientem i zestawia nowe z dostawcą modelu. Jest idealnie umiejscowiony, by czytać, modyfikować lub fabrykować polecenia. Co gorsza, żaden duży dostawca modeli nie wymusza dziś kryptograficznego potwierdzenia integralności odpowiedzi. To poważne niedopatrzenie, które trzeba będzie naprawić. Szybko to jednak nie nastąpi.
Hakerzy już tu są. Co znaleziono w praktyce?
To nie są teoretyczne rozważania. Zespół badawczy zakupił 28 płatnych routerów (m.in. z Taobao i sklepów na Shopify) i przeanalizował 400 darmowych, tworzonych przez społeczności. Wyniki są alarmujące. Dziewięć z nich aktywnie wstrzykiwało złośliwy kod do zwracanych odpowiedzi, w tym jeden płatny i osiem darmowych. Siedemnaście darmowych routerów doprowadziło do nieautoryzowanego użycia poświadczeń AWS należących do badaczy. W jednym, szczególnie bolesnym przypadku, router przechwycił prywatny klucz Ethereum i po prostu opróżnił portfel z kryptowaluty. Jeśli ostatnio czytaliście historie osób, które po eksperymentach z agentami AI narzekały na dziwne ataki na swoje konta – to właśnie macie potencjalnego winowajcę. Szczególnie groźna okazała się technika polegająca na podmianie źródła instalatora lub nazwy pakietu na zasób kontrolowany przez atakującego. Składnia JSON pozostaje nienaruszona, więc atak omija wiele automatycznych zabezpieczeń. Wystarczy jeden zmieniony ‘curl‘, aby wykonać dowolny kod na maszynie klienta.
Jeden wyciek, by uruchomić lawinę. Na czym polega zatruwanie?
Badacze sprawdzili też scenariusz, w którym router nie jest od początku złośliwy, lecz zostaje “zatruty” przez przejęte dane. Po celowym ujawnieniu jednego kontrolowanego klucza OpenAI na chińskich forach, klucz ten wygenerował 100 milionów tokenów i pozwolił odkryć poświadczenia w wielu dalszych sesjach. Jeden wyciek może uruchomić kaskadę nadużyć, której skutki sięgają daleko poza pierwotny incydent. W drugim eksperymencie naukowcy celowo wystawili 20 słabo zabezpieczonych routerów na publicznych adresach IP. Przyciągnęły one 40 tysięcy prób nieautoryzowanego dostępu, obsłużyły około 2 miliardy rozliczalnych tokenów i ujawniły 99 poświadczeń w 440 sesjach. Aż 401 z nich działało już w trybie pełnej autonomii, gdzie agent sam zatwierdza działania. Taki samodzielny agent staje się wyjątkowo niebezpiecznym narzędziem.
Czy istnieje jakieś rozwiązanie tego problemu?
Autorzy badania wskazują trzy środki zaradcze, które można wdrożyć od razu po stronie klienta. Pierwszy to polityka fail-closed, która dopuszcza tylko polecenia z wcześniej zdefiniowanej, lokalnej listy dozwolonych. Drugi to analiza anomalii w odpowiedziach z użyciem modelu IsolationForest, który wykrywa 89% prób wstrzyknięcia złośliwego kodu. Trzeci to włączenie niezmienialnych logów, które pomogą w analizie po incydencie. Docelowo jednak potrzebne są systemowe zmiany. Badacze wskazują na konieczność wprowadzenia podpisów kryptograficznych dla odpowiedzi od dostawców modeli – czegoś na kształt mechanizmu DKIM w poczcie e‑mail. Dopóki OpenAI, Anthropic i inni giganci nie wdrożą takiego rozwiązania, każdy zewnętrzny router trzeba traktować jak potencjalnie wrogi element łańcucha dostaw. Jeśli więc planujecie eksperymenty z agentami AI, uważajcie. I pod żadnym pozorem nie przekazujcie przez pośredników swoich haseł, kluczy i prywatnych danych.