Zlecił Pan agentowi naprawienie błędów. Jeden z nich napisał atakujący.

Deweloper otwiera swojego agenta AI i wpisuje najzwyklejszą na świecie prośbę: „przejrzyj nierozwiązane błędy w Sentry i napraw je". Agent pobiera listę błędów przez swój konektor Sentry, czyta najważniejsze zgłoszenie, postępuje zgodnie z krokami naprawczymi zapisanymi wprost w raporcie i je uruchamia. Pół minuty później wykonał kod atakującego na maszynie dewelopera, z pełnymi uprawnieniami dewelopera, i nikt nie popełnił błędu.

To jest Agentjacking, ujawniony w tym miesiącu przez Tenet Security, który zadziałał w 85% przypadków przeciwko trzem najpopularniejszym agentom kodującym na rynku: Claude Code, Cursor i Codex [1][2].

Co właściwie się wydarzyło

Najpierw, czym jest Sentry: jedna z najpowszechniej używanych usług monitorowania błędów w oprogramowaniu. Kiedy Pana aplikacja zgłasza błąd lub ulega awarii, Sentry go przechwytuje i tworzy raport, który Pana deweloperzy segregują — usługa działa w ogromnej części aplikacji, z których Pan korzysta codziennie. Aby wysyłać te raporty, każda aplikacja osadza DSN: klucz po stronie klienta, który celowo trafia do kodu źródłowego Pana witryny, aby przeglądarka mogła wysyłać błędy do domu. Każdy może go odczytać. I każdy, kto go posiada, może wysłać żądanie POST ze zdarzeniem błędu do Pana projektu w Sentry.

W tym tkwi cały klucz do ataku. Tenet przygotował fałszywe zdarzenie błędu, którego pole wiadomości sformatowano tak, by wyglądało dokładnie jak własne wytyczne naprawcze Sentry: staranny markdown, „zalecane rozwiązanie", polecenie do uruchomienia. Przesłali je z użyciem publicznego DSN. Potem czekali na najnaturalniejszą rzecz, jaką robi deweloper — poproszenie agenta o wyczyszczenie kolejki błędów.

Agent odpytuje Sentry przez swój konektor MCP. Konektor zwraca błąd jako zaufane wyjście systemowe. Agent nie odróżnia prawdziwego raportu Sentry od sfałszowanego; mają identyczną strukturę bajt po bajcie. Robi więc to, co mu kazano, i uruchamia „naprawę", zazwyczaj wywołanie npx do pakietu atakującego. Od tego momentu ma wszystko, co ma deweloper: zmienne środowiskowe, poświadczenia Git, adresy URL prywatnych repozytoriów, klucze chmurowe w ~/.aws/.

Tenet znalazł 2 388 organizacji z DSN-ami podatnymi na wstrzyknięcie — od niezależnych deweloperów po firmy z listy Fortune 100. W kontrolowanych testach agenty rzeczywiście wykonały wstrzyknięte instrukcje w prawdziwych firmach — w tym, jak podaje Tenet, w firmie technologicznej z listy Fortune 100 o wartości 250 miliardów dolarów, której agent AI przeczytał fałszywy raport o błędzie i uruchomił kod Tenet na dwóch jej maszynach firmowych [1][3]. Zgłoszone Sentry 3 czerwca; firma przyjęła zgłoszenie tego samego dnia i odmówiła naprawy przyczyny, nazywając problem „technicznie nie do obrony". Wdrożyła filtr treści blokujący jeden konkretny ciąg ładunku [4].

To nie jest przejaw niedbałości Sentry

Oto niewygodna część: nic w tym łańcuchu nie było błędem. DSN ma być publiczny. Serwer MCP ma zwracać Pana dane o błędach. Agent ma reagować na diagnostykę, o której naprawę Pan poprosił. Każdy krok był autoryzowany — i właśnie dlatego nie wykryła go żadna zapora, żaden EDR, żaden systemowy prompt.

Wada jest strukturalna i nie dotyczy wyłącznie Sentry. Każde narzędzie, które podaje agentowi tekst możliwy do wpłynięcia przez osobę z zewnątrz — tracker błędów, kolejka zgłoszeń, zeskrobana strona internetowa, współdzielony dokument — jest kanałem wstrzyknięcia, a agent traktuje to wszystko jako jeden nierozróżnialny strumień instrukcji. Wstrzyknięcie promptu, dwa lata po rozpoczęciu ery agentów, wciąż pozostaje nierozwiązane: nie da się niezawodnie powstrzymać wrogiego tekstu przed przedostaniem się do rozumowania modelu. Proszę zakładać, że się Panu nie uda.

