Agenci AI poszerzają obszar rażenia zagrożeń w bezpieczeństwie przedsiębiorstw

Google News zwróciło w tym tygodniu uwagę na wyraźny konflikt w przedsiębiorstwach: agenci AI zyskują coraz szersze uprawnienia, podczas gdy mechanizmy kontroli wokół nich pozostają niekompletne. Nagłówek BankInfoSecurity ujmuje tę obawę w kategoriach operacyjnych. Agent nie tworzy już wyłącznie tekstu. Może pobierać rekordy, wywoływać oprogramowanie, modyfikować pliki, wysyłać wiadomości i uruchamiać przepływy pracy.

To połączenie zmienia znaczenie awarii AI. Błąd chatbota zazwyczaj pozostaje w obrębie rozmowy. Błąd agenta może przeniknąć przez każde połączone narzędzie, poświadczenie, magazyn danych i system zależny. Jego obszar rażenia mierzy całkowitą szkodę osiągalną w wyniku jednego skompromitowanego lub błędnego działania.

Głównym sporem nie jest więc zdolność AI kontra starsze oprogramowanie. To autonomia agenta kontra ograniczanie ryzyka w przedsiębiorstwie. Firmy chcą, aby agenci realizowali wieloetapowe zadania z mniejszą liczbą przerw. Zespoły bezpieczeństwa potrzebują, by agenci działali w ramach wąskich tożsamości, ograniczonych uprawnień, zweryfikowanych narzędzi i obserwowalnych ścieżek zatwierdzania.

Anthropic opisał ten sam kompromis na podstawie własnych wdrożeń. Firma twierdzi, że dostęp wystarczający do zakłócenia działania usługi wewnętrznej stał się rutynowy, gdy agenci programistyczni stawali się bardziej użyteczni. Jej inżynierowie doszli jednak również do wniosku, że zabezpieczenia na poziomie modelu nie mogą zapewnić pełnej ochrony.

Ta zmiana ma znaczenie wykraczające poza jednego dostawcę. Lepsze rozumowanie może ograniczać oczywiste błędy, ale pomaga też agentowi znaleźć więcej dróg do realizacji celu. Przedsiębiorstwa muszą obecnie zabezpieczać systemy, które interpretują informacje, wybierają działania i dostosowują plany w trakcie wykonywania zadań.

Co ostrzeżenie Google News faktycznie zmienia

Granica bezpieczeństwa przesuwa się, gdy oprogramowanie może decydować, jak wykorzystać swój dostęp, a nie jedynie wykonywać zdefiniowane wcześniej polecenie.

Tradycyjna automatyzacja podąża zaprojektowaną ścieżką. Skrypt płacowy pobiera określone rekordy, wykonuje zdefiniowane obliczenia i zapisuje wyniki w znanych miejscach docelowych. Jego uprawnienia mogą być nadmierne, ale obrońcy nadal mogą odwzorować oczekiwaną sekwencję.

Agenci AI wprowadzają warstwę decyzyjną między żądaniem a działaniem. Interpretują cel, dzielą go na zadania, wybierają narzędzia, analizują wyniki i zmieniają plan. Ta elastyczność tworzy wartość, ale sprawia też, że zachowanie jest mniej przewidywalne.

NIST definiuje systemy agentowe jako oprogramowanie zdolne do planowania i podejmowania autonomicznych działań wpływających na rzeczywiste środowiska. W swoim styczniowym wezwaniu dotyczącym bezpieczeństwa agentów z 2026 roku wskazał trzy odrębne problemy. Agenci mogą przetwarzać wrogie dane, opierać się na zatrutych modelach lub szkodzić bezpieczeństwu bez udziału zewnętrznego atakującego.

Pierwszym problemem jest pośrednie wstrzyknięcie promptu. Atakujący ukrywa instrukcje w treści, którą agent później odczytuje, na przykład w e-mailu, na stronie internetowej, w dokumencie lub zgłoszeniu do wsparcia. Agent może uznać te wrogie instrukcje za część przydzielonego mu zadania.

