Agentic AI zmusza Zero Trust do zmierzenia się z kryzysem tożsamości

Agentic AI trafiła do Google News z mocnym twierdzeniem: systemy autonomiczne wywracają cyberbezpieczeństwo Zero Trust „do góry nogami”. Nagłówek Breaking Defense wskazuje na rzeczywisty konflikt, choć szczegóły leżące u jego podstaw nadal trudno niezależnie zweryfikować. Zespoły bezpieczeństwa budowały kontrolę dostępu wokół ludzi, urządzeń i przewidywalnych aplikacji. Agenci AI zacierają dziś granice między wszystkimi trzema kategoriami, działając jednocześnie z delegowanymi uprawnieniami.

Nie oznacza to, że Zero Trust stało się przestarzałe. Zmienia natomiast to, co organizacje muszą weryfikować, jak często powinny to robić oraz która tożsamość wykonała dane działanie. Agent może interpretować cel, wybierać narzędzia, czytać zewnętrzne treści, wywoływać API i modyfikować dane. Jego zachowania nie da się w pełni opisać uprawnieniami przypisanymi jego ludzkiemu właścicielowi.

Rezultatem jest niewygodne odwrócenie perspektywy. Zero Trust zakłada, że każde żądanie powinno zostać poddane ocenie, tymczasem przepływy pracy agentic generują długie łańcuchy żądań z prędkością maszynową. Główny spór nie dotyczy zatem agentic AI kontra Zero Trust. Chodzi o statyczną kontrolę dostępu kontra ciągłą kontrolę nad autonomicznym zachowaniem.

Twierdzenie z Google News wskazuje na rzeczywistą zmianę w bezpieczeństwie

Istotna zmiana nie polega na tym, że AI może uzyskiwać dostęp do systemów przedsiębiorstwa, lecz na tym, że po uzyskaniu dostępu może decydować, co zrobić dalej.

Tradycyjne oprogramowanie podąża ścieżkami zdefiniowanymi wcześniej przez programistów. Może zawierać błędy, przyjmować złośliwe dane wejściowe lub udostępniać podatne interfejsy. Mimo to obrońcy zwykle mogą powiązać jego zamierzone funkcje z ustalonymi kontami, procesami i połączeniami sieciowymi.

Agentic AI wprowadza warstwę decyzyjną między instrukcją użytkownika a wynikającym z niej działaniem. Agent może podzielić szeroki cel na mniejsze zadania, wybierać spośród dostępnych narzędzi i dostosowywać się, gdy jedna ścieżka zawiedzie. NIST opisuje współczesnych agentów jako modele ogólnego przeznaczenia połączone z oprogramowaniem umożliwiającym im korzystanie z narzędzi wykraczających poza generowanie tekstu.

Narzędzia te mogą obejmować przeglądarki, bazy danych, kalendarze, interpretery kodu, pliki lokalne i interfejsy administracyjne. Taksonomia tool-use taxonomy NIST rozróżnia dostęp tylko do odczytu od ograniczonego lub nieograniczonego dostępu do zapisu. Oddziela również środowiska zaufane od niezaufanych.

To rozróżnienie ma znaczenie, ponieważ pojedynczy agent często przekracza kilka kategorii podczas jednego zadania. Może przeczytać e-mail, wyodrębnić numer klienta, odpytąć wewnętrzną bazę danych i zaktualizować zgłoszenie wsparcia. Każdy krok może wydawać się dozwolony, gdy jest oceniany osobno.

Połączony przepływ pracy nadal może jednak prowadzić do niebezpiecznego rezultatu. Atakujący może umieścić ukryte instrukcje w e-mailu. Agent może uznać te instrukcje za część swojego zadania, a następnie wykorzystać legalne uprawnienia do ujawnienia danych.

Atak ten nazywa się pośrednim wstrzyknięciem promptu, co oznacza, że złośliwe instrukcje docierają do agenta poprzez treści, które przetwarza. Atakujący nie potrzebuje hasła pracownika. Celuje w sposób, w jaki agent interpretuje zaufane i niezaufane informacje.

Nagłówek Google News oddaje tę zmianę sformułowaniem „do góry nogami”. Wcześniej zespoły bezpieczeństwa obawiały się, że ludzie będą niewłaściwie używać oprogramowania lub ujawniać dane uwierzytelniające. Teraz muszą także brać pod uwagę oprogramowanie, które interpretuje uprawnienia człowieka i działa w ich ramach niezależnie.

