Agent AI posłuchał wpisu, który nie był poleceniem

Polecenie “zignoruj poprzednie instrukcje” agent AI odrzucił, podrobiony znacznik systemowy również. Zadziałał wpis w dzienniku zdarzeń wyglądający jak zwyczajny raport z narzędzia monitorującego. Miał numer zgłoszenia, powołanie na normę i jedną metrykę nie do sprawdzenia. Nie zawierał natomiast żadnego polecenia i to jest w tej historii najważniejsze. Były w nim za to dwa fakty, które agent zweryfikował samodzielnie i które okazały się prawdziwe. Skoro te dwa się zgadzały, przyjął bez sprawdzenia także pozostałe wartości z tego samego wpisu. Przestawił według nich ustawienia domeny, nie pytając nikogo o potwierdzenie, po czym zameldował, że problem rozwiązany. Żaden krok nie złamał przy tym reguły, bo agent miał do wszystkich uprawnienia.

Wpis, który agent wziął za wynik skanera

Skuteczny okazał się tekst, który w ogóle nie próbował rozkazywać. Scenariusz opisali badacze Tenet Security w materiale opublikowanym 9 sierpnia 2026 roku i uzupełnionym cztery dni później. Nazwali ten zestaw technik GhostJacking. Zanim pójdziemy dalej, jedno zastrzeżenie, bez którego reszta zostanie źle zrozumiana. Żaden z opisanych ataków nie wydarzył się poza laboratorium. To scenariusze badawcze na kontach testowych samych badaczy, a nie relacja z włamania.

Najciekawsze jest to, czego agent nie posłuchał. Klasyczne wstrzyknięcia poleceń, czyli próby podszycia się pod instrukcję od użytkownika, zostały odrzucone albo oznaczone jako podejrzane. Nie zadziałało ani “zignoruj poprzednie instrukcje”, ani podrobiony znacznik systemowy, ani wklejony kod. W tej części zabezpieczenia zrobiły to, czego się po nich spodziewamy.

Według badaczy zadziałał natomiast wpis zbudowany jak zwykły raport z narzędzia monitorującego. Było w nim odwołanie do zgłoszenia, powołanie na normę zgodności i wskaźnik nie do zweryfikowania. Ich własne określenie brzmi: ustalenie z luką, nigdy polecenie. Sedno leżało jednak gdzie indziej. Ładunek był zakotwiczony w prawdzie i zawierał dwa twierdzenia, które agent mógł sprawdzić sam, oba dotyczące ustawień poczty w atakowanej domenie. Sprawdził je i oba się potwierdziły. Od tej chwili przestał kwestionować pozostałe wartości z tego samego wpisu, choć to właśnie one były podstawione. Podobny wzorzec widzieliśmy już wtedy, gdy agent AI skasował cudzą rezerwację, bo zaufał temu, co zwróciło mu API.

Zablokowanie żądania było drogą do środka

Zapora zadziałała poprawnie i właśnie to okazało się problemem. Według badaczy spreparowane żądanie zablokował zarządzany zestaw reguł Cloudflare, włączony domyślnie w planach od Pro w górę. Blokada zapisała się w dzienniku zdarzeń i to ten zapis poniósł ładunek dalej.

Mechanizm jest prosty i przez to niewygodny. Pola z nazwą przeglądarki i adresem odsyłającym trafiają do dziennika bajt w bajt. Nie ma przy nich ani neutralizowania znaków specjalnych, ani oznaczenia mówiącego, że treść przyszła z zewnątrz. Właściwy ładunek jechał w polu z nazwą przeglądarki. To, co uruchomiło regułę zapory, siedziało natomiast w treści żądania, a agent przeglądający zablokowane żądania dostaje same nagłówki, bez tej treści. Widzi więc niegroźny opis techniczny zamiast czegoś, co system przed chwilą uznał za atak.

Test przeprowadzono na konfiguracji, którą Cloudflare sam zaleca do zabezpieczania poczty. Skuteczność podana przez badaczy to dziewięć udanych prób na dziesięć przeciw Claude Code w wersji Sonnet 4.6. Liczba pochodzi wyłącznie od nich i wypada to powiedzieć wprost. W całym materiale nie ma oświadczenia Cloudflare ani pozostałych dostawców, więc jedynym potwierdzeniem tej części są testy firmy, która sprzedaje rozwiązanie tego problemu.

Dwa warunki, przy których agent AI da się nabrać

