Uwierzytelnieni agenci AI wciąż mogą odbiegać od celu, ujawniać dane lub zachowywać zatrutą pamięć

Google News zwrócił uwagę na analizę VentureBeat z wyraźnym ostrzeżeniem: agent AI może pomyślnie przejść uwierzytelnienie, a mimo to podjąć niewłaściwe działanie. Poświadczenie może być ważne. Wywołanie API również może być dozwolone. Jednak działanie może naruszać zadanie, ujawniać wrażliwe dane lub utrwalać w pamięci instrukcje atakującego.

To rozróżnienie podważa znane założenie dotyczące bezpieczeństwa. Zarządzanie tożsamością i dostępem weryfikuje, kto lub co zażądało dostępu. Nie określa jednak automatycznie, czy autonomiczny system nadal realizuje przypisany mu cel.

Raport z 30 sierpnia przekonuje, że przedsiębiorstwa wdrażają bramki egzekwujące zasady, zanim ustalą kontekst, którego te bramki wymagają. Porównanie nie dotyczy jednego dostawcy zabezpieczeń z drugim. Chodzi o prawidłowe uwierzytelnienie i prawidłowe zachowanie — dwa warunki, które przestały oznaczać to samo.

Co faktycznie zmienił raport Google News

Raport przedstawia bezpieczeństwo agentów AI jako problem kolejności działań, a nie wyłącznie problem uwierzytelniania.

Współpracownik VentureBeat, Nik Kale, opisuje powtarzający się schemat we wdrożeniach korporacyjnych. Zespoły często zaczynają od bramki czasu działania, która analizuje ruch agentów i stosuje zasady dostępu.

Jednak taka bramka często nie ma informacji o agencie z wcześniejszych etapów. Może nie wiedzieć, kto jest właścicielem agenta, jakie zadanie mu przypisano, które narzędzia zatwierdzono, jaki zakres uprawnień delegowano ani jaki jest pełny łańcuch działań.

Powstały w ten sposób martwy punkt łatwo przeoczyć. Wyobraźmy sobie agenta uzgadniającego finanse, który próbuje zmodyfikować rekord produkcyjny. Bramka może uwierzytelnić token pracownika i potwierdzić, że token zezwala na operację API.

Obie kontrole mogą zakończyć się pomyślnie, mimo że agent przekracza zakres swojego zadania. Pracownik może mieć szeroki dostęp produkcyjny, podczas gdy agentowi delegowano jedynie wąskie zadanie uzgadniania danych.

Sekwencja bezpieczeństwa Kale’a umieszcza egzekwowanie zasad w czasie działania na piątym miejscu w sześcioczęściowym łańcuchu zależności. Najpierw muszą pojawić się inwentaryzacja, odrębna tożsamość, poświadczenia o ograniczonym zakresie oraz telemetria umożliwiająca przypisanie działań.

Po egzekwowaniu zasad następują monitorowanie zachowania i ścieżka izolacji obejmująca wiele systemów. Ta kolejność ma znaczenie, ponieważ każda późniejsza kontrola zależy od kontekstu stworzonego przez wcześniejsze.

Artykuł nie twierdzi, że bramki są bezużyteczne. Argumentuje, że stają się użyteczne dopiero wtedy, gdy organizacja potrafi odpowiedzieć na kilka podstawowych pytań.

Który agent zainicjował żądanie? Kto delegował zadanie? Z jakich uprawnień korzysta agent? Jaki rezultat ma przynieść zadanie?

Konwencjonalna bramka często widzi token, miejsce docelowe i metodę żądania. Warstwa kontroli świadoma działania agentów musi również rozumieć cel, pochodzenie oraz konsekwencje w dalszych systemach.

To kluczowe odwrócenie perspektywy w tym wydarzeniu. Uwierzytelnienie pozostaje konieczne, lecz jego pomyślne zakończenie nie stanowi już wystarczającego dowodu zaufania.

Ważny jest również moment. Agenci AI wychodzą poza generowanie tekstu i trafiają do przepływów pracy, które wywołują API, manipulują plikami, zmieniają bazy danych i koordynują działania z innymi systemami.

Takie działania wywołują trwałe skutki. Błędną odpowiedź można poprawić. Zrealizowana płatność, wyeksportowany zbiór danych, cofnięte poświadczenie lub zmodyfikowane środowisko produkcyjne wymagają izolacji i odzyskania sprawności.

Ten materiał Google News wskazuje zatem na szerszą zmianę operacyjną. Zespoły bezpieczeństwa muszą oceniać pełną ścieżkę — od delegowanego zamiaru po zewnętrzny skutek.

