Jeden prompt, jeden agent, całe konto AWS: kulisy AgentCorruption w Amazon Bedrock AgentCore

8 października 2026 r., Zenity Labs ujawniła AgentCorruption: łańcuch luk w Amazon Bedrock AgentCore, zarządzanej platformie AWS do wdrażania i uruchamiania agentów AI, który pozwalał pojedynczemu promptowi w języku naturalnym skierowanemu do jednego publicznie dostępnego agenta przejąć kontrolę nad każdym agentem AgentCore w tym samym koncie i regionie AWS. Badanie opublikowano wraz z wystąpieniem na SecTor 2026 w Toronto, gdzie dyrektor ds. badań bezpieczeństwa Zenity, Tamir Ishay Sharbat, przedstawił je (Dark Reading, 8 października 2026). Własne opracowanie Zenity, przypisywane Sharbatowi, Lanie Salameh, Dmitry'emu Lozovoyowi i João Donato, rozpoczyna się od mechanizmu: agent AgentCore, który ma dowolne narzędzie zdolne do wykonania żądania wychodzącego, może zostać nakłoniony do wywołania AWS Instance Metadata Service (IMDS) pod adresem link-local 169.254.169.254, który zwraca tymczasowe poświadczenia dla własnej roli wykonawczej agenta. Zenity podaje, że wyeksportowała te poświadczenia na własną maszynę i potwierdziła, że działają z niej. Nie przypisano identyfikatora CVE.

Archiwum rejestruje to jako podatność — coś wykrytego, niekoniecznie wykorzystanego — o wysokiej wadze, pewności A, bez odnotowanych rzeczywistych szkód i z potwierdzonym udziałem AI. Strony nie zgadzają się co do sposobu przedstawienia sprawy, choć zgadzają się co do samego zachowania: AWS powiedział Dark Reading, że badanie „niedokładnie przedstawia oczekiwane i udokumentowane zachowanie jako podatność”.

Czym właściwie był łańcuch

AgentCore pakuje każdego agenta jako kontener i uruchamia go w Firecracker MicroVM na sesję. Pierwszy wpis Zenity w tej serii odtwarza cały przyczółek za pomocą żądania sformułowanego prostym językiem skierowanego do agenta testowego zbudowanego przy użyciu Strands SDK, otwartoźródłowego frameworka agentowego AWS, który zawiera wbudowane narzędzie do żądań HTTP oraz narzędzie powłoki. MikroVM nie ograniczała ruchu do usługi metadanych, więc żądanie przyszło z wnętrza instancji, a IMDS na nie odpowiedział. Badacze przeszli następnie przez endpointy: nazwę roli IAM, same tymczasowe poświadczenia STS, endpoint user-data — który zwrócił identyfikator konta, pełne ARN-y, adres URL środowiska uruchomieniowego i URI obrazu agenta w Amazon Elastic Container Registry (ECR) — oraz tagi instancji, w tym łańcuch certyfikatów mTLS, klucz prywatny i presigned URL do wewnętrznego magazynu. Zenity twierdzi, że ten sam wynik uzyskano przez narzędzie powłoki, ponieważ awaria izolacji leży na poziomie platformy, a nie w jakimkolwiek pojedynczym narzędziu.

Dwa szczegóły w tej sekwencji łatwo przeoczyć. Poświadczenia nie były ograniczone do sandboxa: Zenity wyeksportowało je poza AgentCore i wykonało wywołanie tożsamości AWS, które zwróciło rolę przyjętą przez agenta. A skradziona rola mogła pobrać obraz kontenera, dzięki czemu kod źródłowy agentów stał się czytelny — wpis Zenity zauważa, że obrazy rutynowo zawierają zakodowane na stałe klucze, pozostawione tokeny i konfigurację, której nigdy nie powinno się wbudowywać, oraz że pobrany obraz jest mapą bazowej logiki biznesowej.

Domyślna rola to miejsce, w którym przyczółek stał się kontem.

Drugą wadą, zgłoszoną osobno, jest to, że rola wykonawcza, którą AgentCore domyślnie przypisywał do agentów, nie była ograniczona do jednego agenta. Zenity opisuje uprawnienia obejmujące każdy zasób AgentCore na koncie i w regionie, w tym bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, bedrock-agentcore:CreateEvent, bedrock-agentcore:DeleteEvent oraz, na końcu łańcucha poświadczeń, bedrock-agentcore:GetResourceApiKey i secretsmanager:GetSecretValue.