Nie jest to to samo co bezpośrednie żądanie użytkownika, aby chatbot złamał zasadę. Osoba obsługująca agenta może nigdy nie zobaczyć złośliwej treści. Rutynowa prośba o podsumowanie wiadomości lub przegląd dokumentów może przenieść atak do kontekstu roboczego modelu.

Drugim problemem są uprawnienia. Wstrzyknięta instrukcja ma znaczenie tylko w takim stopniu, w jakim pozwala na to dostęp agenta. Agent badawczy z dostępem tylko do odczytu może zwrócić zmanipulowane informacje. Agent z uprawnieniami do e-maila, pamięci masowej w chmurze, wykonywania kodu i baz danych może ujawnić dane lub zmienić systemy.

Trzecim problemem jest trwałość. Niektórzy agenci utrzymują pamięć między zadaniami lub pobierają wcześniejszy kontekst z magazynu wiedzy. Zatrute informacje mogą wtedy przetrwać poza pierwotną sesją i wpływać na późniejsze decyzje.

Ryzyka te sprawiają, że treści przedsiębiorstwa stają się częścią powierzchni wykonawczej. Zespoły bezpieczeństwa tradycyjnie skanują dokumenty pod kątem złośliwego kodu. Muszą teraz rozważać, czy zwykły język w tych dokumentach może przekierować działanie uprawnionego aktora programowego.

Google News nie stworzyło tego problemu, ale jego agregacja ostrzeżenia BankInfoSecurity uwidacznia tę zmianę szerszej publiczności biznesowej. Bezpieczeństwo agentów wyszło poza wyspecjalizowaną debatę o bezpieczeństwie modeli. Obecnie należy do programów zarządzania tożsamością, bezpieczeństwa aplikacji, architektury chmurowej, zarządzania danymi i reagowania na incydenty.

Ten rozwój zmienia również zakres odpowiedzialności. Dostawca modelu może zwiększać odporność na złośliwe instrukcje, ale przedsiębiorstwo wdrażające model kontroluje uprawnienia i integracje. Twórcy konektorów kontrolują zachowanie narzędzi. Zespoły bezpieczeństwa definiują monitorowanie, a właściciele biznesowi decydują, jak dużą autonomię otrzymuje przepływ pracy.

Żaden pojedynczy uczestnik nie może samodzielnie ograniczyć tego ryzyka. Osiągalny system tworzy łańcuch, a najmniej ograniczone ogniwo determinuje znaczną część możliwych szkód.

Tożsamość agenta staje się punktem największej presji

Przedsiębiorstwo nie może egzekwować zasady najmniejszych uprawnień, jeśli nie potrafi zidentyfikować każdego agenta, jego właściciela i dokładnego zadania stojącego za jego dostępem.

BankInfoSecurity wcześniej zwracał uwagę na tę lukę tożsamościową, przytaczając komentarze CIO Entrust, Rishiego Kaushala. Twierdził on, że agenci potrzebują odrębnych tożsamości, zdefiniowanych uprawnień, ścieżek audytu i jasnej odpowiedzialności. Wymagania te brzmią znajomo, ponieważ rozszerzają ugruntowane praktyki zarządzania tożsamością na mniej przewidywalnego aktora.

Trudność polega na realizacji. Pracownik zazwyczaj ma stabilną tożsamość, dział, przełożonego i funkcję zawodową. Agent może zostać utworzony dla jednego projektu, skopiowany do innego przepływu pracy i połączony z dodatkowymi narzędziami w ciągu kilku godzin.

Niektóre wdrożenia pozwalają wielu agentom korzystać z jednego konta usługi. Inne dziedziczą uprawnienia pracownika, który je uruchamia. Oba projekty osłabiają możliwość przypisania działań, ponieważ dzienniki pokazują szerokie poświadczenie zamiast konkretnego agenta i delegowanego zadania.