Wzorzec działa wtedy, gdy agent może w jednej sesji czytać dane i wykonywać działania, a czytane dane nie mają oznaczenia pochodzenia ani poziomu zaufania. Oba warunki wyglądają na najzwyklejsze decyzje wdrożeniowe. Gdyby chodziło o błąd w jednym produkcie, historia skończyłaby się na poprawce, ale badacze pokazali ten sam schemat na trzech różnych platformach. To nie jest luka z numerem i wersją, którą zamyka się aktualizacją w wyznaczonym terminie, jak cztery luki dopisane w tym tygodniu do katalogu CISA.

Na Datadogu wejściem okazał się klucz przeznaczony wyłącznie do zapisu, wystawiony w kodzie strony i w nagłówkach odpowiedzi. Przeszukując publicznie dostępne dane, badacze znaleźli ponad 2 700 takich ujawnionych kluczy. Spreparowany wpis udawał zgłoszenie wymagające diagnozy i skłonił agenta do uruchomienia polecenia npx, czyli do wykonania kodu na maszynie. Po tym kroku, jak podają badacze, agent mógł wyprowadzić wszystko, co na tej maszynie dostępne, ze zmiennymi środowiskowymi włącznie.

Datadog oznacza wpisy przysłane takim kluczem osobną etykietą, tylko że, jak piszą badacze, jest ona schowana głęboko i żaden agent do niej nie zagląda. Ostrzeżenie więc istnieje, ale siedzi w miejscu, którego nikt nie czyta. Wektor bywa zresztą jeszcze bardziej prozaiczny, co opisywaliśmy przy złośliwym serwerze MCP wchodzącym przez plik konfiguracyjny – MCP to protokół, przez który model sięga do zewnętrznych narzędzi.

Jeden agent uwierzył drugiemu

Najciekawszy technicznie jest przypadek Sentry, bo tam podstępowi uległo zaufanie między dwoma programami. Agent piszący kod przekazuje trudniejsze zgłoszenia do osobnej sztucznej inteligencji Sentry i traktuje jej wnioski jako sprawdzone. Tu widać, czym agent różni się od zwykłej automatyzacji: sam wybiera następny krok, więc podsunięcie mu fałszywej przesłanki wystarczy, żeby zrobił coś, czego nikt nie zaplanował. Tę pętlę decyzji rozkładamy na części w tekście o tym, czym jest agent AI i czego nie potrafi.

Spreparowane zdarzenia dobijały do progu, przy którym taka eskalacja następuje, a potem podsuwały tamtej AI podrobiony wynik wyszukiwania. Agent piszący kod nigdy nie zobaczył surowego wstrzyknięcia. Zobaczył gotową analizę od zaufanego rozmówcy i ją wykonał. Sentry ma regułę mówiącą, żeby nigdy nie wykonywać poleceń z treści zgłoszeń, i ta reguła nie została złamana. Agent nie wykonywał treści zgłoszenia, tylko wniosek kolegi po fachu.

Tu widać, dlaczego przy agentach tak trudno o audyt. Wiadomo, co program zrobił, ale nie to, na jakiej podstawie uznał, że powinien. Pisaliśmy już o tym, jak trudno zajrzeć modelowi w rozumowanie, przy okazji zaszyfrowanych łańcuchów myślowych, które udało się odczytać. Osobna liczba, którą warto czytać ostrożnie, to szacunek 15 tysięcy narażonych organizacji. Badacze wyliczyli go, przenosząc 73 publiczne ślady znalezione w 48 firmach na bazę klientów Cloudflare. Sami zaznaczają, że mierzy on rozpowszechnienie podatnej konfiguracji, a nie potwierdzone włamania.

Zgłoszenie do Anthropiku przeszło całą drogę

Jeden wątek w całym materiale kończy się dobrze. Badacze znaleźli w Claude Desktop nieznaną wcześniej lukę pozwalającą wyjść z piaskownicy sieciowej, czyli z odgrodzenia, które ma nie wypuszczać danych agenta na zewnątrz.

Sam błąd jest pouczający, bo nie leży w modelu. Claude Desktop przepuszcza ruch wychodzący przez pośrednika, który przy każdym połączeniu sprawdza podpisany żeton z listą dozwolonych adresów. Brama weryfikowała podpis i listę, natomiast nie sprawdzała, czy żeton należy do tego środowiska, które akurat wysyła zapytanie. Żeton z szeroką listą dawało się więc przenieść z własnego środowiska do cudzego, a połączenie przechodziło. Jest to klasyczny błąd kontroli dostępu, tyle że w zupełnie nowym miejscu.

