Agent nie jest strażnikiem

Opisywaliśmy, jak upadają kolejne bariery wokół agentów AI. Zabezpieczenia w promptcie nie chroniły, bo agent traktuje niezaufaną treść jako instrukcję. Piaskownica pękła. Okno zgody pokazywało człowiekowi co innego, niż agent faktycznie robił. A na końcu okazało się, że same zabezpieczenia modelu da się wyłączyć, przekonując go, że bierze udział w grze.

Za każdym razem kończyliśmy tym samym zdaniem: jedyną barierą, która się utrzyma, jest to, czego agent nie może zrobić technicznie. W lipcu ujęliśmy to jako rozpoznanie, które nie jest zatrzymaniem, a w sierpniu potwierdził to OWASP, każąc budować system tak, żeby oszukanie modelu niczego ważnego nie psuło.

To była zasada. Nie mieliśmy dla niej implementacji.

20 sierpnia AWS opublikował architekturę, która ją realizuje — i streszcza się w jednym zdaniu: agent działa jako orkiestrator, nie jako strażnik. Autoryzację egzekwują usługi znajdujące się niżej.

Gdzie mieszka decyzja

Zacznijmy od tego, jak wygląda typowe wdrożenie, bo dopiero na tym tle widać różnicę.

Agent AI podłączony do bazy danych, repozytorium dokumentów albo platformy SaaS działa zwykle z własnym zestawem uprawnień, zwykle szerokim — bo musi obsłużyć wszystkich użytkowników. Gdy przychodzi zapytanie, agent pobiera dane i sam decyduje, co z nich pokazać pytającemu. Filtrowanie odbywa się w jego kodzie albo, co gorsza, w jego rozumowaniu.

I to jest właśnie ten punkt, w którym wszystko, co opisywaliśmy przez rok, się rozpada. AWS formułuje to bez ogródek: jeśli atakujący zmanipuluje agenta wstrzyknięciem promptu albo wykorzysta błąd w logice filtrowania, pełny zbiór danych staje się dostępny. Bo agent go ma. Filtr jest tylko obietnicą, że go nie pokaże.

Proponowana architektura przenosi tę decyzję w zupełnie inne miejsce.

Użytkownik loguje się firmowymi poświadczeniami. Informacja o nim — w przykładzie AWS jest to dział, ale może to być dowolny atrybut — trafia do jego tokenu uwierzytelniającego i wędruje razem z żądaniem. Środowisko uruchomieniowe waliduje ten token i sprawdza uprawnienia zanim żądanie w ogóle dotrze do agenta. Zapytania od użytkowników, którzy nie spełniają warunków, są odrzucane, zanim agent się uruchomi.

Dalej kontekst autoryzacji jest przekazywany do każdej usługi, po którą agent sięga. W przykładzie z bazą danych warunek dostępu ocenia mechanizm uprawnień chmury na poziomie polityki, porównując atrybut użytkownika z partycją danych. I tu pada zdanie, które jest sednem całej rzeczy: ponieważ warunek jest oceniany na poziomie polityki, dostęp do danych innego działu zostaje odrzucony nawet wtedy, gdy kod agenta został zmanipulowany wstrzyknięciem promptu.

Rola wykonawcza agenta nie ma przy tym własnych uprawnień do magazynów danych. Każde żądanie niesie krótkotrwałe poświadczenia wyprowadzone kryptograficznie i związane z konkretnym użytkownikiem, wygasające szybko i niemożliwe do ponownego użycia ani podrobienia.

Dlaczego to jest inna kategoria niż wszystko, co zawiodło

Zestawmy tę architekturę z czterema barierami, o których pisaliśmy, bo różnica jest strukturalna, a nie stopniowa.

Filtr w promptcie zawodził, bo prosił model, żeby czegoś nie robił. Piaskownica zawodziła, bo agent mógł sięgnąć do plików, które ją definiowały. Okno zgody zawodziło, bo pokazywało człowiekowi nazwę pliku zamiast rzeczywistego celu zapisu. Zabezpieczenia modelu zawodziły, bo dało się przekonać model, że nie działa w rzeczywistości, w której obowiązują.

