Agenci AI w przedsiębiorstwach wyprzedzają fundamenty bezpieczeństwa

Google News zwróciło uwagę na poważne ostrzeżenie dla przedsiębiorstw: agenci AI już działają wewnątrz firm, mimo że mechanizmy bezpieczeństwa projektowano z myślą o przewidywalnym oprogramowaniu i ludzkich użytkownikach.

Problem nie polega już na tym, czy pracownik może poprosić chatbota o podsumowanie dokumentu. Agenci potrafią pobierać rekordy, wywoływać narzędzia, aktualizować systemy, pisać kod i uruchamiać wieloetapowe procesy. Ten rozszerzony zakres uprawnień sprawia, że odpowiedź AI może przełożyć się na działanie biznesowe.

Centralnym konfliktem jest zderzenie możliwości z kontrolą. Przedsiębiorstwa chcą, aby agenci wykonywali użyteczną pracę przy ograniczonym nadzorze. Zespoły bezpieczeństwa nadal muszą jednak identyfikować każdego agenta, ograniczać jego dostęp, śledzić jego decyzje i zatrzymywać go, gdy jego zachowanie się zmienia.

Ta presja jednocześnie dotyka zespołów odpowiedzialnych za tożsamość, bezpieczeństwo, zgodność i platformy. Dostawcy, w tym Microsoft, Cisco, Google, Amazon i Salesforce, dodają funkcje zarządzania agentami. Sama technologia nie rozwiąże jednak problemu niejasnej odpowiedzialności ani rozproszonych zasad operacyjnych.

Nagłówek pojawiający się w Google News wskazuje więc na szerszą zmianę. Granica bezpieczeństwa przedsiębiorstwa obejmuje teraz aktorów programowych, którzy interpretują cele, wybierają kroki pośrednie i wchodzą w interakcje z innymi aktorami programowymi. Istniejące fundamenty pozostają istotne, ale wiele z nich wymaga znaczącego dostosowania.

Ostrzeżenie Google News dotyczy działań, a nie odpowiedzi

Agent AI staje się problemem bezpieczeństwa, gdy otrzymuje wystarczające uprawnienia, by zmienić coś poza modelem.

Asystenci generatywnej AI przede wszystkim tworzą treści do sprawdzenia przez człowieka. Agent może przejść od generowania do wykonania. Może zapytać o dane klientów, otworzyć zgłoszenie wsparcia, przesłać kod, zaplanować płatność lub przeprowadzić rekonfigurację usługi chmurowej.

To rozróżnienie tworzy kontekst wydarzenia stojącego za tym nagłówkiem. Wdrożenia w przedsiębiorstwach wyszły poza odizolowane interfejsy czatowe i wkroczyły do procesów połączonych z systemami operacyjnymi. Agent może teraz przekraczać granice, którymi zespoły bezpieczeństwa wcześniej zarządzały za pomocą oddzielnych aplikacji i zatwierdzeń przez ludzi.

Microsoft definiuje agentów jako systemy programowe, które uzyskują dostęp do danych, podejmują decyzje i wykonują działania na podstawie delegowanych uprawnień. Jego aktualny poziom bazowy zarządzania zaleca scentralizowane polityki obejmujące tożsamość, odpowiedzialność, dostęp, monitorowanie, dane i standardy tworzenia oprogramowania.

Delegowane uprawnienia oznaczają, że agent działa, korzystając z uprawnień przyznanych przez osobę, usługę lub organizację. Agent nie jest właścicielem tych uprawnień. Jego działania mogą jednak wywołać konsekwencje, zanim pierwotny delegujący zauważy problem.

Weźmy pod uwagę agenta wsparcia połączonego z rekordami klientów i platformą obsługi zgłoszeń. Odczyt historii konta wiąże się z ryzykiem dla poufności. Aktualizacja uprawnienia wiąże się z ryzykiem dla integralności. Wydanie zwrotu środków wprowadza ryzyko finansowe i zwiększa potrzebę mechanizmów zatwierdzania.

Agent programistyczny przedstawia inną wersję tego samego problemu. Może przeglądać repozytoria, generować zmiany, uruchamiać testy i przesyłać pull request. Jeśli może również scalać kod lub uzyskiwać poświadczenia wdrożeniowe, jedno błędne polecenie może trafić do środowiska produkcyjnego.