Nie mogą zatrzymać się na granicy logowania. Istotne pytanie zaczyna się teraz po dopuszczeniu agenta.

Uwierzytelnienie potwierdza tożsamość, nie intencję

Ważne poświadczenie identyfikuje uprawniony podmiot, ale nie dowodzi, że każde działanie agenta służy bieżącemu zadaniu tego podmiotu.

Tradycyjne systemy tożsamości budowano wokół względnie stabilnych uczestników. Osoba loguje się, otrzymuje uprawnienia i wykonuje działania widoczne w śladzie audytowym.

Agenci AI komplikują każdą część tego modelu. Jeden pracownik może uruchomić kilku agentów, a każdy agent może wywoływać wiele narzędzi i tworzyć dodatkowe zadania.

Jeśli wszystkie te procesy używają jednego tokenu pracownika, dzienniki łączą kilka odrębnych podmiotów w jedną tożsamość. Osoby prowadzące dochodzenie widzą poświadczenie, ale nie rzeczywistego decydenta.

Współdzielone konta usługowe tworzą podobny problem. Ukrywają właściciela i utrudniają precyzyjne cofnięcie dostępu, gdy niebezpieczny staje się tylko jeden agent.

Odrębne tożsamości agentów poprawiają możliwość przypisania działań, lecz sama tożsamość nadal nie wystarcza. System musi zachować kontekst delegowania, czyli informację o człowieku lub usłudze, które przydzieliły zadanie, oraz o jego dozwolonym celu.

Rozważmy pracownika mającego dostęp do listy płac, zakupów, danych klientów i raportowania finansowego. Agent poproszony o uzgodnienie faktur nie powinien dziedziczyć całego zakresu dostępu tego pracownika.

Bezpieczny zakres uprawnień jest częścią wspólną trzech ograniczeń. Obejmuje uprawnienia delegującego, zatwierdzone możliwości agenta oraz zasoby wymagane do bieżącego zadania.

Kale nazywa tę zasadę monotonicznym delegowaniem. Każde przekazanie uprawnień powinno zachowywać lub ograniczać dostęp, nigdy go rozszerzać.

Jest to bardziej rygorystyczne niż przypisanie roli. Wymaga poświadczeń ograniczonych do konkretnego zadania, które wygasają i nie mogą sięgać do niepowiązanych systemów.

Poświadczenia krótkotrwałe zmniejszają również wartość skradzionych sekretów. Atakujący, który zdobędzie jeden token, nie powinien uzyskać bezterminowego dostępu do wszystkich zasobów dostępnych dla pracownika.

Telemetria musi następnie łączyć każde wywołanie narzędzia z jego źródłem. Użyteczny zapis identyfikuje agenta, delegującego, zadanie, działanie nadrzędne, poświadczenie, narzędzie i wynik.

Bez tego łańcucha osoby reagujące na incydent napotykają dwa szkodliwe opóźnienia. Najpierw muszą ustalić, który agent istnieje, a następnie określić, których systemów zależnych dotknął.

Uwierzytelniony agent może również odbiegać od celu bez udziału zewnętrznego atakującego. Dryf behawioralny występuje, gdy jego działania stopniowo oddalają się od przypisanego celu lub zatwierdzonego wzorca działania.

Wyzwalaczem mogą być niejednoznaczne instrukcje, zmieniający się kontekst, nieoczekiwana odpowiedź narzędzia albo nagromadzona sekwencja pojedynczych, dozwolonych decyzji.

Takie zachowanie różni się od tradycyjnie przejętego konta. Agent może używać zatwierdzonych poświadczeń i zatwierdzonych API dokładnie zgodnie z projektem.

Błąd leży w relacji między działaniem a pierwotnym zadaniem. Standardowe uwierzytelnienie nie ocenia tej relacji.

Ankieta Okta dotycząca przedsiębiorstw agentowych ilustruje lukę w zarządzaniu. Tylko 34% badanych organizacji stosowało te same mechanizmy bezpieczeństwa wobec cyfrowej i ludzkiej siły roboczej.

Ankieta wykazała również rozbieżność w poziomie pewności. Dziewięćdziesiąt pięć procent kadry kierowniczej było przekonanych, że ich organizacje potrafią wykryć AI działającą poza zamierzonym zakresem.

Wyniki te pochodzą z badań sponsorowanych przez dostawcę, dlatego nie należy traktować ich jako niezależnego pomiaru całego rynku. Mimo to kontrast wskazuje na weryfikowalne pytanie operacyjne.