Rozrost liczby agentów potęguje problem. Gartner przewidywał w kwietniu 2026 roku, że przeciętna globalna firma z listy Fortune 500 będzie korzystać z ponad 150 000 agentów do 2028 roku. Firma zestawiła tę prognozę z liczbą mniejszą niż 15 agentów w 2025 roku.

Prognoza nie jest zmierzoną liczbą wdrożeń, a adopcja może pozostać poniżej oczekiwań. Mimo to ilustruje wyzwanie związane z zarządzaniem. Ręczne przeglądy zaprojektowane dla niewielkiej liczby aplikacji nie są w stanie śledzić tysięcy dynamicznych tożsamości programowych.

Każdy agent powinien więc mieć unikalną, weryfikowalną tożsamość od utworzenia aż do wycofania. Ten zapis powinien identyfikować właściciela biznesowego, właściciela technicznego, zatwierdzone narzędzia, zakres danych, środowisko operacyjne i maksymalny poziom działania.

Użyteczna tożsamość musi również zachowywać kontekst delegacji. Zespoły bezpieczeństwa muszą wiedzieć, która osoba lub usługa przydzieliła zadanie. Potrzebują informacji o żądanym celu, bieżącym etapie przepływu pracy i warunkach przypisanych do uprawnień.

Statyczna kontrola dostępu oparta na rolach nie odpowie na każde pytanie. Agent zakupowy może zasadnie odczytywać umowy podczas oceny dostawcy. Ten sam dostęp nie powinien pozostawać dostępny, gdy agent przygotowuje niezwiązane z tym podsumowanie kalendarza.

Autoryzacja związana z zadaniem zmniejsza tę lukę. Przyznaje agentowi konkretne możliwości w określonym celu i na ograniczony czas. Działania o dużym wpływie mogą wymagać odrębnego sprawdzenia tożsamości lub decyzji polityki w chwili wykonania.

Narodowe Centrum Doskonałości Cyberbezpieczeństwa NIST zaproponowało zastosowanie ugruntowanych standardów tożsamości wobec agentów programowych i AI. Jego dokument koncepcyjny dotyczący tożsamości koncentruje się na identyfikacji, autoryzacji i przypadkach użycia w przedsiębiorstwach, zamiast traktować agentów jako anonimowe procesy działające w tle.

Takie podejście wywiera presję na dostawców rozwiązań tożsamościowych, dostawców chmurowych i twórców aplikacji. Muszą oni przedstawiać agentów jako pełnoprawnych aktorów w produktach budowanych wokół ludzi i konwencjonalnych obciążeń.

Wywiera ono również presję na nabywców korporacyjnych. Zespół oceniający platformę agentową musi patrzeć dalej niż na jakość modelu. Kupujący muszą wiedzieć, czy każde wywołanie narzędzia zawiera możliwy do zidentyfikowania podmiot, cel zadania i możliwy do wyegzekwowania zakres uprawnień.

Dzienniki audytu muszą rejestrować więcej niż prompty i odpowiedzi. Powinny wskazywać, jakie dane agent pobrał, których narzędzi użył, co każde narzędzie zmieniło i które zatwierdzenie autoryzowało działanie.

Dowody te mają znaczenie podczas incydentu. Jeśli śledczy wiedzą jedynie, że agent przetworzył złośliwy dokument, nadal nie mogą zmierzyć skali narażenia. Muszą odtworzyć każdy dotknięty rekord, uzyskany sekret, wysłaną wiadomość i system zmieniony później.

System wewnętrznej wiedzy z funkcją wyszukiwania może pomóc pracownikom zachowywać decyzje i kontekst źródłowy. Jednak każda baza wiedzy AI połączona z agentem również potrzebuje jasnych granic zaufania. Pobierana treść pozostaje danymi, a nie zaufanym autorytetem.

Problem tożsamości jest więc większy niż uwierzytelnianie. Obejmuje pochodzenie, własność, delegację, cel i odpowiedzialność. Bez tych elementów przedsiębiorstwo wie, że automatyzacja zadziałała, lecz nie potrafi wiarygodnie wyjaśnić, kto ją autoryzował ani dlaczego.