Możliwość wyliczania zamieniła te symbole wieloznaczne w listę celów. Zenity użyła uprawnienia logs:DescribeLogGroups roli, ponieważ AgentCore nadaje grupie logów CloudWatch każdego agenta nazwę /aws/bedrock-agentcore/runtimes/{AGENT_ID}-{ENDPOINT_NAME}, i wyprowadziła identyfikatory agentów z tych nazw grup logów. Nazwy repozytoriów ECR podlegały konwencji zaobserwowanej przez badaczy — bedrock-agentcore-<agent_name> — dzięki czemu można było pobrać obraz każdego agenta w regionie. Zasoby pamięci znajdowano w ten sam sposób, na podstawie wzorca grupy logów /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID}, a uprawnienia roli ListActors, ListSessions i ListEvents dawały identyfikatory aktorów i sesji potrzebne do odczytania treści rozmowy.

Opracowanie Zenity przedstawia konkretną demonstrację ruchu bocznego: wejście przez publicznie dostępnego agenta, odkrycie narzędzi billing_agent w tym samym regionie, zauważenie pliku o nazwie billing.json i eksfiltrowanie go przez narzędzie do odczytu plików. Komunikat prasowy przedstawia ten sam scenariusz w ogólnych zarysach — atakujący wchodzący przez agenta obsługi klienta dostępnego z internetu mógłby przenieść się do wewnętrznego agenta finansowego wdrożonego w tym samym regionie, wywołać go i uzyskać dostęp do jego danych, narzędzi, powiązanych poświadczeń i prywatnych rozmów.

Pamięć była tym, co przetrwało prompt

AgentCore Memory przechowuje samą rozmowę jako pamięć krótkotrwałą i zapisuje wyodrębnione rekordy jako pamięć długotrwałą, używając strategii o nazwach SEMANTIC, USER_PREFERENCE, SUMMARIZATION i EPISODIC. Zenity użyło CreateEvent do zapisywania zdarzeń rozmowy w zasobach pamięci innych agentów. W swoim wpisie zachowuje ostrożność co do tego, co ten prymityw może, a czego nie może zrobić: CreateEvent nie pozwala wywołującemu na wybór przestrzeni nazw pamięci długotrwałej ani na bezpośrednie nadpisanie rekordu — o tym, co zostanie wyodrębnione i gdzie trafi, decydują skonfigurowane strategie docelowej pamięci. Zenity opisuje również, jak DeleteEvent jest używany do usuwania zdarzeń z wynikami narzędzi, aby agent wyciągnął błędny wniosek z brakujących danych, oraz do zacierania śladów poprzez usunięcie zdarzenia, które utworzyło pamięć.

Wynikiem prymitywu zapisu była trwałość. Demonstracja Zenity wszczepiła żądanie, aby agent przed udzieleniem odpowiedzi pobrał stronę kontrolowaną przez badaczy i postępował zgodnie z jej zawartością — punkt końcowy command-and-control, którego instrukcje można było zmieniać bez wszczepiania kolejnej pamięci. Ten sam kanał wyprowadzał następnie treść rozmowy: w omówieniu opisano, jak agent wysyła wiadomości użytkownika i własne odpowiedzi do punktu końcowego zbierającego dane, i stwierdzono, że uprawnienia do pamięci dla roli rozciągały się na całe konto i region, a nie tylko na przejętego agenta. Film opublikowany wraz z badaniami pokazuje użytkownika kontynuującego rozmowę, podczas gdy ta treść dociera do serwera badaczy.

Poświadczenia poza AWS