Czy organizacja potrafi odtworzyć jedno zadanie agenta od rozpoczęcia aż po każdy skutek w systemach zależnych? Jeśli nie, jej pewność wyprzedza dowody.

Uwierzytelnienie odpowiada na pytanie, czy poświadczenie może uzyskać dostęp. Bezpieczeństwo agentów musi również odpowiedzieć, czy wynikające z tego działanie mieści się w delegowanym celu.

Zatruwanie pamięci agenta sprawia, że jedno złe wejście staje się trwałe

Zatruwanie pamięci agenta przekształca niezaufaną treść z tymczasowego promptu w instrukcje wielokrotnego użytku, które mogą wpływać na późniejsze sesje.

Pamięć pomaga agentowi zachowywać preferencje, kontekst projektu, historię zadań i wcześniejsze decyzje. Ta ciągłość ogranicza powtarzanie i zwiększa użyteczność długotrwałych przepływów pracy.

Tworzy jednak również trwałą powierzchnię ataku. Agent może zapisywać informacje zebrane ze stron internetowych, dokumentów, wiadomości, odpowiedzi narzędzi lub innych agentów.

Jeśli złośliwa treść trafi do takiego magazynu, agent może później pobrać ją jako zaufany kontekst. Gdy nastąpi szkodliwe działanie, pierwotny atakujący może już nie być obecny.

OWASP definiuje zatruwanie pamięci jako utrwalenie złośliwych informacji w celu wpłynięcia na późniejsze sesje lub użytkowników. W swoich wytycznych dotyczących bezpieczeństwa agentów wymienia to zagrożenie obok przejęcia celu, nadużycia narzędzi, ujawnienia danych i nadmiernej autonomii.

Ta trwałość zmienia reakcję na incydent. Usunięcie pierwotnej wiadomości lub zablokowanie źródła nie musi usuwać zapisanej instrukcji.

Zatruta pamięć może przetrwać między rozmowami. Może też wpływać na podsumowania, pobrane rekordy, plany i decyzje generowane wiele dni później.

Praktyczny scenariusz zaczyna się od odczytania przez agenta zewnętrznego dokumentu. Ukryty tekst fałszywie wskazuje kontakt kontrolowany przez atakującego jako zatwierdzonego dostawcę dla pilnych żądań.

Agent zapisuje to twierdzenie jako wiedzę organizacyjną. Później prawowity użytkownik prosi o pomoc podczas zakłócenia operacyjnego.

Agent pobiera zatruty wpis i rekomenduje kontakt kontrolowany przez atakującego. Jego odpowiedź wydaje się wewnętrznie spójna, ponieważ kieruje się informacją wcześniej zaakceptowaną do pamięci.

Uwierzytelnienie daje w tym scenariuszu niewielką ochronę. Użytkownik jest prawowity, agent jest prawowity, a późniejsze żądanie może być zwyczajne.

Uszkodzonym elementem jest zachowany przez agenta kontekst. Ten kontekst kształtuje sposób wykonania skądinąd dozwolonego zadania.

Zatruwanie pamięci może również tworzyć ścieżki ujawnienia danych. Zapisana instrukcja może nakazywać agentowi dołączanie ukrytych plików, przesyłanie wyników do niezatwierdzonego punktu końcowego lub osłabianie przyszłej kontroli bezpieczeństwa.

Skutek może się rozprzestrzeniać, gdy wielu agentów współdzieli magazyn wektorowy lub warstwę wiedzy. Jeden zatruty wpis może wpłynąć na kilka przepływów pracy bez konieczności kompromitowania każdego agenta z osobna.

Zatruwanie pamięci agenta komplikuje także przypisywanie winy. Szkodliwy wynik może wyglądać jak halucynacja lub awaria modelu, gdy rzeczywistą przyczyną jest uszkodzony trwały stan.

To rozróżnienie wpływa na działania naprawcze. Zmiana modelu lub przepisanie bezpośredniego promptu nie naprawi zatrutego magazynu pamięci.

Zespoły bezpieczeństwa potrzebują informacji o pochodzeniu zapisanego kontekstu. Rejestr pochodzenia wskazuje, skąd dany element pochodził, kiedy trafił do pamięci, który proces go zatwierdził i jak wykorzystywały go późniejsze zadania.

Pamięć powinna również mieć etykiety zaufania. Treści dostarczone przez użytkownika, tekst pobrany z zewnętrznych źródeł, zatwierdzone przez system zasady i zweryfikowane rekordy organizacyjne nie powinny trafiać do jednej, nierozróżnialnej puli.

