AgentCorruption w AWS Bedrock AgentCore: pojedynczy prompt jako droga do kompromitacji środowiska chmurowego

Wprowadzenie do problemu / definicja

AgentCorruption to nazwa scenariusza bezpieczeństwa opisanego w kontekście AWS Bedrock AgentCore, w którym publicznie dostępny agent AI mógł zostać wykorzystany do pozyskania tymczasowych poświadczeń chmurowych i rozszerzenia dostępu na kolejne zasoby w tym samym koncie oraz regionie. Przypadek ten pokazuje, że słabość na styku modelu, narzędzi agenta i środowiska wykonawczego może prowadzić nie tylko do wycieku danych z rozmowy, ale również do naruszenia infrastruktury.

To istotny sygnał dla organizacji wdrażających agentów AI z dostępem do usług sieciowych, pamięci, sekretów i integracji backendowych. W takich architekturach bezpieczeństwo przestaje dotyczyć wyłącznie jakości odpowiedzi modelu i obejmuje także tożsamość chmurową, segmentację uprawnień oraz kontrolę ruchu wykonywanego przez agenta.

W skrócie

Badacze wykazali, że agent uruchomiony w AWS Bedrock AgentCore, wyposażony w możliwość wykonywania żądań HTTP, mógł zostać nakłoniony do odpytywania usługi metadanych instancji. W efekcie możliwe było pozyskanie tymczasowych poświadczeń przypisanych do roli wykonawczej środowiska.

atak mógł rozpocząć się od pojedynczego, odpowiednio przygotowanego promptu,
uzyskane poświadczenia pozwalały na rozpoznanie i wykorzystanie dostępnych uprawnień,
ryzyko rosło wraz z nadmiernie szeroką rolą wykonawczą,
potencjalny wpływ obejmował inne agenty, prywatne sesje, pamięć agenta i sekrety,
AWS wdrożył zmiany ograniczające powierzchnię ataku, w tym dodatkowe utwardzenie mechanizmów dostępu do poświadczeń.

Kontekst / historia

Publiczne ujawnienie badań nastąpiło 8 października 2026 roku, natomiast pierwsze ustalenia dotyczące dostępu do mechanizmu metadanych miały zostać zgłoszone już pod koniec grudnia 2025 roku. Następnie rozszerzono analizę o konsekwencje wynikające z nadmiernych uprawnień domyślnej roli wykonawczej oraz możliwego promienia rażenia w ramach jednego konta i regionu.

Sam wektor nie jest całkowicie nowy z perspektywy bezpieczeństwa chmury. Usługi metadanych od lat są celem ataków w scenariuszach podobnych do SSRF, gdy napastnik potrafi wymusić wykonanie żądania z wnętrza workloadu. Nowością w tym przypadku jest połączenie klasycznego problemu cloud security z warstwą agentową, w której interfejs konwersacyjny staje się praktycznym nośnikiem manipulacji logiką działania aplikacji.

Analiza techniczna

Techniczny rdzeń problemu polegał na tym, że agent działał w kontrolowanym środowisku wykonawczym, ale jednocześnie miał możliwość wykonywania połączeń sieciowych. Jeśli agent otrzymał narzędzie HTTP lub funkcję pobierania zasobów, atakujący mógł skłonić go do wysłania żądania do lokalnego endpointu metadanych i zwrócenia odpowiedzi.

W praktyce oznaczało to uzyskanie prymitywu zbliżonego do SSRF realizowanego przez sam interfejs konwersacyjny. Po pozyskaniu tymczasowych poświadczeń kolejnym etapem było rozpoznanie uprawnień roli oraz dostępnych zasobów. Kluczowym problemem okazał się zbyt szeroki zakres domyślnych uprawnień, który zwiększał blast radius incydentu daleko poza jednego agenta.

Według opisywanego scenariusza skutki techniczne mogły obejmować:

wywoływanie innych agentów w tym samym koncie i regionie,
odczyt prywatnych rozmów i sesji,
manipulowanie historią lub pamięcią agenta,
dostęp do sekretów i danych pomocniczych,
ruch lateralny pomiędzy zasobami powiązanymi z AgentCore.

To szczególnie ważny przykład zmiany charakteru ryzyka. Prompt injection oraz nadużycie narzędzi agenta nie muszą kończyć się na błędnej odpowiedzi modelu czy lokalnym wycieku informacji. W środowiskach zintegrowanych z chmurą mogą prowadzić do przejęcia tożsamości workloadu i naruszenia warstwy wykonawczej.

Konsekwencje / ryzyko

Największe ryzyko wynika z połączenia trzech elementów: publicznej ekspozycji agenta, możliwości wykonywania żądań sieciowych oraz nadmiernych uprawnień przypisanej roli. W takiej konfiguracji zwykły interfejs czatowy może stać się wektorem przejęcia poświadczeń i punktem startowym do dalszej eksploracji środowiska.

Dla organizacji potencjalne skutki obejmują ujawnienie sekretów aplikacyjnych, kompromitację danych przetwarzanych przez agentów, modyfikację pamięci i historii interakcji, a także ingerencję w działanie innych komponentów opartych na tej samej płaszczyźnie uprawnień. Szczególnie groźne są wdrożenia, w których agenci mają integracje z systemami biznesowymi, bazami wiedzy, automatyzacją operacyjną, pocztą, CRM lub narzędziami wsparcia klienta.

Z perspektywy zarządzania ryzykiem przypadek ten pokazuje, że tradycyjne podejście do bezpieczeństwa chmury nie wystarcza, gdy warstwa agentowa otrzymuje autonomię działania. Im większa samodzielność agenta, tym bardziej krytyczne stają się ograniczenia tożsamościowe, sieciowe i funkcjonalne.

Rekomendacje

Podstawową zasadą powinno być bezwzględne stosowanie najmniejszych uprawnień dla każdej roli wykonawczej przypisanej agentowi. Agent nie powinien mieć dostępu ogólnego do zasobów regionalnych ani możliwości komunikacji z innymi agentami, jeśli nie wynika to bezpośrednio z wymagań biznesowych.

Równie istotne jest ograniczenie dostępu do mechanizmów dostarczających tymczasowe poświadczenia oraz kontrola tego, jakie adresy sieciowe mogą być osiągane przez narzędzia agenta. W praktyce należy traktować agentów AI jak uprzywilejowane workloady aplikacyjne, a nie jedynie interfejs użytkownika.

przeprowadzić audyt ról IAM wykorzystywanych przez agentów,
wdrożyć segmentację agentów według funkcji, danych i środowisk,
blokować dostęp do adresów link-local i endpointów metadanych tam, gdzie to możliwe,
ograniczyć lub pośredniczyć wywołania HTTP dostępne dla agentów,
wprowadzić kontrolę wywołań narzędzi oraz walidację ryzykownych promptów,
monitorować odwołania do usług tożsamości, sekretów i pamięci agentów,
oddzielić agentów publicznych od wewnętrznych na poziomie kont, ról i sieci,
regularnie oceniać blast radius dla każdej integracji agentowej.

Podsumowanie

AgentCorruption to jeden z najciekawszych przykładów zderzenia bezpieczeństwa chmurowego z rosnącą autonomią agentów AI. Opisany scenariusz pokazał, że pojedynczy prompt skierowany do publicznego agenta może stać się początkiem przejęcia tożsamości workloadu, a następnie kompromitacji znacznie szerszego fragmentu środowiska.

Najważniejsza lekcja dla zespołów bezpieczeństwa jest jasna: ochrona agentów AI nie może ograniczać się do filtrowania promptów i kontroli odpowiedzi modelu. Kluczowe znaczenie mają uprawnienia, separacja środowisk, twarde ograniczenia sieciowe oraz pełna widoczność tego, jakie operacje agent może wykonać w infrastrukturze.