Nie jest to po prostu kolejny endpoint wchodzący do sieci. Endpoint zwykle ma względnie stabilną funkcję, stan bezpieczeństwa i model własności. Agent może zmieniać swój bieżący plan, zachowując tę samą tożsamość, dane uwierzytelniające i połączenie.

Tworzy to problem widoczności. Log może wskazywać, że ważne konto usługi uzyskało dostęp do bazy danych. Może jednak nie ujawniać, który użytkownik zainicjował zadanie, który agent ułożył plan ani jakie zewnętrzne dane wejściowe wpłynęły na decyzję.

Nagłówek należy nadal traktować jako tezę, a nie dowód konkretnego naruszenia. Do dostarczonej pozycji Google News nie dołączono zweryfikowanych szczegółów incydentu. Szersza kwestia bezpieczeństwa jest jednak potwierdzana przez publiczne badania i bieżące prace nad standardami.

Zespoły bezpieczeństwa nie chronią już wyłącznie dostępu człowiek-aplikacja i aplikacja-aplikacja. Muszą zabezpieczać łańcuch łączący człowieka, agenta, model, kilka narzędzi i wiele źródeł danych. Zaufanie może wyciekać przy każdym przekazaniu.

Zero Trust zostało stworzone dla żądań, a nie otwartych celów

Zero Trust pozostaje istotne, lecz jego konwencjonalna jednostka kontroli jest zbyt wąska dla autonomicznej pracy.

NIST opublikował swoją podstawową architekturę Zero Trust w 2020 roku. Model odrzuca domniemane zaufanie oparte na lokalizacji sieciowej lub własności zasobu. Uwierzytelnianie i autoryzacja odbywają się, zanim sesja dotrze do zasobu przedsiębiorstwa.

Architektura koncentruje się na zasobach, a nie na tradycyjnych segmentach sieci. Zakłada, że sieć może być już skompromitowana. Dostęp powinien więc pozostać ograniczony do najmniejszego zestawu uprawnień wymaganych dla konkretnej misji.

Takie podejście przeciwdziała staremu modelowi perymetru. W ramach bezpieczeństwa perymetru uwierzytelnieni użytkownicy często otrzymywali szeroki dostęp po wejściu do zaufanej sieci. Atakujący mogli następnie przemieszczać się bocznie między systemami po przejęciu jednego konta lub urządzenia.

Agentic AI nie unieważnia tych zasad. W rzeczywistości zasada najmniejszych uprawnień i ciągła ocena stają się ważniejsze, gdy maszyny mogą szybko wykonywać wiele działań. Trudność polega na przełożeniu szerokiego celu użytkownika na egzekwowalne, krótkotrwałe uprawnienia.

Rozważmy agenta, któremu polecono przygotowanie kwartalnego raportu ryzyka klientów. Zadanie brzmi informacyjnie, ale jego wykonanie może wymagać kilku możliwości. Agent musi odnaleźć rekordy, łączyć dane, obliczać trendy i tworzyć dokument.

Czy agent powinien otrzymać dostęp do wszystkich rekordów klientów przez cały czas trwania zadania? Czy powinien zachować te uprawnienia po jego zakończeniu? Czy może wysłać raport e-mailem, czy też dystrybucja powinna wymagać osobnego zatwierdzenia?

Konwencjonalny system dostępu może odpowiedzieć na te pytania na podstawie istniejącej roli użytkownika. Jeśli pracownik może odczytywać bazę danych i wysyłać e-maile, agent dziedziczy oba te uprawnienia. Takie dziedziczenie jest proste, ale tworzy nadmierne uprawnienia.

Agent może wykonywać kombinacje działań, których pracownik nigdy nie zamierzał podjąć. Może też powtarzać je na skalę, jakiej ręczne przepływy pracy rzadko osiągają. Niewielki błąd interpretacyjny może skutkować setkami zapytań do bazy danych lub wiadomości.

Otwarte cele utrudniają projektowanie polityk. „Znajdź istotne dowody” nie określa, które repozytoria należy przeszukać. „Rozwiąż problem” nie definiuje, czy agent może wystawić zwrot, zmodyfikować konto lub wykonać kod.