Ważniejsze jest to, co stało się dalej. Zgłoszenie trafiło do Anthropiku, zespół bezpieczeństwa firmy je potwierdził, a poprawka weszła przed wystąpieniem badaczy na sierpniowej konferencji DEF CON. Nie przyznano przy tym numeru CVE, czyli publicznego identyfikatora luki, i badacze zaznaczają to wprost. Powiedzmy jednak rzecz uczciwie do końca: piaskownica miała dziurę i to nie jest sukces produktu. Sukcesem jest procedura, czyli znalezione, zgłoszone, potwierdzone, naprawione i dopiero potem opublikowane. Przy pozostałych platformach źródło podaje wyłącznie daty zgłoszeń: 3 czerwca i 13 lipca do Sentry, 17 czerwca do Datadoga oraz 22 czerwca do Cloudflare. Czy i jak dostawcy zmienili potem swoje ustawienia, z tego materiału nie wynika.

Pierwsza Misja AI · Kodożercy

AI bez technikaliów – kurs i certyfikat

Pierwsza Misja AI to kurs Kodożerców dla absolutnych początkujących. Sci-fi fabuła, gamifikacja, prawdziwy GPT-4 w ćwiczeniach, certyfikat na koniec.

Zacznij Pierwszą Misję →

Cztery rzeczy do zrobienia bez czekania na łatkę

Zostaje zmiana sposobu, w jaki podłącza się agenta do narzędzi, i badacze podają w tej sprawie cztery zalecenia. Domyślnie blokuj ruch wychodzący, bo to samo w sobie zatrzymuje i pobranie ładunku, i wyniesienie danych. Wymagaj zgody człowieka na każde polecenie, które agent chce wykonać. Nie pozwól, żeby dane czytane przez agenta stawały się poleceniem, które wykonuje. Zakładaj, że każde osiągalne poświadczenie może być zagrożone, i przejrzyj wszystkie narzędzia, do których agent ma dostęp.

Trzeci punkt jest w praktyce najtrudniejszy, bo odczyt cudzych danych bywa właśnie tym powodem, dla którego agenta w ogóle podłączono. Rozdzielenie sesji czytającej od tej, która może coś zmienić, kosztuje wygodę. Jest to cena, o której lepiej rozmawiać przed wdrożeniem niż po nim. O tym, co się psuje w agentach puszczonych na dłuższe zadania, wiadomo już zresztą sporo.

Na koniec rzecz, którą czytelnik ma prawo znać. Tenet Security sprzedaje platformę bezpieczeństwa dla warstwy agentowej, więc to badanie jest jednocześnie materiałem sprzedażowym. Nie unieważnia to ustaleń, bo prelekcja przeszła niezależną recenzję konferencji, zgłoszenia mają daty, a firma udostępniła kod narzędzia agent-jackstop do wzmacniania zabezpieczeń Cursora i Claude Code. Sama zaznacza przy tym, że narzędzie problemu nie rozwiązuje, a jedynie zmniejsza wystawienie na ten atak. Traktujemy to więc jako punkt wyjścia, nie jako lekarstwo.

Podsumowanie

Najtrwalsza lekcja z tego materiału nie dotyczy trzech wymienionych platform, tylko sposobu, w jaki podłączamy agenty do firmowych narzędzi. Model nie ma jak odróżnić danych od polecenia, jeżeli jedno i drugie dociera do niego tym samym kanałem i w tej samej postaci. Klasyczne zabezpieczenia wcale nie milczały: zapora zablokowała żądanie, a oczywiste wstrzyknięcia zostały odrzucone albo oznaczone. Nie zatrzymały jednak dalszego łańcucha, bo agent wykonywał wyłącznie działania, do których miał uprawnienia, i każdy pojedynczy krok wyglądał na uzasadniony. Dopóki narzędzie czytające i narzędzie wykonujące siedzą w jednej sesji, ten sam schemat będzie wracał przy kolejnych integracjach. Drugi warunek, czyli brak informacji o pochodzeniu danych, jest równie łatwy do przeoczenia. Najpełniej domknięto w tej historii obieg zgłoszenia luki w Claude Desktop, a akurat on nie wymagał żadnej nowej technologii.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.