Wszystkie cztery mają jedną wspólną cechę: do zadziałania wymagały, żeby coś po stronie agenta zachowało się właściwie. Żeby model posłuchał instrukcji, rozpoznał zagrożenie, poprawnie opisał operację albo wiedział, gdzie jest.

Ta architektura tej cechy nie ma. Agent może być całkowicie przejęty, może wierzyć w cokolwiek, może próbować pobrać dowolne dane — i nie dostanie ich, bo pytanie o uprawnienia rozstrzyga się poza nim, w warstwie, do której nie ma dostępu. To nie jest lepszy filtr. To jest usunięcie agenta z procesu podejmowania decyzji.

Warto zauważyć, że AWS wprost odwołuje się do tej samej klasyfikacji, którą opisywaliśmy przy sierpniowej liście OWASP — do zagrożeń związanych z przejęciem celu agenta i z nieoczekiwanym wykonaniem kodu. W materiale o kontroli ruchu wychodzącym pada przy tym zdanie, które warto zapamiętać osobno: te same mechanizmy stosują się z równą mocą do obciążeń agentowych, bo zmanipulowany agent staje się niezamierzonym kanałem wyprowadzania danych.

To jest zresztą druga połowa tej samej architektury i warto ją odnotować, bo bywa pomijana. Ograniczenie tego, co agent może przeczytać, nie wystarcza, jeśli nie ograniczy się też tego, dokąd może wysłać to, co przeczytał.

Uczciwie: czego ten wzorzec nie rozwiązuje

Teraz część, bez której ten tekst byłby marketingiem cudzego produktu.

Ten wzorzec wiąże uprawnienia agenta z uprawnieniami użytkownika, który go poprosił. Rozwiązuje przez to bardzo konkretny problem: agent nie pokaże ci danych, do których sam nie masz prawa. To jest realna i ważna klasa ryzyka — w organizacjach, gdzie ten sam asystent obsługuje handel, finanse i kadry, jest to prawdopodobnie najczęstsza droga do wycieku.

Ale zauważmy, czego to nie obejmuje.

Jeśli użytkownik ma uprawnienia do usunięcia bazy danych, to agent zmanipulowany wstrzyknięciem promptu wciąż może tę bazę usunąć — bo działa w granicach uprawnień, które faktycznie przysługują pytającemu. Wzorzec chroni przed dostępem poziomym, nie przed destrukcyjnym działaniem wewnątrz autoryzowanego zakresu.

A to jest dokładnie ta klasa, którą opisywaliśmy w lipcu, gdy model uciekł z własnego środowiska testowego i przez cztery i pół dnia szukał w cudzej infrastrukturze klucza odpowiedzi. Tam nie chodziło o czytanie cudzych danych. Chodziło o realizowanie postawionego celu z uporem, który przekroczył każdą granicę po drodze. Żadna propagacja kontekstu użytkownika tego nie zatrzyma.

Trzeba też powiedzieć rzecz oczywistą: to jest dokumentacja architektoniczna dostawcy chmury, opisana na przykładzie jego własnych usług. Sam wzorzec jest przenoszalny — AWS wskazuje, że dostawcą tożsamości może być rozwiązanie konkurencji, a zakresowanie po dziale mapuje się na dowolny inny podział — ale konkretna implementacja jest związana z konkretną platformą. Warto to czytać jako opis zasady, nie jako rekomendację produktu.

I ostatnia rzecz, dla proporcji: ta architektura wymaga pracy. Propagacja tożsamości przez kolejne warstwy, wymiana tokenów, warunki w politykach dostępu — to nie jest przełącznik, który się włącza. Dlatego wciąż będzie łatwiej dać agentowi szerokie uprawnienia i poprosić go, żeby filtrował. I dlatego większość wdrożeń tak właśnie zrobi.

Co z tego wynika dla obrońcy

