Agenci AI zamieniają dostęp w przedsiębiorstwie w ryzyko wycieku danych od wewnątrz

Google News przedstawia bardziej wyraziste ostrzeżenie dotyczące agentów AI: największe zagrożenie dla danych przedsiębiorstwa może już dysponować ważnymi poświadczeniami i zatwierdzonym dostępem.

Materiał Dark Reading nie opisuje jednego odosobnionego naruszenia. Pokazuje szersze odwrócenie zasad bezpieczeństwa. Firmy zapewniają agentom wewnętrzny dostęp, aby mogli automatyzować użyteczne zadania. Ten sam dostęp pozwala błędom, wrogim instrukcjom lub nadmiernym uprawnieniom przenosić wrażliwe informacje między zaufanymi systemami.

Tradycyjne mechanizmy obronne koncentrują się na utrzymywaniu intruzów poza siecią. Agenci AI komplikują ten model, ponieważ często działają wewnątrz zatwierdzonych aplikacji, wykorzystując legalne tożsamości i autoryzowane narzędzia. Główny konflikt dotyczy dziś produktywności i kontroli, a nie obrońców i oczywistego zewnętrznego atakującego.

Czytelnicy Google News, którzy trafiają na tę historię, powinni traktować ją jako ostrzeżenie dotyczące zarządzania dostępem. Agent nie musi pokonywać granicy bezpieczeństwa, gdy przedsiębiorstwo już połączyło go z pocztą e-mail, dokumentami, bazami danych, przeglądarkami i zewnętrznymi API.

Co faktycznie sygnalizuje nagłówek Google News

Agenci AI zamieniają zwykłe błędy w dostępie w zautomatyzowane łańcuchy działań, które mogą przekraczać granice kilku systemów przedsiębiorstwa.

Agent AI to oprogramowanie wykorzystujące model do planowania zadań, wybierania narzędzi i działania przy ograniczonym udziale człowieka. W przeciwieństwie do chatbota nie zwraca jedynie tekstu. Może pobierać rekordy, wysyłać wiadomości, edytować pliki, wywoływać API lub uruchamiać przepływy pracy.

To rozróżnienie zmienia problem bezpieczeństwa. Chatbot może ujawnić informacje umieszczone w jego kontekście. Agent może wyszukać więcej informacji, połączyć je, przekształcić i przenieść w inne miejsce.

Podstawowa obawa widoczna w nagłówku Google News nie polega na tym, że agenci zawierają wszystkie sekrety firmy. Informacje przedsiębiorstwa zwykle pozostają w repozytoriach, takich jak pamięć masowa w chmurze, systemy obsługi klientów, platformy kodowe i narzędzia współpracy.

Ryzyko wynika z połączeń między tymi repozytoriami a agentem. Materiał Dark Reading dotyczący wspólnej odpowiedzialności podkreśla, że przedsiębiorstwa nadal odpowiadają za ochronę danych i użytkowników połączonych z usługami agentowymi.

Zarządzanie tą odpowiedzialnością staje się trudniejsze, gdy jeden agent dziedziczy dostęp użytkownika, a inny korzysta z ogólnego konta usługowego. Oba rozwiązania mogą tworzyć nieoczekiwane ścieżki ekspozycji.

Agent działający w zakresie użytkownika może przeszukiwać wszystko, do czego pracownik ma dostęp, w tym zapomniane współdzielone foldery. Tożsamość usługowa może dysponować szerszymi uprawnieniami, niż potrzebuje jakikolwiek pojedynczy użytkownik.

Agent może także zestawiać fakty, które osobno wydają się nieszkodliwe. Lista klientów, wewnętrzna mapa drogowa i katalog pracowników mogą po agregacji stać się wysoce wrażliwe.

To istotne odwrócenie sytuacji. Wyszukiwanie w przedsiębiorstwie kiedyś pomagało pracownikom odnajdywać dokumenty, do których już mieli uprawnienia do odczytu. Agent może teraz odnaleźć te dokumenty i podjąć dalsze działania bez odrębnej decyzji człowieka.