Nie są to teoretyczne rozszerzenia chatbota. To zwykłe uprawnienia automatyzacji połączone z probabilistycznym podejmowaniem decyzji. Model może błędnie zrozumieć kontekst, podążyć za złośliwą treścią lub wybrać nieoczekiwane narzędzie, realizując prawidłowy cel.

Agent działa również w dłuższym łańcuchu niż większość tradycyjnych aplikacji. Otrzymuje cel, buduje plan, wybiera narzędzia, pobiera kontekst, ocenia wyniki i dostosowuje kolejny krok. Każde przejście tworzy kolejne miejsce, w którym autoryzacja lub monitorowanie może zawieść.

Zespoły bezpieczeństwa zwykle rozumieją aplikację poprzez z góry określone przepływy. Agenci tworzą część przepływów dynamicznie. Dozwolone zapytanie do bazy danych i zatwierdzona wiadomość wychodząca mogą stać się niebezpieczne, gdy agent połączy je bez rozpoznania ujawnienia danych.

Dlatego sposób przedstawienia sprawy przez Google News ma znaczenie. Ten nagłówek nie jest kolejną prognozą dotyczącą przyszłej sztucznej inteligencji. Odzwierciedla obecną zmianę w rozmieszczeniu uprawnień programowych i szybkości, z jaką mogą być wykorzystywane.

Pierwsze pytanie dotyczące bezpieczeństwa jest zatem konkretne: które agenty mogą dziś wykonywać działania? Jeśli organizacja nie potrafi przygotować takiego spisu, jej polityki obejmują wyłącznie agentów, o których już wie.

Wdrożenia w przedsiębiorstwach wyprzedzają warstwę kontrolną

Luka we wdrożeniach nie polega jedynie na szybkim uruchamianiu rozwiązań; to różnica między eksperymentowaniem z agentami a zarządzaniem każdym agentem jako rozliczalnym zasobem przedsiębiorstwa.

Cisco podało w marcu 2026 r., że 85 procent ankietowanych klientów z dużych przedsiębiorstw eksperymentowało z agentami AI. Według jego badania przedsiębiorstw tylko 5 procent wdrożyło technologię agentową do produkcji.

Liczby te pochodzą od Cisco i należy je traktować jako badanie dostawcy, a nie uniwersalny spis. Nadal ilustrują jednak ważny punkt presji. Eksperymentowanie tworzy tożsamości, poświadczenia, połączenia z narzędziami i przepływy danych, zanim projekt otrzyma formalny status produkcyjny.

Prototyp może uzyskiwać dostęp do rzeczywistych informacji, nawet jeśli jego twórcy nazywają go testem. Pracownicy mogą łączyć konsumenckie usługi AI z firmowymi kontami. Zespoły biznesowe mogą tworzyć agentów przepływów pracy bez angażowania centralnego zespołu bezpieczeństwa. Deweloperzy mogą rozpowszechniać poświadczenia za pośrednictwem frameworków, których operacje bezpieczeństwa nie potrafią łatwo wykryć.

Prowadzi to do powstawania ukrytych agentów, czyli agentów działających bez pełnej ewidencji organizacyjnej lub zatwierdzenia. Ukryte agenty przypominają shadow IT, ale mogą podejmować decyzje i inicjować działania w kilku połączonych usługach.

Tradycyjne inwentaryzacje zasobów mogą rejestrować obciążenie chmurowe, klienta API lub konto usługi. Często nie pokazują jednak, że agent AI kontroluje te komponenty. Zespół bezpieczeństwa widzi poświadczenia, nie widząc systemu rozumowania, który z nich korzysta.

Równie niejasna może stać się odpowiedzialność. Menedżer biznesowy zlecił przepływ pracy, deweloper go złożył, zespół platformowy go hostuje, a dostawca dostarcza model. Gdy agent zachowuje się nieprawidłowo, każdy uczestnik odpowiada tylko za jedną warstwę.

Czytelnicy Google News mogą zetknąć się z bezpieczeństwem agentów jako nową kategorią produktów. Dla przedsiębiorstw natychmiastowym wymogiem jest jednak model operacyjny. Ktoś musi zatwierdzić cel agenta, jego dostęp, sprawdzać jego zachowanie i wycofać go, gdy ten cel przestaje obowiązywać.