Bardziej zdolni agenci tworzą trudniejszy kompromis bezpieczeństwa

Ten sam dostęp, który czyni agenta użytecznym, określa również, jak daleko może dotrzeć błąd, przejęcie kontroli lub skompromitowane narzędzie.

Odizolowany model nie może wysyłać pieniędzy ani zmieniać środowiska produkcyjnego. Zyskuje wartość operacyjną dopiero wtedy, gdy programiści połączą go z bazami danych, przeglądarkami, repozytoriami kodu, systemami komunikacji i aplikacjami biznesowymi.

Każde połączenie rozszerza osiągalny graf. Graf ten obejmuje bezpośrednie narzędzia, dziedziczone poświadczenia, pobrane dane, miejsca docelowe w sieci, współdzieloną pamięć i innych agentów. Obszar rażenia to część tego grafu dostępna po awarii jednego mechanizmu kontroli.

Oczywistą odpowiedzią jest poproszenie człowieka o zgodę przed każdym wrażliwym działaniem. Częste monity mogą jednak stać się czysto ceremonialne. Anthropic podał, że użytkownicy Claude Code zatwierdzili około 93% żądań uprawnień w swoich danych telemetrycznych.

Liczba ta pochodzi z danych własnego produktu Anthropic, więc nie reprezentuje każdego przedsiębiorstwa. Mimo to ujawnia zmęczenie zatwierdzaniem. Gdy oprogramowanie wielokrotnie przerywa użytkownikom pracę, wiele osób zatwierdza żądania bez uważnego sprawdzenia polecenia lub miejsca docelowego.

Analiza ograniczania ryzyka Anthropic rozróżnia nadzór behawioralny od ograniczeń środowiskowych. Mechanizmy behawioralne próbują wpływać na to, co agent wybiera. Kontrole środowiskowe ograniczają to, do czego może on dotrzeć, niezależnie od swojego wyboru.

To rozróżnienie ma kluczowe znaczenie. Prompty systemowe, klasyfikatory, szkolenie i oceny modeli mogą ograniczać szkodliwe zachowanie. Kontrole te są jednak probabilistyczne, co oznacza, że mogą nie wykryć nieznanych lub adaptacyjnych ataków.

Ograniczanie ryzyka ustanawia twardsze granice. Piaskownice ograniczają procesy i pliki. Maszyny wirtualne rozdzielają obciążenia. Kontrole ruchu wychodzącego ograniczają połączenia sieciowe na zewnątrz. Izolacja poświadczeń utrzymuje cenne sekrety poza środowiskiem.

Agent nie może ujawnić poświadczenia, którego nigdy nie otrzymał. Nie może zapisywać danych w produkcyjnej bazie danych przez połączenie tylko do odczytu. Nie może wysyłać danych na dowolny serwer, gdy ruch wychodzący podlega ścisłej liście dozwolonych adresów.

Prowadzi to do niewygodnego kompromisu. Najwęższe środowisko jest zazwyczaj najbezpieczniejsze, ale ogranicza też użyteczność. Agent bez trwałego obszaru roboczego, lokalnych plików lub dostępu do sieci nie może wykonać wielu wartościowych zadań przedsiębiorstwa.

Najsilniejszy projekt nie przyznaje szerokich uprawnień tylko dlatego, że model wydaje się zdolny. Dzieli pracę na odseparowane obszary. Każdy z nich udostępnia wyłącznie dane i działania wymagane na danym etapie.

Rozważmy agenta obsługi klienta. Musi on odczytać zgłoszenie i pobrać istotne informacje o koncie. Może przygotować odpowiedź, ale jej wysłanie stanowi odrębne uprawnienie.