Zero Trust tradycyjnie ocenia żądania dostępu na podstawie tożsamości, kondycji urządzenia, wrażliwości zasobu i kontekstu środowiskowego. Systemy agentic dodają kolejne pytanie: czy to działanie nadal pozostaje zgodne z zadaniem, które uzasadniało dostęp?

Pytanie to wymaga kontroli uwzględniających intencję. Kontrole te porównują działanie z przypisanym agentowi celem, bieżącym planem i zatwierdzoną polityką. Nie mogą zależeć wyłącznie od tego, czy konto technicznie posiada dane uprawnienie.

Granica bezpieczeństwa przesuwa się również podczas pracy wieloagentowej. Jeden agent może delegować badania innemu agentowi. Ten drugi może wywołać usługę zewnętrzną, która zwraca treści zawierające nowe instrukcje.

Każde przekazanie może zmienić kontekst, zachowując pozorną autoryzację. Statyczna polityka widzi zatwierdzone tożsamości przekazujące dane. Polityka behawioralna musi ustalić, czy cały łańcuch nadal służy pierwotnemu celowi.

Dlatego bezpieczeństwo agentic AI nie może kończyć się na segmentacji sieci. Warstwa kontrolna musi rozumieć tożsamości, zadania, narzędzia, pochodzenie danych i historię działań. Musi także zachowywać te powiązania na potrzeby późniejszego dochodzenia.

Pierwotna obietnica Zero Trust nadal obowiązuje: nigdy nie przyznawaj zaufania tylko dlatego, że coś już znajduje się wewnątrz. Przepływy pracy agentic jedynie ujawniają, że „wewnątrz” może opisywać okno kontekstu, delegowane zadanie lub łańcuch narzędzi. Nie odnosi się już wyłącznie do sieci.

Agenci AI potrzebują tożsamości odrębnych od swoich właścicieli

Organizacja nie może zarządzać autonomicznym agentem, jeśli każde działanie widnieje pod kontem człowieka lub współdzielonym kontem usługi.

Tożsamość jest pierwszym punktem nacisku dla zespołów bezpieczeństwa przedsiębiorstw. Ludzie mają dokumentację zatrudnienia, przełożonych, role zawodowe i procedury odejścia. Aplikacje mają właścicieli, procesy wydawnicze i konta usług.

Agenci łączą cechy obu tych grup. Mogą otrzymywać cele od ludzi, ale wykonują je za pośrednictwem oprogramowania. Mogą działać krótko przy jednym zadaniu albo nadal funkcjonować jako trwałe cyfrowe narzędzia pracy.

Traktowanie agenta jako ukrytej funkcji w aplikacji zaciera rozliczalność. Traktowanie go jak zwykłego pracownika również tworzy fałszywe poczucie pewności. Agent potrzebuje pełnoprawnej tożsamości maszynowej powiązanej z właścicielem, przeznaczeniem i wdrożeniem.

Ta tożsamość nie powinna zastępować tożsamości użytkownika inicjującego działanie. Obie powinny być zachowane w całym przepływie pracy. Osoby prowadzące dochodzenie muszą wiedzieć, kto zażądał działania i który agent je wykonał.

Przydatny zapis audytowy powinien również obejmować model, narzędzie, politykę i źródło danych. Bez tego kontekstu log bazy danych pokazuje jedynie końcowy dostęp. Nie potrafi wyjaśnić, dlaczego agent uznał ten dostęp za właściwy.

Zespoły bezpieczeństwa powinny unikać współdzielonych danych uwierzytelniających przy wdrażaniu agentów. Współdzielone konta uniemożliwiają wiarygodne przypisanie działań i komplikują cofanie dostępu. Pozwalają także porzuconym agentom pozostać aktywnymi po zakończeniu pierwotnych projektów.

Tożsamość agenta potrzebuje cyklu życia. Utworzenie powinno wskazywać odpowiedzialnego właściciela i zatwierdzone zastosowanie. Okresowy przegląd powinien potwierdzać, że agent nadal jest potrzebny, a jego uprawnienia wciąż odpowiadają jego celowi.

Równie ważne jest wygasanie. Tymczasowi agenci powinni tracić dostęp po zakończeniu zadania lub projektu. Trwali agenci powinni podlegać regularnej recertyfikacji, podobnie jak uprzywilejowane konta ludzkie.

Uprawnienia powinny być również specyficzne dla zadania i krótkotrwałe. Agent przygotowujący raport może otrzymać tymczasowy dostęp do odczytu wybranych rekordów. Wysłanie tego raportu poza organizację powinno wymagać osobnego uprawnienia lub potwierdzenia przez człowieka.