Ta sama zasada ma znaczenie w osobistej bazie wiedzy AI. Trwały kontekst staje się cenniejszy wraz z nagromadzeniem, ale równie istotne stają się jego pochodzenie i zakres.

Omówienie trwałej pamięci przez OWASP opisuje powiązany przypadek Claude Code o nazwie MemoryTrap. Badacze Cisco odkryli, że rutynowy przepływ pracy programistycznej może umieszczać złośliwą treść na trwałych, zaufanych powierzchniach.

Według OWASP Anthropic później zmienił Claude Code, aby usunąć pamięci użytkownika ze ścieżki promptu systemowego o wysokim poziomie zaufania. Ta naprawa dotyczyła zidentyfikowanej ścieżki, a nie całej klasy zagrożeń.

Wniosek wykracza poza jednego agenta programistycznego. Każdy system, który zapisuje zmienny stan, a później traktuje go jako wskazówki, potrzebuje mechanizmów kontroli specyficznych dla pamięci.

Mechanizmy te obejmują walidację przed zapisaniem, kontrole integralności, pobieranie o ograniczonym zakresie, monitorowanie zmian oraz przywracanie znanego dobrego stanu.

Zespoły muszą również odróżniać pamięć faktograficzną od instrukcji dotyczących zachowania. Zapamiętana data projektu nie powinna mieć takiego samego autorytetu jak polityka bezpieczeństwa.

To rozdzielenie staje się szczególnie istotne, gdy agent może zapisywać własne wspomnienia. Przejęty proces planowania nie powinien po cichu redefiniować przyszłych zasad działania.

Zatruwanie pamięci agentów pokazuje, dlaczego bezpieczeństwo nie może koncentrować się wyłącznie na żądaniach trafiających do modelu. Obrońcy muszą chronić stan przenoszony między żądaniami.

Dlaczego brama nie może udźwignąć całego modelu bezpieczeństwa

Brama może egzekwować politykę, ale nie jest w stanie stworzyć brakujących danych o tożsamości, delegacji ani przypisaniu odpowiedzialności.

Bramy środowiska wykonawczego zajmują atrakcyjną pozycję. Mogą obserwować wywołania narzędzi, analizować żądania, stosować reguły i blokować niebezpieczne miejsca docelowe.

Ta widoczność sprawia, że stanowią logiczny zakup dla organizacji zaniepokojonych bezpieczeństwem agentów AI. Sama brama staje się jednak również uprzywilejowaną infrastrukturą.

Incydent LiteLLM z czerwca 2026 r. pokazał, dlaczego taka koncentracja zasługuje na dokładną analizę. CISA dodała CVE-2026-42271 do katalogu Known Exploited Vulnerabilities po pojawieniu się dowodów na aktywne wykorzystywanie tej luki.

Wada dotyczyła punktów końcowych używanych do testowania konfiguracji serwerów Model Context Protocol. Model Context Protocol, czyli MCP, pozwala aplikacjom AI łączyć się z narzędziami i zewnętrznymi źródłami danych.

Według ujawnienia LiteLLM uwierzytelniony użytkownik mógł podać szczegóły poleceń, które podatny serwer proxy wykonywał na swoim hoście.

Badacze połączyli tę lukę także z osobną podatnością weryfikacji hosta. Jak podano, to zestawienie umożliwiało zdalne wykonanie poleceń bez poświadczeń w podatnych konfiguracjach.

LiteLLM załatał problem wstrzykiwania poleceń w wersji 1.83.7. Ten przypadek nie dowodzi, że każda brama jest niebezpieczna.

Pokazuje, że brama jest częścią powierzchni ataku, a nie substytutem architektury bezpieczeństwa. Umieszczenie większej władzy w jednym mechanizmie kontroli zwiększa skutki jego przejęcia.

Nawet nieprzejęta brama pozostaje ograniczona przez swoje dane wejściowe. Silnik polityk nie może wywnioskować celu na podstawie tokenu okaziciela, który nie zawiera kontekstu zadania.

Nie potrafi też rozróżnić dwudziestu agentów współdzielących jedno konto usługi. Ruch wygląda na autoryzowany, ponieważ bazowy model tożsamości zatarł różnice, zanim rozpoczęło się egzekwowanie zasad.

To główny kompromis. Scentralizowane egzekwowanie może poprawić spójność, lecz centralizacja nie naprawia niejednoznaczności powstającej wcześniej.

