AgentCorruption w AWS Bedrock AgentCore: jak pojedynczy prompt mógł zagrozić całemu środowisku

Wprowadzenie do problemu / definicja

Rosnąca popularność agentowych systemów AI w środowiskach chmurowych otwiera nowe możliwości automatyzacji, ale jednocześnie tworzy nową klasę zagrożeń bezpieczeństwa. Gdy agent otrzymuje dostęp do narzędzi sieciowych, interfejsów API i zasobów organizacji, przestaje być wyłącznie warstwą konwersacyjną, a staje się aktywnym elementem wykonawczym infrastruktury.

Przypadek AgentCorruption pokazuje, iż odpowiednio skonstruowany prompt może doprowadzić do wymuszenia działań wykraczających poza oczekiwany scenariusz użycia. W analizowanym przypadku chodziło o środowiska oparte na AWS Bedrock AgentCore, gdzie agent mógł zostać nakłoniony do pobrania danych z usługi metadanych instancji, a następnie do wykorzystania uzyskanych poświadczeń w dalszych operacjach w chmurze.

W skrócie

Badacze opisali scenariusz, w którym agent uruchomiony w AWS Bedrock AgentCore mógł zostać skłoniony do wykonania żądania HTTP do Instance Metadata Service. Taki krok umożliwiał pozyskanie tymczasowych poświadczeń oraz informacji o środowisku wykonawczym.

Najistotniejsze ustalenia można podsumować następująco:

• atak zaczynał się od pojedynczego promptu lub odpowiednio przygotowanej interakcji z agentem,
• agent mógł uzyskać dostęp do danych z usługi metadanych instancji,
• tymczasowe poświadczenia otwierały drogę do dalszej analizy uprawnień IAM,
• domyślne role wykonawcze mogły zwiększać promień rażenia incydentu w obrębie regionu,
• w odpowiedzi wdrożono zmiany ograniczające ryzyko, w tym korekty dotyczące IMDS i uprawnień.

Kontekst / historia

Ryzyko związane z dostępem do Instance Metadata Service jest dobrze znane w bezpieczeństwie chmury. Od lat wiadomo, iż komponent zdolny do wysłania żądania do interfejsu metadanych może w pewnych warunkach uzyskać wrażliwe informacje, takie jak tymczasowe poświadczenia, identyfikatory instancji czy dane konfiguracyjne.

W tradycyjnym modelu zagrożeń podobne przypadki kojarzono głównie z podatnościami SSRF. W architekturze agentowej wektor ten zyskuje nowy wymiar, ponieważ nie musi opierać się wyłącznie na klasycznej luce aplikacyjnej. Wystarczy, iż agent ma możliwość użycia narzędzia sieciowego i zostanie przekonany do wykonania działania, którego projektant systemu nie przewidział.

To właśnie dlatego AgentCorruption wpisuje się w szerszy trend bezpieczeństwa AI, gdzie kluczowym problemem staje się przecięcie trzech obszarów: automatyzacji, szerokich uprawnień oraz podatności na manipulację wejściem użytkownika.

Analiza techniczna

Sedno problemu dotyczyło relacji między agentem, jego środowiskiem uruchomieniowym oraz usługą metadanych instancji. o ile agent miał możliwość wykonywania żądań HTTP, a izolacja środowiska nie blokowała komunikacji z IMDS, możliwe było skłonienie go do pobrania danych z tego interfejsu.

Technicznie scenariusz ten można opisać jako połączenie prompt injection z nadużyciem przyznanych uprawnień. Agent nie musiał omijać zabezpieczeń w klasycznym sensie. Wystarczyło, iż wykonał polecenie mieszczące się w jego technicznych możliwościach, ale niezgodne z intencją administratora czy twórcy aplikacji.

Po uzyskaniu tymczasowych poświadczeń atakujący mógł sprawdzić efektywny zakres roli IAM przypisanej środowisku wykonawczemu. jeżeli rola była zbyt szeroka, otwierało to drogę do dalszych działań, takich jak wywoływanie innych agentów, przeglądanie sesji czy dostęp do wybranych sekretów. W efekcie pojedynczy publicznie dostępny agent mógł stać się punktem wejścia do znacznie szerszej kompromitacji.