Taki projekt ogranicza narastanie uprawnień, które występuje, gdy tożsamości gromadzą dostęp nieodpowiadający już ich obowiązkom. Narastanie uprawnień jest już trudne w przypadku pracowników. Autonomiczni agenci mogą zwielokrotnić ten problem, ponieważ zespoły mogą szybko ich tworzyć.

Wykrywanie agentów staje się zatem wymogiem operacyjnym. Zespoły bezpieczeństwa potrzebują inwentaryzacji obejmującej usługi SaaS, platformy programistyczne, wewnętrzne systemy automatyzacji i integracje zewnętrzne. Same rejestry zakupów nie zidentyfikują agentów utworzonych w istniejących produktach.

Wykrywanie musi odróżniać funkcję AI od tożsamości wykonującej działania. Funkcja podsumowująca, która tylko odczytuje jeden dokument, wiąże się z innym ryzykiem niż agent mogący przeszukiwać dyski i wysyłać wiadomości. Oba mogą korzystać z tego samego modelu.

Właściciel powinien być także widoczny w politykach i logach. Gdy agent działa poza oczekiwaniami, osoby reagujące potrzebują osoby lub zespołu zdolnego do jego zawieszenia. Anonimowa automatyzacja powoduje opóźnienia podczas incydentów.

Organizacje już korzystają z tożsamości niebędących tożsamościami ludzkimi dla usług, obciążeń i maszyn. Tożsamości agentów rozszerzają tę dyscyplinę, zamiast ją zastępować. Różnica polega na tym, że polityka musi uwzględniać zmienne zachowanie w ramach tej samej przypisanej roli.

Najwięksi dostawcy rozwiązań bezpieczeństwa zmierzają w tym kierunku. Cisco ogłosiło wykrywanie agentów, mechanizmy kontroli tożsamości agentowych oraz egzekwowanie Model Context Protocol w ramach swojej aktualizacji bezpieczeństwa agentów. Model Context Protocol, czyli MCP, łączy modele z narzędziami i danymi zewnętrznymi.

Komunikaty dostawców nie są niezależnym dowodem na to, że mechanizmy kontroli działają w każdym wdrożeniu. Pokazują jednak, w jakim kierunku zmierza konkurencja. Platformy tożsamości, brokerzy dostępu i bramy bezpieczeństwa chcą stać się punktem kontroli ruchu agentów.

Kupujący w przedsiębiorstwach powinni oprzeć się traktowaniu jednej bramy jako kompletnego rozwiązania. NIST od dawna wskazuje, że żaden pojedynczy dostawca nie zapewnia całej architektury Zero Trust. Bezpieczeństwo agentowe dodaje kolejne komponenty i więcej możliwości niespójnego egzekwowania zasad.

Natychmiastowa presja spada na zespoły zarządzania tożsamością i dostępem. Muszą one wspierać szybko tworzone podmioty maszynowe, nie powtarzając problemu niezarządzanych kont usługowych. Statyczne przypisania ról nie wystarczą.

Przejęcie agentów ujawnia ograniczenia statycznych kontroli uprawnień

Prawidłowo uwierzytelniony agent nadal może wykonać niewłaściwe działanie, ponieważ uwierzytelnienie nie weryfikuje jego rozumowania.

Najmocniejszy argument za przebudową Zero Trust wynika z badań nad przejmowaniem agentów. W marcu 2026 r. NIST opublikował wyniki dużych publicznych zawodów red-teamingowych obejmujących 13 modeli czołowej klasy. Ponad 400 uczestników podjęło ponad 250 000 prób ataku.

Co najmniej jeden skuteczny atak przejęcia wykryto wobec każdego testowanego modelu. Modele różniły się odpornością, lecz możliwości nie przewidywały konsekwentnie poziomu bezpieczeństwa. Niektóre rodziny ataków przenosiły się również między różnymi modelami i scenariuszami.

Wyniki te nie oznaczają, że każdy wdrożony agent można łatwo skompromitować. Konkurs zachęca skoncentrowanych atakujących i może nie odtwarzać wszystkich mechanizmów kontrolnych środowiska produkcyjnego. Pokazuje jednak, że odporność na poziomie modelu sama w sobie nie może stanowić granicy bezpieczeństwa.