Aktualne mechanizmy kontroli tożsamości agentów firmy Microsoft wymagają, aby każda tożsamość agenta miała ludzkiego sponsora. Sponsor pozostaje odpowiedzialny za cel, decyzje dotyczące cyklu życia i przeglądy dostępu.

Model ten odpowiada na podstawowe, lecz często zaniedbywane pytanie: kto odpowiada za aktora niebędącego człowiekiem? Wyznaczenie sponsora nie czyni agenta bezpiecznym. Ustanawia osobę, która może zatwierdzać zmiany i otrzymywać eskalacje, gdy dostęp przestaje odpowiadać jego roli.

Warstwa kontrolna potrzebuje również wiarygodnego rejestru. Każdy wpis powinien łączyć agenta z jego właścicielem, celem, modelem, narzędziami, źródłami danych, poświadczeniami, środowiskiem i zasadami zatwierdzania. Lista subskrypcji modeli nie zapewnia takiego widoku.

Wykrywanie musi trwać także po rejestracji. Agenci mogą tworzyć krótkotrwałe procesy, delegować zadania lub wywoływać innych agentów. Statyczny arkusz kalkulacyjny szybko staje się niekompletny, gdy instancje w czasie działania różnią się od zatwierdzonego projektu.

Kolejną lukę tworzy proces zakupowy. Funkcja oprogramowania może dodać zachowanie agentowe w ramach rutynowej aktualizacji. Organizacja może uzyskać autonomię wewnątrz istniejącej platformy bez uruchamiania odrębnego projektu AI lub wywołania dedykowanego przeglądu.

Presja na bezpieczeństwo przesuwa się w konsekwencji w kierunku ciągłego wykrywania. Platformy tożsamości, bramy API, telemetria punktów końcowych, logi chmurowe i mechanizmy kontroli danych muszą współpracować. Żadne pojedyncze źródło nie ujawni całego łańcucha.

Największa presja dotyka firmy ze zdecentralizowanymi zakupami oprogramowania i rozproszonymi systemami tożsamości. Ich zespoły mogą wdrażać agentów szybciej, lecz śledczy mogą mieć trudności z odtworzeniem, kto zatwierdził dane działanie.

Ta nierównowaga wyjaśnia, dlaczego fundamenty przedsiębiorstwa mają większe znaczenie niż odizolowany wynik bezpieczeństwa modelu. Bezpieczniejszy model nie zrekompensuje współdzielonych poświadczeń, nadmiernych uprawnień, brakujących logów ani produkcyjnego przepływu pracy bez właściciela.

Tożsamość musi podążać za agentem przy każdym wywołaniu narzędzia

Nazwany agent ze stałym, nadmiernym dostępem nadal nie jest bezpieczny; tożsamość musi być połączona z wąską autoryzacją i pełnym przypisaniem działań.

Tożsamość jest pierwszym fundamentem, ponieważ każda późniejsza kontrola potrzebuje podmiotu. Systemy bezpieczeństwa muszą wiedzieć, który agent zażądał dostępu, która osoba lub usługa delegowała uprawnienia oraz która instancja wykonała działanie.

Korzystanie ze współdzielonego konta usługi przerywa ten łańcuch. Śledczy mogą ustalić, że konto wysłało zapytanie do bazy danych, lecz nie to, który agent zainicjował żądanie. Mogą również nie zauważyć, czy działanie wynikało z zatwierdzonego zadania człowieka.

Odrębna tożsamość powinna zachowywać ciągłość między wywołaniami modelu przez agenta, komponentami planowania, narzędziami i usługami niższego poziomu. Tożsamość nie potrzebuje jednego stałego poświadczenia. Potrzebuje możliwej do prześledzenia relacji między każdym tymczasowym poświadczeniem a pierwotnym agentem.

Autoryzacja określa, co ta tożsamość może zrobić. Zasada najmniejszych uprawnień ogranicza dostęp do minimalnych zasobów i działań potrzebnych do zatwierdzonego celu. W przypadku agentów zakres powinien również uwzględniać czas, zadanie i delegowane uprawnienia użytkownika.

Agent rozliczeń wydatków może potrzebować odczytu jednego rachunku pracownika i utworzenia jednego roboczego wniosku o zwrot kosztów. Nie powinien przeglądać danych wszystkich pracowników ani zatwierdzać własnej płatności. Uprawnienie powinno wygasać wraz z zakończeniem zadania.

