Agentjacking: jeden klucz Sentry wystarczy, żeby przejąć Claude Code, Cursor i Codex

Wyobraź sobie, że prosisz swojego agenta AI o przejrzenie nierozwiązanych błędów w Sentry. Standardowy poranek, standardowe zadanie. A agent - grzecznie, bez mrugnięcia okiem - pobiera pakiet npm i uruchamia go z pełnymi uprawnieniami twojego konta systemowego. Twoje klucze AWS właśnie trafiły na serwer kontrolowany przez kogoś, kogo nigdy nie spotkałeś. I nikt o tym nie wie - ani EDR, ani firewall, ani Kubernetes, ani ty.

Dokładnie to zademonstrował zespół badaczy z Tenet Security w nowej klasie ataków, którą nazwali Agentjacking. To nie teoretyczny scenariusz z prezentacji konferencyjnej. To działający exploit, przetestowany na realnych maszynach, w realnych organizacjach - z potwierdzonym wykonaniem złośliwego kodu u klientów z list Fortune 500 i Fortune 100.

Szczegółowy raport opublikowali w czerwcu 2026 roku. Branża cyberbezpieczeństwa właśnie dostała poważny rachunek za nadmierne zaufanie, jakim obdarzono agentowe narzędzia AI.

Czym jest Agentjacking i dlaczego to nie jest zwykła luka

Większość ataków wymaga czegoś: skradzionego hasła, zainfekowanego pliku, kliknięcia w link. Agentjacking nie wymaga niczego z tej listy. Atak opiera się na pojedynczym spreparowanym raporcie błędu, wysłanym do Sentry za pomocą publicznego klucza DSN - bez żadnego włamania, bez kradzieży poświadczeń, bez ingerencji w infrastrukturę ofiary.

Całość jest możliwa, bo klucz DSN (Data Source Name) to poświadczenie wyłącznie do zapisu, które Sentry z założenia dokumentuje jako bezpieczne do osadzania w kodzie frontendowym JavaScript. Innymi słowy: jest publiczny z definicji, a jego obecność w źródłach stron internetowych nikogo nie dziwi. Do niedawna.

Atak wykorzystuje architektoniczny błąd na przecięciu dwóch systemów: mechanizmu przyjmowania zdarzeń przez Sentry (który akceptuje dowolne ładunki od każdego, kto dysponuje DSN) oraz serwera Sentry MCP (który zwraca te dane agentom AI jako zaufane wyjście systemowe).

Model Context Protocol, czyli MCP, to stosunkowo nowy standard pozwalający agentom AI na komunikację z zewnętrznymi narzędziami - edytorami, systemami błędów, bazami danych. Sentry podłączone przez MCP stało się dla agentów AI źródłem, któremu ufają bezgranicznie. I właśnie to zaufanie okazało się śmiertelne.

Pięć kroków do przejęcia maszyny dewelopera

Mechanika ataku jest zatrważająco prosta. Atakujący najpierw lokalizuje klucz DSN organizacji docelowej - najczęściej widoczny w publicznych pakietach JavaScript. Następnie tworzy spreparowane zdarzenie błędu zawierające polecenia w formacie markdown, umieszczone w treści wiadomości lub polach kontekstowych.

Injektowany markdown renderuje się identycznie jak legalne szablony systemowe Sentry, co czyni go nieodróżnialnym od prawdziwych komunikatów o błędach. Fałszywa sekcja z poradą naprawczą zawiera polecenie do wykonania - na przykład wywołanie pakietu npm z zewnętrznego rejestru.

Gdy deweloper poprosi swojego agenta AI o naprawienie nierozwiązanych błędów Sentry, agent odpytuje serwer Sentry MCP i otrzymuje injektowane zdarzenie jako część zaufanego wyjścia narzędziowego. I tu jest sedno problemu.

Kluczowe ⚠️

Agent nie rozróżnia danych pobranych z zewnętrznego źródła od instrukcji operatora. Polecenie ukryte w logu błędów - miejscu, gdzie żaden człowiek normalnie nie szuka poleceń - po prostu się wykonuje. To ograniczenie modeli AI, nie błąd konfiguracji.

Po uruchomieniu pakiet potwierdza, że jest w stanie odczytać zmienne środowiskowe, pliki konfiguracyjne chmury i magazyny poświadczeń, a następnie sygnalizuje kontrolowanemu serwerowi, że ekspozycja jest realna. Klucze AWS, tokeny GitHub i poświadczenia git są wszystkie w zasięgu z tego jednego punktu wejścia.

Liczby, które nie pozwalają spać