NIST definiuje przejęcie agenta jako atak polegający na umieszczeniu złośliwych instrukcji w danych przetwarzanych przez agenta. Celem jest skierowanie agenta ku szkodliwemu zachowaniu. Potencjalne skutki obejmują eksfiltrację danych lub wykonanie złośliwego kodu.

Kluczowy szczegół polega na tym, że agent często korzysta z prawidłowych narzędzi i poświadczeń. Zapora sieciowa może widzieć zatwierdzone połączenie. System tożsamości może widzieć uwierzytelnione konto. Niebezpieczny krok zachodzi w interpretacji treści przez agenta.

To sprawia, że statyczne listy dozwolonych działań są niepełne. Zezwolenie agentowi na odczyt poczty e-mail i aktualizację bazy danych może być konieczne do wykonywania jego pracy. Polityka nadal musi uniemożliwiać e-mailowi redefiniowanie tego, co narzędzie bazodanowe powinno zrobić.

Odpowiednie ustalenia zespołów red-team wspierają obronę warstwową. Modele wymagają oceny, ale wdrożenia potrzebują również ograniczonych narzędzi, granic danych, monitorowania i punktów zatwierdzania.

Uprawnienia narzędzi powinny odzwierciedlać konsekwencje, a nie wygodę. Odczyt publicznej strony internetowej wiąże się z innym ryzykiem niż uruchamianie pobranego kodu. Zapytanie o rekord klienta różni się od jego usunięcia lub wyeksportowania.

Narzędzia o dużym wpływie powinny udostępniać wąskie operacje. Agent, który musi zaplanować spotkanie, nie powinien otrzymywać nieograniczonej kontroli nad skrzynką pocztową. Agent finansowy, który przygotowuje płatność, nie powinien jednocześnie jej zatwierdzać i wysyłać.

Zasada ta nazywa się rozdzieleniem obowiązków. Zapobiega ona temu, by jedna tożsamość kontrolowała każdy etap wrażliwego procesu. Systemy agentowe potrzebują tego samego podziału, nawet jeśli automatyzacja czyni konsolidację kuszącą.

Zatwierdzenie przez człowieka pozostaje użyteczne na nieodwracalnych granicach. Transfery, usunięcia, publikacje zewnętrzne, wdrożenia produkcyjne i zmiany poświadczeń zasługują na wyraźne kontrole. Zatwierdzenie powinno pokazywać zamierzone działanie i istotny kontekst.

Ogólny przycisk „zezwól” zapewnia niewielką ochronę. Osoba zatwierdzająca musi wiedzieć, który agent zażądał działania, z jakich danych skorzystał i jaki skutek przyniesie zatwierdzenie. W przeciwnym razie automatyzacja jedynie przenosi socjotechnikę na ekran zatwierdzania.

Monitorowanie powinno koncentrować się na zmianach zachowania. Agent, który nagle uzyskuje dostęp do nieznanych repozytoriów, może wskazywać na przejęcie lub błędne planowanie. Powtarzające się nieudane wywołania narzędzi mogą sygnalizować, że agent próbuje wyjść poza swoją rolę.

Limity szybkości również ograniczają szkody wynikające z błędów. Wykonywanie działań z szybkością maszyny może przekształcić jedną złą decyzję w rozległy incydent. Ograniczenie wolumenu działań daje systemom monitorującym i zespołom reagowania czas na interwencję.

Sandboxing nadal ma wartość, ale nie powinien tworzyć założenia bezpieczeństwa. Agent może wyrządzić szkody bez opuszczania swojego środowiska uruchomieniowego. Wysłanie autoryzowanych danych do niewłaściwego miejsca docelowego może nie wymagać żadnego exploita.

Kluczową niewiadomą jest to, czy systemy rozumiejące intencje mogą podejmować wiarygodne decyzje bez blokowania użytecznej pracy. Plany agentów się zmieniają, zadania biznesowe zawierają niejednoznaczności, a polityki nie są w stanie przewidzieć każdego uzasadnionego wyjątku.

Zbyt restrykcyjne kontrole będą generować ciągłe prośby o zatwierdzenie. Zespoły mogą wtedy przyznawać szersze uprawnienia, aby przywrócić produktywność. Taka reakcja odtwarza dokładnie to domyślne zaufanie, które Zero Trust miało usunąć.