W praktyce oznacza to, iż bezpieczeństwo agentów AI zależy nie tylko od jakości filtrów wejścia czy ochrony promptów, ale również od architektury sieciowej, zasad IAM oraz ograniczeń nakładanych na narzędzia dostępne agentowi.

Konsekwencje / ryzyko

Największym zagrożeniem nie był sam odczyt metadanych, ale możliwość eskalacji w obrębie konta i regionu. o ile publiczny agent dysponuje szerokimi uprawnieniami, kompromitacja jego środowiska może doprowadzić do przejęcia kolejnych komponentów lub dostępu do bardziej wrażliwych zasobów.

Zakres ryzyka obejmuje kilka poziomów:

• wyciek tymczasowych poświadczeń i wykonywanie działań w imieniu usługi,
• ruch boczny między agentami lub innymi zasobami współdzielącymi role i mechanizmy orkiestracji,
• dostęp do historii sesji, sekretów i danych operacyjnych,
• ujawnienie tokenów API, danych klientów i informacji kontekstowych,
• utrata integralności działania agentów odpowiedzialnych za procesy biznesowe.

Z perspektywy obrony szczególnie istotne jest to, iż atak może zaczynać się od legalnego interfejsu użytkownika, takiego jak chatbot, asystent wsparcia czy agent samoobsługowy. W takim modelu granica między aplikacją publiczną a uprzywilejowanym zapleczem staje się znacznie mniej wyraźna.

Rekomendacje

Organizacje korzystające z agentów AI w AWS powinny potraktować je jak uprzywilejowane workloady, a nie wyłącznie interfejsy użytkownika. najważniejsze znaczenie ma zasada najmniejszych uprawnień oraz ograniczenie dostępu do wszystkich usług i narzędzi, które nie są absolutnie niezbędne.

Najważniejsze działania obronne obejmują:

• audyt ról IAM przypisanych agentom i usunięcie zbędnych uprawnień,
• ograniczenie możliwości wykonywania dowolnych żądań HTTP,
• blokowanie lub ścisłą kontrolę dostępu do endpointów metadanych,
• segmentację środowisk według funkcji, regionu i poziomu zaufania,
• monitorowanie nietypowych wywołań API związanych z AgentCore, STS i usługami przechowującymi sekrety,
• wdrażanie mechanizmów detekcji prompt injection oraz walidacji działań wykonywanych przez narzędzia agenta,
• regularny przegląd logów sesji pod kątem prób uzyskania poświadczeń lub dostępu do metadanych.

Warto również zadbać o kontrolę egress, zatwierdzanie operacji wysokiego ryzyka oraz ograniczenie pamięci i zakresu działania każdego agenta do jasno zdefiniowanego przypadku użycia. Im mniejszy zakres swobody ma agent, tym mniejszy potencjalny wpływ skutecznej manipulacji.

Podsumowanie

AgentCorruption to istotny sygnał ostrzegawczy dla organizacji rozwijających agentowe systemy AI w chmurze. Pokazuje, iż choćby pojedynczy prompt może uruchomić łańcuch zdarzeń prowadzący od manipulacji zachowaniem modelu do kompromitacji zasobów infrastrukturalnych.

Bezpieczeństwo takich wdrożeń wymaga więc spojrzenia szerszego niż sama ochrona modelu. najważniejsze pozostają izolacja środowiska wykonawczego, blokowanie dostępu do wrażliwych usług metadanych, rygorystyczne zarządzanie uprawnieniami IAM oraz stały monitoring działań wykonywanych przez agentów.

Źródła

1. Dark Reading — AgentCorruption Puts AWS Environments at Risk With Single Prompt
2. Zenity Labs — AgentCorruption
3. AWS Documentation — Security best practices in IAM
4. AWS Documentation — Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service
5. AWS Documentation — Amazon EC2 instance metadata options