Tenet Security ujawniło nową klasę ataku o nazwie Agentjacking. Mechanizm: pojedyncze zatrute zdarzenie błędu, wstrzyknięte do platformy monitoringu Sentry, przejmuje agenta AI do kodowania — Claude Code, Cursor, Codex — i każe mu wykonać kod atakującego na maszynie dewelopera. Bez phishingu. Bez malware. Bez włamania na serwer. Bez żadnej interakcji użytkownika poza tym, co robi codziennie: poproszeniem asystenta AI, żeby zbadał błąd w aplikacji.
Skuteczność: 85% na najpopularniejszych agentach na rynku, potwierdzona na ponad 100 realnych celach. Liczba wystawionych organizacji: 2388 z wstrzykiwalnymi poświadczeniami, w tym 71 z listy Tranco top-1M.
Ale najważniejsze w tej historii nie są liczby. Najważniejszy jest koncept, który Tenet nazwał Authorized Intent Chain — i to jest powód, dla którego żadne tradycyjne narzędzie bezpieczeństwa tego nie złapie.
Łańcuch, w którym każdy krok jest autoryzowany
Tu jest sedno, które czyni Agentjacking groźniejszym niż zwykły exploit.
Tenet opisuje atak jako Authorized Intent Chain — łańcuch autoryzowanej intencji. Każda pojedyncza akcja w łańcuchu ataku jest technicznie dozwolona. Wysłanie zdarzenia błędu do Sentry przez publiczny DSN — dozwolone, tak działa Sentry. Pobranie tego błędu przez agenta AT przez MCP — dozwolone, po to integruje się agenta z narzędziem monitoringu. Wykonanie polecenia przez agenta — dozwolone, agent ma uprawnienia do działania na maszynie dewelopera. Nigdzie w tym łańcuchu nie ma akcji nieautoryzowanej.
A cały dominujący model bezpieczeństwa jest zbudowany po to, by łapać zachowanie nieautoryzowane. EDR szuka złośliwych procesów. WAF szuka złośliwych żądań. IAM kontroluje, kto ma dostęp. Firewall blokuje nieautoryzowane połączenia. Agentjacking omija to wszystko — EDR, WAF, kontrole IAM, VPN, Cloudflare, firewalle — bo nie zawiera ani jednej akcji, którą te narzędzia są zaprojektowane wykryć. Nie ma nic złośliwego do złapania. Jest tylko ciąg legalnych operacji, które razem dają atakującemu wykonanie kodu.
To jest dokładnie ta klasa problemu, którą OWASP nazwał tydzień temu: granica między „safety" a „security" znika, gdy agent może autonomicznie działać. Tutaj widać to w czystej postaci — atak jest jednocześnie awarią „safety" (agent robi coś szkodliwego, czytając dane) i atakiem „security" (ktoś go do tego nakłonił), a żadne z tradycyjnych narzędzi nie jest zbudowane do łapania ataku, w którym wszystko jest autoryzowane.
Jak działa — wejście przez poświadczenie, które ma być publiczne
Punktem wejścia jest Sentry Data Source Name (DSN). To jest poświadczenie zapisu, rutynowo i celowo osadzane we frontendowym JavaScripcie — bo po to istnieje, by przeglądarka użytkownika mogła zgłaszać błędy do Sentry. Jest publiczne z założenia, zindeksowane w całej sieci.
Tenet użył pasywnego rekonesansu — inspekcji JavaScriptu, wyszukiwań Censys, analizy loaderów CDN, code search — by znaleźć 2388 organizacji z wstrzykiwalnymi DSN. Żadnego włamania, żadnego łamania zabezpieczeń. Te poświadczenia leżą w kodzie źródłowym stron, widoczne dla każdego.
Mając DSN, atakujący wysyła do Sentry spreparowane zdarzenie błędu — które wygląda jak normalny crash aplikacji, ale w treści zawiera sformatowane instrukcje. Gdy deweloper później prosi swojego agenta AI, żeby zbadał błędy w Sentry — co jest absolutnie normalnym, codziennym workflow debugowania — agent pobiera to zdarzenie przez MCP, czyta instrukcje atakującego i je wykonuje.
To jest ten sam wzorzec, który opisujemy od miesiąca: agent AI traktuje niezaufaną treść jako instrukcję. ChatGPhish — strona internetowa. Claude Code GitHub Action — zgłoszenie GitHub. Gemini — powiadomienie push. Agentjacking — zdarzenie błędu w Sentry. Cztery różne kanały wejścia, jedna klasa problemu. Różnica jest taka, że tutaj kanałem jest narzędzie, któremu deweloper ufa najbardziej w momencie, gdy jest najmniej czujny — bo właśnie szuka przyczyny awarii.
Dlaczego prompt nie pomaga — i dlaczego to nie da się załatać
Tu jest punkt, który Tenet udowodnił eksperymentalnie i który jest najważniejszy dla zrozumienia, czemu to nie jest zwykły bug.
Obrony na poziomie promptu okazały się bezskuteczne. Agenci wykonywali ładunki atakującego nawet wtedy, gdy system prompt jawnie instruował je, by ignorowały niezaufane dane. To potwierdza, że słabość jest wpisana w to, jak obecne modele przetwarzają wyjście narzędzi MCP — nie jest to błędna konfiguracja, którą da się załatać.
To jest dokładnie ta sama lekcja, którą zapisaliśmy przy prompt leaking i Claude Code: ograniczenia na poziomie instrukcji językowej są miękkie. Model można przekonać, żeby zignorował zdanie „ignoruj niezaufane dane", bo dla modelu wszystko, co trafia do kontekstu, jest równoprawne. Agent nie potrafi odróżnić prawdziwej wskazówki od fałszywej — i gdy ładunek zostanie raz spreparowany, może być wstrzyknięty do tysięcy projektów jednocześnie.
Co udany atak daje atakującemu: zmienne środowiskowe, poświadczenia Git, URL-e prywatnych repozytoriów, tożsamości deweloperów. Pojedyncza złośliwa instrukcja może wykraść poświadczenia potoku CI/CD, uzyskać dostęp do prywatnych repozytoriów kodu, skompromitować infrastrukturę chmurową i ustanowić trwały dostęp. To jest pełna kompromitacja środowiska deweloperskiego przez jedno zdarzenie błędu.
Odpowiedź Sentry — i co ona znaczy
Reakcja producenta jest tu sama w sobie tematem, bo wpisuje się w nasz wątek o disclosure.
Tenet zgłosił odkrycie do Sentry 3 czerwca. Sentry potwierdził problem tego samego dnia — ale odmówił naprawy u źródła, opisując całą klasę ataku jako „technicznie nieobronną" na poziomie platformy. Zamiast tego wdrożył globalny filtr treści blokujący konkretny ciąg ładunku — czyli wykrywanie tej jednej aktywności bez adresowania przyczyny. Sentry wskazał, że to dostawcy modeli powinni uruchamiać middleware przeciw temu.
To jest uczciwie postawiony spór, nie wymówka — i warto go oddać sprawiedliwie. Sentry ma rację w jednym: jeśli DSN jest z założenia publiczny, a agent z założenia ufa wyjściu MCP, to platforma monitoringu faktycznie nie ma gdzie postawić obrony. Problem nie jest w Sentry — jest w tym, że agent wykonuje to, co przeczyta. Ale to oznacza, że odpowiedzialność spada na warstwę, która dziś jest najsłabiej chroniona: runtime agenta.
Wniosek Tenet jest trafny: jeśli właściciel platformy uważa tę klasę ataku za „technicznie nieobronną" u źródła, jedyne miejsce, gdzie można ją zatrzymać, to runtime agenta — w momencie, gdy decyduje się działać. To jest ta sama konkluzja, do której doszedł OWASP: bezpieczeństwo agenta musi być wbudowane w to, co agent może zrobić, nie w to, co mu się każe w instrukcji.
Dlaczego to jest punkt zwrotny
Agentjacking warto odnotować jako moment, w którym coś się przesuwa. Dla obrońców sygnalizuje nową erę ryzyka w łańcuchu dostaw AI, gdzie sam agent AI staje się główną powierzchnią ataku.
Dotąd opisywaliśmy agenty AI jako cel (Langflow), jako wektor (Claude Code) i jako narzędzie (Codex znajdujący HTTP/2 Bomb). Agentjacking pokazuje czwarty wymiar: agent jako kanał dowodzenia. Każda integracja narzędzia MCP zwracająca dane wpływane z zewnątrz tworzy tę samą klasę podatności. Platformy obserwowalności — Sentry i wszystko, co do niego podobne — mogą być uzbrojone jako kanały command-and-control. Im więcej narzędzi MCP podłączasz do agenta, tym więcej drzwi, przez które niezaufana treść może wejść i stać się poleceniem.
To jest konsekwencja architektury, nie pojedynczego błędu. I dlatego nie da się jej zamknąć jedną łatką — wymaga zmiany w tym, jak agenty traktują wszystko, co czytają.
Co zrobić
Zinwentaryzuj, z którymi narzędziami MCP twoje agenty AI faktycznie się integrują — i które z nich przyjmują niezaufane lub anonimowe dane wejściowe. Sentry to jeden przykład; każda integracja zwracająca dane wpływane z zewnątrz jest tą samą klasą ryzyka. To jest pytanie, na które OWASP i Tenet zgodnie wskazują jako pierwsze: co twój agent czyta i komu to ufa.
Wprowadź kontrolę runtime, nie polegaj na prompcie. Tenet udowodnił, że instrukcja „ignoruj niezaufane dane" nie działa. Jedyna skuteczna warstwa to ograniczenie tego, co agent może fizycznie wykonać — sandbox, lista dozwolonych poleceń, human-in-the-loop przy akcjach wrażliwych. Pytanie brzmi: jakie kontrole runtime są na miejscu, by wstrzyknięta treść nie przekładała się automatycznie na wykonanie kodu na endpoincie dewelopera.
Traktuj publiczne DSN i podobne poświadczenia zapisu jako powierzchnię ataku. Jeśli twój DSN jest we frontendowym JavaScripcie — a prawdopodobnie jest, bo tak działa Sentry — to ktoś może przez niego wstrzyknąć zatrute zdarzenie. Nie da się go ukryć, ale można ograniczyć, czego agent dotyka, gdy czyta dane z monitoringu.
Dla zespołów używających Claude Code, Cursor czy Codex: human-in-the-loop przy debugowaniu produkcyjnych błędów nie jest paranoją. Agent czytający zdarzenia z Sentry i działający bez przeglądu to dokładnie ścieżka, którą Tenet zademonstrował z 85% skutecznością.
Źródła
Tenet Security — oryginalny research z pełnym łańcuchem ataku i konceptem Authorized Intent Chain: https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/
The Hacker News — analiza mechanizmu zaufania MCP i odpowiedzi Sentry: https://thehackernews.com/2026/06/agentjacking-attack-tricks-ai-coding.html
Cyber Security News — szczegóły rekonesansu DSN i liczby wystawionych organizacji: https://cybersecuritynews.com/agentjacking-attack-hijacks-ai-coding-agent/
Infosecurity Magazine — wskaźnik skuteczności 85% i potwierdzenie obejścia obrony na poziomie promptu: https://www.infosecurity-magazine.com/news/agentjacking-attacks-hijack-ai/
GBHackers — analiza Authorized Intent Chain i omijania EDR/WAF/IAM: https://gbhackers.com/agentjacking-attack-hijacks-ai-coding-agents/
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł