AgentCorruption: jeden prompt przejmował agentów AI w AWS

Co odkryli badacze Zenity w Amazon Bedrock AgentCore

Badacze Zenity Labs opisali łańcuch słabości, który nazwali AgentCorruption. Jego punktem wyjścia był publicznie dostępny agent AI, czyli na przykład asystent obsługi klienta na stronie firmy. Według autorów agent zbudowany na otwartym frameworku Strands, z wbudowanymi narzędziami do zapytań sieciowych, wykonał polecenie, które ujawniło jego tymczasowe poświadczenia w chmurze AWS.

Źródłem problemu była według Zenity niewystarczająca izolacja środowiska, w którym działają agenty AgentCore Runtime. Agent mógł odpytać usługę metadanych instancji (IMDS), czyli wewnętrzny mechanizm chmury przekazujący maszynie m.in. jej dane uwierzytelniające. Badacze podkreślają, że problem leżał w platformie, a nie w konkretnym narzędziu, więc dotyczył każdego agenta zdolnego do wysyłania zapytań sieciowych.

Zenity opublikowało wyniki w serii czterech wpisów. Opisuje w nich początkowy dostęp, nadużycie zbyt szerokiej roli, zatruwanie pamięci agentów i kradzież poświadczeń z AWS Secrets Manager. Pominęliśmy techniczne szczegóły, które mogłyby ułatwić powtórzenie ataku.

Do czego dawała dostęp domyślna rola agenta

Samo przejęcie poświadczeń jednego agenta nie byłoby tak groźne, gdyby jego uprawnienia były wąskie. Według Zenity domyślna rola wykonawcza AgentCore obejmowała jednak cały region konta AWS i pozwalała na odczyt, zapis i usuwanie danych. W praktyce jeden przejęty agent stawał się kluczem do pozostałych agentów firmy.

Badacze wymieniają następujące możliwości, jakie dawała im ta rola:

• wykrycie nazw i identyfikatorów innych agentów w regionie na podstawie grup logów,
• pobranie obrazów kontenerów innych agentów i odczyt ich kodu źródłowego,
• wywoływanie prywatnych agentów, np. agenta obsługującego rozliczenia,
• odczyt prywatnych rozmów użytkowników zapisanych w pamięci agentów,
• dopisywanie i usuwanie zdarzeń w historii rozmów, co pozwala trwale zmienić zachowanie agenta i zatrzeć ślady,
• dostęp do sekretów w AWS Secrets Manager, w tym kluczy do usług spoza AWS.

Oś czasu zgłoszenia i reakcja AWS

Od pierwszego zgłoszenia do publikacji minęło ponad dziewięć miesięcy. Poniższa oś czasu pochodzi z głównego wpisu Zenity Labs. AWS nie opublikował własnego komunikatu ani biuletynu dotyczącego AgentCorruption, a w materiałach badaczy brak bezpośredniej wypowiedzi firmy.

• 25 grudnia 2025 roku - Zenity zgłasza AWS dostęp agentów do usługi metadanych instancji (w jednym z wpisów serii pojawia się też data 17 grudnia).
• 12 stycznia 2026 roku - drugie zgłoszenie dotyczy zbyt szerokiej domyślnej roli i zasięgu możliwych szkód.
• 14 lutego 2026 roku - AgentCore przechodzi na IMDSv2, a nowo wdrażane agenty startują wyłącznie z tą wersją usługi metadanych.
• 25 lutego 2026 roku - według Zenity AWS informuje, że pracuje nad przyczyną problemu. Domyślna rola pozostaje bez zmian.
• 12 kwietnia 2026 roku - AWS zamyka pierwsze zgłoszenie ze statusem informacyjnym.
• 22 czerwca 2026 roku - Zenity potwierdza, że uprawnienia domyślnej roli nadal się nie zmieniły.
• 29 września 2026 roku - badacze odnotowują wyraźne ograniczenie domyślnej roli. AWS usunął m.in. wywoływanie agentów między regionami, odczyt prywatnych rozmów i dostęp do Secrets Manager.

Czego nie wiadomo o skutkach luki

