Zenity AgentCorruption ujawnił ścieżkę przejęcia całego konta AWS AgentCore
Badacze Zenity AgentCorruption odkryli, że jeden złośliwy prompt mógł ujawnić tymczasowe poświadczenia AWS z publicznie dostępnego agenta Amazon Bedrock AgentCore. Według doniesień poświadczenia te otwierały drogę do każdego środowiska uruchomieniowego AgentCore współdzielącego podatne konto, region oraz domyślną rolę o szerokim zakresie uprawnień. Odkrycie przekształciło znany problem prompt injection w awarię bezpieczeństwa chmurowego obejmującą całe konto.
Atak nie wymagał złamania modelu podstawowego, przedostania się do niepowiązanego klienta AWS ani kradzieży hasła administratora. Łączył zdolność agenta do wykonywania żądań HTTP z poświadczeniami metadanych i nadmiernymi uprawnieniami Identity and Access Management. Zenity twierdzi, że łańcuch ataku dotarł do prywatnych agentów, kodu źródłowego, historii rozmów, przechowywanych sekretów i pamięci długoterminowej.
To połączenie ma większe znaczenie niż nagłówek o jednym prompcie. AWS promował AgentCore jako zarządzaną infrastrukturę do bezpiecznej obsługi agentów produkcyjnych, obejmującą tożsamość, pamięć, narzędzia, obserwowalność i izolowane środowiska uruchomieniowe. AgentCorruption pokazał, jak te połączone usługi mogły wzmacniać skutki kompromitacji jednego agenta, gdy ich granice autoryzacji były zbyt szerokie.
Istnieje też istotne zastrzeżenie. Zenity ujawniło problemy na kilka miesięcy przed publikacją badań 8 października 2026 r. Badacze poinformowali, że AWS ograniczył domyślną rolę wykonawczą przed publikacją, a dokumentacja AWS wymaga obecnie silniejszych kontroli metadanych i ostrzega przed produkcyjnym użyciem szerokich polityk generowanych przez CLI.
Wynik nie stanowi dowodu, że każde obecne wdrożenie AgentCore pozostaje otwarte na pełny łańcuch ataku. Jest dowodem na to, że zespoły nie mogą traktować zarządzanej infrastruktury agentowej jako substytutu zasady najmniejszych uprawnień. Bezpieczeństwo agentów musi obecnie obejmować łącznie zachowanie modelu językowego, poświadczenia środowiska uruchomieniowego, uprawnienia chmurowe, integralność pamięci i ruch boczny.
Jak Zenity AgentCorruption przekształcił jeden prompt w poświadczenia AWS
Pierwsza awaria przekroczyła granicę między niezaufanym wejściem językowym a zaufaną tożsamością chmurową.
Według badań AgentCorruption firmy Zenity, wystawiony AgentCore zaakceptował prompt nakazujący mu wysłanie żądania do lokalnego punktu końcowego metadanych. Żądanie było skierowane na 169.254.169.254, adres link-local używany przez środowiska obliczeniowe AWS do udostępniania metadanych obciążenia oraz tymczasowych poświadczeń roli.
Odpowiednią usługą jest Instance Metadata Service, zwykle skracana do IMDS. Środowisko Firecracker microVM AgentCore korzysta z pokrewnej MicroVM Metadata Service, czyli MMDS, aby udostępniać poświadczenia roli wykonawczej wewnątrz obciążenia.
Ten mechanizm dostarczania poświadczeń ma uzasadnione zastosowanie. Agent może potrzebować tymczasowej autoryzacji do odczytania zatwierdzonego obiektu S3, wywołania innej usługi AWS lub wykonania zadania biznesowego. Tymczasowe poświadczenia pozwalają również uniknąć osadzania stałych kluczy dostępu w kodzie lub obrazach kontenerów.
Problem pojawia się, gdy niezaufany prompt może nakłonić narzędzie do skontaktowania się z punktem końcowym metadanych. Zenity twierdzi, że narzędzie obsługujące HTTP wysłało żądanie z wnętrza microVM, więc usługa metadanych potraktowała je jako żądanie lokalnego obciążenia. Odpowiedź ujawniła tymczasowy klucz dostępu, tajny klucz i token sesji środowiska uruchomieniowego agenta.
Jest to wzorzec fałszowania żądań po stronie serwera, zwykle określany jako SSRF. Atakujący skłania komponent po stronie serwera do wysłania żądania do miejsca docelowego, do którego nie może dotrzeć bezpośrednio. W tym przypadku agent miał według doniesień stać się komponentem wysyłającym żądanie, ponieważ jego narzędzia mogły wykonywać wychodzące wywołania HTTP.
Prompt injection dostarczył intencję, a narzędzie HTTP — możliwości. Usługa metadanych dostarczyła następnie tożsamość chmurową. Żaden z tych elementów samodzielnie nie zapewniłby zgłaszanego zasięgu oddziaływania.
Model, który jedynie generowałby niebezpieczny tekst, nie ukradłby poświadczeń. Punkt końcowy metadanych chroniony przed narzędziami agenta zatrzymałby tę ścieżkę. Wąsko ograniczona rola wykonawcza powstrzymałaby skutki nawet po kradzieży poświadczeń.
AWS obecnie wyraźnie dokumentuje tę właściwość ekspozycji poświadczeń. Jego wytyczne dotyczące poświadczeń wskazują, że kod lub podmioty wewnątrz microVM mogą wywoływać punkt końcowy metadanych i uzyskiwać dostęp do dostępnych poświadczeń. AWS zaleca zatem klientom ograniczanie ról wykonawczych wyłącznie do uprawnień wymaganych przez ich obciążenia.
Zenity początkowo zgłosiło AWS problem z metadanymi 25 grudnia 2025 r. Badacze twierdzą, że AWS zamknął zgłoszenie jako informacyjne 12 kwietnia 2026 r. AWS przekazał im, że nowo wdrażani agenci korzystali z IMDSv2 od 14 lutego.
IMDSv2 wymaga tokenu sesji, zanim klient będzie mógł pobrać metadane. Taka konstrukcja blokuje wiele konwencjonalnych ataków SSRF, ponieważ atakujący nie zawsze może kontrolować wstępne żądanie tokenu i jego nagłówki.
Autonomiczny agent zmienia to założenie. Jeśli agent potrafi wykonywać wystarczająco elastyczne żądania, może uzyskać token, a następnie pobrać poświadczenia. Zenity argumentuje, że wymóg IMDSv2 zwiększył trudność ataku, lecz nie usunął podstawowego problemu zaufania.
AWS później wyszedł poza opcjonalne wdrożenie. Aktualne wytyczne dotyczące środowiska uruchomieniowego mówią, że środowiska AgentCore bez włączonego MMDSv2 są odrzucane od 30 czerwca 2026 r. Kontrola ta poprawia poziom bazowy, choć nie usprawiedliwia nadmiernych uprawnień przypisanych do poświadczeń, do których legalny kod środowiska uruchomieniowego wciąż może uzyskać dostęp.
Kluczowa lekcja ma charakter architektoniczny. Prompt injection staje się kompromitacją chmury, gdy agent potrafi przełożyć instrukcje w języku naturalnym na uprzywilejowane operacje sieciowe i tożsamościowe. Filtrowanie złośliwego zdania odnosi się tylko do jednej warstwy tej ścieżki.
Domyślna rola sprawiła, że jeden agent stał się problemem wszystkich
Skradzione poświadczenia stały się dźwignią obejmującą całe konto, ponieważ testowana rola wykonawcza powierzała jednemu agentowi dostęp do innych agentów w całym regionie.
Zenity przesłało drugie zgłoszenie 12 stycznia 2026 r., koncentrując się na uprawnieniach stojących za początkową kompromitacją. Badacze stwierdzili, że domyślna rola nie była ograniczona do środowiska uruchomieniowego, które ją przyjęło. Kilka uprawnień dotyczyło zasobów AgentCore na tym samym koncie AWS i w tym samym regionie.
Pierwszy etap rozszerzenia wykorzystywał CloudWatch Logs. Zenity twierdzi, że logs:DescribeLogGroups umożliwiało skompromitowanej tożsamości wyliczenie nazw regionalnych grup logów. Konwencje nazewnictwa AgentCore ujawniały w tych nazwach identyfikatory środowisk uruchomieniowych i zasobów pamięci.
Atakujący nie potrzebowali istniejącego spisu prywatnych agentów. Według doniesień mogli wyprowadzić identyfikatory środowisk uruchomieniowych z metadanych operacyjnych już widocznych dla roli. Rozpoznanie przekształciło skradzioną tożsamość z lokalnego punktu zaczepienia w mapę sąsiednich zasobów.
Rola zawierała również regionalne uprawnienia dla Amazon Elastic Container Registry. Zenity twierdzi, że przewidywalne nazewnictwo repozytoriów pozwoliło badaczom powiązać środowiska uruchomieniowe AgentCore z obrazami kontenerów. Pobranie tych obrazów ujawniło kod aplikacji i potencjalnie wrażliwą konfigurację osadzoną we wdrożonych artefaktach.
Odkrycie to podważa powszechne założenie dotyczące zarządzanych środowisk uruchomieniowych. MicroVM może izolować jedną działającą sesję od drugiej, podczas gdy IAM nadal autoryzuje tę sesję do pobierania niepowiązanych zasobów. Izolacja obliczeniowa i izolacja autoryzacji rozwiązują różne problemy.
Następnie pojawiło się bedrock-agentcore:InvokeAgentRuntime. Analiza roli Zenity pokazuje, że testowana polityka obejmowała zasoby środowisk uruchomieniowych z symbolem wieloznacznym w regionie. Skradzione poświadczenia mogły więc wywoływać prywatnych agentów, do których użytkownik zewnętrzny nigdy nie powinien mieć dostępu.
Publiczny bot wsparcia mógł mieć ograniczone narzędzia i starannie filtrowane dane. Prywatny agent rozliczeniowy mógł mieć dostęp do plików finansowych, wewnętrznych API lub systemów transakcyjnych. Wywoływanie w całym regionie połączyło wystawiony punkt wejścia z bardziej wrażliwym agentem.
Zenity zademonstrowało tę ścieżkę na testowym agencie rozliczeniowym. Badacze wyliczyli jego narzędzia, zidentyfikowali plik o nazwie billing.json i polecili agentowi zwrócić jego zawartość. Scenariusz ten ilustrował ruch boczny przez legalne API AgentCore, a nie drugi exploit oprogramowania.
Pamięć rozmów ponownie rozszerzyła skalę szkód. AgentCore Memory przechowuje krótkoterminowe zdarzenia według zasobu pamięci, aktora i sesji. Strategie długoterminowe mogą zachowywać wyodrębnione fakty, preferencje, podsumowania i wnioski na potrzeby przyszłych interakcji.
Zenity twierdzi, że skompromitowana rola mogła wyliczać aktorów i sesje, a następnie wywoływać ListEvents, aby pobierać treść rozmów. Ponieważ uprawnienia te obejmowały zasoby pamięci z symbolem wieloznacznym, badacze mieli według doniesień dostęp do rozmów należących do innych agentów i użytkowników.
Ujawnione materiały mogły obejmować dane osobowe, kod źródłowy, wewnętrzne plany, rejestry klientów lub poświadczenia wklejone podczas rozwiązywania problemów. Platforma nie może ustalić, czy sekret wprowadzony do rozmowy powinien był się tam znaleźć. Autoryzacja musi uniemożliwiać niepowiązanym obciążeniom odczytanie sesji w ogóle.
Uprawnienia do zapisu stworzyły odrębne zagrożenie dla integralności. Zenity ustaliło, że rola mogła tworzyć i usuwać zdarzenia pamięci. Atakujący mógł wstrzyknąć fałszywy kontekst do aktywnej sesji, usunąć wyniki narzędzi lub wpłynąć na to, co agent uważał za wydarzone.
Ryzyko to różni się od zwykłej kradzieży danych. Zmanipulowany agent może nadal przedstawiać się jako zaufana usługa firmy, działając jednocześnie w oparciu o kontekst dostarczony przez atakującego. Użytkownicy mogą nie zobaczyć wrogiej instrukcji, ponieważ znajduje się ona w zapisanym stanie sesji, a nie w widocznym prompcie.
AWS poinformował Zenity 25 lutego, że jego zespół zajmuje się podstawowym problemem. Badacze sprawdzili ponownie 22 czerwca i przekazali, że domyślna rola pozostała niezmieniona. Ta oś czasu pozostawiła szeroką rolę w centrum nierozwiązanego łańcucha przez kilka miesięcy.
Podczas końcowego przeglądu 29 września Zenity wykryło istotne ograniczenia. Badacze stwierdzili, że AWS usunął uprawnienia umożliwiające wywoływanie między środowiskami uruchomieniowymi, dostęp do prywatnych rozmów oraz pobieranie z Secrets Manager. Inne uprawnienia również zostały zawężone.
Ta naprawa wyraźnie zmienia obecną ocenę ryzyka. Opublikowany łańcuch dokumentuje to, co badacze osiągnęli wobec wcześniejszych ustawień domyślnych, a nie stanowi dowodu, że identyczne uprawnienia nadal są dziś przypisane. Istniejące role utworzone przez klientów, skopiowane polityki i starsze wdrożenia nadal zasługują na bezpośredni przegląd.
Zarządzana izolacja zderzyła się z rzeczywistością nadmiernych uprawnień
AgentCorruption ujawnił konflikt między obietnicą izolacji AgentCore a współdzielonymi ścieżkami autoryzacji otaczającymi każde izolowane środowisko uruchomieniowe.
AWS uruchomił AgentCore w wersji ogólnodostępnej w październiku 2025 r., opisując go jako infrastrukturę do bezpiecznego uruchamiania agentów na dużą skalę. Platforma połączyła izolację środowiska uruchomieniowego z tożsamością, pamięcią, bramami, automatyzacją przeglądarki, wykonywaniem kodu i obserwowalnością.
Każda z tych możliwości odpowiada na rzeczywisty problem wdrożeniowy. Agenci potrzebują stanu między rozmowami, poświadczeń dla połączonych usług, zarządzanego dostępu do narzędzi oraz śledzenia nieprzewidywalnych działań. Samodzielne budowanie wszystkich tych komponentów zwiększa koszty i złożoność.
Jednak integracja tworzy również zależności bezpieczeństwa. Środowisko uruchomieniowe może być odizolowane obliczeniowo, podczas gdy jego rola wykonawcza może wywoływać inne środowisko. Magazyn tokenów może trzymać sekrety poza kodem aplikacji, lecz zbyt szeroka tożsamość może zażądać tych sekretów.
To właśnie jest kluczowe odwrócenie w Zenity AgentCorruption. Połączone mechanizmy kontroli zarządzanej platformy miały wspierać bezpieczne użycie produkcyjne. Przy testowanych ustawieniach domyślnych te same połączenia miały, według raportu, przenosić kompromitację przez granice usług.
Obecne praktyki bezpieczeństwa środowisk uruchomieniowych AWS wyraźniej uznają to rozróżnienie. Dokumentacja ostrzega klientów, aby nie używali w produkcji polityk deweloperskich generowanych przez CLI. Zaleca wskazywanie konkretnych ARN-ów środowisk uruchomieniowych zamiast instrukcji zasobów z symbolami wieloznacznymi.
Wskazówki mówią również, że rola wykonawcza powinna mieć uprawnienia równe lub mniejsze niż podmioty uprawnione do jej wywoływania. Ta zasada jest użytecznym sposobem oceny publicznych agentów. Jeśli anonimowy użytkownik może wywołać środowisko uruchomieniowe, nie powinno ono dziedziczyć uprawnień niedostępnych dla anonimowych użytkowników.
Publiczna dostępność nie czyni agenta automatycznie niebezpiecznym. Zmienia poziom zaufania wobec każdej instrukcji docierającej do modelu. Rola wykonawcza musi zakładać, że część zaakceptowanych danych wejściowych będzie złośliwa, wprowadzająca w błąd lub zaprojektowana w celu manipulowania narzędziami.
Uwierzytelnianie pomaga identyfikować wywołujących, ale nie eliminuje prompt injection. Prawidłowe konto klienta może przesyłać wrogie instrukcje. Przejęte dokumenty i strony internetowe mogą także dostarczać pośredni prompt injection, gdy użytkownik prosi agenta o ich podsumowanie.
Mechanizmy kontroli bramy mogą ograniczać ekspozycję, walidując żądania, zanim dotrą one do środowiska uruchomieniowego. Guardrails mogą wykrywać znane wzorce ataków, a interceptory mogą ograniczać operacje zależnie od tożsamości i kontekstu. Te mechanizmy działają tylko wtedy, gdy wywołujący nie mogą ominąć bramy i bezpośrednio wywołać środowiska uruchomieniowego.
Wskazówki bezpieczeństwa AgentCore zalecają obecnie ograniczenie wywoływania środowiska uruchomieniowego do roli wykonawczej bramy, gdy brama jest zamierzonym punktem wejścia. Takie podejście przenosi autoryzację poza pętlę decyzyjną modelu. Agent nie może przekonać systemu do obejścia odmowy IAM.
Ograniczanie zakresu zasobów IAM pozostaje silniejszą granicą powstrzymywania. Agent obsługi klienta nie powinien otrzymywać uprawnień z symbolem wieloznacznym do wywoływania każdego środowiska uruchomieniowego. Uprawnienie do zapisu pamięci powinno wskazywać konkretny zasób pamięci, zakres aktora i potrzebę biznesową wszędzie tam, gdzie usługa pozwala na taką precyzję.
To samo rozumowanie dotyczy repozytoriów kontenerów i logów. Metadane operacyjne często wydają się mniej wrażliwe niż dane aplikacyjne. Jednak nazwy, identyfikatory, endpointy i wzorce repozytoriów mogą stać się systemem rozpoznania ułatwiającym ruch boczny.
Organizacje potrzebują również separacji według poziomu zaufania. Publiczni agenci i agenci wewnętrzni nie powinni współdzielić ról wykonawczych tylko dlatego, że narzędzie konfiguracyjne ułatwia takie ustawienie. Wrażliwe funkcje można rozdzielić między konta AWS lub regiony, gdy mechanizmy kontroli na poziomie konta zapewniają wyraźniejszą izolację.
Żaden filtr promptów nie może zagwarantować, że model odrzuci każdą złośliwą odmianę. Modele interpretują znaczenie, zamiast egzekwować skończoną gramatykę poleceń. Atakujący mogą przeformułowywać żądania, ukrywać instrukcje w pobranych danych lub wykorzystywać konflikty między kontekstem systemowym a użytkownika.
To ograniczenie nie czyni wdrażania agentów niepraktycznym. Zmienia ono miejsce, w którym obrońcy powinni pokładać zaufanie. Zabezpieczenia na poziomie modelu mogą ograniczać skuteczną manipulację, podczas gdy deterministyczne mechanizmy kontroli w chmurze ograniczają to, co może zrobić zmanipulowany model.
Zespoły powinny traktować prompty jako niezaufane dane wejściowe, a narzędzia jako uprzywilejowane interfejsy. Każde wywołanie narzędzia wymaga decyzji autoryzacyjnej opartej na uwierzytelnionym użytkowniku, żądanym zasobie i dozwolonej operacji. Decyzja modelu o wywołaniu narzędzia nigdy nie powinna sama w sobie służyć jako autoryzacja.
Dla organizacji dokumentujących te decyzje przeszukiwalny zestaw inżynierskich baz wiedzy może pomóc połączyć informacje o właścicielach środowisk uruchomieniowych, politykach IAM, modelach zagrożeń i procedurach reagowania na incydenty. Taki zapis staje się istotny, gdy wiele zespołów wdraża agentów za pośrednictwem współdzielonych kont chmurowych.
Zatruwanie pamięci zmieniło naruszenie w trwałą kontrolę
Najistotniejszą częścią łańcucha nie była kradzież poświadczeń, lecz możliwość uszkodzenia tego, co zaufani agenci zapamiętywali później.
AgentCore Memory obsługuje stan krótkoterminowy i długoterminowy. Pamięć krótkoterminowa rejestruje zdarzenia z kolejnych tur sesji. Pamięć długoterminowa wyodrębnia informacje wielokrotnego użytku, dzięki czemu agent może przypominać sobie preferencje, fakty, podsumowania lub wcześniejsze wnioski.
Ta trwałość poprawia użyteczność. Agent wsparcia może pamiętać nierozwiązaną sprawę, a asystent w miejscu pracy może zachować preferencje formatowania. Tworzy jednak również trwały kanał wejściowy, który może wpływać na przyszłe decyzje.
Badanie zatruwania pamięci Zenity wskazuje, że skradziona rola mogła odkrywać identyfikatory pamięci poprzez logi CloudWatch. Następnie mogła wyświetlać aktorów, sesje i skonfigurowane strategie pamięci.
Badacze użyli CreateEvent, aby dodać wrogą treść do rozmów innych agentów. Mechanizm ekstrakcji pamięci przetwarzał te zdarzenia i przekształcał ich zawartość w rekordy długoterminowe. Przyszłe sesje mogły pobierać te rekordy jako zaufany kontekst.
Atakujący nie musiał więc powtarzać pierwotnego prompt injection przy każdej interakcji. Wszczepiona instrukcja mogła przetrwać poza przejętą sesją i wpływać na późniejsze rozmowy. Widoczny interfejs nadal sprawiałby wrażenie oficjalnego agenta organizacji.
Zenity opisuje to jako trwałe dowodzenie i kontrolę. To określenie należy rozumieć jako charakterystykę środowiska testowego dokonaną przez badaczy. Dokładny rezultat behawioralny zależy od konfiguracji pamięci, logiki pobierania, zachowania modelu, narzędzi i mechanizmów autoryzacji.
Zaprezentowany prymityw pozostaje jednak poważny. Fałszywa preferencja mogłaby nakazać agentowi wysłanie danych na adres kontrolowany przez atakującego. Sfingowany fakt mógłby przekierować przepływ pracy, a zatrute podsumowanie mogłoby fałszywie przedstawiać wcześniejszą zgodę klienta.
Manipulacja historią krótkoterminową dodaje bezpośrednie ryzyka. Wstawione zdarzenie asystenta może wyglądać dla modelu jak coś, co wcześniej postanowił. Usunięty wynik narzędzia może usunąć dowód, który w innym przypadku powstrzymałby niebezpieczne działanie.
Tradycyjne bezpieczeństwo aplikacji często traktuje logi i historię jako dowody po incydencie. Systemy agentowe mogą aktywnie przekazywać zapisaną historię z powrotem do przyszłych decyzji. Naruszenia integralności tych danych mogą zatem zmieniać wykonanie, a nie tylko utrudniać dochodzenie.
Pamięć komplikuje również odzyskiwanie kontroli. Rotacja skradzionych poświadczeń zatrzymuje dalszy dostęp przez API, ale nie usuwa automatycznie każdego zatrutego rekordu. Zespoły reagujące muszą zidentyfikować sesje, zdarzenia, podsumowania i wyodrębnione wspomnienia, których dotknęła przejęta tożsamość.
Obecne wytyczne dotyczące pamięci AWS zalecają walidację danych wejściowych, guardrails przed utrwaleniem oraz regularne testowanie prompt injection. Podkreślają również polityki najmniejszych uprawnień dla zasobów pamięci.
Mechanizmy te powinny być połączone z pochodzeniem danych. Rekord długoterminowy powinien zachowywać wystarczającą ilość metadanych, aby wskazać użytkownika, agenta, sesję i proces ekstrakcji, który go utworzył. Zespoły bezpieczeństwa potrzebują skutecznego sposobu izolowania wspomnień powiązanych z przejętą tożsamością.
Działania wysokiego ryzyka nie powinny opierać się na przywołanym kontekście jako dowodzie autoryzacji. Agent może pamiętać, że użytkownik preferuje określone konto bankowe, ale przelew nadal wymaga aktualnej, niezależnie zweryfikowanej zgody. Pamięć może kierować przepływem pracy, nie autoryzując go.
Organizacje powinny także rozdzielać typy danych według konsekwencji. Preferencje dotyczące stylu pisania niosą mniejsze ryzyko niż instrukcje płatnicze, nadania dostępu czy adresy docelowe. Wrażliwe wspomnienia wymagają surowszych reguł tworzenia, krótszego okresu przechowywania i silniejszego nadzoru.
Monitorowanie musi obejmować zarówno zapisy, jak i odczyty. Nietypowe serie CreateEvent, dostęp do pamięci między agentami lub zmiany dotyczące wielu aktorów mogą sygnalizować nadużycie. CloudTrail, logi aplikacyjne i dane obserwowalności AgentCore powinny zasilać alerty powiązane z oczekiwanym zachowaniem obciążenia.
W tym miejscu incydent wykracza poza AWS. Każda platforma agentowa łącząca trwałą pamięć z narzędziami staje przed podobnym problemem integralności. Szczegóły implementacyjne są różne, ale pytanie o zaufanie pozostaje niezmienne.
Jakie informacje agent może zapamiętywać, kto może je zapisywać i od jakich decyzji mogą one później zależeć? AgentCorruption pokazuje, że niepełne odpowiedzi mogą zmienić tymczasowy przyczółek w trwały wpływ.
Co klienci AgentCore powinni teraz zweryfikować
Pełny historyczny łańcuch został zawężony przed publikacją, lecz uprawnienia definiowane przez klientów i starsze konfiguracje określają pozostałą ekspozycję każdego wdrożenia.
Pierwsza kontrola dotyczy roli wykonawczej przypisanej do każdego środowiska uruchomieniowego AgentCore. Zespoły powinny wyliczyć dozwolone działania i zasoby, a następnie usunąć uprawnienia niezwiązane z udokumentowaną funkcją środowiska. Symbole wieloznaczne zasługują na konkretne uzasadnienie, a nie rutynową akceptację.
Role produkcyjne nie powinny dziedziczyć polityk wygenerowanych dla prototypów. AWS obecnie oznacza uprawnienia generowane przez CLI jako udogodnienia deweloperskie i doradza klientom tworzenie wąsko ograniczonych alternatyw. Udane wdrożenie testowe nie jest dowodem, że jego rola należy do środowiska produkcyjnego.
Druga kontrola dotyczy wymuszania MMDSv2. Bieżące środowiska uruchomieniowe powinny ustawiać requireMMDSV2 na true w konfiguracji metadanych. Zespoły powinny zweryfikować wdrożoną konfigurację, zamiast zakładać, że aktualizacja platformy poprawnie zmieniła każde historyczne środowisko uruchomieniowe.
MMDSv2 nadal należy traktować jako jedną warstwę. Jeśli agent zgodnie z przeznaczeniem kontroluje elastycznego klienta HTTP, powłokę lub interpreter kodu, może wykonywać żądania, których proste zabezpieczenia SSRF zakładały, że atakujący nie potrafią skonstruować. Polityka sieciowa powinna blokować niepotrzebny dostęp do endpointów metadanych.
Trzecia kontrola obejmuje dostępność przychodzącą. Zespoły powinny zidentyfikować środowiska uruchomieniowe akceptujące bezpośrednie wywołania publiczne, IAM lub oparte na JWT. Publiczni agenci potrzebują najmniejszych ról, ponieważ ich dane wejściowe pochodzą od najmniej zaufanych odbiorców.
Gdy AgentCore Gateway zapewnia egzekwowanie polityk, bezpośrednie wywoływanie środowiska uruchomieniowego powinno być ograniczone. W przeciwnym razie atakujący może ominąć guardrails bramy i wywołać endpoint środowiska uruchomieniowego inną autoryzowaną ścieżką. Uwierzytelnianie i identyfikatory użytkowników muszą pochodzić od zweryfikowanych podmiotów.
Czwarta kontrola dotyczy ruchu bocznego. Środowisko uruchomieniowe nie powinno wywoływać niepowiązanych agentów, wyświetlać regionalnych grup logów, pobierać niepowiązanych obrazów ECR ani wyliczać zasobów pamięci. Te uprawnienia powinny być izolowane według ARN środowiska uruchomieniowego i funkcji biznesowej.
Piąta kontrola dotyczy poufności rozmów. Zespoły bezpieczeństwa powinny sprawdzić, czy jedna tożsamość środowiska uruchomieniowego może wyświetlać aktorów, sesje lub zdarzenia należące do innego obciążenia. Powinny również zweryfikować, czy polityki zasobów i polityki tożsamości łącznie zapewniają zamierzoną odmowę.
Szósta kontrola dotyczy integralności pamięci. Zespoły powinny zinwentaryzować podmioty mające dostęp do CreateEvent, DeleteEvent i pamięci długoterminowej. Alerty powinny odróżniać normalne zapisy w sesjach użytkowników od zmian między agentami lub zmian o dużej skali.
Siódma kontrola dotyczy przechowywanych poświadczeń. AgentCore Identity może przechowywać tokeny stron trzecich poza kodem aplikacji, ale IAM nadal kontroluje, kto może je pobierać. Role środowisk uruchomieniowych nie powinny mieć szerokiego dostępu do kluczy API ani wartości Secrets Manager.
Osoby prowadzące dochodzenie w sprawie możliwej historycznej ekspozycji potrzebują czegoś więcej niż aktualnych zestawień polityk. Powinny przeanalizować zdarzenia CloudTrail, logi wywołań środowiska uruchomieniowego, aktywność związaną z metadanymi, pobrania obrazów ECR, wywołania API pamięci oraz dostęp do Secrets Manager w odpowiednim okresie.
Tymczasowe poświadczenia wygasają, lecz ich skutki mogą się utrzymywać. Atakujący może skopiować kod źródłowy, zachować pozyskany sekret, zmodyfikować historię sesji albo zaszczepić pamięć długoterminową przed wygaśnięciem poświadczeń. Plany reagowania powinny obejmować rotację poświadczeń i walidację stanu.
Kluczowe pozostają dwie niewiadome. Ustalenia Zenity pochodzą z wdrożeń kontrolowanych przez badaczy, a żadne cytowane tu publiczne dowody nie potwierdzają powszechnego wykorzystania tej techniki w środowiskach klientów. AWS nie opublikował osobnego biuletynu bezpieczeństwa opisującego pełny łańcuch AgentCorruption.
Ten brak powinien powstrzymywać przed zawyżaniem twierdzeń, a nie przed odrzucaniem badań. Zenity opublikowało szczegółowe przykłady uprawnień, ścieżki wykorzystania oraz daty ujawnienia. Zaktualizowana dokumentacja AWS niezależnie potwierdza, że kod środowiska uruchomieniowego może uzyskiwać dostęp do poświadczeń metadanych oraz że szerokie polityki programistyczne nie są odpowiednie dla środowisk produkcyjnych.
Pierwszym sygnałem, który warto obserwować, jest wydanie przez AWS formalnego komunikatu, retrospektywy lub dodatkowych wytycznych dotyczących migracji polityk. Taka dokumentacja wyjaśniłaby, których konfiguracji dotyczy problem i czy klienci muszą ręcznie naprawić starsze role.
Drugim sygnałem jest dalsze ograniczanie dostępu do metadanych z narzędzi kontrolowanych przez agenta. Kontrola blokująca środowiskom uruchomieniowym dostęp do punktów końcowych poświadczeń zmniejszyłaby zależność od zachowania modelu. Szczegółowa polityka ruchu wychodzącego mogłaby również ograniczać inne ścieżki SSRF.
Trzecim sygnałem jest widoczna dla klientów ochrona pamięci. Lepsze określanie pochodzenia danych, autoryzacja zapisu ograniczona zakresem, alerty integralności oraz narzędzia do masowej kwarantanny ułatwiłyby wykrywanie i odwracanie zatruwania pamięci. Takie możliwości mają znaczenie, gdy pamięć długoterminowa trafia do procesów krytycznych dla biznesu.
AgentCorruption od Zenity ostatecznie testuje szersze założenie stojące za agentami korporacyjnymi. Zarządzana infrastruktura może zmniejszać złożoność operacyjną, ale nie może bezpiecznie łączyć tożsamości, pamięci i dostępu do narzędzi w jednej, szeroko zaufanej roli.
Programiści powinni teraz zadać konkretne pytanie dotyczące każdego wdrożonego agenta: co dzieje się, gdy model wykona najgorszą instrukcję, jaką może otrzymać? Należy prześledzić wynikające z tego wywołania narzędzi, poświadczenia, uprawnienia, osiągalnych agentów i pamięci dostępne do zapisu.
Jeśli odpowiedź wykracza poza wąskie zadanie tego agenta, należy traktować taki zakres jako aktywną wadę bezpieczeństwa. Przejrzyj rolę, odizoluj publiczne środowiska uruchomieniowe, przetestuj granice pamięci i bezpośrednio potwierdź bieżące ustawienia domyślne AWS. Najbezpieczniejszy agent nie jest tym, który zawsze odrzuca manipulację. To taki agent, którego uprawnienia w chmurze nie pozwalają, by zmanipulowana odpowiedź przerodziła się w incydent obejmujący całe konto.