Tenet Security nie poprzestała na teorii. Testy przeprowadzone na Claude Code, Cursor i OpenAI Codex CLI przyniosły 85-procentowy wskaźnik powodzenia exploitacji. Agenty pobierały injektowane zdarzenia z Sentry, interpretowały je jako miarodajne wskazówki diagnostyczne i wykonywały dostarczone przez atakującego polecenia - eksfiltrując poświadczenia AWS, tokeny OAuth GitHub, sekrety Kubernetes oraz inne wrażliwe zmienne środowiskowe.

Badacze zidentyfikowali co najmniej 2 388 organizacji z publicznie dostępnymi kluczami DSN, które mogłyby zostać użyte do injektowania złośliwych zdarzeń Sentry. Wśród nich znalazły się firmy z list Fortune 500 i Fortune 100. Claude Code, Cursor i Codex - wszystkie trzy zareagowały na injektowane błędy, a zespół odnotował ponad 100 potwierdzonych przypadków wykonania kodu.

Zakres eksfiltrowanych danych jest imponujący w najgorszym możliwym sensie: w trakcie testów potwierdzono dostęp do kluczy dostępu AWS, osobistych tokenów dostępu GitHub, poświadczeń klastrów Kubernetes, poświadczeń rejestrów z plików `.npmrc` i `.docker/config.json` oraz zawartości zmiennych środowiskowych CI/CD.

Uwaga ⚠️

To nie jest atak laboratoryjny. Tenet potwierdziła wykonanie kodu na maszynach organizacji z listy Fortune 100 - za korporacyjnymi firewallami, bez żadnego alertu ze strony EDR, WAF czy systemów IAM.

Dlaczego żaden firewall tego nie widzi

To, co wyróżnia Agentjacking spośród innych klas ataków, to całkowita bezużyteczność tradycyjnych zabezpieczeń. Atak omija ochronę perymetru w całości. EDR, zapory aplikacji webowych, polityki IAM, VPN-y i firewalle nie oferują żadnej ochrony, ponieważ złośliwa instrukcja dociera jako zwykłe wskazówki diagnostyczne wewnątrz zaufanego wyjścia systemowego. Atakujący w żadnym momencie nie dotyka bezpośrednio infrastruktury ofiary.

Agent nie może odróżnić danych, które czyta, od instrukcji do wykonania. Polecenie umieszczone tam, gdzie agent będzie je czytał - nawet w miejscu, gdzie człowiek nigdy by nie zajrzał, jak dziennik błędów - może po prostu zostać uruchomione. To jest ograniczenie samych modeli, a nie coś, co da się naprawić zmianą konfiguracji.

Publiczny DSN i zaufanie agenta do danych zwracanych przez MCP to śmiertelne połączenie, bo każde z nich osobno jest nieszkodliwe - razem stają się niebezpieczne. Poświadczenie pozwala atakującemu pisać do danych, które agent czyta, a agent dostarcza uprawnienia do działania na podstawie tych danych.

Odpowiedź Sentry i co z tym dalej

Tenet ujawniła wyniki badań firmie Sentry 3 czerwca 2026 roku. Sentry potwierdziła problem tego samego dnia, ale odmówiła wdrożenia fundamentalnej poprawki, opisując tę klasę ataków jako „technicznie nieobronną” na poziomie platformy. Firma uruchomiła globalny filtr treści blokujący konkretny ciąg znaków użyty w dowodzie koncepcji, choć badacze zauważają, że zapewnia to ograniczoną ochronę przed nieznacznie zmodyfikowanymi atakami.

Innymi słowy: Sentry umyła ręce. Co samo w sobie nie powinno dziwić - DSN naprawdę był zaprojektowany jako publiczny klucz do zapisu, zanim ktokolwiek wymyślił, że agenty AI będą podłączać się do tych samych danych przez MCP. Problem nie leży w Sentry - leży w tym, że architektura MCP zakłada ufanie wszystkim danym zwracanym przez narzędzie.

Tenet udostępniła otwartoźródłowy zestaw konfiguracji o nazwie agent-jackstop, który wzmacnia Cursor i Claude Code przed tą klasą ataków i daje zespołom konkretny punkt startowy, podczas gdy szersze pytania są jeszcze dyskutowane.

Protip ✅

Jeśli Twój zespół używa Claude Code lub Cursor z integracją Sentry przez MCP - sprawdź repozytorium agent-jackstop na GitHubie Tenet Security. To jedyna konkretna, dostępna dziś ochrona przed Agentjacking.

Problem głębszy niż Sentry