To bardziej rygorystyczne niż przyznanie agentowi takich samych uprawnień jak jego ludzki sponsor. Menedżer może mieć dostęp do tysięcy rekordów w ramach wielu uzasadnionych obowiązków. Agent wykonujący jedno delegowane zadanie powinien otrzymać wyłącznie odpowiedni podzbiór.

Współczesne projekty coraz częściej wykorzystują autoryzację just-in-time. Agent żąda w razie potrzeby dostępu o wąskim zakresie, a silnik polityk ocenia to żądanie. Działania o wyższym ryzyku mogą wymagać, aby człowiek zatwierdził dokładną operację.

Model Context Protocol, powszechnie nazywany MCP, standaryzuje sposób, w jaki aplikacje AI łączą się z narzędziami i źródłami danych. Standaryzacja może poprawić widoczność, ale MCP nie czyni automatycznie integracji bezpieczną.

Serwer nadal wymaga uwierzytelniania, autoryzacji, walidacji danych wejściowych i rejestrowania zdarzeń. Klient nadal może zostać zmanipulowany przez wrogą treść. Serwer MCP z szerokimi uprawnieniami może zamienić wygodną integrację w skoncentrowany punkt awarii kontroli.

To samo ostrzeżenie dotyczy komunikacji między agentami. Jeden agent może delegować badania innemu, a następnie wykorzystać wynik do uruchomienia działania. Rejestry bezpieczeństwa muszą zachowywać ten łańcuch delegowania, zamiast traktować końcowe żądanie jako odizolowane zdarzenie.

Uwierzytelnianie odpowiada na pytanie, która tożsamość złożyła żądanie. Autoryzacja odpowiada, czy żądanie było dozwolone. Bezpieczeństwo agentów musi również ocenić, czy żądanie odpowiada zatwierdzonemu celowi i bieżącemu kontekstowi.

Ta ostatnia kontrola jest trudna. Agent zakupowy może mieć uzasadnione uprawnienie do wyszukiwania dostawców. To samo uprawnienie staje się podejrzane, jeśli nagle pobiera kompletną bazę dostawców po przeczytaniu złośliwego dokumentu.

W tym miejscu monitorowanie zachowań uzupełnia statyczną politykę. System powinien porównywać bieżącą aktywność z zadeklarowanym celem agenta, zwykłą sekwencją narzędzi, zakresem danych i limitami transakcji. Nieoczekiwane odchylenia zasługują na przegląd lub automatyczne zawieszenie.

Framework AEGIS Forrester wskazuje, że bezpieczeństwo agentów musi łączyć zarządzanie, tożsamość, dane, bezpieczeństwo aplikacji, operacje związane z zagrożeniami i zero trust. Jego kluczowa teza brzmi: autonomia obejmuje mechanizmy kontroli, które wcześniej były zarządzane jako odrębne dziedziny.

Zero trust oznacza, że każde żądanie podlega wyraźnej ocenie, zamiast dziedziczyć zaufanie z lokalizacji sieciowej. W odniesieniu do agentów wymaga to zweryfikowanej tożsamości, wąskiego zakresu dostępu, kontroli kontekstowych i ciągłej obserwacji.

Ten fundament poprawia również bezpieczeństwo operacyjne. Błędnie skonfigurowany agent i przejęty agent mogą wykonywać podobne działania. Silna tożsamość i autoryzacja pomagają ograniczyć oba przypadki bez konieczności wcześniejszego ustalania przez system bezpieczeństwa intencji.

Tytuł znaleziony w Google News pyta, czy fundamenty przedsiębiorstw są gotowe. Tożsamość oferuje praktyczny test: czy firma potrafi zatrzymać jednego agenta bez wyłączania każdego przepływu pracy, który korzysta z tych samych poświadczeń?

Jeśli odpowiedź brzmi „nie”, organizacja nie ma jeszcze kontroli na poziomie agentów. Ma dostęp aplikacyjny z dołączoną warstwą AI.

Prompt Injection Zamienia Zaufane Dane w Ścieżkę Ataku

Agenci nie tylko przetwarzają niezaufany tekst; mogą przekształcać go w instrukcje mające dostęp do narzędzi przedsiębiorstwa.

Prompt injection występuje, gdy treść wpływa na model, aby zignorował lub zreinterpretował jego zamierzone instrukcje. Złośliwe polecenie może pojawić się na stronie internetowej, w e-mailu, dokumencie, zgłoszeniu wsparcia, komentarzu w kodzie lub pobranym rekordzie wiedzy.