Wydanie zwrotu wymaga kolejnego uprawnienia z określonym limitem. Zmiana właściciela konta lub eksport danych klientów powinny wymagać silniejszej weryfikacji. Agent nigdy nie powinien otrzymywać wszystkich tych możliwości za pośrednictwem jednego stałego poświadczenia.

Ta sama zasada dotyczy agentów programistycznych. Odczytywanie repozytorium różni się od modyfikowania gałęzi deweloperskiej. Scalanie kodu, dostęp do sekretów, zmienianie infrastruktury i wdrażanie na produkcję należą do odrębnych stref zaufania.

Istotna jest również odwracalność. Przedsiębiorstwa mogą automatycznie zezwalać na działania o niewielkim wpływie, gdy łatwo je skontrolować i cofnąć. Nieodwracalne zmiany zasługują na surowsze bramki, węższe limity i niezależne rejestry.

Te ramy ograniczają zależność od pozornych intencji agenta. Polityka bezpieczeństwa ocenia żądane działanie, tożsamość, zasób, cel i kontekst zadania. Kontrola nie musi rozstrzygać, czy model jest szczery.

framework ryzyk agentowych OWASP odzwierciedla ten szerszy model zagrożeń. Jego kategorie obejmują przejęcie celu, niewłaściwe użycie narzędzi, nadużycie uprawnień, zatruwanie pamięci, niezabezpieczoną komunikację i awarie kaskadowe.

Kategorie te pokazują, dlaczego konwencjonalne filtrowanie promptów nie może udźwignąć całego ciężaru. Doskonale czyste żądanie użytkownika nadal może uruchomić skompromitowane narzędzie. Bezpieczne narzędzie może zwrócić zatrutą treść. Prawidłowo działający agent może odziedziczyć nadmierne uprawnienia.

Kluczowe pytanie dotyczące bezpieczeństwa nie brzmi, czy agentowi można zaufać w oderwaniu od kontekstu. Chodzi o to, czy otaczająca go architektura pozostaje bezpieczna, gdy agent podejmie błędną decyzję.

Wstrzyknięcie promptu to dopiero pierwsza awaria w łańcuchu

Udane wstrzyknięcie promptu staje się incydentem przedsiębiorstwa, gdy nadmierny dostęp, słaba izolacja lub brak weryfikacji pozwalają instrukcji wywołać konsekwencje.

NIST opisuje przejęcie agenta jako niepowodzenie w oddzielaniu zaufanych instrukcji od niezaufanych danych. Obecne architektury agentowe często łączą oba te elementy w jednym kontekście modelu. Taki projekt pozwala treści w języku naturalnym wpływać na planowanie.

Atakujący może umieścić ukryte instrukcje na stronie internetowej odwiedzanej przez agenta badawczego. Złośliwy e-mail może polecić asystentowi przekazanie dokumentów. Zatruty plik repozytorium może skierować agenta programistycznego ku niebezpiecznemu poleceniu.

Agent nie musi mieć złośliwych intencji. Wystarczy, że zinterpretuje tekst atakującego jako istotne upoważnienie. Wynikowe wywołanie narzędzia może wyglądać poprawnie pod względem technicznym, ponieważ wykorzystuje zatwierdzony konektor i uwierzytelnione konto.

NIST przetestował ten wzorzec za pomocą AgentDojo, platformy badawczej z symulowanymi środowiskami pracy, podróży, Slacka i bankowości. Jego oceny przejęć obejmowały również scenariusze zdalnego wykonania kodu, eksfiltracji bazy danych i zautomatyzowanego phishingu.

Testy te pokazują ścieżki ataku, a nie uniwersalny wskaźnik naruszeń. Wyniki zależą od modelu, narzędzi, metody ataku, zadania i liczby prób. Przedsiębiorstwa powinny unikać przekształcania jednego wyniku benchmarku w gwarancję bezpieczeństwa.

Adaptacyjni atakujący sprawiają, że taka ostrożność jest konieczna. Obrona blokująca znane sformułowanie może przeoczyć parafrazę. Model odporny na pojedynczą próbę nadal może zawieść po wielokrotnych wariantach.

