AgentForger: jeden link tworzy agenta AI w firmie

Klasyczny CSRF (Cross-Site Request Forgery) polega na tym, że kliknięcie w spreparowany link powoduje wykonanie jednej niezamierzonej akcji w aplikacji, w której jesteś zalogowany: zmiana adresu e-mail, przelew, usunięcie zasobu. Nieprzyjemne, ale ograniczone — jedno żądanie, jeden skutek.

Badacze z Zenity Labs pokazali, co się dzieje, gdy tę samą technikę wycelować w platformę agentową. Podatność, którą nazwali AgentForger, pozwalała jednym linkiem utworzyć, skonfigurować, opublikować i zaplanować autonomicznego agenta w ChatGPT Workspace ofiary. Skutkiem nie było pojedyncze żądanie, tylko nowy, trwały byt działający wewnątrz organizacji — z narzędziami, harmonogramem, zatwierdzonymi uprawnieniami i dostępem do już podłączonych konektorów. OpenAI naprawiło błąd w cztery dni od zgłoszenia; szczegóły upubliczniono pod koniec lipca 2026.

To najciekawsza luka tego miesiąca nie dlatego, że była trudna technicznie, ale dlatego, że pokazuje nową klasę skutków.

Dlaczego „CSRF na agenta” to inna kategoria ryzyka

Zenity nazwało to Cross-Site Agent Forgery i ta nazwa dobrze oddaje różnicę. Porównajmy:

	Klasyczny CSRF	AgentForger
Skutek	jedna akcja	powstanie nowego agenta
Czas życia	moment kliknięcia	trwały, do wykrycia i usunięcia
Uprawnienia	te, co ma sesja, jednorazowo	narzędzia + konektory, wielokrotnie
Inicjatywa	brak	agent działa sam, wg harmonogramu
Widoczność	ślad w logach akcji	wygląda jak legalny zasób firmowy

Kluczowa zmiana jest w wierszu „inicjatywa”. Ofiara klika raz, a napastnik zyskuje coś, co samo wraca do pracy — w opisywanym scenariuszu agent odpytywany był cyklicznie, w krótkich interwałach. To już nie jest atak typu „ukradnij i wyjdź”, tylko implant: mechanizm trwałej obecności, tyle że zbudowany nie z malware’u, lecz z legalnych funkcji platformy AI.

Łańcuch ataku krok po kroku

Na podstawie opisu Zenity Labs przebieg wygląda tak:

1. Dostarczenie linku. Zwykły phishing — wiadomość, komunikator, dokument. Ofiara musi być zalogowana do swojego środowiska ChatGPT Workspace (a jest, bo to narzędzie pracy).
2. Wymuszenie akcji w tle. Kliknięcie powoduje wysłanie żądań do panelu agentów w kontekście uwierzytelnionej sesji ofiary. Bez widocznego okna kreatora, bez świadomej zgody.
3. Utworzenie i konfiguracja agenta. Napastnik definiuje instrukcje systemowe agenta (czyli jego „cel”), przypisuje mu narzędzia i zatwierdzenia.
4. Publikacja i harmonogram. Agent zostaje opublikowany w przestrzeni roboczej i dostaje cykliczny wyzwalacz — dzięki temu wraca do działania bez udziału ofiary.
5. Praca na cudzych uprawnieniach. Agent korzysta z już autoryzowanych konektorów ofiary: dysków w chmurze, komunikatorów, poczty. Nie musi łamać żadnego uwierzytelnienia — dziedziczy dostęp, który organizacja świadomie przyznała człowiekowi.
6. Realizacja celu atakującego. W scenariuszu badaczy oznaczało to rozpoznanie, zbieranie wrażliwych dokumentów i wyłapywanie haseł pojawiających się w rozmowach.

Zwróć uwagę na punkt 5 — tu leży sedno. Nie doszło do żadnego „włamania” w klasycznym sensie. Doszło do nadużycia zaufania delegowanego: firma pozwoliła pracownikowi podłączyć narzędzia do asystenta, a atakujący przejął tę delegację.

Autonomiczny insider — dlaczego to trudne do wykrycia

Tradycyjne wykrywanie zagrożeń szuka rzeczy nietypowych: nieznanych plików wykonywalnych, dziwnych procesów, ruchu do podejrzanych domen. AgentForger nie generuje żadnego z tych sygnałów.

Z perspektywy monitoringu widać: firmowe konto, firmowe narzędzie SaaS, autoryzowany wcześniej konektor, dostęp do dokumentów, do których pracownik i tak ma prawo. Wszystko wygląda legalnie, bo formalnie jest legalne. Anomalią jest wyłącznie intencja i rytm — agent, którego nikt świadomie nie zamawiał, pracujący regularnie i sięgający szerzej niż jego rzekomy właściciel.