Zagrożenie nie wymaga złośliwych intencji. Nieprecyzyjna prośba może wywołać zbyt szerokie wyszukiwanie. Niewiarygodny plan może wybrać niewłaściwego odbiorcę lub miejsce docelowe.

Przejęty dokument może także przekierować przepływ pracy. Pośredni prompt injection występuje, gdy wrogie instrukcje są ukryte w treści czytanej przez agenta, takiej jak e-mail lub strona internetowa.

Model może zinterpretować te instrukcje jako część swojego zadania. Jeśli ten sam agent ma dostęp do prywatnych danych i może komunikować się na zewnątrz, atakujący połączył rozpoznanie z eksfiltracją.

Dlatego ta historia ma znaczenie wykraczające poza jeden nagłówek. Agent znajduje się na styku tożsamości, danych, aplikacji i działań. Każde połączenie rozszerza zasięg pojedynczej awarii.

Natychmiastowa zmiana ma więc charakter architektoniczny. Firmy nie przyznają już oprogramowaniu wyłącznie dostępu do danych. Przyznają systemom swobodę decydowania o sposobie wykorzystania tego dostępu.

Ścieżka ekspozycji od wewnątrz na zewnątrz

Najgroźniejszy przepływ pracy agenta łączy niezaufaną treść, wrażliwe dane i działanie wychodzące pod jedną tożsamością.

Rozważmy agenta, któremu zlecono przygotowanie przeglądu konta. Odczytuje dane klientów, przeszukuje wewnętrzne wiadomości, sprawdza ostatnie zgłoszenia wsparcia i tworzy podsumowanie.

Każdy krok wydaje się uzasadniony. Ścieżka ekspozycji pojawia się, gdy jeden z pobranych elementów zawiera instrukcje przeznaczone dla modelu, a nie dla pracownika.

Złośliwe zgłoszenie do wsparcia może nakazać agentowi zignorowanie pierwotnego zadania. Może skierować system do odnalezienia dodatkowych rekordów i przesłania ich za pomocą dozwolonego żądania internetowego.

Atakujący nigdy nie loguje się do firmy. Agent odczytuje treść atakującego po tym, jak trafia ona do systemu zwykłym kanałem biznesowym.

Ten wzorzec ataku wykorzystuje granicę, której modele językowe nie potrafią niezawodnie egzekwować samodzielnie. Ten sam kontekst może zawierać instrukcje użytkownika, pobrane fakty, wskazówki systemowe i tekst kontrolowany przez atakującego.

Modele przetwarzają te elementy jako język. Etykiety i prompty mogą pomagać, ale nie tworzą deterministycznej bariery autoryzacyjnej.

Narzędzia agenta sprawiają, że ta słabość ma realne konsekwencje. Zatruta instrukcja ma niewielką wartość, gdy model nie może uzyskać dostępu do prywatnych danych ani działać poza sesją.

Ryzyko rośnie, gdy deweloperzy udostępniają szerokie narzędzia dla wygody. Uniwersalna przeglądarka, nieograniczony konektor bazy danych, powłoka lub funkcja komunikacyjna mogą obsługiwać wiele przepływów pracy. Mogą także wspierać działania, których pierwotna funkcja nigdy nie wymagała.

OWASP określa ten problem jako nadmierną sprawczość. Jego przykłady obejmują zadania tylko do odczytu, obsługiwane przez rozszerzenia, które mogą także modyfikować, usuwać lub wysyłać informacje.

Uprawnienia tworzą kolejną warstwę. Konektor przeznaczony do odczytu jednej tabeli produktów nie powinien otrzymywać dostępu do zapisu ani wglądu w niepowiązane rekordy.

Ogólne uprzywilejowane konta są szczególnie ryzykowne. Mogą zacierać granicę między tym, o co może poprosić pojedynczy użytkownik, a tym, co może pobrać infrastruktura agenta.

Pamięć rozszerza okno ekspozycji. Pamięć agenta przechowuje fakty lub kontekst do późniejszego wykorzystania, co pomaga zachować ciągłość między sesjami.