Brama zyskuje wartość po tym, jak organizacja ustanowi inwentaryzację agentów. Każdy agent produkcyjny potrzebuje właściciela, określonego celu, zatwierdzonych narzędzi, źródła poświadczeń i statusu cyklu życia.

Kolejną zależnością jest odrębna tożsamość powiązana z delegacją. Narzędzie powinno wiedzieć zarówno, który agent je wywołał, jak i czyj autorytet ten agent reprezentuje.

Poświadczenia muszą następnie mieć wąskie zakresy i krótki czas życia. Agent uzgadniający powinien mieć dostęp do niezbędnej księgi, a nie do każdej bazy danych dostępnej dla jego ludzkiego sponsora.

Następnie potrzebna jest telemetria umożliwiająca przypisanie odpowiedzialności. Zespoły bezpieczeństwa muszą móc prześledzić ukończone zadanie przez każde wywołanie narzędzia i każdy wynik po stronie systemów zależnych.

Dopiero wtedy polityka środowiska wykonawczego może podjąć decyzję uwzględniającą kontekst. Decyzja staje się bardziej szczegółowa niż pytanie, czy token zezwala na zapis w bazie danych.

Może zapytać, czy ten agent może wykonać ten zapis dla tego podmiotu, w ramach tego zadania, wobec tego rekordu.

Dodatkowy kontekst wspiera również mechanizmy dodatkowego potwierdzenia. Operacje o dużym wpływie mogą wymagać niezależnej akceptacji, nawet jeśli agent dysponuje ważnymi poświadczeniami.

Płatności, usunięcia, zmiany produkcyjne, eksporty danych i modyfikacje polityk dostępu należą do tej kategorii. Ich konsekwencje uzasadniają zewnętrzną granicę autoryzacji.

Agent nie powinien zatwierdzać własnego działania. W przeciwnym razie wstrzyknięta instrukcja może wpłynąć zarówno na propozycję, jak i na zabezpieczenie.

Przedsiębiorstwa potrzebują także ścieżki wyłączenia działającej między systemami. Wyłączenie jednej tożsamości nie wystarcza, jeśli aktywne tokeny, uruchomione zadania i połączone narzędzia pozostają dostępne.

Ograniczanie skutków powinno unieważniać podstawowe i pochodne poświadczenia, zatrzymywać bieżące zadania, wyłączać dostęp do narzędzi oraz izolować obciążenie robocze hostujące agenta.

Tej zdolności nie można improwizować podczas incydentu. Zespoły muszą ją przetestować przed przyznaniem agentowi uprawnień produkcyjnych.

Brama pozostaje więc wartościowa, lecz jej rola się zmienia. Staje się warstwą egzekwowania w większym łańcuchu zależności.

To węższa obietnica niż „zabezpieczyć każde żądanie agenta”. Jest jednak także łatwiejsza do obrony.

Zasada najmniejszych uprawnień pomaga, ale nie zatrzymuje dryfu

Ograniczanie dostępu zmniejsza szkody, jakie może wyrządzić agent, podczas gdy mechanizmy behawioralne odnoszą się do tego, co agent robi w obrębie tej ograniczonej granicy.

Zasada najmniejszych uprawnień pozostaje jednym z najczytelniejszych dostępnych zabezpieczeń. Agent nie może ujawnić bazy danych, do której nie sięgają jego poświadczenia.

Teleport zlecił badanie z udziałem 205 liderów bezpieczeństwa i infrastruktury. Organizacje zgłaszające systemy AI z nadmiernymi uprawnieniami odnotowały wskaźnik incydentów na poziomie 76%, w porównaniu z 17% w przypadku systemów o najmniejszych uprawnieniach.

To 4,5-krotna różnica w zgłoszonych wskaźnikach badania. Badanie tożsamości firmy zostało przeprowadzone przez Eleven Market Research w grudniu 2025 r.

Badania sponsorowane przez dostawców mają ograniczenia. Ich definicje systemów AI, incydentów i poziomów uprawnień mogą różnić się od wewnętrznych pomiarów innej organizacji.

Wyniki nadal wspierają praktyczną tezę. Mniejsze zakresy uprawnień na ogół zmniejszają liczbę systemów dostępnych dla omylnego lub przejętego agenta.

Jednak zasada najmniejszych uprawnień nie dowodzi poprawności zachowania. Agent może niewłaściwie wykorzystywać ograniczony autorytet, którym zgodnie z prawem dysponuje.

