Publikacja AgentCorruption Zenity z 8 października opisuje historyczną ścieżkę od publicznie dostępnego agenta Amazon Bedrock AgentCore do sąsiednich środowisk runtime i trwałej pamięci. Warunkiem była zbyt szeroka rola wykonawcza w tym samym koncie AWS i regionie, nie włamanie do innych klientów ani kradzież hasła administratora.
Polecenie wywołało żądanie sieciowe ujawniające tymczasowe poświadczenia, a IAM zwiększył ich zasięg. Przed publikacją badacze stwierdzili istotne ograniczenie domyślnej roli przez AWS. To dowód słabości wcześniejszych testowanych ustawień, nie pełnej podatności każdej dzisiejszej instalacji.
Polecenie przekroczyło granicę tożsamości środowiska
AgentCore, ogólnie dostępny od października 2025, łączy izolowane runtime z tożsamością, pamięcią, bramami, przeglądarką, wykonywaniem kodu i obserwowalnością. Rozwiązuje realne problemy, ale integracja tworzy zależności autoryzacji poza granicą microVM.
W teście narzędzie HTTP wykonało niezaufane instrukcje i pobrało lokalne metadane. AWS używa usługi link-local; Firecracker w AgentCore udostępnia pokrewny MMDS. Tymczasowe poświadczenia roli legalnie pozwalają kodowi korzystać z zatwierdzonych zasobów bez stałych kluczy w obrazach.
Żądanie pochodziło z microVM, więc wyglądało lokalnie i zwróciło tymczasowy klucz dostępu, klucz tajny oraz token sesji. To SSRF: napastnik skłania serwer do kontaktu z celem niedostępnym bezpośrednio. Injection dostarcza intencję, narzędzie sieć, a metadane tożsamość.
Sam niebezpieczny tekst nie tworzy takiej ścieżki. Zablokowanie zbędnego dostępu narzędzia do metadanych przerwałoby ją; wąska rola ograniczyłaby skutki kradzieży. AWS jawnie mówi, że kod i podmioty wewnątrz microVM mogą pobierać dostępne poświadczenia, i zaleca minimalne prawa.
Zenity zgłosiło metadane 25 grudnia 2025. AWS zamknął sprawę jako informacyjną 12 kwietnia 2026, wskazując IMDSv2 w nowych wdrożeniach od 14 lutego. Tokenowy etap blokuje wiele tradycyjnych SSRF, lecz elastyczny agent może wykonać także wstępne żądania. Zdaniem Zenity zwiększa to trudność, nie rozwiązuje zaufania.
Obecna dokumentacja mówi o odrzucaniu runtime bez MMDSv2 od 30 czerwca 2026. Klient powinien sprawdzić rzeczywiste ustawienia, w tym requireMMDSV2, zamiast zakładać migrację całej historii. Metadane są jedną warstwą, nie uzasadnieniem nadmiernych praw legalnego kodu.
Szerokie prawa rozszerzyły punkt zaczepienia
Drugi raport z 12 stycznia dotyczył zasięgu roli. Regionalna lista grup logów CloudWatch i wzorce nazw AgentCore ujawniały identyfikatory runtime i pamięci bez wcześniejszego spisu. Prawa ECR i przewidywalne repozytoria łączyły je z obrazami, potencjalnie odsłaniając kod oraz konfigurację.
Testowane wywołania z wildcardem docierały do prywatnych agentów tego samego konta i regionu. Publiczny bot wsparcia mógł dojść do wrażliwszego agenta rozliczeń. Zenity pokazało jego narzędzia i billing.json przez legalne API, nie drugi niezależny exploit.
Prawa pamięci miały pozwalać listować aktorów i sesje oraz czytać zdarzenia innych agentów i użytkowników. Rozmowy mogły zawierać dane osobowe, kod, plany, rekordy klientów lub poświadczenia wklejone podczas diagnozy. Czy sekret powinien trafić do rozmowy i czy obcy proces może ją czytać to dwie odrębne sprawy.
Tworzenie i usuwanie zdarzeń dotykało także integralności. Fałszywy kontekst trafiał do aktywnej sesji, a prawdziwe wyniki narzędzi mogły znikać. Izolacja obliczeń nie zabraniała tożsamości wywoływać ani zmieniać innych zasobów; izolacja autoryzacji jest osobnym wymogiem.
AWS poinformował 25 lutego o pracy nad problemem. Według badaczy 22 czerwca rola pozostawała bez zmian, ale 29 września była mocno ograniczona: usunięto wywołania innych runtime, dostęp do prywatnych rozmów i Secrets Manager, zawężając pozostałe prawa.
To istotnie zmienia ocenę teraźniejszości. Własne role, skopiowane polityki i starsze instalacje wymagają przeglądu, ale demonstracja historyczna nie dowodzi tych samych dzisiejszych uprawnień. Badano kontrolowane środowiska; cytowane publiczne dane nie wykazują szerokich ataków na klientów. AWS nie opublikował wtedy osobnego biuletynu całej ścieżki.
Pamięć mogła utrwalać wpływ po wygaśnięciu poświadczeń
Krótka pamięć przechowuje zdarzenia sesji, długie strategie wydobywają fakty, preferencje, podsumowania i lekcje. Pomaga to pamiętać otwartą sprawę lub styl, ale czyni historię wejściem do przyszłych decyzji, nie tylko materiałem po incydencie.
Zenity opisywało identyfikatory z logów, wyliczanie aktorów, sesji i strategii oraz dodawanie wrogich zdarzeń. Ekstrakcja zamieniała część treści w długoterminowe rekordy, pobierane później jako zaufany kontekst. Początkowy injection nie musiał być powtarzany przy każdej rozmowie.
Badacze nazywają to trwałym sterowaniem w ich teście. Zachowanie zależy od konfiguracji, wyszukiwania, modelu, narzędzi i praw. Fałszywy adres, zgoda lub podsumowanie ilustrują ryzyko integralności, nie dowód, że każdy zapis kontroluje każdego agenta.
Dopisane zdarzenie asystenta może wyglądać jak dawna decyzja, usunięty wynik zabiera kontrdowód. Wygaśnięcie lub rotacja kluczy zatrzyma dalsze API, ale nie usunie skopiowanego kodu, sekretów czy skażonego stanu. Odtworzenie wymaga odnalezienia dotkniętych sesji, zdarzeń, podsumowań i wspomnień.
AWS zaleca walidację, zabezpieczenia przed zapisem, regularne testy injection i najmniejsze prawa pamięci. Pochodzenie powinno wskazywać użytkownika, agenta, sesję i proces ekstrakcji, umożliwiając kwarantannę. Preferencje stylu różnią się od adresów płatności lub przyznawania dostępu, które wymagają silniejszego tworzenia, retencji i przeglądu.
Pamięć nie może sama autoryzować ryzyka. Zapamiętane konto bankowe nie zastępuje aktualnej niezależnej zgody. Oprócz odczytów trzeba monitorować zapis i usuwanie, nietypowe liczby i ruch między agentami, łącząc CloudTrail, logi aplikacji i obserwowalność AgentCore.
Autoryzacja musi istnieć poza decyzją modelu
AWS ostrzega przed szerokimi politykami deweloperskimi generowanymi CLI w produkcji i zaleca konkretne ARN runtime zamiast wildcardów. Rola nie powinna mieć większych praw niż podmioty uprawnione do jej wywołania. Publiczny agent potrzebuje szczególnie wąskich uprawnień.
Nie każdy publiczny agent jest niebezpieczny. Język wejściowy pozostaje jednak niezaufany, także od uwierzytelnionych klientów i z dokumentów czy stron zawierających instrukcje pośrednie. Uwierzytelnienie identyfikuje osobę, nie zabezpiecza całej przesłanej treści.
Bramy, guardrails i interceptory pomagają, o ile inna dozwolona ścieżka ich nie omija. Jeżeli brama jest wejściem, bezpośrednie wywołanie runtime powinno należeć tylko do jej roli. Tożsamość użytkownika musi wynikać ze zweryfikowanego podmiotu, nie z modelu lub deklaracji klienta.
IAM ograniczony zasobami może blokować innych agentów, obrazy, regionalne logi i pamięci. Publiczne oraz wewnętrzne procesy nie powinny dzielić roli dla wygody; oddzielne konta lub regiony mogą dać wyraźniejsze granice.
Narzędzia są uprzywilejowanymi interfejsami, nie prawami nadanymi wyborem modelu. Autoryzacja musi niezależnie rozpatrzyć użytkownika, zasób i operację. Bazy wiedzy technicznej mogą połączyć właścicieli, polityki, modele zagrożeń i procedury, lecz nie zastępują wymuszonej odmowy.
Obecny przegląd potrzebuje historii i trwałego stanu
Przegląd powinien objąć role, metadane, wejścia publiczne/IAM/JWT, obejścia bramy, prawa między runtime, ECR i logi, pamięć między użytkownikami, tworzenie/usuwanie oraz tokeny i Secrets Manager. Polityki zasobów i tożsamości trzeba testować wspólnie pod kątem oczekiwanej odmowy, nie oceniać po działającym prototypie.
Historyczna ekspozycja wymaga odpowiednich zdarzeń CloudTrail, wywołań runtime, aktywności metadanych, pobrań obrazów, pamięci i sekretów, a nie tylko bieżących polityk. Tymczasowe klucze mogą zostawić trwałe skutki; rotacja i sprawdzanie stanu są komplementarne.
Przydatne byłyby formalny biuletyn lub migracja AWS, silniejsze oddzielenie narzędzi od punktów poświadczeń i widoczne pochodzenie pamięci, wąskie zapisy, alerty oraz zbiorowa kwarantanna. To dowody do poszukania, nie funkcje uznane za gotowe.
Szersze pytanie brzmi, co pozostaje możliwe po wykonaniu złośliwego polecenia. Zarządzana infrastruktura zmniejsza złożoność, lecz nie może bezpiecznie łączyć narzędzi, tożsamości i trwałej pamięci w jedną szeroko zaufaną rolę. Deterministyczne granice mają powstrzymać zmanipulowaną odpowiedź przed incydentem całego konta nawet przy porażce modelu.
Źródła i dodatkowa lektura
Badanie łańcucha Zenity · Wytyczne AWS o poświadczeniach · Analiza roli Zenity · Bezpieczeństwo runtime AWS · Kontekst: bazy wiedzy technicznej · Badanie zatruwania pamięci · Praktyki pamięci AWS · Relacja o AgentCorruption