Trwała pamięć może jednak zachowywać zatrute instrukcje, poufne materiały lub błędne założenie bezpieczeństwa. Problem wprowadzony podczas jednego zadania może później wpłynąć na innego użytkownika lub przepływ pracy.

Logi mogą stać się drugim repozytorium danych. Szczegółowe ślady pomagają zespołom badać decyzje agenta, lecz mogą zawierać prompty, pobrane dokumenty, poświadczenia lub dane osobowe.

Zespół może więc ograniczyć jedno ryzyko, tworząc inne. Słabo chronione dane obserwowalności stają się cennym celem, ponieważ rejestrują to, co agent zobaczył i próbował zrobić.

Systemy wieloagentowe dodają kolejne transfery. Jeden agent może zbierać informacje, drugi je analizować, a trzeci przekazywać wynik.

Każde przekazanie wymaga uwierzytelnionych tożsamości, ograniczonych uprawnień i zweryfikowanych danych. W przeciwnym razie przejęty komponent może przekazywać szkodliwe instrukcje dalej, sprawiając wrażenie zaufanego ruchu wewnętrznego.

Zewnętrzny atakujący pozostaje istotny, ale końcowe działanie następuje z wnętrza przedsiębiorstwa. Dociera ono przez zatwierdzoną tożsamość i podąża ścieżką aplikacyjną, którą obrońcy mogą uznać za normalną.

Na tym polega problem od wewnątrz na zewnątrz. Awaria bezpieczeństwa zaczyna się od legalnego dostępu, przekracza wewnętrzne granice danych i wychodzi przez dozwolone narzędzie.

Dlaczego zespoły ds. tożsamości odczuwają pierwszą presję

Agenci AI zachowują się jak użytkownicy, uwierzytelniają się jak usługi i działają szybciej niż procesy zarządzania zaprojektowane dla którejkolwiek z tych grup.

Systemy dostępu dla ludzi zakładają rozpoznawalnego pracownika, rolę zawodową, przełożonego i cykl zatrudnienia. Konta usługowe zwykle obsługują przewidywalne oprogramowanie o stabilnych funkcjach.

Agenci nie pasują do żadnej z tych kategorii. Ich działania zmieniają się wraz z promptami, pobranym kontekstem, dostępnymi narzędziami, wersjami modeli i wynikami pośrednimi.

Agent może uwierzytelniać się tokenem API, działać w imieniu pracownika i delegować część zadania innemu agentowi. Tworzy to kilka tożsamości w ramach jednego przepływu pracy.

Zespoły bezpieczeństwa muszą wiedzieć, kto zainicjował żądanie. Muszą także wiedzieć, który agent działał, jakich poświadczeń użył i czyja autoryzacja miała zastosowanie.

Końcowe działanie powinno pozostać przypisywalne do tych tożsamości. Bez tego łańcucha osoby reagujące na incydenty mogą zobaczyć autoryzowane wywołanie API, nie rozumiejąc stojącego za nim rozumowania ani intencji użytkownika.

NIST dostrzegł tę lukę w swoim projekcie dotyczącym tożsamości agentów z 2026 roku. Proponowane prace koncentrują się na identyfikacji, autoryzacji, audycie i niezaprzeczalności w odniesieniu do agentów programowych.

Wymagania te przypominają ugruntowane praktyki zarządzania tożsamością, lecz agenci zmieniają tempo działania. Kwartalny przegląd dostępu nie jest w stanie ograniczyć uprawnień, które stają się zbędne kilka minut po zakończeniu zadania.

Stały dostęp tworzy problem kumulacji. Zespoły przyznają uprawnienie na potrzeby pilotażu, zachowują je dla wygody, a później łączą agenta z kolejnym systemem.

Efektywny zasięg agenta rośnie, nawet jeśli żaden administrator celowo nie tworzy jednego uprzywilejowanego superagenta. Oddzielne uprawnienia mogą połączyć się w niebezpieczną ścieżkę.