Człowiek może rozpoznać podejrzany język i go odrzucić. Agent może przetworzyć tę samą treść jako użyteczny kontekst. Jeśli agent może wywoływać narzędzia, tekst atakującego może wpływać na działania wykraczające poza model.

Wyobraźmy sobie agenta przeglądającego dokumenty dostawców. Jeden z dokumentów zawiera ukryty tekst nakazujący agentowi pobrać poufne ceny i wysłać je na zewnętrzny adres. Żądanie jest złośliwe, mimo że plik dotarł przez zatwierdzone repozytorium.

Filtrowanie danych wejściowych może wychwycić oczywiste instrukcje, ale nie rozstrzygnie każdego konfliktu między danymi a poleceniami. Język naturalny pełni obie funkcje. Agent musi interpretować, która treść opisuje zadanie, a która próbuje je zmienić.

Ta niejednoznaczność odróżnia bezpieczeństwo agentów od konwencjonalnego skanowania pod kątem złośliwego oprogramowania. Dokument nie musi zawierać wykonywalnego kodu. Może wykorzystywać zachowanie modelu polegające na wykonywaniu instrukcji, używając zwykłego języka.

Zagrożenia agentowe OWASP obejmują przejęcie celu, niewłaściwe użycie narzędzi, nadużycie tożsamości, zatruwanie pamięci, niebezpieczną komunikację między agentami i kaskadowe awarie. Kategorie te łączą zachowanie modeli ze znanymi konsekwencjami dla bezpieczeństwa.

Ograniczenia narzędzi zapewniają jedną z form obrony. Agent badawczy, który tylko odczytuje zatwierdzone źródła, nie może wysyłać e-maili ani modyfikować rekordów klientów. Jego przejęte dane wyjściowe nadal mogą wprowadzić człowieka w błąd, ale bezpośredni promień rażenia pozostaje mniejszy.

Rozdział obowiązków zapewnia kolejną warstwę ochrony. Jeden komponent może przygotować działanie, podczas gdy inna usługa polityk je zatwierdza. Agent nie powinien decydować, autoryzować i wykonywać transakcji o dużym wpływie w ramach tej samej niekontrolowanej ścieżki rozumowania.

Istotna jest również klasyfikacja danych. Warstwa narzędzi powinna wiedzieć, czy żądane informacje są publiczne, wewnętrzne, poufne czy regulowane. Wygenerowany przez agenta plan nie powinien nadpisywać polityki blokującej przesyłanie danych objętych ograniczeniami.

Pamięć wprowadza mniej widoczne ryzyko. Agenci mogą przechowywać podsumowania, preferencje, pobrane fakty lub wcześniejsze instrukcje na potrzeby późniejszych zadań. Atakujący, który zatruje tę pamięć, może wpływać na przyszłe zachowanie po zniknięciu pierwotnych złośliwych danych wejściowych.

Zespoły muszą odróżniać kontekst roboczy od trwałej pamięci. Tymczasowe dane zadania powinny wygasać. Trwałe rekordy powinny wskazywać źródło, czas utworzenia, politykę dostępu i status walidacji.

Dotyczy to każdej organizacji budującej bazę wiedzy AI. Użyteczne wyszukiwanie zależy od pochodzenia danych, uprawnień i wyraźnego oddzielenia rekordów autorytatywnych od niezaufanych materiałów.

Programiści muszą również zakładać, że zabezpieczenia zawiodą. Odmowa modelu wykonania niebezpiecznego żądania podczas testów nie gwarantuje spójnego zachowania przy innym sformułowaniu, narzędziach i pobranym kontekście.

Testy przed wdrożeniem powinny obejmować ataki wieloetapowe, a nie tylko pojedyncze złośliwe prompty. Test powinien badać, czy agent zmienia plan, szuka alternatywnych narzędzi lub przenosi skażone instrukcje do innego agenta.

Kontrole w czasie działania pozostają konieczne, ponieważ środowisko operacyjne się zmienia. Pojawiają się nowe dokumenty, uprawnienia są rozszerzane, narzędzia otrzymują aktualizacje, a modele się zmieniają. Bezpieczny wynik testu jest dowodem dotyczącym jednej konfiguracji w jednym momencie.