Zbyt pobłażliwe kontrole prowadzą do przeciwnej porażki. Agenci działają płynnie, dopóki złośliwe dane wejściowe lub błąd planowania nie wykorzystają ich uprawnień. Zespoły bezpieczeństwa muszą mierzyć zarówno zablokowaną pracę, jak i niebezpieczne działania.

Ten kompromis uniemożliwia łatwe twierdzenia, że produkt „agentowego Zero Trust” rozwiązał problem. Prezentacje produktów zwykle pokazują wybrane przepływy pracy. Rzeczywiste wdrożenia zawierają systemy legacy, współdzielone tożsamości i niespójne logi.

Najbardziej wiarygodne podejście w krótkim okresie jest warstwowe. Nadaj każdemu agentowi tożsamość, ogranicz każde narzędzie, zachowaj informację o użytkowniku inicjującym, weryfikuj działania o istotnych konsekwencjach i monitoruj zachowanie. Zakładaj, że zabezpieczenia modelu czasem zawiodą.

Rywalizacja przenosi się do płaszczyzny kontroli

Dostawcy bezpieczeństwa rywalizują o pośredniczenie w zachowaniu agentów, podczas gdy przedsiębiorstwom nadal brakuje wspólnego modelu potwierdzającego skuteczność takiego pośrednictwa.

Agentowa AI tworzy możliwości dla dostawców tożsamości, dostawców bezpieczeństwa sieciowego, platform chmurowych i wyspecjalizowanych firm zajmujących się bezpieczeństwem AI. Każda grupa kontroluje inną część przepływu pracy. Żadna nie widzi automatycznie całego łańcucha.

Dostawcy tożsamości wiedzą, kto otrzymał dostęp. Platformy sieciowe obserwują połączenia między systemami. Dostawcy chmury mogą monitorować obciążenia robocze i wywołania API. Narzędzia bezpieczeństwa AI analizują prompty, wyniki modeli i żądania narzędzi.

Cenną pozycją jest punkt podejmowania decyzji polityki. W architekturze Zero Trust komponent ten ocenia dostęp i decyduje, czy egzekwowanie zasad powinno go dopuścić. Systemy agentowe czynią tę decyzję bogatszą i bardziej sporną.

Dostawca rozwiązań sieciowych może twierdzić, że komunikacja agentów powinna przechodzić przez brokera bezpieczeństwa. Dostawca tożsamości może skoncentrować politykę na tożsamościach maszynowych i delegowanej autoryzacji. Dostawca bezpieczeństwa AI może priorytetowo traktować inspekcję promptów i ocenę zachowania.

Wszystkie trzy perspektywy zawierają część odpowiedzi. Kontekst sieciowy nie może ujawnić każdej złośliwej instrukcji. Inspekcja promptów sama nie może wyegzekwować zablokowanego zapytania do bazy danych. Weryfikacja tożsamości nie może zagwarantować, że uwierzytelniony agent realizuje swój cel.

MCP stał się jednym z punktów zainteresowania, ponieważ standaryzuje połączenia między modelami a narzędziami. Brama może inwentaryzować serwery, ograniczać operacje i rejestrować wywołania. Nie każdy agent korzysta jednak z MCP, a brama nie może zarządzać narzędziami, które ją omijają.

Komunikacja agent-agent stwarza kolejne wyzwanie. Delegowanie może przekraczać granice modeli, dostawców lub organizacji. Agent odbierający potrzebuje dowodów dotyczących tożsamości nadawcy, jego uprawnień i żądanego zakresu.

Podpisana wiadomość może uwierzytelnić nadawcę. Nie dowodzi jednak, że plan nadawcy jest bezpieczny. Polityka musi oddzielać pochodzenie, które określa, skąd pochodzi żądanie, od autoryzacji, która ustala, czy powinno ono zostać wykonane.

Prace nad standaryzacją zaczynają rozwiązywać te luki. NIST uruchomił swoją inicjatywę standardów dla agentów w lutym 2026 r. Jej agenda obejmuje interoperacyjność, otwarte protokoły, bezpieczeństwo, tożsamość i zaufane wdrażanie.

Inicjatywa ta ma znaczenie, ponieważ organizacje potrzebują porównywalnych reprezentacji tożsamości i uprawnień agentów. Bez wspólnych formatów każda platforma tworzy własne tożsamości i sygnały polityki. Zespoły bezpieczeństwa mają wtedy trudności z egzekwowaniem kontroli w różnych środowiskach.