Głębszym problemem jest kompozycyjność. Agenci często wywołują inne usługi, które mają własne uprawnienia i podatności. Jedna zmanipulowana decyzja może zatem przejść przez kilka systemów bez przekroczenia oczywistego perymetru sieciowego.

Przepływy pracy wielu agentów tworzą kolejną warstwę. Agent planujący może delegować badania jednemu agentowi, a wykonanie drugiemu. Jeśli tożsamość i integralność wiadomości są słabe, skompromitowany uczestnik może fałszywie przedstawić instrukcje lub wyniki.

Pamięć może wydłużyć ten łańcuch w czasie. Fałszywa polityka, kontakt do dostawcy lub wyjątek bezpieczeństwa zapisane podczas jednego zadania mogą wpływać na późniejszą pracę. Pierwotne złośliwe źródło może zniknąć, zanim śledczy zauważą jego skutki.

Łańcuchy dostaw narzędzi dodają konwencjonalne ryzyko programistyczne. Konektor agenta może zawierać podatny kod, niebezpieczne ustawienia domyślne lub skompromitowaną zależność. Zabezpieczenia modelu nie naprawiają tych wad.

Te niepewności osłabiają twierdzenia, że jeden produkt bezpieczeństwa może rozwiązać ryzyko związane z agentami. Skanery promptów, bramy agentowe, platformy tożsamości, narzędzia obserwowalności i piaskownice rozwiązują po jednym fragmencie problemu. Żadne z nich nie kontroluje samodzielnie całego łańcucha.

Przedsiębiorstwa borykają się również z luką pomiarową. Raport zespołu red-team może stwierdzać, że wstrzyknięcie promptu się powiodło, nie dokumentując, do czego agent mógł następnie uzyskać dostęp. Taki wynik niewiele mówi o wpływie na działalność.

Przydatne testy powinny rejestrować zasięg po kompromitacji. Śledczy potrzebują informacji o wywołanych narzędziach, danych, do których uzyskano dostęp, ujawnionych poświadczeniach, skontaktowanych celach i zrealizowanych zmianach. Pozwala to przełożyć teoretyczny promień rażenia na obserwowalne konsekwencje.

Testy powinny również odróżniać działania podjęte od działań zakończonych powodzeniem. Model może zażądać zakazanego transferu, podczas gdy warstwa polityk go blokuje. To porażka behawioralna, ale zarazem pomyślny wynik powstrzymania zagrożenia.

Odwrotnie, agent może wygenerować pozornie nieszkodliwe żądanie, które przekracza granicę biznesową. Tradycyjne monitorowanie bezpieczeństwa może je zatwierdzić, ponieważ poświadczenie i wywołanie API wyglądają na prawidłowe.

W tym miejscu kontekst biznesowy staje się niezbędny. Zadanie analizy sprzedaży nie ma powodu zmieniać danych płacowych. Asystent spotkań nie powinien tworzyć kluczy dostępu do chmury. Polityka musi łączyć działanie z przypisanym celem.

Kontrola człowieka pozostaje cenna w przypadkach niejednoznacznych lub o dużym wpływie, ale osoba zatwierdzająca potrzebuje użytecznych dowodów. Ogólne okno potwierdzenia nie ujawnia źródła, celu, dotkniętych rekordów ani odwracalności.

Znaczący punkt kontrolny może wskazywać, że agent chce wysłać pięć plików na zewnętrzny adres. Powinien zidentyfikować pliki, odbiorcę, instrukcję wyzwalającą i wyjątek od polityki. Osoba zatwierdzająca może wtedy podjąć świadomą decyzję.

Przedsiębiorstwa powinny również zakładać, że część kontroli zawiedzie. Plany reagowania na incydenty muszą umożliwiać zawieszenie jednej tożsamości agenta bez wyłączania całego współdzielonego konta usługi. Zespoły powinny unieważniać delegowane poświadczenia i poddawać kwarantannie dotkniętą pamięć.

