Zero trust dla agentów AI: założenia zaufania, które wykorzystuje atakujący — i egzekwowanie, które je blokuje

Architektura zero trust powstała dla ludzi i serwerów. Agenty AI łamią jej milczące założenia: same decydują, co zrobić w następnym kroku, wywołują narzędzia w cudzym imieniu i rozmnażają się w sekundy. Statyczny klucz API i jednorazowe logowanie tu nie wystarczą. Poniżej tłumaczę, jak przełożyć zasady zero trust na warstwę agentową — kto pyta o pozwolenie, gdzie zapada decyzja i jak agenty mają się sobie nawzajem uwierzytelniać.

Czym jest zero trust dla agentów AI i jak go egzekwować?

Zero trust dla agentów AI to model, w którym żadne wywołanie — ani człowieka, ani agenta, ani narzędzia — nie jest domyślnie zaufane. Każde żądanie dostępu jest uwierzytelniane, autoryzowane i szyfrowane osobno, w momencie wykonania, niezależnie od tego, czy pochodzi z wnętrza sieci, czy spoza niej. Egzekwowanie opiera się na trzech filarach: ciągłej weryfikacji tożsamości i kontekstu przy każdym kroku, punkcie decyzji polityki (PDP), który centralnie rozstrzyga „tak/nie“, oraz wzajemnym mTLS między agentami, który gwarantuje, że obie strony połączenia są tym, za kogo się podają.

W praktyce oznacza to przesunięcie kontroli z brzegu sieci do każdego pojedynczego wywołania. Agent, który chce odczytać bazę, nie dostaje dostępu dlatego, że „działa w naszym klastrze“. Dostaje go, bo w tej sekundzie ma ważną, krótko ważną tożsamość, jego żądanie pasuje do polityki, a kanał jest obustronnie zweryfikowany. Reszta artykułu rozkłada te trzy filary na części pierwsze.

Dlaczego klasyczny zero trust nie wystarcza dla agentów?

Klasyczny zero trust zakłada, że podmiot (użytkownik lub usługa) jest względnie stabilny: ma trwałą tożsamość, przewidywalny zakres działań i człowieka, który ponosi odpowiedzialność. Agent AI łamie każde z tych założeń po kolei.

Po pierwsze, agent działa w cudzym imieniu. Wywołuje API, kasuje pliki i wysyła wiadomości jako delegat użytkownika albo innej usługi. Jeśli polityka widzi tylko tożsamość samego agenta, traci z oczu pytanie kluczowe: w czyim imieniu i z jakim zakresem uprawnień on teraz działa.

Po drugie, agent jest nieprzewidywalny. To samo zapytanie raz kończy się jednym wywołaniem narzędzia, a raz pętlą dziesięciu kroków, bo model sam planuje trasę. Uprawnienia nadane „na zapas, raz na dobę“ stają się dziurą — agent przejęty przez wstrzyknięcie polecenia (prompt injection) wykorzysta każde uprawnienie, które akurat ma w kieszeni; obrona to wąskie, krótkożyciowe uprawnienia per narzędzie.

Po trzecie, agenty mnożą się i znikają w tempie, którego ręczne nadawanie dostępów nie nadgoni. Trwały klucz API zaszyty w obrazie kontenera to dokładnie ten antywzorzec, który zero trust miał wyplenić — tyle że teraz w skali tysięcy efemerycznych podmiotów.

Wniosek jest prosty: tożsamość agenta musi być krótko ważna i sprawdzana w locie, a decyzja o dostępie musi uwzględniać kontekst delegacji, a nie tylko „kto dzwoni“.

Na czym polega ciągła weryfikacja w systemie agentowym?

Ciągła weryfikacja to rezygnacja z modelu „uwierzytelnij raz, ufaj do wylogowania“ na rzecz oceny zaufania przy każdym istotnym kroku. W systemie agentowym istotny krok to nie tylko zalogowanie — to każde wywołanie narzędzia, każde przejście do innej usługi, każda zmiana zakresu działania.

W praktyce ciągła weryfikacja składa się z kilku elementów. Tożsamość agenta jest krótko ważna: token żyje minuty, nie miesiące, i odnawia się automatycznie. Kontekst żądania jest oceniany na bieżąco: kto jest pierwotnym zleceniodawcą, jakie narzędzie agent chce wywołać, jakie dane wchodzą w grę, czy zachowanie nie odbiega od normy. A decyzja jest odwoływalna: jeśli w trakcie sesji wykryjemy anomalię, kolejne wywołanie zostaje zablokowane, mimo że poprzednie przeszło.

Dobrą bazą pojęciową jest tu publikacja NIST SP 800-207, która definiuje zero trust jako ciągłą ocenę zaufania opartą na zasadzie najmniejszych uprawnień i braku domyślnego zaufania do lokalizacji w sieci. Dla agentów dokładamy do tego wymiar delegacji — token musi nieść informację, że agent działa w imieniu konkretnego użytkownika i tylko w wąsko określonym zakresie (na przykład poprzez OAuth 2.0 i mechanizm token exchange opisany w RFC 8693).