Agent obsługi klienta może mieć uprawnienie do odczytu jednego konta. Nadal może ujawnić dane tego konta w niewłaściwym kanale.

Agent planujący może mieć dostęp do zapisu w kalendarzu. Nadal może anulować zatwierdzone spotkanie po błędnym odczytaniu złośliwej treści w zaproszeniu.

Agent finansowy może mieć dostęp do jednej księgi. Nadal może zmienić niewłaściwy rekord, pozostając w pełni w zakresie swoich technicznych uprawnień.

W tym miejscu użyteczne stają się bazowe profile zachowania. Profil bazowy opisuje normalne narzędzia agenta, miejsca docelowe, częstotliwość działań, domeny danych i wzorce zadań.

Zespoły bezpieczeństwa mogą następnie wykrywać odchylenia. Przykłady obejmują nieoczekiwany dostęp między domenami, powtarzające się nieudane zatwierdzenia, nietypowe eksporty lub zmiany częstotliwości wywołań narzędzi.

Profile bazowe muszą opierać się na wiarygodnej tożsamości i telemetrii. W przeciwnym razie dane różnych agentów zostają połączone w jeden mylący profil.

Monitorowanie wymaga także świadomości zadania. Rzadki zapis do bazy danych może być uzasadniony dla jednego zadania i niebezpieczny dla innego.

Ten wymóg sprawia, że reguły statyczne są niewystarczające. Decyzje środowiska wykonawczego potrzebują ustrukturyzowanego kontekstu dotyczącego celu, inicjatora, zatwierdzonych zasobów i oczekiwanego wyniku.

Trudne pytanie brzmi, jak bardzo system egzekwowania może ufać temu kontekstowi. Jeśli agent sam generuje opis zadania, przejęty agent może fałszywie przedstawić jego cel.

Zaufany kontekst zadania powinien więc pochodzić z zewnętrznego orkiestratora, definicji przepływu pracy lub systemu zatwierdzania. Agent może korzystać z tego kontekstu, ale nie powinien po cichu go przepisywać.

Pamięć wymaga podobnego traktowania. Model nie powinien promować niezweryfikowanego pobranego tekstu do trwałej polityki bez niezależnej walidacji.

Granice te oddzielają decydenta od autoryzacji decyzji. Zmniejszają prawdopodobieństwo, że jeden zmanipulowany model kontroluje każdy etap.

Zatwierdzenie przez człowieka może pomóc na nieodwracalnych granicach, ale nie jest pełną odpowiedzią. Duża liczba żądań i powtarzalne komunikaty powodują zmęczenie zatwierdzaniem.

Interfejs zatwierdzania musi pokazywać istotne fakty. Osoby dokonujące przeglądu potrzebują informacji o inicjującym zadaniu, zasobie, którego dotyczy działanie, proponowanej zmianie i oczekiwanej konsekwencji.

Ogólny przycisk „zezwól” przenosi odpowiedzialność bez zapewnienia wystarczających informacji. Może stać się kolejną ceremonią uwierzytelniania, która nie wychwytuje intencji.

Skuteczne bezpieczeństwo agentów AI łączy zatem ograniczenia i obserwację. Zasada najmniejszych uprawnień ogranicza promień rażenia, podczas gdy telemetria i niezależna autoryzacja ujawniają dryf behawioralny.

Mechanizmy kontroli integralności pamięci odnoszą się do trwałej manipulacji. Ścieżka wyłączenia między systemami obsługuje przypadki pominięte przez kontrole prewencyjne.

Żadna pojedyncza warstwa nie dowodzi, że agent będzie zachowywał się poprawnie. Celem jest uczynienie niebezpiecznego zachowania widocznym, ograniczonym, odwracalnym i możliwym do przypisania.

Sześć mechanizmów kontroli, które przedsiębiorstwa mogą zweryfikować już teraz

Bezpieczeństwo agentów AI staje się mierzalne, gdy każdy mechanizm kontroli ma test operacyjny zamiast deklaracji polityki.

Pierwszym testem jest inwentaryzacja. Organizacja powinna być w stanie wskazać każdego agenta produkcyjnego i zidentyfikować jego odpowiedzialnego właściciela.

Inwentaryzacja powinna obejmować cel, zatwierdzone narzędzia, domeny danych, źródła poświadczeń, dostawcę modelu, lokalizację wdrożenia i status cyklu życia.

Agenci działający w cieniu zasługują na takie samo traktowanie. System nie staje się mniej ryzykowny tylko dlatego, że dział wdrożył go bez centralnej akceptacji.