Na przykład dostęp do odczytu bazy danych może sam w sobie wyglądać bezpiecznie. Zewnętrzny dostęp do sieci może również wspierać uzasadnione zadanie badawcze.

Razem te możliwości mogą pozwolić na opuszczenie organizacji przez wrażliwe rekordy. Zespoły bezpieczeństwa często nazywają to połączenie toksycznym, ponieważ całkowite ryzyko przekracza ryzyko każdego uprawnienia rozpatrywanego osobno.

Presja spada także na właścicieli aplikacji. Muszą udostępniać węższe funkcje zamiast przekazywać agentom ogólne interfejsy administracyjne.

Agent planujący spotkania może potrzebować tworzyć blokady w kalendarzu. Niekoniecznie musi mieć uprawnienia do usuwania każdego wydarzenia lub odczytywania prywatnych notatek każdego uczestnika.

Właściciele danych stają przed powiązaną decyzją. Muszą ustalić, czy istniejące uprawnienia użytkowników nadal są odpowiednie, gdy oprogramowanie może wyszukiwać, podsumowywać i redystrybuować informacje z szybkością maszyny.

Pracownik, który technicznie może otworzyć tysiące dokumentów, rzadko przejrzy je wszystkie. Agent może szybko przemierzyć ten zakres dostępu i usunąć praktyczne tarcie, które wcześniej ograniczało ekspozycję.

Nie oznacza to, że każdy agent zasługuje na mniejszy dostęp niż jego użytkownik. Oznacza to, że autoryzacja musi uwzględniać żądane zadanie, miejsce docelowe, wrażliwość danych i proponowane działanie.

Statyczna kontrola dostępu oparta na rolach nie jest w stanie wyrazić wszystkich tych warunków. Przedsiębiorstwa potrzebują kontroli polityk w całym przepływie pracy, zwłaszcza przed pobraniem wrażliwych danych lub komunikacją zewnętrzną.

Google News nagłaśnia problem bezpieczeństwa, który przekracza granice odpowiedzialności organizacyjnej. Zespoły ds. tożsamości kontrolują poświadczenia, zespoły aplikacyjne tworzą narzędzia, a zespoły ds. danych klasyfikują informacje.

Liderzy programów AI często kontrolują tempo wdrożenia. Gdy te grupy działają niezależnie, agent dziedziczy ich luki i łączy je w jedną ścieżkę wykonania.

Obietnice produktywności zderzają się teraz z rzeczywistością bezpieczeństwa

Agenci stają się bardziej użyteczni, gdy zyskują kontekst i uprawnienia, lecz te same cechy zwiększają szkody wynikające z manipulacji lub błędu.

Użyteczny agent dla przedsiębiorstwa musi wiedzieć wystarczająco dużo, aby wykonywać rzeczywistą pracę. Potrzebuje dostępu do odpowiednich systemów, zrozumienia kontekstu użytkownika i uprawnień do wykonywania zatwierdzonych działań.

Usunięcie tych możliwości tworzy bezpieczniejszy, lecz ograniczony chatbot. Rozszerzenie ich tworzy zdolnego pracownika, którego błędy mogą mieć konsekwencje operacyjne.

To podstawowy kompromis opisany w materiale Dark Reading. Celem nie jest eliminowanie autonomii agentów. Chodzi o to, by autonomia nie przekształciła się w nieograniczone uprawnienia.

Kontrole bezpieczeństwa mogą ograniczać ryzyko, ale żadna z nich sama w sobie nie daje pełnej odpowiedzi. Filtry promptów mogą wykrywać znany złośliwy język, lecz atakujący mogą kodować lub maskować instrukcje.

Zabezpieczenia oparte na modelu napotykają głębsze ograniczenie. Wykorzystują systemy probabilistyczne do oceny innego systemu probabilistycznego, a podobne słabości mogą dotyczyć obu warstw.

Zatwierdzanie przez człowieka pomaga, gdy działanie jest rzadkie i ma istotne konsekwencje. Staje się mniej użyteczne, gdy pracownicy rutynowo zatwierdzają złożone żądania, których nie są w stanie sensownie przeanalizować.