Kluczowa zmiana mentalna: nie pytamy „czy ten agent jest zaufany“, tylko „czy to konkretne żądanie, w tym kontekście, w tej sekundzie, mieści się w polityce“.

Czym jest punkt decyzji polityki (PDP) i punkt egzekwowania (PEP)?

Punkt decyzji polityki (PDP, Policy Decision Point) to komponent, który odpowiada na jedno pytanie: „czy to żądanie wolno wykonać?“. Punkt egzekwowania polityki (PEP, Policy Enforcement Point) to komponent, który to pytanie zadaje i który wykonuje wyrok — przepuszcza żądanie albo je blokuje. Rozdzielenie tych dwóch ról to fundament architektury zero trust, opisany m.in. w modelu NIST.

Przewaga tego podziału jest praktyczna. Logika autoryzacji żyje w jednym miejscu (PDP), spięta z politykami pisanymi deklaratywnie, a nie rozsiana po kodzie każdego agenta. Egzekwowanie dzieje się tam, gdzie płynie ruch (PEP) — przy bramie API, w proxy sidecar, w warstwie wywołania narzędzia. Agent nie nosi w sobie reguł bezpieczeństwa; pyta zewnętrzny mózg i dostaje jednoznaczną odpowiedź.

Tak wygląda przepływ żądania w modelu PDP/PEP dla agenta:

Etap	Kto działa	Co się dzieje
1. Żądanie	Agent	Chce wywołać narzędzie lub usługę i trafia na PEP
2. Zapytanie o decyzję	PEP	Pyta PDP: podmiot, akcja, zasób, kontekst delegacji
3. Ewaluacja polityki	PDP	Zestawia żądanie z politykami i sygnałami ryzyka
4. Decyzja	PDP → PEP	Zwraca „zezwól“ / „odmów“ (ew. z ograniczeniami)
5. Egzekwowanie	PEP	Przepuszcza lub blokuje; loguje wynik

Do zapisywania polityk warto sięgnąć po dojrzałe standardy. OPA (Open Policy Agent) z językiem Rego pełni rolę PDP dla autoryzacji usług i jest projektem CNCF. Cedar (silnik polityk rozwijany przez AWS i wykorzystywany w Amazon Verified Permissions) daje czytelny, weryfikowalny język polityk dostępu. Oba pozwalają trzymać reguły poza kodem agenta, wersjonować je i audytować — co przy efemerycznych, nieprzewidywalnych agentach jest warunkiem panowania nad systemem.

Jakie sygnały powinien brać pod uwagę PDP przy agentach?

Polityka dla agenta nie może opierać się wyłącznie na statycznej roli. Sensowny PDP łączy kilka warstw sygnałów w jednej decyzji:

• Tożsamość agenta — zweryfikowana, krótko ważna, najlepiej oparta na standardzie tożsamości obciążeń (SPIFFE/SPIRE).
• Kontekst delegacji — w czyim imieniu agent działa i z jakim zakresem (token wymieniony zgodnie z RFC 8693).
• Akcja i zasób — konkretne narzędzie, metoda, wrażliwość danych.
• Sygnały ryzyka — częstotliwość wywołań, odchylenie od typowego wzorca, pora, źródło.
• Ograniczenia wyniku — decyzja może być warunkowa: „zezwól, ale tylko do odczytu“ albo „zezwól, ale wymagaj potwierdzenia człowieka“.

Im więcej z tych sygnałów trafia do PDP, tym bliżej jesteśmy realnej zasady najmniejszych uprawnień, a nie jej deklaracji.

Jak działa mTLS między agentami i dlaczego jest potrzebny?

mTLS (mutual TLS, wzajemny TLS) to odmiana TLS, w której obie strony połączenia przedstawiają certyfikat i obie się nawzajem weryfikują — nie tylko klient sprawdza serwer, jak w zwykłym HTTPS. W komunikacji agent–agent oznacza to, że agent A wie z pewnością kryptograficzną, że rozmawia z agentem B, a nie z podstawionym pośrednikiem, i odwrotnie.

To odpowiedź na konkretne zagrożenie. W systemie wielu agentów ruch wewnętrzny bywa traktowany jak „zaufana sieć“ — i właśnie tam zero trust każe nie ufać. Bez wzajemnego uwierzytelniania przejęty albo podszywający się agent może wpiąć się w łańcuch wywołań, podać się za usługę zaufaną i przejąć dane lub uprawnienia. mTLS zamyka tę furtkę na poziomie transportu: brak ważnego certyfikatu po drugiej stronie to brak połączenia.

Praktyczny szkielet wygląda tak. Każdy agent (jako obciążenie) dostaje tożsamość kryptograficzną zamiast hasła — standardem branżowym jest tu SPIFFE (Secure Production Identity Framework for Everyone) i jego implementacja SPIRE, projekty CNCF. Tożsamość ma postać dokumentu SVID (np. krótko ważnego certyfikatu X.509), który jest automatycznie rotowany. Siatka usług (service mesh, np. Istio czy Linkerd) potrafi narzucić mTLS między obciążeniami niejako „z zewnątrz“, bez przepisywania kodu agentów, i często integruje się z SPIFFE.