Dzienniki muszą przetrwać sesję agenta i pozostać niezależne od jego środowiska. W przeciwnym razie skompromitowany proces może zmienić dowody potrzebne obrońcom.

Sceptyczny wniosek jest prosty. Żaden publiczny benchmark ani deklaracja dostawcy nie dowodzi, że wstrzyknięcia promptów zostały wyeliminowane. Bezpieczeństwo zależy od nakładających się kontroli, które nie pozwalają, by pojedyncza porażka modelu stała się zdarzeniem obejmującym całe przedsiębiorstwo.

Trzy sygnały pokażą, czy przedsiębiorstwa ograniczają ryzyko

Kolejny etap wdrażania agentów będzie oceniany na podstawie węższych uprawnień, mierzalnego powstrzymywania zagrożeń i dowodów incydentów, a nie wyłącznie autonomii.

Pierwszym sygnałem będzie powszechne wsparcie dla tożsamości specyficznej dla agentów. Platformy chmurowe i programistyczne powinny identyfikować agenta, delegującego użytkownika, właściciela biznesowego i aktywne zadanie w każdym wrażliwym żądaniu.

Informacje te muszą przechodzić przez konektory. Aplikacja odbierająca wywołanie narzędzia nie powinna widzieć wyłącznie współdzielonego klucza API. Powinna otrzymywać weryfikowalny kontekst dotyczący aktora programowego i jego delegowanych uprawnień.

Jeśli dostawcy ustandaryzują ten kontekst, przedsiębiorstwa będą mogły egzekwować spójne polityki na wielu platformach agentowych. Wzmocniłoby to argument, że tożsamość może ograniczać niekontrolowany rozwój agentów. Dalsza zależność od współdzielonych poświadczeń osłabiłaby go.

Przegląd publicznych komentarzy NIST z maja 2026 roku wykazał szeroką zgodę, że ustalone praktyki cyberbezpieczeństwa pozostają istotne, ale wymagają dostosowania. podsumowanie odpowiedzi dotyczących bezpieczeństwa wskazało również zapotrzebowanie na wytyczne wdrożeniowe, wymianę informacji i standardy.

Drugim sygnałem będzie to, czy dostawcy publikują wyniki powstrzymywania zagrożeń zamiast jedynie wskaźników bezpieczeństwa modeli. Przedsiębiorstwa potrzebują testów mierzących, co dzieje się po wykonaniu przez agenta złośliwej instrukcji.

Przydatny raport powinien wskazywać, czy agent dotarł do sekretu, zmienił rekord, skontaktował się z niezatwierdzonym celem lub przekroczył granicę między tenantami. Powinien oddzielać odporność modelu od egzekwowania polityk i izolacji środowiskowej.

Takie dowody mogą zmienić proces zakupowy. Nabywcy mogliby porównywać wdrożenia według maksymalnego osiągalnego zakresu szkód, zamiast opierać się na szerokich deklaracjach o wiarygodności. Zespoły bezpieczeństwa mogłyby również ustalać progi akceptacji dla każdego przepływu pracy.

Publiczne ujawnianie informacji pozostanie trudne, ponieważ architektura powstrzymywania zagrożeń może odsłaniać szczegóły obrony. Dostawcy nadal mogą publikować metodologie, kategorie testów, wyniki zbiorcze i niezależnie zweryfikowane ustalenia bez ujawniania konfiguracji możliwych do wykorzystania.

Jeśli takie raportowanie stanie się normą, poprze tezę, że przedsiębiorstwa traktują promień rażenia jako mierzalną właściwość inżynieryjną. Jeśli dostawcy nadal będą raportować wyłącznie sukces realizacji zadań, luka bezpieczeństwa pozostanie w dużej mierze ukryta.

Trzecim sygnałem będzie pierwsza dojrzała fala raportowania incydentów związanych z agentami. Organizacje potrzebują zapisów rozróżniających niewłaściwe użycie przez użytkownika, nieprawidłowe zachowanie modelu, manipulację zewnętrzną, kompromitację konektora i awarię autoryzacji.