Najważniejsza niewiadoma dotyczy agentów wdrożonych przed zmianami. Zenity pisze, że z IMDSv2 startują nowo wdrażane agenty, ale nie wyjaśnia, czy AWS zaktualizował starsze wdrożenia i role utworzone wcześniej. Rola już przypisana agentowi zwykle nie zmienia się sama, więc ten punkt każda firma powinna sprawdzić we własnym koncie.

Badanie nie zawiera też informacji o wykorzystaniu luki poza testami badaczy ani o liczbie klientów, których mogła dotyczyć. Zenity Labs jest działem badawczym firmy sprzedającej platformę bezpieczeństwa agentów AI, także dla AgentCore. Nie podważa to opisanych ustaleń, ale wyjaśnia, dlaczego wnioski autorów akcentują skalę ryzyka.

Podobny problem opisała wcześniej Unit 42, zespół badawczy Palo Alto Networks. W kwietniu 2026 roku ostrzegł, że role tworzone automatycznie przez zestaw startowy AgentCore obejmują całe konto AWS. AWS dodał wtedy do dokumentacji ostrzeżenie, że takie role służą do prac rozwojowych i testów, a nie do środowisk produkcyjnych.

Co AgentCorruption oznacza dla polskich firm

Dla polskich firm budujących agentów na AWS najważniejszy wniosek dotyczy konfiguracji, a nie samego modelu językowego. Agent dostępny publicznie, np. na stronie sklepu, powinien być traktowany jak niezaufany punkt wejścia. Jeśli działa na tym samym koncie i w tym samym regionie co agenty wewnętrzne, szeroka rola może połączyć oba światy.

Sprawa ma też wymiar prawny. Jeżeli pamięć agentów zawierała dane osobowe klientów, a ktoś nieuprawniony uzyskał do niej dostęp, administrator danych musi ocenić, czy doszło do naruszenia ochrony danych w rozumieniu RODO. Takie naruszenie co do zasady zgłasza się prezesowi UODO w ciągu 72 godzin od jego stwierdzenia. Samo badanie Zenity nie świadczy o tym, że do naruszeń doszło.

Co sprawdzić w koncie AWS już teraz

Poniższa lista to wnioski redakcji z badań Zenity i Unit 42 oraz z zaleceń AWS dotyczących ról w środowisku produkcyjnym. Nie zastępuje audytu bezpieczeństwa konkretnego wdrożenia.

1. Zrób listę wszystkich agentów AgentCore i sprawdź, które role IAM są do nich przypisane, zwłaszcza w przypadku agentów wdrożonych przed lutym 2026 roku.
2. Zastąp role domyślne i utworzone przez zestaw startowy osobną rolą dla każdego agenta, ograniczoną do konkretnych zasobów zamiast symboli wieloznacznych.
3. Oddziel agentów publicznych od agentów wewnętrznych - najlepiej osobnymi kontami AWS albo co najmniej osobnymi rolami bez wzajemnego dostępu.
4. Upewnij się, że agenty korzystają z IMDSv2, i ogranicz ich ruch wychodzący do adresów, których naprawdę potrzebują.
5. Nie przechowuj sekretów w obrazach kontenerów, zmiennych konfiguracyjnych ani w pamięci rozmów. Rotuj klucze, jeśli istnieje ryzyko, że były dostępne dla agenta.
6. Przejrzyj logi pod kątem nietypowych wywołań między agentami, pobrań obrazów kontenerów i zmian w historii rozmów.

Ocena redakcji

W naszej ocenie AgentCorruption dobrze pokazuje, że przy agentach AI granicę bezpieczeństwa wyznaczają uprawnienia, a nie skuteczność filtrów nałożonych na model. Prompt injection, czyli wstrzyknięcie modelowi poleceń przez treść podaną z zewnątrz, trudno całkowicie wyeliminować. Szkody, jakie może wyrządzić, zależą już jednak od tego, do czego agent ma dostęp. Długi czas reakcji AWS i brak publicznego komunikatu utrudniają klientom ocenę, czy ich wcześniejsze wdrożenia wymagają zmian, dlatego bezpieczniej założyć, że tak.