Same standardy nie mogą rozstrzygnąć tolerancji ryzyka. Szpital, bank, wykonawca obronny i agencja marketingowa przypiszą różne konsekwencje temu samemu działaniu narzędzia. Interoperacyjność zapewnia wspólną infrastrukturę, a nie uniwersalną politykę.

Ujęcie Breaking Defense jest szczególnie istotne dla środowisk o wysokich wymaganiach zapewnienia. Systemy obronne często łączą dane tajne, ograniczenia misji, sprzęt legacy i ścisłą rozliczalność. Autonomiczne działanie może mieć konsekwencje wykraczające poza zwykłą automatyzację biurową.

Środowiska te tworzą także presję na automatyzację. Analitycy mierzą się z dużą liczbą alertów, dokumentów i danych z czujników. Agenci mogą pomagać w korelowaniu informacji i wykonywaniu powtarzalnych kroków, lecz szersza autonomia zwiększa potrzebę kontroli możliwej do prześledzenia.

Konkurencję należy zatem oceniać na podstawie dowodów, a nie słownictwa produktowego. Kupujący muszą testować, czy mechanizm kontroli niezawodnie identyfikuje agentów, wiąże działania z właścicielami, ogranicza narzędzia i tworzy użyteczne rejestry audytowe.

Powinni także testować przypadki awarii. Co dzieje się, gdy dostawca tożsamości jest niedostępny? Czy agent może przejść na zapisane w pamięci podręcznej uprawnienia? Czy broker odmawia dostępu w razie awarii, czy ruch omija inspekcję?

Pokrycie międzyplatformowe jest równie ważne jak pojedyncze funkcje. Organizacja może korzystać z modelu jednej chmury, agenta programistycznego innego dostawcy i kilku asystentów SaaS. Mechanizm kontroli, który widzi tylko jedno środowisko, pozostawia istotne martwe pola.

Rynek prawdopodobnie skonsoliduje się wokół zintegrowanych platform, ale integracja może tworzyć własne ryzyko koncentracji. Jedna skompromitowana płaszczyzna polityki może wpłynąć na wielu agentów. Niezależne rejestrowanie i egzekwowanie zasad pozostają ważnymi zabezpieczeniami.

Google News może wzmacniać nagłówki o agentowej AI zastępującej znane modele bezpieczeństwa. Dokładniejszy wniosek jest węższy. Obecni dostawcy muszą rozszerzyć Zero Trust z decyzji dotyczących połączeń na zarządzanie tożsamością, intencją i działaniami.

Na co zespoły bezpieczeństwa powinny zwracać uwagę dalej

O kolejnej fazie zdecydują mierzalne dowody z wdrożeń, a nie szersze twierdzenia o autonomicznym bezpieczeństwie.

Pierwszym sygnałem będzie to, czy grupy standaryzacyjne stworzą użyteczne specyfikacje tożsamości agentów i delegowanej autoryzacji. NIST poinformował, że jego inicjatywa będzie rozwijać badania, wytyczne i inne rezultaty. Przedsiębiorstwa powinny obserwować formaty, które działają u różnych dostawców.

Użyteczna specyfikacja tożsamości musi łączyć agenta z właścicielem, celem, modelem i zatwierdzonymi narzędziami. Powinna również zachowywać informację o użytkowniku inicjującym podczas delegowania. Jeżeli platformy przyjmą niekompatybilne reprezentacje, zarządzanie pozostanie rozproszone.

Drugim sygnałem są niezależne testy bezpieczeństwa. Konkurs NIST wykrył skuteczne ataki przeciwko każdemu testowanemu modelowi czołowej klasy, ale organizacje potrzebują ocen na poziomie wdrożenia. Testy powinny obejmować modele, narzędzia, uprawnienia, pamięć i dane zewnętrzne.

Testy porównawcze powinny mierzyć więcej niż powodzenie prompt injection. Powinny badać, czy agenci przekraczają zakres zadania, niewłaściwie używają prawidłowych narzędzi lub ukrywają działania o istotnych konsekwencjach w długich przepływach pracy. Powinny także testować odzyskiwanie sprawności i jakość audytu.

Jeśli skuteczność ataków spadnie, podczas gdy agenci zachowają użyteczne możliwości, wzrośnie zaufanie do mechanizmów kontroli uwzględniających intencje. Jeśli ulepszone modele nadal będą podatne na ataki we wdrożeniach bogatych w narzędzia, kontrola infrastruktury stanie się jeszcze ważniejsza.