Monity o zatwierdzenie również wymagają jasnych informacji. Użytkownik nie może ocenić działania opisanego wyłącznie jako „kontynuuj przepływ pracy” lub „użyj konektora”.

Interfejs powinien wskazywać zasób, operację, odbiorcę i kategorię danych. Powinien także wyjaśniać, dlaczego żądane działanie wynika z pierwotnego zadania.

Zasada najmniejszych uprawnień ogranicza potencjalne szkody. Jednak określenie minimalnych uprawnień dla zmieniającego się, wieloetapowego przepływu pracy jest trudniejsze niż ustalenie zakresu jednej tradycyjnej aplikacji.

Uprawnienia mogą być właściwe na jednym etapie, a nadmierne na kolejnym. Tymczasowe poświadczenia powiązane z zadaniem stanowią lepszy model niż stały dostęp.

Monitorowanie w czasie wykonywania zapewnia kolejną warstwę. Może wykrywać nietypową skalę pobierania danych, nowe miejsca docelowe, nietypowe kombinacje narzędzi lub zachowanie odbiegające od bazowego profilu agenta.

Jednak wykrywanie anomalii wymaga historii, kontekstu i wiarygodnego przypisania działań. Nowy agent może nie mieć stabilnego punktu odniesienia, podczas gdy legalne przepływy pracy mogą znacznie się różnić.

Dark Reading poinformował o badaniu Gartnera sugerującym, że około 90% obecnych agentów ma niską autonomię. Pozostałe 10% dysponuje szerszym zestawem narzędzi, dostępem do danych i swobodą działania w czasie wykonywania.

Systemy o wysokiej autonomii zasługują na ukierunkowane kontrole, ponieważ ich tryby awarii obejmują więcej niż niepoprawny tekst. Mogą zmieniać systemy produkcyjne lub przenosić poufne dane.

Ten sam raport przywołał badanie dostawcy przeprowadzone wśród ponad 400 liderów technologii i bezpieczeństwa. Wykazało ono, że 84% respondentów stwierdziło, iż ich agenci mogli uzyskiwać dostęp do wrażliwych danych.

Kolejne 67% uważało, że agenci uzyskali dostęp do informacji, do których nie powinni byli dotrzeć. Dane te pochodziły z badania dostawcy rozwiązań bezpieczeństwa, więc wskazują na obawy, a nie uniwersalny wskaźnik incydentów.

Mimo to ustalenia są zgodne z ryzykiem architektonicznym. Przedsiębiorstwa często podłączają agentów, zanim uzyskają pełny spis tożsamości, narzędzi, ścieżek danych i odziedziczonych uprawnień.

Sceptyczne spojrzenie jest również konieczne. Nie każdy agent stanowi nową klasę katastrofalnego zagrożenia.

Wiele ryzyk przypomina znane problemy związane z kontami usługowymi, nadmiernymi uprawnieniami, niebezpiecznymi integracjami i słabym zarządzaniem danymi. Lepsze, sprawdzone kontrole mogą zapobiec dużej części z nich.

Zmienia się jednak ich połączenie. Agenci dynamicznie wybierają działania i przetwarzają język kontrolowany przez atakujących, podczas gdy tradycyjne integracje podążają z góry określonymi ścieżkami kodu.

Ta różnica sprawia, że zachowanie jest mniej przewidywalne. Zwiększa też znaczenie jakości autoryzacji w czasie wykonywania względem jakości początkowego logowania.

Kontrole ograniczające ekspozycję danych przez agentów

Przedsiębiorstwa potrzebują deterministycznych kontroli wokół modelu, ponieważ instrukcje wewnątrz modelu nie mogą egzekwować własnych uprawnień.

Pierwszym wymogiem jest inwentaryzacja agentów. Zespoły bezpieczeństwa nie mogą zarządzać tożsamościami, konektorami, narzędziami i magazynami danych, o których istnieniu nie wiedzą.