Organy regulacyjne i grupy branżowe mogą pomóc ustanowić wspólny słownik. Bez niego każdy incydent staje się odosobnioną anegdotą, a przedsiębiorstwa mają trudności z porównywaniem przyczyn i kontroli.

Raporty o incydentach powinny identyfikować początkowy punkt wejścia i dalszą ścieżkę działania. Powinny opisywać, które granice się utrzymały, które zawiodły oraz jak naprawiono poświadczenia lub pamięć.

Lepsze raportowanie może początkowo sprawić, że bezpieczeństwo agentów będzie wyglądać gorzej, ponieważ widocznych stanie się więcej awarii. Taka przejrzystość nadal oznaczałaby postęp. Ukryte incydenty nie mogą poprawiać standardów ani testów obronnych.

Ostrzeżenie BankInfoSecurity przekazywane przez Google News należy zatem odczytywać jako opowieść o architekturze, a nie prognozę nieuniknionej katastrofy. Agenci poszerzają ekspozycję, ponieważ przedsiębiorstwa łączą systemy rozumowania z rzeczywistymi uprawnieniami.

Powstrzymywanie zagrożeń pozostaje możliwe. Wymaga odrębnych tożsamości, uprawnień związanych z zadaniem, podzielonych na segmenty narzędzi, chronionych poświadczeń, ograniczonych sieci, wiarygodnych dzienników i celowo zaprojektowanych bramek zatwierdzania.

Wymaga również inwentaryzacji. Zespoły bezpieczeństwa nie mogą zarządzać agentami, których jednostki biznesowe utworzyły bez rejestracji. Każdy agent potrzebuje właściciela, celu, profilu uprawnień, klasyfikacji danych i procesu wycofania.

Organizacje powinny zaczynać od przepływów pracy, w których maksymalna strata jest ograniczona, a działania odwracalne. Mogą rozszerzać uprawnienia dopiero po tym, gdy testy pokażą, że granice tożsamości, polityk i środowiska utrzymują się pod atakiem.

Takie podejście czasem spowolni wdrożenie. Może też zachować tempo adopcji, zapobiegając temu, by jeden możliwy do uniknięcia incydent zakończył cały program. Bezpieczeństwo staje się ograniczeniem operacyjnym umożliwiającym kontrolowane użycie, a nie końcową kontrolą przed uruchomieniem.

Dla pracowników wiedzy kwestia ta sięga codziennych narzędzi. Asystent odczytujący e-maile, dokumenty, spotkania i pliki lokalne działa w obrębie głęboko osobistego kontekstu. Użytkownicy powinni wiedzieć, do których źródeł może uzyskać dostęp i które działania wymagają potwierdzenia.

Dla programistów istotną jednostką nie jest już tylko model. Jest nią kompletny system agentowy, obejmujący prompty, pamięć, narzędzia, poświadczenia, środowisko uruchomieniowe, sieć, polityki i dzienniki.

Dla nabywców korporacyjnych decydujące pytanie jest proste: Co ten agent nadal może zrobić po tym, jak zawiedzie jego rozumowanie? Dostawca, który nie potrafi wyznaczyć tej granicy, nie zdefiniował rzeczywistego ryzyka produktu.

Google News będzie nadal prezentować dramatyczne przykłady, w miarę jak agenci będą trafiać do kolejnych procesów pracy. Czytelnicy powinni spojrzeć poza najbardziej alarmujące zachowania i zbadać uprawnienia stojące za nimi. Czy agent był jednoznacznie zidentyfikowany, ściśle ograniczony zakresem, odizolowany i możliwy do obserwowania? Zadaj te pytania, zanim przyznasz kolejny konektor, poświadczenie lub zgodę. Najbezpieczniejszy agent nie jest tym, który obiecuje, że nigdy nie zawiedzie. To ten, którego awaria nie może rozprzestrzenić się daleko.