Jeden prompt przejął wszystkie agenty AI w koncie AWS

Wystarczyła jedna wiadomość w oknie czatu, by badacze z Zenity Labs przejęli kontrolę nad każdym agentem AI działającym w tym samym koncie i regionie AWS. Luka, którą nazwali „AgentCorruption”, dotyczyła platformy Amazon Bedrock AgentCore – rozwiązania, które AWS promuje jako narzędzie dla firm do uruchamiania agentów z dostępem do narzędzi, pamięci i systemów zarządzania uprawnieniami. Problem okazał się systemowy i dotyczył agentów z wbudowanymi narzędziami w różnych konfiguracjach.

Jak pojedynczy agent stał się bramą do całego konta

Punktem wyjścia był znany problem chmury obliczeniowej. AWS udostępnia wewnętrzny adres 169.254.169.254, pod którym działa Instance Metadata Service (IMDS) – usługa serwująca tymczasowe dane uwierzytelniające, których instancje używają do komunikacji z AWS. Kto przechwyci te poświadczenia, może podszyć się pod daną instancję. Standardowo agent AI nie powinien mieć do nich dostępu. Według analizy Zenity, AgentCore nie zapewniał jednak właściwej izolacji.

Badacze zbudowali testowego agenta przy użyciu Strands – otwartego frameworka od AWS zawierającego narzędzie webowe. Następnie poprosili go zwykłym językiem, by odpytał usługę metadanych i przesłał wyniki na zewnętrzny serwer. Agent wykonał polecenie bez oporu. Jak ujęli to sami badacze, granica piaskownicy, która powinna była ich powstrzymać, po prostu nie istniała.

Skradzione poświadczenia działały poza platformą – na własnej maszynie badaczy. Od tego momentu agent nie był już potrzebny. Usługa metadanych ujawniła także inne wrażliwe dane: materiały certyfikatów i kluczy dla wewnętrznej usługi AWS oraz presigned URL prowadzący do wewnętrznego zasobu S3, który nie należał do konta badaczy. Jak podkreśla Zenity, pominięcie narzędzia webowego niczego by nie zmieniło – atak działał równie skutecznie przez narzędzie wiersza poleceń, ponieważ sama wada tkwiła w platformie.

Domyślna rola jak uniwersalny klucz do wszystkiego

Największe szkody wynikały z uprawnień, które AgentCore przyznawał każdemu agentowi domyślnie. Nie były one ograniczone do pojedynczego agenta – obejmowały wszystkich w danym regionie i pozwalały na odczyt, zapis oraz usuwanie, aż po działania destrukcyjne. Automatyczny skrypt był w stanie pobrać obrazy kontenerów wszystkich agentów w regionie i skopiować ich kod źródłowy.

Co dokładnie mogli zrobić badacze

Wylistować każdego agenta i w kilka sekund pobrać jego pakiety kodu
Wywołać dowolnego agenta indywidualnie
Przejść od publicznego agenta obsługi klienta do wewnętrznego agenta finansowego i sięgnąć po jego dane
Czytać prywatne rozmowy między użytkownikami a dowolnym agentem w regionie
Manipulować pamięcią długoterminową agentów, by przekierowywać przyszłe konwersacje na zewnętrzne serwery

Pakiety kodu często zawierają zapomniane hasła lub klucze API obok samego kodu źródłowego. W przypadku agentów z włączoną pamięcią długoterminową badacze mogli wstrzykiwać instrukcje, które kazały agentom przekazywać kolejne rozmowy w określone miejsce. Użytkownicy nadal rozmawialiby z pozornie zaufanym agentem, nie zauważając niczego niepokojącego.

Zabezpieczenia haseł i kluczy API również zawiodły. AWS zaleca przechowywanie poświadczeń w oddzielnym, zabezpieczonym sejfie, ale domyślne uprawnienia pozwalały na bezpośredni dostęp do tego sejfu – w tym do kluczy dla usług spoza AWS.

Reakcja AWS i poprawki, które przyszły z opóźnieniem

