Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ujawnione podatności w rozwiązaniach Amazon Bedrock AgentCore, Google Agent Development Kit for Python oraz pakietach Vercel AI SDK pokazały istotny problem bezpieczeństwa w architekturze agentów AI. W każdym z tych przypadków warstwa wykonawcza akceptowała dane wyglądające jak autoryzowane wywołanie narzędzia, mimo że nie zostały one faktycznie zatwierdzone przez model językowy.
W praktyce oznaczało to możliwość uruchamiania funkcji agenta z pominięciem promptów systemowych, mechanizmów kontroli treści i dodatkowych zabezpieczeń opartych na decyzji modelu. To nie był klasyczny prompt injection, lecz obejście granicy zaufania między modelem a wykonaniem akcji.
W skrócie
Badacze bezpieczeństwa opisali trzy odrębne zestawy luk, które prowadziły do podobnego efektu: narzędzia agentów mogły zostać uruchomione bez legalnej tury modelu. Problem objął usługi i biblioteki rozwijane przez AWS, Google oraz Vercel.
- AWS poprawił problem po stronie zarządzanej usługi Bedrock AgentCore.
- Google usunął błędy w ADK for Python w wersji 2.5.0.
- Vercel opublikował poprawki dla pakietów harness związanych z agentami kodującymi.
Wspólnym mianownikiem był brak skutecznej weryfikacji, czy żądanie wykonania narzędzia rzeczywiście pochodziło z autoryzowanej ścieżki działania modelu.
Kontekst / historia
Agenci AI są coraz częściej wykorzystywani jako warstwa pośrednia między modelem językowym a narzędziami wykonującymi konkretne operacje. Mogą one obsługiwać zapytania do API, odczyt sekretów, wdrożenia, działania w chmurze, a nawet uruchamianie kodu. Standardowy mechanizm zakłada, że model analizuje kontekst, a następnie generuje uporządkowaną instrukcję użycia narzędzia.
Opisane przypadki podważyły ten model bezpieczeństwa. Zamiast wymagać dowodu, że konkretna akcja została zatwierdzona przez model w ramach legalnej sesji, podatne komponenty przyjmowały odpowiednio sformatowane dane jako wystarczającą podstawę do wykonania operacji.
Sprawa ma też szerszy wymiar architektoniczny. Wraz z rozwojem systemów agentowych rośnie ryzyko, że organizacje będą nadmiernie ufały zabezpieczeniom osadzonym wyłącznie na poziomie LLM, ignorując konieczność twardej autoryzacji w runtime.
Analiza techniczna
Istotą problemu był brak niezawodnego powiązania wywołania narzędzia z konkretną decyzją modelu. Jeśli runtime nie weryfikuje pochodzenia żądania, to każde dane wejściowe przypominające autoryzowane polecenie mogą zostać potraktowane jako legalne.
W Amazon Bedrock AgentCore podatność dotyczyła ścieżki InvokeHarness. Uwierzytelniony użytkownik mógł dostarczyć blok typu tool-use w końcowej wiadomości żądania, a mechanizm wykonywania mógł uznać go za prawidłową instrukcję użycia narzędzia. W efekcie możliwe było pominięcie uruchomienia modelu i wszystkich kontroli związanych z jego odpowiedzią.
W Google ADK dla Pythona badacze wskazali dwa pokrewne problemy. Pierwszy dotyczył mechanizmu potwierdzania narzędzi wymagających dodatkowej zgody. Jeśli atakujący mógł manipulować historią sesji lub wstrzykiwać zdarzenia, był w stanie sfałszować potwierdzenie wykonania wrażliwego narzędzia. Drugi problem obejmował tryb resumable, w którym komunikaty użytkownika mogły zawierać fragmenty function_call interpretowane jako bezpośrednie instrukcje uruchomienia narzędzia.
W przypadku Vercel problem miał inną ścieżkę wykorzystania, ale prowadził do podobnego rezultatu. Warstwa relay ufała procesowi w sandboxie, jeśli spełniał on określone warunki identyfikacyjne. To otwierało drogę do uzyskania dostępu do narzędzi hosta przez niezaufany kod działający już w środowisku izolowanym, w tym do funkcji związanych z wdrożeniami, sekretami i API chmurowymi.
W ujęciu architektonicznym wszystkie trzy przypadki pokazują ten sam antywzorzec: format danych został potraktowany jako dowód uprawnienia. Tymczasem prawidłowy model bezpieczeństwa wymaga powiązania każdej akcji z sesją, stanem autoryzacji, decyzją modelu oraz nienaruszonym zestawem argumentów.
Konsekwencje / ryzyko
Skutki takich luk zależą przede wszystkim od tego, jakie uprawnienia miał agent oraz do jakich zasobów był podłączony. Sama podatność nie nadawała agentowi nowych uprawnień, ale pozwalała przejąć te, które już posiadał w środowisku produkcyjnym.
- nieautoryzowane uruchamianie narzędzi administracyjnych,
- odczyt lub ujawnienie sekretów, tokenów i danych dostępowych,
- modyfikację konfiguracji lub artefaktów wdrożeniowych,
- wykonywanie operacji w chmurze z uprawnieniami przypisanymi agentowi,
- obejście kontroli bezpieczeństwa opartych wyłącznie na promptach i logice modelu.
To szczególnie groźne w środowiskach, w których agent pełni rolę operacyjną, integruje się z CI/CD, repozytoriami kodu, systemami chmurowymi lub magazynami sekretów. W takich scenariuszach błąd w walidacji ścieżki wykonania może prowadzić do realnego naruszenia integralności środowiska.
Rekomendacje
Organizacje wdrażające agentów AI powinny traktować warstwę wykonawczą jako kluczowy punkt egzekwowania bezpieczeństwa. Nie wystarczy zakładać, że model, prompt systemowy lub mechanizm potwierdzeń same w sobie zablokują nieautoryzowane użycie narzędzi.
- zaktualizować komponenty do wersji zawierających poprawki,
- odrzucać wszelkie wywołania narzędzi, function_call i komunikaty potwierdzeń pochodzące z niezaufanych granic systemu,
- powiązać każde wykonanie narzędzia z konkretnym zdarzeniem modelu, identyfikatorem sesji, nazwą narzędzia i zestawem argumentów,
- stosować zasadę najmniejszych uprawnień dla agentów, ról IAM, sekretów i narzędzi hostowych,
- utrzymywać twardą segmentację między sandboxem a hostem,
- rejestrować i audytować wszystkie wywołania narzędzi w celu wykrywania anomalii.
Z perspektywy AppSec i DevSecOps warto przeprowadzić przegląd architektury agentów pod kątem pytania, czy jakikolwiek użytkownik, proces, plugin lub zależność może dostarczyć dane wyglądające jak autoryzowane polecenie wykonania. Jeśli tak, obecny model ochrony może być niewystarczający.
Podsumowanie
Luki ujawnione w AWS, Google i Vercel nie są wyłącznie serią odizolowanych błędów, lecz sygnałem ostrzegawczym dla całego ekosystemu agentów AI. Pokazują, że granica zaufania nie może kończyć się na modelu językowym.
Bezpieczeństwo agentów wymaga ścisłej autoryzacji w runtime, integralności przepływu sterowania oraz jednoznacznego potwierdzenia pochodzenia każdego wywołania narzędzia. Dla organizacji rozwijających systemy agentowe to wyraźna wskazówka, że ochrona promptu nie zastąpi kontroli wykonania.
Źródła
- https://thehackernews.com/2026/08/aws-google-and-vercel-patch-agent-flaws.html
- https://github.com/google/adk-python/releases/tag/v2.5.0
- https://nvd.nist.gov/vuln/detail/CVE-2026-18236
- https://github.com/advisories/GHSA-8fq9-q6jc-57v8
- https://github.com/advisories/GHSA-76m4-4vjr-r9w5