CoreBreak: agenci AWS, Google i Vercel uruchamiali narzędzia bez modelu

Badania zaprezentowane jako CoreBreak ujawniły pięć podatności w infrastrukturze agentowej AWS, Google i Vercel. W różnych wariantach napastnik mógł dostarczyć komunikat wyglądający jak wynik modelu, sfałszować zatwierdzenie narzędzia albo wznowić sesję z przygotowanym function call. Runtime wykonywał akcję, mimo że żaden model jej nie zaproponował.

To zmienia sposób myślenia o guardrailach. System prompt, filtr treści i odmowa modelu nie mają znaczenia, jeśli warstwa wykonawcza przyjmuje poprawnie ukształtowany obiekt bez kryptograficznego lub stanowego dowodu jego pochodzenia.

Trzy warianty tej samej klasy

W Amazon Bedrock AgentCore endpoint InvokeHarness akceptował blok tool-use w końcowej wiadomości przekazanej przez uwierzytelnionego wywołującego. CVE-2026-18830 opisuje niedostateczną walidację wejścia. Serwerowa poprawka odrzuca takie bloki, lecz wdrożenia oparte bezpośrednio na frameworku powinny niezależnie sprawdzić własną historię wiadomości i dyspozytor.

W Google ADK badacze znaleźli problemy z wiązaniem zatwierdzenia z konkretnym narzędziem i argumentami oraz ze wznowieniem przepływu. Approval nie może być ogólnym „tak” przechowywanym w rozmowie. Musi dotyczyć dokładnej operacji, principalu, zasobu, parametrów i jednej instancji wykonania.

W harnessie Vercel kod działający w sandboxie mógł wykorzystać mechanizm zaufania do wywołania narzędzi hosta. Naprawa polegała m.in. na jednorazowych, podpisanych zgodach powiązanych z obserwowanym zdarzeniem modelu. To właściwy kierunek: dowód decyzji powstaje poza nieufnym kontekstem i nie może zostać odtworzony przez samą treść.

Jak wygląda bezpieczny tool gateway

Model jest planistą, nie principalem bezpieczeństwa. Narzędzie powinno otrzymać tożsamość użytkownika i agenta, tenant, dozwolony scope, hash parametrów, identyfikator przebiegu, czas ważności oraz wynik niezależnej polityki. Runtime musi sprawdzić tę strukturę bez pytania modelu, czy jest prawidłowa.

Po wykonaniu zgoda powinna zostać zużyta. Ponowne odtworzenie wiadomości, retry po timeout albo wznowienie starej sesji nie może ponownie uruchomić płatności, usunięcia danych czy odczytu sekretu. Idempotency chroni przed błędem, ale nie zastępuje autoryzacji.

Co powinny zrobić zespoły

1. Zaktualizuj SDK, managed runtime i adaptery do wersji wskazanych przez AWS, Google i Vercel; sprawdź też kod skopiowany lub sforkowany.
2. Narysuj przepływ od wiadomości do dyspozytora narzędzi i zaznacz, gdzie powstaje decyzja o autoryzacji.
3. Odrzucaj tool calls pochodzące bezpośrednio z wejścia użytkownika, pamięci, historii wznowienia lub sandboxu.
4. Wiąż approval z nazwą narzędzia, pełnymi argumentami, zasobem, principalem, tenantem i krótkim terminem ważności.
5. Stosuj jednorazowe nonce, podpis lub MAC oraz przechowuj stan zatwierdzenia poza kontekstem LLM.
6. Alertuj na wykonanie narzędzia bez poprzedzającego zdarzenia inferencji i decyzji policy engine.
7. Testuj replay, zamianę argumentów, podmianę tenantów, resume oraz sfałszowane role wiadomości jako przypadki regresyjne.

Gateway powinien wydawać zdolności, nie przekazywać całą sesję

Zamiast przekazywać agentowi stały token chmurowy, warstwa narzędziowa może wystawiać jednorazową zdolność do konkretnej akcji: wskazanego zasobu, metody, limitu danych i krótkiego okna czasu. Gateway ponownie sprawdza parametry po ich znormalizowaniu, dzięki czemu model nie może zmienić celu przez alternatywne kodowanie, redirect albo nazwę symboliczną wskazującą inny obiekt.

Ważne jest rozdzielenie decyzji „model proponuje” od „system zatwierdza”. Schemat narzędzia waliduje typy, policy engine ocenia tożsamość i klasyfikację danych, a wykonawca nie przyjmuje dodatkowych pól poza podpisaną decyzją. Dla operacji nieodwracalnych potrzebny jest etap human-in-the-loop pokazujący finalny, rozwinięty cel — po rozwiązaniu aliasów i redirectów. Log audytowy powinien zawierać hash promptu, wersję polityki, argumenty przed i po normalizacji oraz wynik zewnętrznego API.

Fakty i wnioski

Prezentacja CoreBreak w harmonogramie Black Hat i advisory dostawców potwierdzają pięć ustaleń i wdrożone poprawki w większości komponentów. Nie ma informacji o masowym wykorzystaniu tych ścieżek produkcyjnie.

Wniosek Breachroad: autoryzacja musi być deterministyczna i egzekwowana po stronie narzędzia. Audyt bezpieczeństwa AI/LLM powinien śledzić cały protokół wykonawczy, a szkolenia dla zespołów uczyć rozdzielania inteligencji od uprawnień.