Trzecim sygnałem będzie zachowanie przedsiębiorstw po zakończeniu pilotaży. Zespoły ds. bezpieczeństwa powinny śledzić, ilu agentom przypisano unikalne tożsamości, ograniczone poświadczenia i jasno określonych właścicieli. Powinny także mierzyć liczbę porzuconych agentów i niezweryfikowanych uprawnień.

Same liczby wdrożeń mówią niewiele. Firma może uruchomić tysiące agentów, utrzymując ich w trybie tylko do odczytu i w izolacji. Pojedynczy agent z szerokim dostępem do środowiska produkcyjnego może stanowić większe ryzyko niż cała ta populacja.

Kolejną weryfikację rzeczywistości zapewnią raporty o incydentach. Opisując publiczne przypadki, należy wyjaśniać, czy awarie wynikały z prompt injection, nadmiernych uprawnień, niejasności tożsamości czy braku granic zatwierdzania. Bez tych szczegółów branża nie może porównywać zabezpieczeń.

Przed rozszerzeniem pilotażu liderzy bezpieczeństwa powinni zadać bezpośrednie pytania:

• Czy każdy agent ma unikalną tożsamość i przypisanego właściciela odpowiedzialnego za jego działanie?

• Czy uprawnienia mogą wygasać automatycznie po zakończeniu zadania?

• Czy logi zachowują informacje zarówno o osobie składającej żądanie, jak i o działającym agencie?

• Które narzędzia mogą wprowadzać nieodwracalne zmiany?

• Czy treści zewnętrzne mogą wpływać na wywołania tych narzędzi?

• Jaki wolumen działań uruchamia przegląd lub zawieszenie?

• Czy osoby reagujące na incydenty mogą wyłączyć jednego agenta bez zatrzymywania całej platformy?

• Czy delegowani agenci są ograniczeni pierwotnym zadaniem?

• Czy system bezpiecznie odmawia działania, gdy usługi polityk są niedostępne?

• Czy audytorzy mogą odtworzyć, dlaczego doszło do wrażliwego działania?

Te pytania przekształcają tezę „stawiającą wszystko na głowie” w test wdrożeniowy. Jeśli platforma nie potrafi na nie odpowiedzieć, jej język Zero Trust pozostaje niepełny. Jeśli potrafi, architektura może już się dostosowywać.

Najważniejszy wniosek jest taki, że organizacje nie powinny porzucać Zero Trust. Powinny stosować je wobec mniejszych, bardziej dynamicznych jednostek uprawnień. Każdy agent, wywołanie narzędzia, delegacja i istotne działanie zasługują na własny kontekst polityki.

Takie podejście wprowadzi tarcie. Niektóre zautomatyzowane zadania będą wymagały węższego zakresu narzędzi lub potwierdzenia przez człowieka. Część pilotaży zwolni, gdy zespoły będą budować inwentaryzacje i mechanizmy kontroli cyklu życia.

Alternatywą jest ukryta władza. Agenci odziedziczą szerokie ludzkie uprawnienia, będą przetwarzać niezaufane treści i pozostawiać niepełne zapisy. Zespoły ds. bezpieczeństwa odkryją wtedy autonomiczne procesy dopiero po incydencie.

Agentowa AI nie pokonała Zero Trust. Ujawniła miejsca, w których wiele programów Zero Trust zatrzymało się na uwierzytelnianiu, dostępie sieciowym lub kondycji urządzeń. Kolejna wersja musi regulować to, co uwierzytelnione maszyny decydują się zrobić.

Pytanie postawione za pośrednictwem Google News warto więc zachować, nawet jeśli nagłówek przesadza ze skalą odwrócenia. Czy Twoja organizacja potrafi prześledzić tożsamość, cel, dowody i uprawnienia agenta, zanim zostanie wykonane jego kolejne działanie?

Zacznij od jednego procesu produkcyjnego i odtwórz ten łańcuch od początku do końca. Jeśli którykolwiek etap przekazania staje się niewidoczny, potraktuj go jako lukę w kontroli. To ćwiczenie daje więcej wartości niż przyjęcie kolejnej etykiety bezpieczeństwa, ponieważ sprawdza, czy Zero Trust towarzyszy agentowi podczas rzeczywistej pracy.