Drugim testem są tożsamość i delegacja. Dzienniki powinny odróżniać agenta od osoby, usługi lub przepływu pracy, które przydzieliły mu zadanie.

To powiązanie musi przetrwać wywołania narzędzi i przekazania między agentami. W przeciwnym razie możliwość przypisania odpowiedzialności znika, gdy tylko przepływ pracy opuści pierwszą aplikację.

Trzecim testem jest zakres poświadczeń. Zespoły bezpieczeństwa powinny wybrać agenta i potwierdzić, że jego aktywny token nie może uzyskać dostępu do niepowiązanych zasobów.

Poświadczenie powinno także wygasać wraz z zadaniem. Długotrwałe sekrety zamieniają tymczasowy dostęp agenta w trwałą ekspozycję.

Czwartym testem jest rekonstrukcja. Badacze powinni wybrać jedno ukończone zadanie i prześledzić je od inicjacji po każdy efekt po stronie systemów zależnych.

Kompletny ślad obejmuje prompty, pobrany kontekst, odczyty pamięci, zapisy pamięci, wywołania narzędzi, zatwierdzenia, poświadczenia, wyniki i zmiany zewnętrzne.

Ten zapis nie powinien zależeć wyłącznie od zgłaszanego przez agenta toku rozumowania. Najbardziej wiarygodne dowody pochodzą z systemów znajdujących się poza modelem.

Piątym testem jest egzekwowanie uwzględniające kontekst. Organizacja powinna spróbować wykonać działanie, które może wykonać ludzki sponsor, ale nie delegowany agent.

Brama powinna zablokować działanie, ponieważ wykracza ono poza zakres zadania. Blokowanie wyłącznie dlatego, że token nie ma dostępu, testuje zwykłe uprawnienia, a nie kontrolę świadomą agenta.

Szóstym testem jest ograniczanie skutków. Symulowany incydent powinien zweryfikować, czy organizacja może zatrzymać agenta we wszystkich połączonych systemach.

Zespoły powinny unieważnić poświadczenia, zatrzymać aktywne uruchomienia, zablokować narzędzia, odizolować obciążenie robocze i zapobiec automatycznemu wznawianiu działań oczekujących w kolejce.

Pamięć wymaga dodatkowych testów w całej tej sekwencji. Zespoły bezpieczeństwa powinny określić, kto może zapisywać trwały kontekst i które późniejsze przepływy pracy mogą go pobierać.

Powinny wprowadzić nieszkodliwy rekord testowy z niezaufanego źródła. System powinien oznaczyć jego pochodzenie, ograniczyć jego zakres i uniemożliwić mu stanie się polityką.

Równie ważne jest ćwiczenie wycofania zmian. Usunięcie jednego zatrutego wpisu nie powinno niszczyć prawidłowych wspomnień ani pozostawiać niezmienionych pochodnych podsumowań.

Kontekst pochodny tworzy subtelny problem odzyskiwania. Złośliwy rekord mógł już wpłynąć na podsumowanie, plan lub współdzielony obiekt wiedzy.

Usunięcie wyłącznie oryginału pozostawia te elementy potomne nienaruszone. Systemy pamięci potrzebują więc śledzenia pochodzenia między rekordami źródłowymi a wygenerowanymi artefaktami.

Nabywcy korporacyjni powinni pytać dostawców, czy zmiany w pamięci podlegają audytowi. Powinni także pytać, czy etykiety zaufania przetrwają podsumowywanie i pobieranie.

Programiści potrzebują jasnych mechanizmów kontroli granic narzędzi. Model powinien otrzymywać wyłącznie narzędzia wymagane do bieżącego zadania, a nie cały katalog integracji.

Pracownicy umysłowi powinni rozumieć, że pewne wspomnienie agenta nie potwierdza jego pochodzenia. Trwały kontekst może być nieaktualny, błędny albo celowo zmanipulowany.

Te kontrole przekształcają abstrakcyjną kwestię bezpieczeństwa w obserwowalne dowody. Ujawniają też, gdzie pęka łańcuch zależności wdrożenia.

Firma nie musi wymieniać całej infrastruktury tożsamości przed rozpoczęciem działań. Może rejestrować agentów względem istniejących tożsamości obciążeń roboczych i dodawać zaufane identyfikatory zadań.

Następnie może przejść do krócej ważnych poświadczeń, bogatszych logów i niezależnego zatwierdzania operacji o dużym wpływie.

Kolejność ma większe znaczenie niż branding poszczególnych mechanizmów kontroli. Każda warstwa niższego poziomu powinna wykorzystywać dowody wytworzone wyżej.

