Zerowe zaufanie dla agentów

Architektura bezpieczeństwa "never trust, always verify" dla agentów AI — każde żądanie agenta wymaga weryfikacji tożsamości i autoryzacji, niezależnie od lokalizacji sieciowej. Zero trust enforcement sprawia że governance CoE AI jest egzekwowalne technicznie, nie tylko na papierze.

W Polsce nazywane też:

zero trust agentyzerowe zaufanie AInever trust always verifyarchitektura ZTA dla agentów

Tradycyjna architektura bezpieczeństwa IT opierała się na założeniu: sieć wewnętrzna jest bezpieczna, zewnętrzna jest niebezpieczna. Firewall na granicy, zaufanie wewnątrz. To działało gdy „wewnątrz” był fizyczny budynek z komputerami połączonymi kablami.

Chmura, BYOD, praca zdalna i teraz agenty AI rozbiły to założenie. „Wewnątrz” nie istnieje w sensie geograficznym. Agent działający w AWS us-east-1 nie jest „wewnątrz” bardziej niż attaker z zewnątrz.

Zero trust odpowiada na to: nigdy nie ufaj, zawsze weryfikuj. Niezależnie od skąd przychodzi żądanie.

Czym jest zero trust dla agentów

Zero trust dla agentów to architektura bezpieczeństwa dla systemów agentowych opierająca się na zasadzie „never trust, always verify” — gdzie każdy agent musi udowodnić tożsamość i autoryzację dla każdego żądania do zasobów, niezależnie od lokalizacji sieciowej, bez założenia zaufania bazującego na przynależności do sieci wewnętrznej lub poprzednich interakcjach.

Pięć zasad zero trust dla agentów

Verify explicitly: każde żądanie agenta do zasobu jest weryfikowane — tożsamość agenta (Web Bot Auth, kryptograficzne podpisywanie), tożsamość użytkownika w imieniu którego działa (JWT, OAuth), autoryzacja do konkretnego zasobu (RBAC, policy engine).

Least privilege access: agent ma dostęp tylko do minimum zasobów niezbędnych dla konkretnego zadania. Dostęp jest przyznawany na czas trwania zadania, nie permanentnie. Intent Mandate jako mechanizm ograniczonego, czasowego dostępu.

Assume breach: projektuj system zakładając że agent zostanie skompromitowany. Co się stanie gdy skompromitowany agent wykona maksimum możliwych szkód w ramach swoich uprawnień? Czy jest to akceptowalne? Jeśli nie — uprawnienia są za szerokie.

Microsegmentation: różne agenty mają dostęp do różnych segmentów zasobów. Agenty obsługi klienta nie mają dostępu do danych finansowych. Kompromitacja jednego agenta nie daje dostępu do wszystkiego.

Continuous monitoring: zaufanie nie jest statyczne. Anomalie w zachowaniu agenta — nowe wzorce działań, nieoczekiwane zasoby — automatycznie triggerują re-weryfikację lub blokadę.

Narzędzia implementacji

Azure AD Conditional Access dla agentów, AWS IAM z STS (krótkotrwałe tokeny), HashiCorp Vault z dynamic secrets (credentials ważne przez minuty nie stale), Cloudflare Zero Trust dla egress control — razem tworzą stos zero trust dla agentów.

Zero trust a agent sprawl

Zero trust jest naturalnym antidotum na agent sprawl — każdy agent musi być zarejestrowany, zweryfikowany i mieć explicite przyznane uprawnienia. „Dziki” agent bez rejestracji nie uzyska dostępu do żadnych zasobów. Zero trust enforcement sprawia że CoE AI governance jest egzekwowalne technicznie, nie tylko na papierze.

Hierarchia pryncypałówHierarchia podmiotów autoryzowanych do wydawania poleceń agentowi AI — producent modelu (najwyższy autorytet), operator (kontekst wdrożenia), użytkownik (polecenia w ramach kontekstu) — definiująca jak agent rozstrzyga konflikty między poleceniami z różnych poziomów.Kontrola dostępu oparta na rolach dla agentówRozszerzenie RBAC o agentów AI jako osobny typ principal — definiujące jakie zasoby i akcje są dostępne dla agenta, niezależnie od uprawnień użytkownika w imieniu którego działa. RBAC na poziomie infrastruktury (nie promptu) jest odporny na permission injection.Mandat intencjiKryptograficznie podpisana deklaracja zgody użytkownika na działania agenta w jego imieniu — element AP2 — zawierająca zakres uprawnień, limity kwot i okres ważności. Cyfrowy odpowiednik pełnomocnictwa: weryfikowalny przez systemy płatnicze bez kontaktu z użytkownikiem przy każdej transakcji.Niekontrolowany rozrost agentówNiekontrolowana proliferacja agentów AI w organizacji — tworzonych bez centralnego nadzoru, dokumentacji ani review bezpieczeństwa — prowadząca do sytuacji w której organizacja nie wie ile agentów działa, do jakich zasobów mają dostęp i jakie ryzyko reprezentują. Enterprise-owa wersja shadow IT.Wyciek poświadczeńNieautoryzowane ujawnienie poświadczeń uwierzytelniających — kluczy API, tokenów, haseł — przez agenta AI: przez złośliwy atak nakłaniający agenta do ich ujawnienia, błąd konfiguracji który przechowuje credentials niezabezpieczenie, lub włączenie ich do odpowiedzi przez nieuwagę. Moltbook case study: 1,5 miliona API keys w plaintext w bazie danych.Izolacja agentaZestaw mechanizmów izolacji środowiska wykonawczego agenta AI — ograniczających dostęp do zasobów systemu, sieci, danych i innych agentów — tak że kompromitacja lub błędne działanie agenta ma ograniczony zasięg i nie może się rozprzestrzeniać. Implementacja zasady defence in depth: nie eliminacja ryzyka, ale zawężenie jego konsekwencji.