Ostatni wpis w serii domyka temat połączonych narzędzi. AgentCore Identity i Outbound Auth przechowują poświadczenia narzędzi jako sekrety w AWS Secrets Manager, pod nazwami tworzonymi z nazwy dostawcy i stałego wzorca, takiego jak bedrock-agentcore-identity!default/apikey/{provider_name}. Zenity odzyskało nazwy dostawców, wyciągając je z kodu źródłowego agenta, który wcześniej pobrało z ECR, a inne odzyskało metodą brute force: podaje, że domyślny pięcioznakowy sufiks jest generowany po stronie klienta z cyfr i małych liter, co daje 2 x (10+26)^5 = 120,932,352 kombinacji w obrębie obu typów dostawców. Przy tempie żądań, jakie było w stanie utrzymać wobec Secrets Manager, Zenity twierdzi, że pełna enumeracja zajmuje kilka godzin — dłużej, niż żyją poświadczenia STS — więc zbudowało pętlę, która ponownie odpytuje punkt końcowy IMDS agenta o świeże poświadczenia, gdy stare wygasają. Zenity dodaje, że zmienne środowiskowe były czytelne przez punkt końcowy metadanych user-data, a każda nazwa miała przedrostek CONTAINER_ENV_, w tym klucz, którego agent używa do uwierzytelniania u swojego dostawcy modelu, oraz że wywołanie każdego wykrytego agenta z odpowiednim promptem pozwalało pozyskiwać te wartości na dużą skalę.

Uznane, lecz kwestionowane z powodu formalności

To, co zostało ustalone, jest wąskie i konkretne. Agenci AgentCore mogli dotrzeć do IMDS i otrzymać tymczasowe poświadczenia własnej roli wykonawczej — AWS temu nie zaprzecza, określając to w swoim oświadczeniu jako „udokumentowane i oczekiwane”. Domyślna rola wykonawcza miała uprawnienia ograniczone do konta i regionu, a nie do pojedynczego agenta; AWS od tego czasu ją zmienił, a Zenity twierdzi, że własne testy potwierdziły to ograniczenie. To badanie jest demonstracją, a nie zaobserwowaną kampanią: Sharbat powiedział Dark Reading, że Zenity nie widziało żadnych dowodów, że luka została wykorzystana w rzeczywistych warunkach przed poprawką, przypisując to częściowo trudności z ustaleniem, które organizacje uruchamiają agentów na AgentCore, i dodając, że jest „w 100% pewien, że istnieją sposoby, aby to zrobić”.

Sporne jest to, czy cokolwiek z tego należy nazywać podatnością. Oświadczenie AWS, przekazane serwisom Dark Reading i The Next Web, brzmi: „AWS wie o opublikowanych badaniach dotyczących Amazon Bedrock AgentCore, które błędnie przedstawiają oczekiwane i udokumentowane zachowanie jako podatność. Agent może uzyskać dostęp do zasobów na innym koncie AWS tylko wtedy, gdy deweloper wyraźnie przyzna uprawnienia zarówno roli wykonawczej agenta, jak i zasobowi docelowemu”. Oświadczenie AWS przytoczone we własnych postach Zenity zachowuje istotę pierwszego zdania — „opisane zachowanie jest udokumentowane i oczekiwane” — i dodaje, że klienci powinni przyznawać rolom wykonawczym tylko te uprawnienia, których potrzebują ich agenci. U podstaw tej niezgodności leżą dwie kwestie. AWS ujmuje granicę w kategoriach dostępu do zasobów na innym koncie AWS, podczas gdy ustalenie Zenity dotyczy agentów w obrębie jednego konta i regionu AWS; a role opisywane przez Zenity pochodziły z domyślnych ustawień platformy, a nie z polityki napisanej ręcznie przez klienta.

Korekta własnego artykułu przez The Next Web zasługuje na odnotowanie, ponieważ pokazuje, że twierdzenie zostało zawężone przez kogoś innego niż sami badacze. The Next Web najpierw opublikował, a później skorygował nagłówek mówiący, że badacze przejęli każdego agenta AgentCore w danym regionie; poprawiona wersja podaje, że badanie obejmowało agentów w ramach jednego konta AWS i jednego regionu, oraz zauważa, że wcześniejszy nagłówek przedstawiał twierdzenie badaczy jako fakt.

Os czasu ujawnienia