Inwentaryzacja powinna obejmować agentów działających produkcyjnie, wewnętrzne pilotaże, aplikacje dostawców oraz asystentów instalowanych przez pracowników. Powinna także uwzględniać porzucone projekty z poświadczeniami, które nadal pozostają aktywne.

Każdy agent potrzebuje odrębnej tożsamości. Współdzielone klucze API ukrywają przypisanie działań i utrudniają cofnięcie dostępu.

Tożsamość powinna być powiązana z właścicielem, zatwierdzonym przeznaczeniem, modelem, zestawem narzędzi i stanem cyklu życia. Przedsiębiorstwa powinny ją wyłączać po zakończeniu projektu lub odejściu jego właściciela.

Drugim wymogiem jest autoryzacja ograniczona zakresem zadania. Decyzje o dostępie powinny oceniać, o co poprosił użytkownik, i jakie działanie agent obecnie proponuje.

Żądanie podsumowania jednego folderu nie powinno autoryzować wyszukiwania we wszystkich repozytoriach. Żądanie przygotowania wiadomości e-mail nie powinno automatycznie autoryzować jej wysłania.

Trzecim wymogiem jest oddzielenie odczytu od działania. Agenci przetwarzający niezaufane treści nie powinni automatycznie kontrolować narzędzi o dużym wpływie.

Wytyczne OWASP dotyczące bezpieczeństwa agentów zalecają minimalny dostęp do narzędzi, izolowaną pamięć, przegląd przez człowieka ryzykownych działań oraz ustrukturyzowane monitorowanie.

Jedna z opcji architektonicznych wykorzystuje oddzielne komponenty. Ograniczony model odczytuje treści zewnętrzne, natomiast komponent uprzywilejowany otrzymuje wyłącznie zweryfikowane, ustrukturyzowane informacje.

Takie podejście nie eliminuje manipulacji, ale przerywa bezpośrednią ścieżkę od wrogiego tekstu do autoryzowanego działania.

Czwartym wymogiem jest egzekwowanie zasad uwzględniające dane. Narzędzie powinno oceniać klasyfikację żądanych informacji przed ich zwróceniem.

Punkt egzekwowania zasad powinien znajdować się poza modelem. Model może zaproponować zapytanie, lecz deterministyczna polityka powinna zdecydować, które rekordy i pola zostaną udostępnione.

Przedsiębiorstwa powinny również zachowywać kontekst bezpieczeństwa użytkownika. Agent działający w imieniu jednego pracownika nie powinien po cichu przełączać się na szerszą tożsamość usługową.

Tam, gdzie to możliwe, domyślny powinien być dostęp tylko do odczytu. Funkcje zapisu, usuwania, wysyłania, publikowania i płatności powinny wymagać węższych zakresów oraz silniejszych kontroli.

Piątym wymogiem jest kontrola miejsc docelowych. Organizacje często skupiają się na tym, co agent może odczytać, pomijając to, gdzie może wysłać wynik.

Domeny z listy dozwolonych, zatwierdzeni odbiorcy, inspekcja treści i ograniczone ścieżki sieciowe mogą ograniczać eksfiltrację. Te kontrole pozostają użyteczne nawet wtedy, gdy obrona przed promptami zawodzi.

Szóstym wymogiem jest chroniona pamięć. Wrażliwe materiały nie powinny trafiać do pamięci długoterminowej bez określonego celu, okresu przechowywania i granicy dostępu.

Pamięć powinna pozostawać odizolowana między użytkownikami i obszarami roboczymi. Zespoły powinny skanować zapisany kontekst pod kątem poświadczeń, danych osobowych i podejrzanych instrukcji.

Siódmym wymogiem jest rzeczywista obserwowalność. Dzienniki powinny rejestrować żądanie użytkownika, tożsamość agenta, wywołanie narzędzia, decyzję autoryzacyjną, kategorię danych i wynik działania.

Nie powinny kopiować każdego sekretu w postaci zwykłego tekstu. Redakcja danych i kontrolowany dostęp są niezbędne, ponieważ zapisy dochodzeń mogą stać się kolejną powierzchnią ekspozycji.