Katastrofą nie jest samo wstrzyknięcie

Oto część, nad którą warto się zatrzymać. Powodem, dla którego Agentjacking jest pożarem najwyższego stopnia, nie jest to, że agent dał się oszukać. Chodzi o to, do czego oszukany agent miał dostęp. Działał z pełnym, stałym dostępem dewelopera: każdym kluczem w środowisku, każdym plikiem poświadczeń na dysku, całym magazynem kluczy odległym o jedno polecenie.

Ten zasięg rażenia nie jest prawem natury. Jest kwestią konfiguracji. Agent miał stały dostęp do tego wszystkiego, ponieważ dziś tak przechowuje się poświadczenia — wszechobecnie, na maszynie, czytelne dla wszystkiego, co się na niej uruchamia. Wystarczy to usunąć, a ten sam atak napotka na ścianę.

Zaprojektowane celowo z myślą o tym

Poświadczenie Clavitor nigdy nie znajduje się w środowisku, w którym działa agent. Nie ma czegoś takiego jak ~/.aws/credentials do odczytania ani klucza API w zmiennej środowiskowej do wykradzenia, ponieważ wartość tajna nigdy nie trafia tam, gdzie wykonywany jest kod — agent otrzymuje wynik użycia poświadczenia, a nie samo poświadczenie. Może sięgnąć wyłącznie po tę jedną rzecz, dla której został nazwany, więc nie może wyliczyć zawartości magazynu, żeby sprawdzić, co jeszcze się w nim znajduje. A nadanie dostępu jest ograniczone zakresem i odwoływalne, więc sesja, która zaczyna zachowywać się jak atakujący, może zostać przerwana w trakcie działania.

Oto uczciwe zastrzeżenie: to nie powstrzymuje wstrzyknięcia i nie powstrzymuje przejętego agenta przed uruchomieniem polecenia. Wstrzyknięcie promptu jest nierozwiązane i nie twierdzimy, że je rozwiązujemy. Zmienia się zysk z ataku. Kod atakującego nadal się uruchamia — i trafia na środowisko, w którym nie ma nic wartego kradzieży. Przejęcie się udaje, ale kradzież się nie udaje.

Zapisaliśmy zasady, których system poświadczeń musi przestrzegać, gdy samego agenta można zwrócić przeciwko Panu — począwszy od tego, że tajna wartość nigdy nie przebywa tam, gdzie uruchamiany jest kod, oraz że agent sięga wyłącznie po to, dla czego został nazwany. Proszę sprawdzić swój system według tych zasad: clavitor.ai/rules.

Lekcja nie brzmi „załataj Sentry"

Sentry nie może tego naprawić i powiedziało to wprost. A następnym zatrutym narzędziem nie będzie Sentry. Dopóki Pana agenty noszą ze sobą wszechobecne, stałe poświadczenia, każde zaufane narzędzie, które czytają, jest naładowanym pistoletem, a wstrzyknięcie promptu jest spustem, którego nie da się zablokować.

Nie powstrzyma Pan złośliwego tekstu. Proszę więc przestać trzymać poświadczenia w zasięgu agenta, który go czyta.

Clavitor (@clavitorai) to magazyn poświadczeń zbudowany dla agentów AI — i przeciwko nim. clavitor.ai

Źródła

[1] Tenet Security — „Agentjacking: przejmowanie agentów kodujących za pomocą fałszywych błędów Sentry" (85% skuteczności; 2 388 organizacji; mechanizm): https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/

[2] The Hacker News — „Atak Agentjacking nakłania agentów AI do uruchamiania złośliwego kodu": https://thehackernews.com/2026/06/agentjacking-attack-tricks-ai-coding.html

[3] The New Stack — „Publiczny klucz Sentry wystarczy, by przejąć Claude Code, Cursor i Codex": https://thenewstack.io/agentjacking-sentry-mcp-attack/

[4] Infosecurity Magazine — „Nowe ataki „Agentjacking" mogą przejmować agentów AI" (reakcja Sentry): https://www.infosecurity-magazine.com/news/agentjacking-attacks-hijack-ai/