Zenity złożyła dwa zgłoszenia, a nie jedno, i odpowiedziano na nie różnie. Zgłoszenie dotyczące dostępu do IMDS złożono 25 grudnia 2025 r.; AWS zamknęła je 12 kwietnia 2026 r. jako „informacyjne”, pisząc, że AgentCore używał IMDSv2 dopiero od 14 lutego 2026 r., a nowo wdrożeni agenci uruchamiali się w ten sposób. Ta korekta ma znaczenie dla szczegółów tych badań, ponieważ IMDSv2 wymaga tokena sesji przy każdym żądaniu i uniemożliwia zwykłe nieuwierzytelnione pobranie, którego badacze użyli do uzyskania poświadczeń. Drugie zgłoszenie, dotyczące domyślnej roli i zasięgu potencjalnych szkód, złożono 12 stycznia 2026 r.. AWS poinformowała Zenity 25 lutego 2026 r., że zespół nad nim pracował, podczas gdy rola pozostawała bez zmian; Zenity ponownie przeanalizowała rolę 22 czerwca 2026 r. i stwierdziła, że jej uprawnienia nie uległy zmianie. Ostateczna weryfikacja 29 września 2026 r. wykazała, że rola została znacznie zawężona, a komunikat prasowy Zenity stwierdza, że usunięcie objęło wywoływanie innych agentów, czytanie prywatnych rozmów i dostęp do sekretów w AWS Secrets Manager, a inne uprawnienia również zostały znacznie ograniczone. Własne wpisy Zenity zauważają, że AWS uczyniła od tego czasu IMDSv2 domyślnym dla wdrożeń AgentCore i że obie strony współpracowały w tym procesie.

Co nie jest znane

Zenity nie opublikowało, ilu agentów lub organizacji działało z domyślną rolą w okresie między lutową zmianą IMDSv2 a zawężeniem pod koniec września, a żadne z cytowanych źródeł nie stwierdza, że jakiekolwiek dane klientów zostały ujawnione poza środowiskiem samych badaczy. Zmiana IMDSv2 dotyczy agentów wdrożonych po 14 lutego 2026 r., zgodnie z informacjami AWS przytoczonymi przez Zenity; co oznacza ona dla agentów wdrożonych przed tą datą, nie zostało podane w przeanalizowanych tu źródłach. Archiwum nie odnotowuje żadnych rzeczywistych szkód, a źródła potwierdzają taki odczyt, opisując demonstrację oraz to, że AWS kwestionuje etykietę podatności, zamiast zgłaszać własny incydent.

Sharbat powiedział Dark Reading, że Zenity bada obecnie inne platformy chmurowe pod kątem podobnych problemów z dostępem do metadanych i że firma na razie nie podaje ich nazw. Wniosek, który z tego wyciąga, dotyczy uprawnień, a nie samej usługi metadanych: „Nawet jeśli ktoś dostanie się do IMDS, promień rażenia będzie znacznie mniejszy”.

Dlaczego ten zapis jest przechowywany

AgentCorruption nie jest godny uwagi dlatego, że punkty końcowe metadanych są nowym pomysłem. Sharbat wskazał publiczności SecTor włamanie do Capital One z 2019 r., w którym SSRF dotarł do IMDS i przekształcił się w skradzione poświadczenia, i opisał to jako awarię zasady najmniejszych uprawnień tego samego rodzaju. Nowe jest to, kto wykonuje pobieranie. Żądanie, które doprowadziło do powstania tożsamości AWS, zostało wykonane przez agenta AI robiącego to, o co go poproszono, prostym językiem, za pośrednictwem narzędzia, które mu dano, aby mógł być użyteczny — a agent przekazał odpowiedź z powrotem. Dwa warunki, które zmieniły to w problem obejmujący całe konto, to punkt końcowy metadanych, którego piaskownica nie zablokowała, oraz domyślna rola szersza niż agent, który ją posiadał.

Pełne badanie, obejmujące pięcioczęściową serię techniczną i film demonstracyjny, jest podlinkowane w komunikacie prasowym Zenity z 8 października 2026 r. Ten zapis to jeden z wpisów wśród udokumentowanych incydentów z udziałem agentów w archiwum incydentów AI, gdzie każdy wpis zawiera własne źródła, wagę, stopień pewności i flagę sporu — pola, które pozwalają odróżnić spór dostawcy dotyczący sposobu przedstawienia, jak w tym przypadku, od kwestionowanego ustalenia szkody.

To jeden rekord, zbadany i opisany przez innych, a tutaj przytoczony z podaniem ich jako źródła. Pozostałe udokumentowane incydenty z agentami, każdy z własnymi źródłami, poziomem dotkliwości, stopniem pewności i flagą sporu, znajdują się w archiwum incydentów AI — dzięki czemu domyślne ustawienie platformy, które zamienia jedno polecenie w przyczółek obejmujący całe konto, można odczytać obok tego, co faktycznie wydarzyło się gdzie indziej.