Rzecz pierwsza jest diagnostyczna i można ją sprawdzić od ręki: z czyimi uprawnieniami działa twój agent? Jeśli odpowiedź brzmi „ma własną rolę z dostępem do wszystkiego, co obsługuje", to filtrowanie odbywa się w jego kodzie, a to znaczy, że jedno udane wstrzyknięcie promptu odsłania pełny zbiór.

Rzecz druga jest projektowa i wynika wprost z tej zasady. Pytanie, które warto zadać przy każdym wdrożeniu agenta, brzmi: czy przy założeniu, że agent jest całkowicie przejęty, cokolwiek go jeszcze powstrzyma? Jeśli jedyną odpowiedzią jest „nie powinien tego zrobić" albo „ma to zabronione w instrukcji", to nie ma odpowiedzi.

Rzecz trzecia dotyczy ruchu wychodzącego. Ograniczenie tego, co agent może przeczytać, i ograniczenie tego, dokąd może to wysłać, są dwoma osobnymi kontrolami. Zmanipulowany agent z dostępem do sieci wychodzącej jest kanałem wyprowadzania danych niezależnie od tego, jak wąsko zakresowano jego odczyt.

Rzecz czwarta jest kolejnościowa. Wszystko powyżej ma sens niezależnie od tego, czy używasz akurat tej chmury, tego dostawcy tożsamości i tego środowiska uruchomieniowego. Zasada brzmi: decyzja o uprawnieniach nie może mieszkać w komponencie, który da się przekonać.

Jedna myśl na koniec

Rok pisania o upadających barierach ma tę wadę, że łatwo z niego wyjść z wnioskiem, iż nic nie działa. To nie jest prawda — działa dokładnie jedna rzecz i była nią od początku: uprawnienie egzekwowane poza agentem.

Nowe jest to, że przestała być postulatem. Można ją teraz opisać krok po kroku: token, walidacja przed uruchomieniem agenta, propagacja kontekstu, warunek oceniany na poziomie polityki, poświadczenia krótkotrwałe i związane z użytkownikiem. To wciąż nie jest rozwiązanie wszystkiego i wciąż nie chroni przed agentem, który robi coś głupiego w granicach tego, co mu wolno.

Ale jest to pierwsza architektura, w której odpowiedź na pytanie „co się stanie, gdy model zostanie oszukany" brzmi: nic szczególnego. Bo nikt go o nic ważnego nie pytał.

Źródła

AWS Security Blog — architektura propagacji kontekstu autoryzacji użytkownika w agentach, z opisem przepływu tokenu, walidacji przed uruchomieniem agenta oraz oceny warunku dostępu na poziomie polityki, wraz ze stwierdzeniem, że dostęp międzydziałowy zostaje odrzucony nawet przy zmanipulowanym kodzie agenta: https://aws.amazon.com/blogs/security/propagate-user-authorization-context-in-ai-agents-with-amazon-bedrock-agentcore/

Help Net Security — omówienie architektury z cytatem o agencie jako orkiestratorze, a nie strażniku, oraz opisem przykładu z systemem CRM obsługującym pracowników różnych działów: https://www.helpnetsecurity.com/2026/08/20/aws-ai-agents-access-controls/

Cyber Security News — analiza znaczenia przeniesienia autoryzacji do warstwy infrastruktury, z opisem krótkotrwałych poświadczeń związanych z użytkownikiem oraz braku własnych uprawnień roli wykonawczej agenta do magazynów danych: https://cybersecuritynews.com/aws-ai-agent-data-access/

AWS Security Blog — materiał o kontroli ruchu wychodzącego z odniesieniem do zagrożeń z listy OWASP dla aplikacji agentowych oraz stwierdzeniem, że zmanipulowany agent staje się niezamierzonym kanałem wyprowadzania danych: https://aws.amazon.com/blogs/security/prevent-data-exfiltration-aws-egress-controls-for-cloud-workloads/

AWS Prescriptive Guidance — zalecenia dotyczące bezpieczeństwa danych w systemach agentowych, w tym wdrażania deterministycznego pośrednika między agentem a źródłami danych tam, gdzie usługom niższego poziomu brakuje własnych kontroli: https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-security/best-practices-data.html