Badacze Zenity Labs ujawnili podatność w ChatGPT Workspace Agents, która pozwalała przygotować link tworzący agenta AI w środowisku zalogowanego pracownika. Agent mógł odziedziczyć dostęp do poczty, kalendarza, dysku i komunikatorów, wyłączyć pytania o zatwierdzenie oraz cyklicznie wykonywać instrukcje napastnika. Problem został usunięty 8 czerwca 2026 roku, przed opublikowaniem szczegółów.
Czym jest AgentForger?
AgentForger to nazwa podatności wykrytej przez zespół Zenity Labs w mechanizmie budowania firmowych agentów ChatGPT.
Według badaczy pojedynczy, odpowiednio przygotowany link mógł uruchomić proces tworzenia agenta w uwierzytelnionej sesji pracownika. Agent działałby z jego tożsamością i uzyskałby dostęp do wcześniej autoryzowanych aplikacji firmowych.
Atak wymagał spełnienia kilku warunków:
- pracownik musiał być zalogowany do ChatGPT,
- musiał posiadać dostęp do Workspace Agents,
- przynajmniej jeden firmowy konektor musiał być wcześniej autoryzowany,
- użytkownik musiał otworzyć przygotowany odnośnik.
Zagrożenie opisało Zenity Labs w komunikacie z 23 lipca 2026 r.. Techniczne elementy scenariusza przedstawił także The Hacker News.
Luka została naprawiona przed jej ujawnieniem
Zenity zgłosiło problem poprzez program Bugcrowd 4 czerwca 2026 roku. Według badaczy:
- zgłoszenie zostało potwierdzone następnego dnia,
- podatność usunięto w ciągu czterech dni,
- niebezpieczny parametr usunięto 8 czerwca,
- szczegóły kampanii opublikowano dopiero 23 lipca.
Użytkownicy nie muszą instalować osobnej poprawki na komputerach, ponieważ mechanizm znajdował się po stronie platformy.
Zenity informuje również, że nie znalazło dowodów wykorzystania AgentForger w rzeczywistych atakach. Opisane działania zostały zademonstrowane w kontrolowanych scenariuszach proof of concept.
Jak działał atak?
Złośliwe polecenie ukryte w prawdziwym adresie
Agent Builder przyjmował część konfiguracji przez parametry znajdujące się w adresie URL. Jeden z nich pozwalał przekazać początkową instrukcję dla agenta.
Problem polegał na tym, że instrukcja nie była tylko wyświetlana w polu edytora. Po otwarciu strony mogła zostać automatycznie przesłana do Buildera i wykonana.
Link prowadził do prawdziwej domeny ChatGPT. Dla pracownika mógł więc wyglądać znacznie bardziej wiarygodnie niż klasyczna strona phishingowa działająca pod podobnym, ale fałszywym adresem.
Polecenie tworzyło nowego agenta
W demonstracji przygotowanej przez badaczy instrukcja nakazywała:
- utworzyć agenta na podstawie gotowego szablonu,
- połączyć go z dostępnymi konektorami,
- zmienić poziom zatwierdzania operacji,
- opublikować agenta,
- utworzyć cykliczny harmonogram,
- natychmiast uruchomić go w trybie podglądu.
Pracownik mógł nie zauważyć, że otwarcie linku doprowadziło do powstania nowej automatyzacji działającej w jego środowisku.
Dlaczego firmowe konektory zwiększały ryzyko?
Sam agent bez dostępu do danych i aplikacji posiada ograniczone możliwości. Problem staje się poważny, gdy może działać poprzez wcześniej zatwierdzone integracje.
W zależności od konfiguracji konektory mogą zapewnić dostęp do:
- Gmaila albo Outlooka,
- Google Drive,
- kalendarza,
- Slacka,
- Microsoft Teams,
- dokumentów firmowych,
- wewnętrznych baz wiedzy,
- danych udostępnionych konkretnemu pracownikowi.
Agent nie musiał przełamywać haseła do każdego z tych systemów. Korzystał z uprawnień przyznanych wcześniej przez prawdziwego użytkownika.
Legalna tożsamość utrudnia wykrycie
W logach działania agenta mogły wyglądać jak operacje wykonywane przez uprawnionego pracownika:
- odczyt wiadomości,
- pobieranie dokumentów,
- przeszukiwanie dysku,
- wysyłanie wiadomości,
- korzystanie z kalendarza,
- publikowanie treści w komunikatorze.
To istotna różnica w porównaniu z malware działającym na komputerze. Operacje mogły odbywać się w usługach chmurowych bez instalowania pliku wykonywalnego na stacji roboczej.
Agent mógł wyłączyć pytania o zatwierdzenie
W przedstawionym scenariuszu agent ustawiał dostępne konektory w trybie Never ask, czyli bez każdorazowego pytania użytkownika o zgodę.
Następnie uruchamiał się w trybie Preview, który nie był jedynie statycznym podglądem konfiguracji. Pozwalał faktycznie wykonać agenta z przyznanymi mu uprawnieniami.
Połączenie kilku elementów tworzyło poważne ryzyko:
- legalna sesja pracownika,
- firmowe konektory,
- brak dodatkowego zatwierdzania,
- możliwość publikacji,
- automatyczny harmonogram,
- natychmiastowe pierwsze uruchomienie.
Harmonogram zapewniał trwałość
AgentForger nie musiał kończyć działania po zamknięciu karty przeglądarki. Złośliwa instrukcja mogła ustawić jego uruchamianie co godzinę.
Badacze pokazali scenariusz, w którym agent podczas każdego uruchomienia:
- sprawdzał skrzynkę pracownika,
- wyszukiwał wiadomości od napastnika,
- rozpoznawał temat rozpoczynający się od słowa
TASK, - traktował treść wiadomości jako nowe zadanie,
- wykonywał polecenie,
- odsyłał wynik na adres kontrolowany przez napastnika.
Pierwsze kliknięcie tworzyło więc kanał sterowania. Kolejne instrukcje mogły być dostarczane pocztą bez następnych kliknięć ofiary.
Co mógł zrobić przejęty agent?
W kilkunastu demonstracjach Zenity pokazało możliwość wykorzystania agenta do:
- rozpoznania struktury organizacji,
- przeszukiwania firmowej poczty,
- pobierania dokumentów z chmury,
- poszukiwania haseł i innych sekretów w wiadomościach,
- wysyłania danych na zewnętrzny adres,
- podszywania się pod pracownika,
- rozsyłania phishingu przez komunikator,
- tworzenia kolejnych agentów,
- wykonywania nowych zadań dostarczanych przez napastnika.
Zakres rzeczywistych możliwości zawsze zależałby od uprawnień użytkownika i podłączonych aplikacji. Agent nie mógł automatycznie uzyskać dostępu do danych, których pracownik sam nie mógł odczytać.
Szczególne ryzyko kont uprzywilejowanych
Jeżeli link otworzyłaby osoba posiadająca szeroki dostęp, na przykład:
- administrator,
- członek zarządu,
- pracownik finansów,
- osoba z działu HR,
- pracownik pomocy technicznej,
- menedżer projektu,
- administrator usług chmurowych,
agent mógłby otrzymać dostęp do znacznie bardziej wrażliwych informacji niż w przypadku zwykłego konta użytkownika.
AgentForger a klasyczny phishing
Klasyczny phishing często prowadzi do:
- kradzieży hasła,
- przejęcia sesji,
- uruchomienia malware,
- podania kodu MFA,
- wykonania pojedynczej płatności.
AgentForger reprezentuje nieco inny model. Celem nie jest wyłącznie przejęcie konkretnego sekretu, lecz stworzenie wewnątrz organizacji nowego wykonawcy działającego z legalną tożsamością pracownika.
Taki agent może:
- działać cyklicznie,
- odbierać nowe zadania,
- podejmować działania w kilku aplikacjach,
- łączyć informacje z różnych źródeł,
- wykorzystywać legalne mechanizmy automatyzacji.
Dlatego zabezpieczenie agentów AI nie może ograniczać się do sprawdzania, czy sam model generuje bezpieczne odpowiedzi.
Co powinna sprawdzić organizacja?
Mimo że luka została naprawiona, firmy korzystające z agentów i firmowych konektorów powinny przeprowadzić podstawowy audyt.
1. Przygotuj listę agentów
Dla każdego agenta ustal:
- nazwę i przeznaczenie,
- właściciela,
- datę utworzenia,
- osobę, która go opublikowała,
- połączone aplikacje,
- zakres uprawnień,
- aktywne harmonogramy,
- odbiorców wyników,
- ustawienia zatwierdzania.
Agent bez znanego właściciela powinien zostać wyłączony do czasu wyjaśnienia.
2. Sprawdź agentów utworzonych przed 8 czerwca
Szczególną uwagę należy zwrócić na agentów powstałych w czasie, gdy podatny mechanizm mógł być dostępny.
Sygnałami ostrzegawczymi mogą być:
- nieznana instrukcja systemowa,
- harmonogram uruchamiany co godzinę,
- dostęp do wielu aplikacji jednocześnie,
- ustawienie Never ask dla operacji wrażliwych,
- wysyłanie wyników poza organizację,
- zadania odczytywane z poczty,
- brak uzasadnienia biznesowego,
- agent utworzony przez pracownika, który go nie rozpoznaje.
Znalezienie jednego takiego elementu nie dowodzi ataku. Wymaga jednak wyjaśnienia.
3. Przejrzyj logi połączonych usług
Należy sprawdzić nie tylko historię samego agenta, lecz również:
- wiadomości wysłane przez Outlook lub Gmail,
- pobieranie dużej liczby plików,
- dostęp do dokumentów w nietypowych godzinach,
- wiadomości wysłane przez Slack i Teams,
- nowe reguły pocztowe,
- zmiany kalendarza,
- operacje na danych wrażliwych,
- komunikację z nieznanymi odbiorcami.
4. Skontroluj przyznane konektory
Dla każdego użytkownika warto ustalić:
- które aplikacje połączył z agentami,
- czy wszystkie integracje są nadal potrzebne,
- czy dostęp obejmuje zapis, czy tylko odczyt,
- jakie dane są dostępne przez konektor,
- czy uprawnienia można ograniczyć,
- kiedy połączenie zostało ostatnio użyte.
Nieaktywny konektor nadal może stanowić drogę do danych, jeżeli jego autoryzacja pozostaje ważna.
Jak reagować na podejrzanego agenta?
- Wyłącz harmonogram i zatrzymaj wykonywanie agenta.
- Zapisz jego instrukcje, konfigurację, właściciela i czas utworzenia.
- Odłącz konektory i unieważnij powiązane tokeny.
- Zabezpiecz historię działań agenta i logi aplikacji.
- Ustal, do jakich danych posiadał dostęp.
- Sprawdź wiadomości i pliki wysłane poza organizację.
- Zweryfikuj działania wykonane w imieniu pracownika.
- Unieważnij aktywne sesje użytkownika.
- Zmień dane uwierzytelniające, jeśli mogły zostać ujawnione.
- Powiadom osoby, które otrzymały podejrzane wiadomości.
- Oceń, czy doszło do naruszenia danych osobowych lub tajemnicy przedsiębiorstwa.
- Nie usuwaj agenta przed zabezpieczeniem materiału do analizy.
Jak bezpiecznie wdrażać agentów AI?
Stosuj zasadę minimalnych uprawnień
Agent przygotowujący podsumowanie dokumentu nie potrzebuje możliwości wysyłania poczty. Agent zarządzający kalendarzem nie musi posiadać dostępu do całego dysku.
Każdy konektor powinien otrzymać tylko uprawnienia konieczne do określonego zadania.
Pozostaw zatwierdzenie ważnych operacji
Dodatkowego potwierdzenia powinny wymagać między innymi:
- wysłanie wiadomości,
- udostępnienie dokumentu,
- usunięcie danych,
- zmiana uprawnień,
- publikacja treści,
- utworzenie kolejnej automatyzacji,
- przekazanie informacji poza firmę.
Tryb bez pytania nie powinien być domyślny dla operacji wpływających na ludzi, dane lub systemy.
Ogranicz automatyczne harmonogramy
Każdy cyklicznie uruchamiany agent powinien mieć:
- zatwierdzonego właściciela,
- opis celu biznesowego,
- określony czas działania,
- dozwolone źródła poleceń,
- maksymalny zakres operacji,
- rejestrowanie wykonanych czynności,
- możliwość szybkiego zatrzymania.
Traktuj linki do kreatorów jak pliki wykonywalne
Pracownicy powinni zachować ostrożność wobec odnośników prowadzących bezpośrednio do kreatora agenta, automatyzacji lub gotowego szablonu.
Nawet prawidłowa domena nie gwarantuje bezpieczeństwa całego adresu. Parametry URL mogą przekazywać instrukcje albo konfigurację.
Prowadź oddzielny rejestr agentów AI
Standardowa lista kont użytkowników nie pokazuje pełnego ryzyka. Organizacja powinna prowadzić również ewidencję:
- agentów,
- botów,
- automatyzacji,
- kont serwisowych,
- konektorów,
- tokenów,
- harmonogramów,
- źródeł instrukcji.
Agent AI powinien być traktowany jako osobna tożsamość maszynowa, nawet jeśli formalnie działa w imieniu pracownika.
Fakty potwierdzone i informacje nieustalone
Potwierdzone przez badaczy:
- AgentForger dotyczył mechanizmu ChatGPT Workspace Agents.
- Atak rozpoczynał się od otwarcia przygotowanego linku.
- Link mógł przekazać instrukcję do Agent Buildera.
- Agent mógł połączyć się z aplikacjami wcześniej autoryzowanymi przez użytkownika.
- Demonstracja obejmowała wyłączenie pytań o zatwierdzenie i uruchomienie harmonogramu.
- Agent mógł odbierać kolejne zadania przez firmową pocztę.
- Zenity zgłosiło problem 4 czerwca 2026 roku.
- Według Zenity podatność usunięto 8 czerwca, przed publicznym ujawnieniem.
- Badacze nie znaleźli dowodów wykorzystania luki w rzeczywistych atakach.
Niepotwierdzone publicznie:
- wykorzystanie AgentForger przeciwko konkretnej organizacji,
- kradzież rzeczywistych danych przy użyciu tej podatności,
- liczba środowisk, które miały wcześniej podatną konfigurację,
- stworzenie złośliwych agentów poza testami Zenity,
- przeprowadzenie przy jej użyciu rzeczywistej kampanii BEC.
Ocena: najważniejszą lekcją nie jest sama usunięta luka, lecz zmiana modelu zagrożeń. Agent posiadający tożsamość użytkownika, konektory i harmonogram może działać jak konto serwisowe, aplikacja chmurowa i wewnętrzny pracownik jednocześnie. Wymaga więc własnej inwentaryzacji, logowania i kontroli uprawnień.
Podsumowanie
AgentForger został szybko naprawiony i nie ma dowodów, że wykorzystano go przeciwko rzeczywistym organizacjom. Nie oznacza to jednak, że firmy mogą pominąć problem bezpieczeństwa agentów AI.
Podłączenie agenta do poczty, dysku i komunikatora tworzy nową tożsamość zdolną do wykonywania realnych działań. Organizacje powinny wiedzieć, jakie agenty działają w ich środowisku, kto je utworzył, z jakich konektorów korzystają oraz które operacje wykonują bez zatwierdzenia człowieka.