Badacze z Tenet byli w tym punkcie wyjątkowo precyzyjni: Sentry to tylko przykład. Słabość, którą zademonstrował Tenet, nie należy wyłącznie do Sentry. Każda integracja MCP, która zwraca zewnętrznie influencjonowane dane do agenta, niesie takie samo zagrożenie. W miarę jak więcej narzędzi będzie łączyć się przez MCP, powierzchnia ataku dostępna przez zaufaną telemetrię będzie się powiększać.

Zagrożenie dotyka każdego agenta AI integrującego się z Sentry przez MCP, w tym Claude Code i Cursor. Ryzyko wykracza jednak poza Sentry - każda integracja narzędzi MCP zwracająca zewnętrznie influencjonowane dane do agenta AI tworzy tę samą klasę podatności.

To jest prawdziwa skala problemu. Ekosystem MCP rośnie w błyskawicznym tempie - agenty AI podłączają się do GitHuba, Jiry, Slacka, systemów monitoringu, baz danych. Każde z tych narzędzi, jeśli akceptuje zewnętrzne dane, może stać się wektorem Agentjacking. Branża przez ostatnie dwa lata skupiała się na zabezpieczaniu promptów użytkownika - i kompletnie przegapiła kanał boczny przez dane narzędziowe.

Uwaga ⚠️

Filtrowanie promptów użytkownika nie chroni przed Agentjacking. Złośliwa instrukcja nie pochodzi od użytkownika - pochodzi z narzędzia, któremu agent ufa bezwarunkowo. To fundamentalnie inny problem.

Co muszą zrobić organizacje - i to już teraz

Tenet ujawniła wyniki badań firmie Sentry 3 czerwca 2026 roku. Sentry potwierdziła problem i uruchomiła ograniczone filtry, ale nie wdrożyła kompleksowej poprawki. Ciężar ochrony spada więc na organizacje i twórców agentów AI.

Liderzy ds. bezpieczeństwa muszą zrozumieć, że integracje MCP to nowa granica ataków na łańcuch dostaw oprogramowania. Konieczna jest ocena, z jakimi narzędziami łączą się agenty AI, czy te narzędzia zwracają niezaufane dane i jakie mechanizmy kontrolne istnieją, aby zapobiec uruchamianiu kodu na podstawie injektowanych danych.

Praktyczny zestaw działań jest krótki, ale niezbędny: audyt wszystkich integracji MCP w środowiskach developerskich, weryfikacja które narzędzia akceptują zewnętrzne dane wejściowe, wdrożenie zasady minimalnych uprawnień dla kont używanych przez agenty AI oraz - do czasu pojawienia się systemowych rozwiązań - rozważenie wyłączenia automatycznego wykonywania poleceń przez agentów bez potwierdzenia człowieka.

Protip ✅

Rotuj klucze DSN Sentry regularnie i ogranicz które DSN są w ogóle aktywne w produkcji. Stary, zapomniany DSN w publicznym repo sprzed dwóch lat to dziś wektor ataku na całą infrastrukturę chmurową.

Kto na tym straci - a kto powinien wyciągnąć wnioski

Agentjacking to rachunek za nadmierną ufność, którą branża AI wbudowała w agentowe narzędzia do programowania. Przez ostatnie dwa lata Claude Code, Cursor i Codex ścigały się o tytuł najlepszego asystenta dewelopera - i każdy z nich wygrywał w benchmarkach pisania kodu, testów jednostkowych, refaktoryzacji. Nikt nie pytał głośno: a co, jeśli agent wykonuje nie tylko dobry kod, ale też złośliwy?

Odpowiedź przyszła z zewnątrz, od badaczy bezpieczeństwa, a nie od samych producentów. Jeśli zespoły będą nadal podłączać agentów do zewnętrznych usług bez mechanizmów kontrolujących, co te usługi zwracają, injektowane dane będą nadal znajdować drogę do wykonania.

Dla niezależnych deweloperów stawką jest osobisty laptop z kluczami AWS do produkcyjnego środowiska. Dla firm z Fortune 100 - całe repozytoria kodu, sekrety CI/CD i dostęp do infrastruktury wartej miliardy. Jeden injektowany błąd daje dostęp do zmiennych środowiskowych, kluczy AWS, tokenów GitHub, tokenów autoryzacyjnych Sentry, poświadczeń git, prywatnych adresów URL repozytoriów i tożsamości dewelopera - po cichu eksfiltrując je na serwer atakującego bez phishingu, bez wcześniejszego kompromitowania serwera i bez żadnej interakcji użytkownika poza normalnym przepływem pracy.

Agentjacking to nie bug do załatania w następnym sprincie. To sygnał, że branża musi poważnie przemyśleć architekturę zaufania w autonomicznych agentach AI - zanim ktoś zrobi to za nią, przy użyciu jednego publicznego klucza i kilku linijek JSON.