Co ważne, mTLS i PDP grają w jednej drużynie, ale rozwiązują różne problemy. mTLS odpowiada na pytanie „czy ten kanał jest autentyczny i poufny“ (uwierzytelnienie + szyfrowanie transportu). PDP odpowiada na pytanie „czy temu podmiotowi wolno wykonać tę akcję“ (autoryzacja). Dopiero razem dają pełne egzekwowanie: zweryfikowana tożsamość po obu stronach łącza plus decyzja polityki przy każdym żądaniu.

Certyfikaty o krótkim czasie życia zamiast stałych sekretów

Najważniejsza zasada higieny przy mTLS dla agentów: certyfikaty mają mieć krótki czas życia i automatyczną rotację, a nie być zaszyte w obrazie na zawsze. Trwały sekret, który wyciekł, daje napastnikowi tygodnie dostępu. Certyfikat ważny godzinę ogranicza okno ataku do godziny i znosi potrzebę ręcznego odwoływania. SPIRE realizuje to wprost — wydaje i odświeża SVID-y, a obciążenie nigdy nie przechowuje trwałego klucza prywatnego dłużej, niż musi.

Jak złożyć te trzy filary w jeden przepływ?

Zobaczmy, jak ciągła weryfikacja, PDP/PEP i mTLS współpracują w pojedynczym wywołaniu agenta, który chce odczytać rekord klienta w imieniu zalogowanego użytkownika:

1. Tożsamość obciążenia. Agent uruchamia się i przez SPIRE otrzymuje krótko ważny SVID — swoją kryptograficzną tożsamość.
2. Kontekst delegacji. Agent wymienia token użytkownika na wąsko zakresowany token „w imieniu“ (token exchange wg RFC 8693), więc niesie informację, dla kogo działa i co mu wolno.
3. Kanał mTLS. Połączenie do usługi danych zestawia się przez wzajemny TLS — obie strony weryfikują certyfikaty. Podstawiona usługa nie przejdzie.
4. Decyzja polityki. PEP przed usługą pyta PDP (OPA/Cedar): „agent X, w imieniu użytkownika Y, chce odczytać rekord Z — wolno?“. PDP zestawia tożsamość, delegację, wrażliwość danych i ryzyko.
5. Egzekwowanie i ślad. PEP wykonuje wyrok i loguje go. Następne wywołanie w tej samej sesji przechodzi tę samą bramkę od nowa — bez domyślnego zaufania do tego, że „przecież już raz przeszło“.

Ten sam przepływ powtarza się przy każdym kroku planu agenta. To jest sedno: zero trust agentowy nie jest bramą na wejściu, lecz bramką przy każdym pojedynczym działaniu.

Od czego zacząć wdrożenie zero trust dla agentów?

Wdrożenie warto rozłożyć na warstwy, a nie próbować zbudować wszystkiego naraz. Sensowna kolejność wygląda następująco.

Zacznij od tożsamości obciążeń: zastąp trwałe klucze API certyfikatami o krótkim czasie życia (SPIFFE/SPIRE). To samo w sobie zamyka najczęstszą dziurę — wykradziony, wieczny sekret. Następnie narzuć mTLS na ruch między agentami; siatka usług pozwala zrobić to bez przepisywania kodu i daje szyfrowanie oraz wzajemne uwierzytelnianie „za darmo“ względem aplikacji.

Kolejny krok to wydzielenie PDP: przenieś logikę autoryzacji do OPA lub Cedar, zacznij od polityk dla najwrażliwszych narzędzi i danych. Na końcu dołóż kontekst delegacji (token exchange) i sygnały ryzyka, żeby decyzje uwzględniały, w czyim imieniu agent działa i czy nie zachowuje się anomalnie.

Przez cały czas trzymaj się dwóch zasad zero trust: najmniejsze uprawnienia (agent dostaje dokładnie tyle, ile potrzebuje na ten krok) i pełna audytowalność (każda decyzja PDP zostawia ślad). Bez logów nie odtworzysz, dlaczego agent zrobił to, co zrobił — a przy nieprzewidywalnych systemach to często jedyna droga do diagnozy incydentu.

Podsumowanie

Zero trust dla agentów AI sprowadza się do trzech współpracujących filarów. Ciągła weryfikacja zastępuje jednorazowe logowanie oceną zaufania przy każdym kroku. Punkt decyzji polityki (PDP) z punktem egzekwowania (PEP) centralizuje „tak/nie“ poza kodem agenta, na dojrzałych silnikach jak OPA czy Cedar. mTLS między agentami — najlepiej z tożsamościami SPIFFE/SPIRE o krótkim czasie życia — gwarantuje, że obie strony łącza są autentyczne. Żaden z tych filarów osobno nie wystarczy: dopiero razem dają system, w którym przejęty czy podszywający się agent nie ma swobody, bo każde jego działanie z osobna musi przejść przez bramkę.