To dokładnie ta klasa problemu, którą opisywaliśmy przy tożsamościach nieludzkich (NHI): agent to konto, które ma uprawnienia, wykonuje akcje i powinno podlegać cyklowi życia — a w większości firm nie podlega żadnemu. Pokrewne ryzyko po stronie przeglądarki omawialiśmy w tekście o bezpieczeństwie agentów przeglądarkowych.

Co z tego wynika dla obrońcy

Traktuj „utworzenie agenta” jak operację wysokiego ryzyka. Tak jak reset MFA czy nadanie roli administratora. Powinna wymagać świadomego potwierdzenia odpornego na CSRF, a najlepiej dodatkowej akceptacji, gdy agent dostaje harmonogram lub dostęp do konektorów z danymi.

Inwentaryzuj agentów. Zadaj sobie pytanie, na które dziś większość organizacji nie potrafi odpowiedzieć: ilu agentów działa w naszej przestrzeni roboczej, kto ich stworzył, jakie mają narzędzia i kiedy ostatnio coś zrobiły? Bez tej listy nie wykryjesz jednego agenta więcej. To ta sama dyscyplina, co przy wykrywaniu shadow AI.

Ogranicz zakres konektorów. Zasada minimalnych uprawnień dotyczy integracji tak samo jak kont. Konektor do całego dysku firmowego „bo wygodniej” to gotowy kanał eksfiltracji w dniu, w którym ktoś przejmie agenta. Warto tu wrócić do fundamentów bezpieczeństwa OAuth 2.0 — zakresy, zgody i możliwość ich odebrania.

Loguj i alarmuj na zdarzenia cyklu życia agenta. Utworzenie, zmiana instrukcji systemowych, dodanie narzędzia, nadanie harmonogramu, publikacja. To są Twoje 4720/4732 świata agentowego — jeśli ich nie zbierasz, nie masz jak zauważyć implantu.

Uwzględnij agentów w planie reagowania. Odpowiedz zawczasu: kto może natychmiast wyłączyć agenta? jak odbieramy zgody konektorów? jak ustalamy, do czego agent zdążył sięgnąć? Rozpisaliśmy to w reagowaniu na incydenty z udziałem AI.

Testuj platformę agentową jak aplikację. Podatność była w warstwie webowej produktu, nie w modelu. Klasyczne pytania AppSec — czy operacje zmieniające stan są chronione tokenem, czy SameSite jest ustawione sensownie, czy krytyczne akcje wymagają ponownego uwierzytelnienia — okazały się ważniejsze niż cokolwiek związanego z LLM-em. Do oceny całości przydaje się audyt bezpieczeństwa AI/LLM i harness do red teamingu agentów.

Najczęstsze pytania (FAQ)

Czy to była podatność modelu, czy aplikacji? Aplikacji. Nie chodziło o prompt injection ani o „oszukanie” modelu, tylko o brak właściwej ochrony operacji zmieniających stan w panelu agentów. Model wykonywał dokładnie to, co miał w instrukcjach — problem w tym, że instrukcje napisał napastnik.

Luka jest naprawiona — po co się tym zajmować? Bo naprawiono jedną instancję ogólnego wzorca. Każda platforma pozwalająca tworzyć agentów z narzędziami, harmonogramem i dostępem do danych ma tę samą powierzchnię ataku. AgentForger to dowód wykonalności, a nie odosobniony przypadek.

Jak sprawdzić, czy coś takiego u nas nie działa? Przejrzyj listę agentów/asystentów w firmowej przestrzeni roboczej: kto jest autorem, jakie mają instrukcje, harmonogramy i podłączone konektory. Szukaj bytów bez właściciela, z cyklicznym wyzwalaczem i szerokim dostępem. Następnie sprawdź logi konektorów pod kątem odczytów w regularnych odstępach poza godzinami pracy.

Czy blokada „AI w firmie” rozwiązuje problem? Nie — przenosi go do shadow IT, gdzie nie masz żadnej widoczności. Skuteczniejsze jest udostępnienie kontrolowanej ścieżki: zatwierdzone narzędzia, ograniczone konektory, rejestr agentów i logowanie zdarzeń.

Podsumowanie

AgentForger pokazuje, że w architekturze agentowej stara podatność webowa daje nową jakość skutku. Jedno kliknięcie nie kończy się pojedynczą akcją, lecz powołaniem autonomicznego pracownika działającego na uprawnieniach ofiary, według instrukcji napastnika, w rytmie ustalonym przez napastnika. Obrona nie wymaga egzotycznych narzędzi: potrzebna jest inwentaryzacja agentów, minimalne zakresy konektorów, logowanie cyklu życia agentów i traktowanie ich tworzenia jak operacji uprzywilejowanej. Jeśli wdrażasz agentów AI i chcesz wiedzieć, co się stanie po jednym kliknięciu Twojego pracownika — sprawdźmy to razem.

---

Źródła i dalsza lektura: Zenity Labs — AgentForger, The Hacker News, The Register, OWASP Top 10 for LLM Applications.