Wyszukiwalna baza wiedzy również potrzebuje jasnych uprawnień źródłowych i granic pobierania danych. Wygoda wyszukiwania nie powinna usuwać zasad dostępu na poziomie dokumentów.

Wreszcie zespoły muszą testować kompletny przepływ pracy. Same oceny modeli nie mogą ujawnić, co dzieje się, gdy współdziałają tożsamość, pobieranie danych, pamięć, narzędzia i treści zewnętrzne.

Zespoły red team powinny wykorzystywać zatrute dokumenty, mylące e-maile, nadmierne żądania, testy pamięci między użytkownikami i nieautoryzowane miejsca docelowe. Powinny powtarzać testy po każdej zmianie modelu, promptu, konektora lub polityki.

Trzy sygnały, które warto obserwować po tym ostrzeżeniu Google News

Kolejnym testem będzie to, czy przedsiębiorstwa zastąpią szeroki, stały dostęp agentów widocznymi, tymczasowymi i egzekwowalnymi uprawnieniami.

Pierwszym sygnałem jest wdrażanie tożsamości specyficznych dla agentów. Microsoft i inni dostawcy platform dodają sposoby rejestrowania agentów, przypisywania uprawnień i rejestrowania ich zachowania.

Sama rejestracja nie wystarczy. Istotna zmiana nastąpi, gdy firmy będą mogły prześledzić każde działanie przez agenta, użytkownika inicjującego, poświadczenie i delegowaną usługę.

Jeśli te zapisy pojawią się w standardowych systemach zarządzania tożsamością i reagowania na incydenty, ryzyko od wewnątrz stanie się łatwiejsze do zbadania. Dalsze poleganie na współdzielonych tokenach osłabiłoby ten postęp.

Drugim sygnałem jest egzekwowanie zasad w czasie wykonywania. Zespoły bezpieczeństwa potrzebują kontroli, które mogą odrzucić pojedyncze wywołanie narzędzia bez wyłączania całego agenta.

Warto obserwować poświadczenia powiązane z zadaniem, krótkie okna autoryzacji, polityki uwzględniające dane oraz monity o zatwierdzenie wskazujące proponowaną operację. Te możliwości wzmocniłyby argument, że autonomia może współistnieć z kontrolą.

Marketingowe twierdzenia o „bezpiecznych agentach” same w sobie stanowią niewielki dowód. Nabywcy powinni pytać, czy autoryzacja odbywa się poza modelem i czy polityki mają zastosowanie do każdego żądania w dalszym łańcuchu.

Trzecim sygnałem są publiczne dowody incydentów. Rynkowi wciąż brakuje spójnego raportowania o awariach agentów, sytuacjach bliskich incydentom i ekspozycji danych.

Użyteczne ujawnienia powinny opisywać wejście inicjujące, dostępne narzędzia, skuteczne uprawnienia, nieskuteczne zabezpieczenia i końcowy wpływ. Zagregowane twierdzenia bez tych szczegółów nie mogą pokazać, czy nowe kontrole działają.

Regulatorzy i grupy opracowujące standardy również mają tu znaczenie. Prace NIST nad standardami dla agentów mogą zapewnić przedsiębiorstwom wspólny język dotyczący tożsamości, autoryzacji i audytowalności.

Google News będzie nadal pokazywać ostrzeżenia, gdy dostawcy umieszczają agentów w coraz większej liczbie przepływów pracy. Czytelnicy powinni patrzeć poza dramatyczne nagłówki i analizować ścieżkę dostępu stojącą za każdym zdarzeniem.

Przed zaufaniem jakiemukolwiek agentowi przedsiębiorstwa zadaj trzy pytania: Co może odczytać, co może zrobić i dokąd może wysłać wynik?

Jeśli organizacja nie potrafi odpowiedzieć na wszystkie trzy pytania na podstawie egzekwowalnej polityki i audytowalnych zapisów, agent nie jest jedynie asystentem. Jest nieograniczoną wewnętrzną tożsamością czekającą na niewłaściwą instrukcję.