Tworzy to główny kompromis artykułu. Więcej kontekstu i więcej narzędzi czyni agentów użytecznymi, ale zwiększa też liczbę ścieżek prowadzących od niezaufanych danych wejściowych do działań o istotnych skutkach.

Przedsiębiorstwa nie muszą eliminować każdej niepewnej decyzji modelu. Potrzebują architektury, która zapobiega przyznawaniu nieograniczonych uprawnień niepewnym decyzjom.

Dzienniki Audytu Muszą Obejmować Decyzje, Delegowanie i Konsekwencje

Tradycyjne dzienniki rejestrują zdarzenia systemowe, lecz dochodzenia dotyczące agentów wymagają pełnej ścieżki od żądania człowieka do decyzji modelu i działania zewnętrznego.

Użyteczny zapis dotyczący agenta zaczyna się od zadania inicjującego. Powinien identyfikować zgłaszającego, agenta, zatwierdzony cel, wersję polityki, konfigurację modelu, narzędzia, źródła danych i delegowane uprawnienia.

Następnie zapis powinien obejmować żądania narzędzi i ich wyniki. Powinien pokazywać, która tożsamość działała, do jakiego zasobu uzyskała dostęp, która polityka dopuściła operację oraz czy zatwierdził ją człowiek.

Rejestrowanie wewnętrznego rozumowania rodzi komplikacje prawne, prywatnościowe i techniczne. Ślady rozumowania modelu mogą zawierać wrażliwe informacje i nie zawsze wiarygodnie wyjaśniają zachowanie modelu. Przedsiębiorstwa powinny priorytetowo traktować obserwowalne dane wejściowe, decyzje, wywołania narzędzi i rezultaty.

To rozróżnienie ma znaczenie podczas incydentu. Śledczy potrzebują wystarczających dowodów, aby odtworzyć sekwencję. Nie potrzebują niepopartej dowodami narracji, która rzekomo ujawnia dokładnie, co model „myślał”.

Dzienniki muszą być odporne na modyfikację. Agent mający uprawnienia do zmiany systemu nie powinien móc usuwać jedynego dowodu opisującego tę zmianę. Rekordy bezpieczeństwa wymagają odrębnych kontroli dostępu, zasad retencji i ochrony integralności.

Obserwowalność wymaga również korelacji między platformami. Jeden przepływ pracy może rozpocząć się w aplikacji do współpracy, wywołać hostowany model, odpytać bazę danych w chmurze, wywołać zewnętrzne API i zaktualizować platformę klientów.

Każda usługa może utworzyć technicznie poprawny dziennik, podczas gdy cała historia pozostaje niewidoczna. Wspólny identyfikator transakcji powinien łączyć pierwotne żądanie z każdym delegowanym krokiem.

Zespoły muszą zdecydować, co wywołuje interwencję. Nieudane logowanie łatwo sklasyfikować. Zmiana sekwencji narzędzi przez agenta może być niewinną adaptacją albo wczesnym dowodem manipulacji.

Polityka może zacząć się od granic o wysokiej pewności. Systemy bezpieczeństwa mogą blokować niezatwierdzone miejsca docelowe, eskalację uprawnień, nadmierne pobieranie danych, zakazane transakcje i działania poza określonymi okresami pracy.

Analityka zachowań może następnie identyfikować bardziej subtelne odchylenia. Przykłady obejmują nietypowe kombinacje narzędzi, powtarzające się odrzucone żądania, szybkie wyliczanie danych, nowe wzorce delegowania lub dostęp niezwiązany z zadeklarowanym celem.

Przegląd człowieka powinien skupiać się na tych niejednoznacznych przypadkach. Wymaganie zatwierdzenia każdego działania niskiego ryzyka niszczy efektywność, którą obiecują agenci. Dopuszczenie każdego działania eliminuje rozliczalność wymaganą przez przedsiębiorstwa.

Organizacja potrzebuje zatem poziomów ryzyka. Odczyt publicznej strony internetowej różni się od eksportu danych klientów. Sporządzenie wiadomości różni się od jej wysłania. Przygotowanie zmiany w kodzie różni się od jej wdrożenia.

Każdy poziom powinien określać autonomię, zatwierdzanie, rejestrowanie, testowanie i wymagania dotyczące wycofania zmian. Klasyfikacja należy do procesu biznesowego, a nie wyłącznie do modelu.