Gdy takich dowodów brakuje, organizacja powinna ograniczyć uprawnienia agenta. Nie powinna rekompensować tego większym zaufaniem do bramy.

Na co zespoły bezpieczeństwa powinny zwrócić uwagę w następnej kolejności

Kolejny etap bezpieczeństwa agentów AI będzie mierzony przez mechanizmy kontroli produktów, dowody incydentów i standardy dotyczące pamięci.

Pierwszym sygnałem będzie natywna tożsamość ograniczona do zakresu zadania na platformach agentowych. Dostawcy muszą udostępniać odrębne identyfikatory agentów, łańcuchy delegacji i krótkotrwałe poświadczenia poprzez standardowe interfejsy.

Jeśli te możliwości staną się domyślne, bramy będą mogły egzekwować polityki na podstawie czegoś więcej niż ważności tokenu. Wzmocniłoby to model oparty na zależnościach opisany w raporcie Google News.

Jeśli platformy nadal będą polegać na współdzielonych kontach usługowych i tokenach deweloperskich, model w praktyce osłabnie. Przedsiębiorstwa będą miały trudności z zapewnieniem przypisywalności działań po wdrożeniu.

Drugim sygnałem będą niezależne testy zabezpieczeń pamięci. Obecne wytyczne wyraźnie identyfikują zatruwanie pamięci agentów, ale implementacje znacznie się różnią.

Przydatne testy powinny mierzyć, czy zatruta treść utrzymuje się, przenika między użytkownikami, wpływa na narzędzia, przetrwa streszczanie lub pozostaje po próbie usunięcia.

Powinny też oceniać możliwość naprawy. Wykrycie szkodliwego wspomnienia ma ograniczoną wartość, jeśli zespoły nie potrafią zidentyfikować i usunąć każdego pochodnego artefaktu.

Standaryzowane wyniki pomogłyby kupującym odróżnić podstawowe filtrowanie danych wejściowych od rzeczywistej ochrony w całym cyklu życia. Ujawniłyby również, czy zabezpieczenia działają poza kontrolowanymi demonstracjami.

Trzecim sygnałem będzie publiczne raportowanie incydentów powiązane z łańcuchami działań agentów. Zespoły bezpieczeństwa potrzebują dowodów pokazujących, gdzie zawiodły tożsamość, delegacja, pamięć lub mechanizmy ograniczania skutków.

Raport stwierdzający, że „AI popełniła błąd”, nie wystarczy. Analitycy potrzebują informacji o źródle zadania, pobranym kontekście, ścieżce narzędziowej, zakresie poświadczeń i skutku zewnętrznym.

Bardziej szczegółowe raportowanie mogłoby wzmocnić albo podważyć obecną tezę. Powtarzające się awarie po prawidłowym uwierzytelnieniu potwierdziłyby, że sama tożsamość nie wystarcza.

Z kolei trwałe ograniczenie liczby incydentów wśród wdrożeń wykorzystujących poświadczenia o ograniczonym zakresie i telemetrię umożliwiającą przypisanie działań wspierałoby proponowaną kolejność kontroli.

Liderzy bezpieczeństwa powinni zacząć zbierać te pomiary już teraz. Czekanie na dojrzałą kategorię dostawców sprawia, że dzisiejsi agenci działają według założeń z wczoraj.

Deweloperzy mogą zacząć od prześledzenia jednego kompletnego zadania. Nabywcy korporacyjni mogą wymagać dowodów dotyczących tożsamości, pochodzenia pamięci i ograniczania skutków między systemami.

Pracownicy umysłowi mogą kwestionować pochodzenie zapamiętanych przez agenta faktów, zanim podejmą działania na podstawie wrażliwych rekomendacji.

Kluczowa lekcja z tej historii Google News nie polega na tym, że uwierzytelnianie zawiodło. Uwierzytelnianie wykonuje węższe zadanie, niż wymagają obecnie autonomiczne przepływy pracy.

Trudniejsza praca zaczyna się po przyznaniu dostępu. Czy Twoja organizacja potrafi udowodnić, dlaczego agent podjął działanie, ograniczyć zakres jego dostępu, sprawdzić, co pamięta, i zatrzymać go wszędzie?

Wybierz w tym tygodniu jednego agenta produkcyjnego i odtwórz jego ostatnie ukończone zadanie. Jeśli któregoś ogniwa brakuje, ta luka wskazuje kolejny mechanizm kontroli do zbudowania.