Zenity zgłosiło swoje ustalenia AWS 25 grudnia 2025 roku. Po zgłoszeniu AWS uczyniło IMDSv2 domyślnym dla wdrożeń AgentCore. IMDSv2 to bezpieczniejsza wersja usługi metadanych, a nowo wdrażani agenci startują teraz z nią domyślnie. To właśnie IMDS było pierwszym ogniwem w łańcuchu ataku.

Drugim problemem była zbyt szeroka domyślna rola wykonawcza AgentCore. Według zaktualizowanego stanowiska Zenity, AWS zmieniło tę rolę około sierpnia. Nowa wersja nie zawiera już uprawnień pozwalających agentom wywoływać inne agenty, czytać prywatne rozmowy czy pobierać poświadczenia z AWS Secrets Manager. Inne uprawnienia zostały znacząco zawężone. Badacze nadal zalecają jednak firmom tworzenie własnych, węższych ról dla swoich agentów.

Bezpieczeństwo chmury opiera się na segmentacji i dostępie o minimalnych uprawnieniach. Ale agenci AI potrzebują swobody, by być użyteczni.
Michael Bargury, CTO Zenity

Michael Bargury, CTO Zenity, wskazuje na fundamentalne napięcie: każda firma uruchamiająca agentów w chmurze mierzy się z tym kompromisem. Ponieważ agenci publiczni i wewnętrzni często dzielą to samo środowisko, pojedyncza luka może naruszyć granice całego systemu.

Wzorzec, który się powtarza – agenci zwracają się przeciw właścicielom

Luka w AgentCore wpisuje się w serię odkryć Zenity, które łączy podobny schemat: nieszkodliwie wyglądające dane wejściowe skłaniają agenta do działania przeciwko własnej organizacji. Pod nazwą AgentFlayer badacze wykorzystali ataki zero-click, by skłonić Salesforce Einstein, Copilot Studio i Cursor do przekierowywania danych klientów lub wycieku poświadczeń. W ramach AgentForger wystarczył pojedynczy zmanipulowany link ChatGPT, by utworzyć autonomicznego agenta w OpenAI Workspace Agents z wyłączonymi wymogami zatwierdzenia.

Porównanie nie wypada korzystnie dla AWS. OpenAI zamknęło swoją lukę w ciągu czterech dni, podczas gdy nadmierne domyślne uprawnienia AgentCore utrzymywały się miesiącami po zgłoszeniu Zenity. Dotyczy to platformy, którą AWS otworzyło dla wszystkich przedsiębiorstw i która według Amazona jest wykorzystywana między innymi przez Sony i Ericsson.

Problem pamięci agentów jako wektora ataku pokrywa się z ustaleniami środowiska badawczego. Google DeepMind wymienia manipulację pamięcią długoterminową jako osobną klasę ataków w swojej taksonomii „AI Agent Traps”. Wystarczy kilka zatrutych dokumentów w bazie wiedzy, by ukierunkować odpowiedzi agenta. W badaniu red-teamowym „Agents of Chaos” agent OpenClaw został zdalnie przejęty przez zewnętrznie edytowalny dokument podlinkowany w jego pliku pamięci, a inny agent przekazał niezredagowane dane bankowe.

Sam Altman, CEO OpenAI, wskazał oczywisty środek zaradczy: agenci powinni otrzymywać wyłącznie minimalny zakres dostępu, jaki jest im potrzebny. Według Zenity domyślna rola AgentCore łamała dokładnie tę zasadę.

Historia AgentCorruption to przypomnienie, że bezpieczeństwo agentów AI nie jest problemem, który rozwiąże się sam. Domyślne konfiguracje platform chmurowych mogą być wygodne, ale wygoda rzadko idzie w parze z zasadą minimalnych uprawnień. Firmy wdrażające agentów powinny traktować domyślne role jako punkt wyjścia, nie gotowe rozwiązanie – i regularnie weryfikować, do czego ich agenci mają faktyczny dostęp.