Na szczególną uwagę zasługuje możliwość wycofania zmian. Niektóre działania można odwrócić, a innych nie. Usunięty plik środowiska testowego może być możliwy do odzyskania. Ujawniony sekret, zrealizowana płatność lub publiczna wiadomość mogą wywołać trwałe konsekwencje.

Plany reagowania na incydenty muszą obejmować powstrzymywanie agentów. Zespoły potrzebują szybkiej metody zawieszenia tożsamości, unieważnienia tymczasowych poświadczeń, odizolowania dotkniętej pamięci, zachowania rekordów i zidentyfikowania zależnych agentów.

Branża zaczyna formalizować sposób zgłaszania incydentów z udziałem agentów. Proponowany framework SAFE obejmowałby nieautoryzowany dostęp, naruszenia poufnych informacji, kontynuowane próby sondowania oraz niektóre sytuacje bliskie incydentowi.

Zgodnie z opublikowaną propozycją istotne dowody mogą obejmować prompty, ślady, wywołania narzędzi, tożsamości, uprawnienia i poświadczenia. Inicjatywa pozostaje propozycją, lecz jej lista dowodów ilustruje, jak wiele kontekstu wymaga incydent z udziałem agenta.

Wspólne raportowanie mogłoby ujawnić powtarzające się wzorce awarii, których pojedyncze firmy nie mogą dostrzec. Mogłoby także stworzyć trudne pytania dotyczące poufności, odpowiedzialności i porównywalnych miar dotkliwości.

Nagłówek z Google News ostatecznie sprawdza, czy firmy potrafią odpowiedzieć na podstawowe pytania kryminalistyczne. Który agent działał, kto go autoryzował, jakie informacje go ukształtowały, która polityka dopuściła działanie i co zmieniło się później?

Jeśli te odpowiedzi wymagają ręcznej rekonstrukcji prowadzonej przez kilka zespołów, fundament bezpieczeństwa nie jest gotowy na rutynową autonomię agentów.

Co Liderzy Bezpieczeństwa Powinni Obserwować Dalej

Kolejny etap będzie mierzony egzekwowalnymi kontrolami i zgłoszonymi awariami, a nie liczbą dostawców dodających etykietę agenta.

Pierwszym sygnałem jest wdrażanie odrębnych tożsamości agentów. Microsoft, Cisco i inni dostawcy platform wprowadzają funkcje tożsamości skoncentrowane na agentach. Przedsiębiorstwa powinny obserwować, czy klienci wdrażają je w agentach zewnętrznych i własnych, a nie tylko w środowisku jednego dostawcy.

Szeroki zasięg tożsamości wzmocniłby argument, że istniejące programy zarządzania tożsamością mogą ewoluować wokół podmiotów nieludzkich. Ograniczony zasięg pozostawiłby organizacje z oddzielnymi rejestrami agentów i niespójnym egzekwowaniem zasad.

Drugim sygnałem jest polityka czasu działania w protokołach narzędziowych. MCP i inne standardy połączeń ułatwiają budowanie integracji agentów. Postęp w bezpieczeństwie zależy od tego, czy bramki mogą konsekwentnie uwierzytelniać agentów, zawężać uprawnienia, analizować kontekst i rejestrować działania.

Protokół może zostać szeroko przyjęty, zanim jego mechanizmy zarządzania dojrzeją. Zespoły bezpieczeństwa powinny mierzyć odrzucone działania, tymczasowe poświadczenia, wyjątki od polityk i niezarejestrowane połączenia narzędziowe, zamiast liczyć skonfigurowane serwery.

Trzecim sygnałem jest wiarygodne ujawnianie incydentów. Publiczne raportowanie powinno ujawnić, czy awarie dotyczą prompt injection, nadmiernych uprawnień, błędnego delegowania, zatrutej pamięci, niebezpiecznych narzędzi czy braku zatwierdzenia przez człowieka.

Rekordy incydentów pomogą przedsiębiorstwom odróżnić powszechne awarie operacyjne od spekulatywnych zagrożeń. Sprawdzą również, czy obecne rejestrowanie gromadzi wystarczająco dużo dowodów do znaczącej analizy.

Liderzy bezpieczeństwa nie powinni czekać na nagłówek opisujący poważną stratę. Mogą już teraz oceniać gotowość za pomocą kontrolowanych ćwiczeń.

Nadaj agentowi testowemu uzasadniony cel biznesowy i umieść sprzeczne instrukcje w pobranej treści. Obserwuj, czy podąża za treścią, żąda szerszego dostępu, próbuje użyć innego narzędzia, czy zatrzymuje się do przeglądu.

Następnie unieważnij jego tożsamość w trakcie przepływu pracy. Potwierdź, że każde narzędzie odrzuca późniejsze żądania i że zależne agenty otrzymują tę zmianę. Unieważnienie skuteczne tylko na jednej platformie tworzy fałszywe poczucie bezpieczeństwa.

Przeprowadź drugie ćwiczenie skoncentrowane na odpowiedzialności właścicielskiej. Zapytaj, kto zatwierdza zwiększenie uprawnień, kto otrzymuje alert, kto może zawiesić agenta i kto decyduje, czy wraca on do działania.

Odpowiedzi powinny wskazywać nazwane role, a nie działy. „Bezpieczeństwo i IT” nie stanowią rozliczalnej procedury operacyjnej.

Organizacje powinny także mierzyć, ilu agentów pozostaje nieznanych. Ustalenia z procesu wykrywania, osierocone tożsamości, współdzielone poświadczenia i niezatwierdzone punkty końcowe narzędzi ujawniają luki w kontroli wyraźniej niż komunikaty o wdrożeniach.

Pracownicy umysłowi również odgrywają rolę w tym procesie. Powinni wiedzieć, kiedy agent działa z ich upoważnienia i które działania wymagają potwierdzenia. Delegowanie nie powinno ukrywać odpowiedzialności za zautomatyzowanym interfejsem.

Programiści potrzebują zatwierdzonych wzorców dotyczących tożsamości, dostępu do narzędzi, sekretów, logów, testowania i pamięci. Wymaganie, by każdy zespół sam wymyślał te podstawy, gwarantuje niespójną ochronę.

Nabywcy korporacyjni powinni pytać dostawców, jak tożsamości agentów są mapowane na ludzkich sponsorów, jak wygasają uprawnienia i jak działania pojawiają się w istniejących systemach bezpieczeństwa. Powinni też testować, czy logi pozostają dostępne po wyłączeniu agenta.

Najważniejsza lekcja płynąca z Google News nie jest taka, że przedsiębiorstwa muszą przestać używać agentów. Chodzi o to, że autonomia powinna wynikać ze zweryfikowanej dojrzałości mechanizmów kontroli.

Organizacja gotowa na agentów potrafi zidentyfikować każdego z nich, ograniczyć każde wywołanie narzędzia, zachować łańcuchy delegowania, wykrywać zmiany zachowania i szybko odbierać uprawnienia. Potrafi także wyjaśnić, kto pozostaje odpowiedzialny, gdy automatyzacja zawiedzie.

Organizacja nieprzygotowana widzi jedynie pomocny interfejs. Za nim współdzielone poświadczenia, szerokie uprawnienia, dane o mieszanym poziomie zaufania i rozproszone logi tworzą strukturę uprawnień, nad którą nikt nie sprawuje pełnej kontroli.

Najbliższe od jednego do trzech miesięcy powinny wyjaśnić, czy platformy tożsamości, bramy środowiska wykonawczego i działania na rzecz transparentności zbliżają się do wspólnych praktyk. Taka konwergencja ułatwiłaby nadzór nad agentami w mieszanych środowiskach korporacyjnych.

Do tego czasu każda organizacja powinna traktować autonomię agentów jako dostęp, na który trzeba zasłużyć. Zacznij od wąskich zadań, odwracalnych działań, krótkotrwałych uprawnień i obserwowalnych przepływów pracy. Rozszerzaj uprawnienia tylko wtedy, gdy dowody pokazują, że mechanizmy kontroli działają.

Pytanie dla czytelników jest pilne: gdyby jeden z waszych agentów jutro dokonał nieautoryzowanej zmiany, czy wasz zespół potrafiłby go zidentyfikować, zatrzymać i odtworzyć pełny łańcuch zdarzeń? Jeśli nie, potraktujcie najnowsze ostrzeżenie z Google News jako impuls do zinwentaryzowania agentów, wyznaczenia odpowiedzialnych właścicieli i przetestowania unieważniania uprawnień przed przyznaniem większej autonomii.