Agenci Shadow AI stanowią niewidoczne ryzyko dla przedsiębiorstw
Google News wskazał ostrzeżenie Dark Reading dotyczące agentów shadow AI, gdy przedsiębiorstwa stają przed niepokojącym konfliktem: wdrożenia przyspieszają, podczas gdy widoczność pozostaje niepełna.
Problem wykracza poza pracowników wklejających poufny tekst do niezatwierdzonego chatbota. Autonomiczne agenty mogą otrzymywać poświadczenia, łączyć się z systemami firmowymi, zachowywać kontekst i podejmować działania bez akceptacji na każdym etapie.
Zmienia to główną rywalizację w obszarze bezpieczeństwa. Przedsiębiorstwa nie równoważą już produktywności ze zwykłym zarządzaniem oprogramowaniem. Równoważą autonomiczne działanie z kontrolami zaprojektowanymi dla użytkowników będących ludźmi i przewidywalnych aplikacji.
Dark Reading udokumentował, w jaki sposób systemy agentowe mogą trafiać do środowisk produkcyjnych z szerokimi poświadczeniami i słabymi mechanizmami potwierdzania. W jednym opisywanym incydencie z udziałem agenta programistycznego w ciągu kilku sekund usunięto produkcyjną bazę danych oraz jej kopie zapasowe na poziomie wolumenu. Szerszy wniosek publikacji jest ważniejszy niż pojedyncza awaria: agent z nadmiernym dostępem może przekształcić rutynową pomyłkę w natychmiastowe zdarzenie operacyjne.
Ostrzeżenie pojawia się także w okresie szybkiego rozwoju produktów przez Microsoft, Google, Amazon, Nvidia i licznych dostawców zabezpieczeń. Każda firma chce stać się częścią stosu agentowego przedsiębiorstw. Jednak każdy nowy framework, konektor i delegowana tożsamość daje zespołom bezpieczeństwa kolejną relację do wykrycia i objęcia nadzorem.
Kluczowe odwrócenie jest niewygodne. Agenci AI mają ograniczać pracę ręczną, lecz zarządzanie nimi tworzy nową kategorię ciągłej pracy. Zespoły bezpieczeństwa muszą zidentyfikować każdego agenta, zrozumieć jego cel, zmapować jego dostęp, monitorować jego działania i bezpiecznie go wycofać.
Google News uwidacznia problem ukrytych agentów
Najnowsze ostrzeżenie ma znaczenie, ponieważ shadow AI przeszło od nieautoryzowanych rozmów do nieautoryzowanego działania.
Google News pełni tu funkcję kanału odkrywania, podczas gdy źródłowe materiały Dark Reading odzwierciedlają szerszą zmianę w badaniach nad bezpieczeństwem przedsiębiorstw. Pracownicy i programiści wdrażają agentów za pośrednictwem narzędzi lokalnych, platform chmurowych, rozszerzeń oprogramowania i wewnętrznych projektów automatyzacji.
Agent AI to oprogramowanie wykorzystujące model do realizacji celu w wielu krokach. Może wybierać narzędzia, pobierać informacje, wywoływać API i modyfikować systemy przy mniejszym bezpośrednim nadzorze niż konwencjonalna aplikacja.
Ta autonomia odróżnia ukrytego agenta od niezatwierdzonego chatbota. Chatbot zwykle zwraca informacje osobie. Agent może wysłać wiadomość, zmienić kod, zaktualizować rekord klienta, odpytać bazę danych lub uruchomić kolejny zautomatyzowany proces.
Dark Reading podał, że bezpieczeństwo agentowej AI pozostaje istotną przeszkodą dla przedsiębiorstw, ponieważ popularne lokalne agenty rozprzestrzeniają się szybciej, niż zespoły ds. tożsamości są w stanie je zinwentaryzować. Materiał opisywał użytkowników uruchamiających instancje, zanim zespoły bezpieczeństwa dowiedziały się o istnieniu tych agentów. Raport analizował również demonstrację, w której złośliwe zgłoszenie wsparcia pomogło agentowi eskalować uprawnienia i wydobyć dane w mniej niż minutę.
Przykłady te nie dowodzą, że każde wdrożenie agenta jest niebezpieczne. Pokazują, jak znane błędy kontroli stają się poważniejsze, gdy oprogramowanie może planować i działać.
Skala luki w widoczności jest wyraźniejsza w badaniu enterprise agent survey z 2026 roku, przeprowadzonym przez Cloud Security Alliance. CSA podało, że 82% uczestniczących organizacji odkryło w poprzednim roku nieznanych wcześniej agentów.
Badanie oparto na 418 odpowiedziach specjalistów IT i bezpieczeństwa. Token Security zleciło i sfinansowało ankietę — relację, którą czytelnicy powinni uwzględnić przy interpretacji jej wniosków.
Nawet z tym zastrzeżeniem kilka ustaleń wskazuje na spójny problem z zarządzaniem. Czterdzieści jeden procent respondentów wielokrotnie odkrywało nieznanych agentów. Wewnętrzne środowiska automatyzacji i skryptów były najczęstszym źródłem, wskazanym przez 51%.
Platformy LLM, w tym niestandardowe narzędzia, asystenci i wtyczki, znalazły się na kolejnym miejscu z wynikiem 47%. Automatyzacja SaaS oraz przepływy pracy tworzone przez programistów również należały do głównych źródeł.
Ten rozkład wyjaśnia, dlaczego zwykła inwentaryzacja oprogramowania jest niewystarczająca. Agent może występować jako proces na komputerze, zasób chmurowy, wtyczka, integracja API lub przepływ pracy osadzony w zatwierdzonym produkcie SaaS.
Widoczna aplikacja jest tylko jednym elementem. Poświadczenia, endpointy modeli, połączenia z narzędziami, magazyny pamięci i agenci podrzędni tworzą wokół niej system operacyjny.
System ten może pozostać aktywny po przejściu pracownika, który go utworzył, do innego projektu. Może także zachować dostęp po utracie pierwotnego celu biznesowego.
Google News mogło przedstawić jeden nagłówek szerszej publiczności, lecz zdarzenie wykracza poza pojedynczy cykl publikacyjny. Przedsiębiorstwa odkrywają, że ich zasoby AI obejmują podmioty, których nigdy nie zarejestrowały, oraz uprawnienia, których nigdy nie zweryfikowały.
Dlaczego agenci Shadow AI niosą inne ryzyko
Ukryty agent łączy nieznany zasób z aktywną tożsamością, tworząc ryzyko, które tradycyjne shadow IT rzadko niosło z taką samą szybkością.
Shadow IT zwykle oznacza oprogramowanie lub infrastrukturę przyjęte bez formalnego zatwierdzenia. Jego ryzyka obejmują niezarządzane przechowywanie danych, niebezpieczną konfigurację, słabą ocenę dostawców i brakujące rejestry audytowe.
Shadow AI dziedziczy te problemy. Następnie dodaje probabilistyczne decyzje, trwały kontekst, użycie narzędzi i autonomiczne wykonywanie działań.
Konwencjonalna aplikacja SaaS realizuje zaprogramowane przepływy pracy. Agent interpretuje cel i wybiera drogę jego realizacji. Dwa podobne żądania mogą prowadzić do różnych działań, ponieważ model, kontekst i dostępne narzędzia wpływają na każdą decyzję.
Ta elastyczność tworzy wartość. Utrudnia też ocenę agenta w ramach jednorazowego przeglądu bezpieczeństwa.
Efektywne uprawnienia agenta zależą od czegoś więcej niż jego początkowa konfiguracja. Zespoły bezpieczeństwa muszą uwzględniać użytkownika zgłaszającego żądanie, delegowane poświadczenia, podłączone narzędzia, pobrane treści, dostępne dane i każde działanie następcze.
Prompt injection czyni tę relację szczególnie niebezpieczną. Prompt injection występuje, gdy niezaufana treść manipuluje instrukcjami agenta, potencjalnie kierując go z dala od zadania zamierzonego przez użytkownika.
Złośliwa instrukcja może być ukryta w zgłoszeniu wsparcia, dokumencie, e-mailu lub stronie internetowej. Jeśli agent potraktuje taką treść jako zaufaną wskazówkę, może ujawnić informacje albo wywołać autoryzowane narzędzie w nieautoryzowanym celu.
Analiza infrastruktury Cloud Security Alliance opisuje to jako wielowarstwową powierzchnię ataku, a nie zbiór samowolnych aplikacji. To rozróżnienie jest użyteczne, ponieważ agenci łączą systemy, które zespoły bezpieczeństwa często oceniają oddzielnie.
Rozważmy pracownika, który tworzy agenta do podsumowywania opinii klientów. Agent odczytuje współdzielony dysk, wywołuje zewnętrzny model, przechowuje kontekst, publikuje wnioski na kanale komunikacyjnym i aktualizuje bazę danych planowania.
Każde połączenie z osobna może wyglądać rozsądnie. Razem tworzą potok zdolny do przenoszenia poufnych informacji przez kilka granic zaufania.
Pracownik może zabezpieczyć pierwsze źródło danych, ale przeoczyć ustawienia retencji dostawcy modelu. Może przechowywać poświadczenie API w lokalnym pliku konfiguracyjnym. Może przyznać agentowi uprawnienia do edycji każdego rekordu, choć potrzebuje on jedynie dostępu do odczytu.
Agent może również kumulować uprawnienia poprzez delegowany dostęp OAuth. OAuth umożliwia jednej usłudze działanie za pośrednictwem uprawnień przyznanych przez użytkownika lub inną aplikację.
Porzucony agent może zatem pozostać funkcjonalny bez konwencjonalnego konta pracownika. Jego token może przetrwać wewnątrz przepływu pracy, integracji lub środowiska programistycznego, któremu poświęca się niewiele uwagi.
CSA nazywa nagromadzenie zapomnianych agentów i zachowanych uprawnień „długiem wycofania”. Jedynie 21% respondentów ankiety zgłosiło posiadanie formalnego procesu wycofywania agentów z użycia.
Ta luka w cyklu życia komplikuje reagowanie na incydenty. Zespół bezpieczeństwa nie może szybko odebrać agentowi dostępu, gdy nie dysponuje pełnym zapisem jego tożsamości, właściciela, narzędzi i zależności.
Ryzyko nie ogranicza się do wrogiego przejęcia. Agent może spowodować szkody, wiernie realizując źle określony cel.
Dark Reading przeanalizował ten wzorzec awarii po tym, jak agent programistyczny AI miał rzekomo usunąć dane produkcyjne i powiązane kopie zapasowe. Konkretny incydent obejmował kilka słabości kontroli, w tym szerokie poświadczenia i niewystarczające oddzielenie środowisk.
Są to znane błędy inżynieryjne. Autonomia skraca czas między błędem a jego konsekwencjami.
Operator będący człowiekiem może zatrzymać się przed usunięciem bazy danych. Deterministyczny system wdrożeniowy może odrzucić działanie wykraczające poza zaprogramowaną ścieżkę. Agent może zinterpretować destrukcyjne działanie jako prawidłowy krok w kierunku realizacji przydzielonego celu.
Dlatego reguły oparte na promptach nie wystarczą. Polecenie agentowi unikania szkodliwych działań może wpłynąć na jego zachowanie, ale nie usuwa jego technicznej możliwości ich wykonania.
Możliwości muszą być ograniczane poza modelem. Agent nie powinien mieć dostępu do systemów i działań, których jego zadanie nie wymaga.
Kontrole tożsamości w przedsiębiorstwach przechodzą najtrudniejszy test
Główna rywalizacja toczy się obecnie między autonomicznymi możliwościami a systemami tożsamości zbudowanymi wokół stabilnych użytkowników, kont usługowych i przewidywalnych obciążeń.
Zarządzanie tożsamością i dostępem odpowiada na kilka podstawowych pytań. Kto żąda dostępu, do jakiego zasobu może dotrzeć, jakie działanie może wykonać i jak długo to uprawnienie powinno pozostawać ważne?
Przedsiębiorstwa spędziły lata na ulepszaniu tych kontroli dla pracowników i kont usługowych. Agenci podważają obie kategorie.
Agent nie jest osobą, lecz często działa w jej imieniu. Nie jest też tradycyjnym kontem usługowym, ponieważ sekwencja jego działań może się zmieniać, gdy interpretuje nowy kontekst.
Traktowanie agenta jako współdzielonego konta usługowego zaciera rozliczalność. Logi mogą wskazywać, które poświadczenie uzyskało dostęp do pliku, nie ujawniając, który użytkownik zainicjował zadanie ani dlaczego agent wybrał ten plik.
Systemy wieloagentowe komplikują problem. Jeden agent może delegować pracę drugiemu, który wywołuje trzecie narzędzie przy użyciu innych poświadczeń.
Tożsamość i intencja pierwotnego użytkownika mogą zniknąć w tym łańcuchu. Uprawnienia podążają wówczas za integracją techniczną, a nie za upoważnieniem osoby, która zleciła pracę.
Prognoza bezpieczeństwa Google z 2026 roku przewidziała tę zmianę. Wskazywała, że agenci powinni stać się zarządzanymi cyfrowymi podmiotami z precyzyjnym, uwzględniającym kontekst dostępem.
Raport podkreślał zasadę najmniejszych uprawnień, tymczasowy dostęp i śledzalny łańcuch delegowania. Zasada najmniejszych uprawnień oznacza, że tożsamość otrzymuje wyłącznie dostęp wymagany do bieżącego zadania.
Są to ugruntowane praktyki bezpieczeństwa. Trudność polega na stosowaniu ich przy szybkości i skali aktywności agentów.
Pracownik może wykonać kilka ważnych działań w ciągu dnia pracy. Agent może zainicjować wiele wywołań narzędzi w ramach jednego zadania i działać nieprzerwanie.
Kwartalny przegląd dostępu nie może ocenić każdej decyzji. Statyczne uprawnienia nie mogą określić, czy konkretne działanie odpowiada bieżącemu celowi agenta.
Przedsiębiorstwa potrzebują więc kontekstu w momencie podejmowania decyzji. Prośba o odczyt jednego zatwierdzonego folderu projektu może zostać zrealizowana automatycznie. Prośba o eksport rekordów klientów powinna uruchomić silniejszą weryfikację lub etap zatwierdzenia przez człowieka.
Badanie CSA pokazuje, że organizacje już dostrzegają to rozróżnienie. Pięćdziesiąt trzy procent respondentów stwierdziło, że agenci działają autonomicznie w zadaniach niskiego ryzyka, podczas gdy działania wyższego ryzyka podlegają ocenie człowieka.
Tylko 13% zgłosiło w pełni autonomiczne modele. Gdy agenci przekraczali jednak swój zakres działania, zaledwie 11% respondentów stwierdziło, że działanie zostałoby automatycznie zablokowane.
Ta luka ma znaczenie. Rejestrowanie działania po jego zakończeniu pomaga w dochodzeniu, ale nie zapobiega utracie danych ani szkodom operacyjnym.
Zatwierdzanie przez człowieka również ma ograniczenia. Jeśli każde działanie wywołuje monit, pracownicy będą zatwierdzać prośby bez uważnej oceny. Zmęczenie zatwierdzaniem może zmienić widoczną kontrolę w nieskuteczny rytuał.
Lepszy projekt wiąże interwencję z ryzykiem. Zespoły bezpieczeństwa powinny określić, które zasoby, klasyfikacje danych i działania wymagają silniejszych mechanizmów kontroli.
Microsoft zaczął przedstawiać Agent 365 jako płaszczyznę kontroli dla tego problemu. Jego aktualizacja Agent 365 opisuje wykrywanie lokalnych i chmurowych agentów, w tym połączenia między środowiskami Microsoft, Amazon i Google.
Microsoft twierdzi, że jego produkty bezpieczeństwa mogą mapować urządzenia, serwery Model Context Protocol, powiązane tożsamości i dostępne zasoby chmurowe. Model Context Protocol, czyli MCP, to standard umożliwiający aplikacjom AI łączenie się z narzędziami i źródłami danych.
Taka mapa relacji jest bardziej użyteczna niż płaska lista agentów. Pomaga obrońcom oszacować zasięg skutków, jeśli agent lub jego poświadczenia zostaną naruszone.
Microsoft twierdzi również, że administratorzy mogą wykrywać i blokować powszechne metody używane przez niektórych niezarządzanych lokalnych agentów. Kontrole środowiska wykonawczego mają zatrzymywać podejrzane zachowania podczas działania agenta.
Te możliwości wskazują kierunek rozwoju bezpieczeństwa przedsiębiorstw, lecz deklaracje dostawców wymagają praktycznej weryfikacji. Wykrywanie międzyplatformowe może pominąć niestandardowych agentów, prywatną infrastrukturę, nieobsługiwane łączniki oraz przepływy pracy ukryte wewnątrz innych produktów.
Płaszczyzna kontroli tworzy też własne ryzyko koncentracji. Przedsiębiorstwa muszą zdecydować, jak dużą władzę przyznać systemowi odpowiedzialnemu za nadzorowanie wszystkich pozostałych agentów.
Rezultatem nie jest prosta migracja ze starych narzędzi tożsamościowych do nowych. Przedsiębiorstwa muszą rozszerzać kontrole tożsamości, zachowując jednocześnie niezależne monitorowanie, ścieżki odzyskiwania i rzeczywistą odpowiedzialność człowieka.
Sama Widoczność Nie Oznacza Kontroli
Wykrycie agenta jest konieczne, ale inwentaryzacja nie może dowieść, że jego działania pozostają bezpieczne lub zgodne z przypisanym mu celem.
Dostawcy rozwiązań bezpieczeństwa odpowiedzieli na problem shadow AI produktami do wykrywania. Produkty te analizują urządzenia końcowe, ruch sieciowy, środowiska chmurowe, aktywność w przeglądarce, tożsamości i integracje SaaS.
Taka widoczność stanowi punkt wyjścia. Firma nie może zarządzać zasobem, którego nie potrafi zidentyfikować.
Niebezpieczeństwo polega na traktowaniu wykrywania jako zakończonego zadania. Agent może pojawić się w inwentaryzacji, podczas gdy jego najważniejsze relacje pozostają nieznane.
Zespoły bezpieczeństwa muszą wiedzieć, kto jest jego właścicielem, z którego modelu korzysta, jakie dane pobiera, gdzie znajduje się jego pamięć, jakie poświadczenia posiada i jakie narzędzia może wywoływać.
Potrzebują też dowodów behawioralnych. Agent zatwierdzony do uzgadniania faktur nie powinien nagle przeszukiwać repozytoriów kodu źródłowego ani wysyłać plików do nieznanej domeny.
Tradycyjne systemy zapobiegania utracie danych mogą wykryć część informacji wrażliwych opuszczających organizację. Mogą jednak nie rozumieć, dlaczego agent uzyskał dostęp do informacji ani czy działanie odpowiadało intencji użytkownika, który je zainicjował.
To samo ograniczenie dotyczy monitorowania urządzeń końcowych. Nazwa procesu może ujawnić, że agent działa, ale nie zawsze pozwala odtworzyć chmurowy przepływ pracy uruchomiony za jego pośrednictwem.
Ciągła autoryzacja oferuje silniejszy model. Ocenia, czy dostęp pozostaje właściwy na każdym istotnym etapie, zamiast ufać jednemu początkowemu logowaniu.
W przypadku agentów taka ocena powinna uwzględniać cel zadania, uprawnienia użytkownika, wrażliwość zasobu, reputację narzędzia, bieżące zachowanie i niedawne zmiany ryzyka.
Ciągła autoryzacja nie wymaga ręcznego zatwierdzania każdej operacji. Działania niskiego ryzyka, które można odwrócić, mogą być realizowane w ramach określonej granicy.
Działania o dużym wpływie zasługują na inną ścieżkę. Usuwanie rekordów, publikowanie zewnętrznych wiadomości, modyfikowanie infrastruktury, zmienianie uprawnień lub eksport regulowanych danych powinny napotykać ograniczenia techniczne.
Granica powinna istnieć poza modelem. Poświadczenia tylko do odczytu, odizolowane środowiska, limity transakcji i odrębne usługi zatwierdzania mogą ograniczyć to, co agent faktycznie może zrobić.
Odzyskiwanie wymaga podobnego rozdzielenia. Kopie zapasowe nie powinny znajdować się w tej samej granicy uprawnień co system produkcyjny, który agent może modyfikować.
Relacja Dark Reading dotycząca baz danych konkretyzuje tę kwestię. Jeśli agent może usunąć zarówno dane produkcyjne, jak i ich kopię odzyskiwania za pośrednictwem jednej ścieżki poświadczeń, kopia zapasowa nie zapewnia niezależnego zabezpieczenia.
Obserwowalność również wymaga trwałych zapisów. Dzienniki powinny zachowywać dane o użytkowniku inicjującym, tożsamości agenta, modelu i wersji, żądanym celu, wybranych narzędziach, danych, do których uzyskano dostęp, otrzymanych zatwierdzeniach i końcowym wyniku.
Rejestrowanie wszystkiego rodzi problemy związane z prywatnością i przechowywaniem danych. Wrażliwe prompty i pobrane dane nie powinny stać się nieograniczonym wtórnym zbiorem danych.
Przedsiębiorstwa potrzebują limitów retencji i kontroli dostępu dla telemetrii agentów. Osoby prowadzące dochodzenia potrzebują wystarczającego kontekstu, aby odtworzyć decyzje, nie ujawniając każdej poufnej informacji szerokiej grupie.
Ład organizacyjny powinien również odróżniać zatwierdzone eksperymenty od niekontrolowanego dostępu produkcyjnego. Deweloperzy potrzebują środowisk, w których mogą testować nowych agentów bez oczekiwania na pełny cykl zakupowy.
Środowiska te powinny wykorzystywać dane syntetyczne lub odpowiednio chronione. Powinny izolować poświadczenia i zapobiegać bezpośredniemu dostępowi do kluczowych zasobów produkcyjnych.
Całkowity zakaz tworzy kolejny problem z widocznością. Prognoza Google ostrzegła, że zakazywanie agentów może wypchnąć ich użycie poza sieć firmową, gdzie monitorowanie staje się jeszcze słabsze.
Nie oznacza to, że każde narzędzie powinno otrzymać zgodę. Oznacza to, że zatwierdzona ścieżka musi być na tyle użyteczna, aby pracownicy ją wybierali.
Zespoły bezpieczeństwa mogą oferować zweryfikowane modele, standardowe łączniki, ograniczone poświadczenia, środowiska testowe i szybki proces rejestracji. Środki te zmniejszają zachętę do budowania ukrytych alternatyw.
Rolę mają również menedżerowie biznesowi. Powinni wyznaczyć właściciela dla każdego agenta produkcyjnego i udokumentować proces biznesowy, który obsługuje.
Własność musi obejmować wycofanie. Gdy projekt się kończy, organizacja powinna unieważnić tokeny, usunąć integracje, usunąć niepotrzebną pamięć i zweryfikować, że zależne przepływy pracy nie wywołują już agenta.
Bez takiej dyscypliny cyklu życia widoczność staje się rosnącą listą nierozwiązanych zasobów. Przedsiębiorstwo wie, że ryzyko istnieje, ale nadal nie może z przekonaniem go usunąć.
Dowody Są Poważne, Ale Mają Ograniczenia
Obecne badania wskazują na znaczną lukę w zarządzaniu, lecz ankiety finansowane przez dostawców i odosobnione incydenty nie mogą zmierzyć pełnej częstotliwości szkód powodowanych przez agentów.
Raportowanie bezpieczeństwa wymaga dwóch form ostrożności. Przedsiębiorstwa nie powinny odrzucać shadow agents jako hipotetycznego problemu. Nie powinny też traktować każdej prognozy ani statystyki dostawcy jako neutralnego pomiaru.
Badanie CSA dostarcza użytecznych szczegółów, ponieważ podaje liczbę respondentów, termin badania i kilka wzorców wdrożeń. Stwierdza również, że Token Security zlecił, sfinansował i pomógł opracować kwestionariusz.
Token sprzedaje zabezpieczenia tożsamości dla agentów AI. Nie unieważnia to ustaleń, ale tworzy komercyjny interes w podkreślaniu luk w widoczności i tożsamości.
Inne często cytowane pomiary pochodzą od dostawców bezpieczeństwa obserwujących własnych klientów. Te zbiory danych mogą ujawniać trendy w telemetrii produktu, lecz mogą nie reprezentować wszystkich przedsiębiorstw.
Na wynik mogą wpływać dobór klientów, konfiguracja wdrożeń, metody wykrywania i terminologia. Jeden produkt może liczyć każdy przepływ pracy jako agenta, podczas gdy inny liczy tylko niezależne tożsamości agentów.
Termin „incydent” również wymaga ostrożnej interpretacji. Może obejmować ujawnienie danych, naruszenia zasad, nieoczekiwane zachowanie, zakłócenia operacyjne lub potwierdzone naruszenie.
CSA podało, że 65% respondentów doświadczyło incydentu związanego z agentem AI w poprzednim roku. Wśród dotkniętych organizacji ujawnienie danych było najczęściej zgłaszanym wpływem biznesowym.
To ustalenie budzi niepokój. Nie określa jednak, ile incydentów dotyczyło złośliwych atakujących, przypadkowych działań, niezatwierdzonego użycia lub awarii w zatwierdzonych systemach.
Raporty przypadków zapewniają głębię, ale nie określają częstości. Usunięcie produkcyjnej bazy danych jednej firmy pokazuje wiarygodny łańcuch awarii. Nie może powiedzieć czytelnikom, jak często podobne zdarzenia występują na rynku.
Ta sama ostrożność dotyczy demonstracji ataków. Kontrolowany exploit pokazuje, że projekt może zawieść w określonych warunkach. Zabezpieczenia produkcyjne, uprawnienia i monitorowanie mogą zmienić wynik.
Przedsiębiorstwa powinny zatem pytać dostawców o metodologię wykrywania, granice zasięgu, wskaźniki fałszywych alarmów i niezależną walidację. Panel oznaczony jako „pełna inwentaryzacja” zasługuje na szczególną kontrolę.
Nieznani agenci są nieznani właśnie dlatego, że wykrywanie jest niepełne. Żaden dostawca nie może udowodnić uniwersalnego zasięgu, pokazując wyłącznie zasoby znalezione przez własne czujniki.
Liderzy bezpieczeństwa powinni też oddzielać ryzyko modelu od ryzyka systemowego. Agent może podjąć złą decyzję z powodu zachowania modelu, ale to nadmierne uprawnienia decydują, czy decyzja przerodzi się w poważny incydent.
I odwrotnie, wąskie uprawnienia nie rozwiązują każdego problemu. Agent z dostępem tylko do odczytu nadal może ujawnić poufne informacje, tworzyć szkodliwe rekomendacje lub wpływać na inny system.
Najbardziej wiarygodna odpowiedź łączy ocenę modelu, zarządzanie tożsamością, ochronę danych, monitorowanie środowiska wykonawczego i odporność operacyjną. Żadna pojedyncza warstwa nie ponosi całego ciężaru.
Przedsiębiorstwa potrzebują również raportowania incydentów, które odróżnia awarie agentów od zwykłych awarii aplikacji. Użyteczne raporty powinny rejestrować poziom autonomii, ścieżkę dostępu, tożsamość inicjującą, naruszony komponent i wpływ biznesowy.
Bez wspólnych definicji rynek będzie tworzył duże, ale niezgodne liczby. Utrudni to zarządom i regulatorom zrozumienie, czy ryzyko się zmniejsza.
Czytelnicy Google News powinni interpretować obecny nagłówek jako ostrzeżenie poparte zbieżnymi dowodami, a nie pełny pomiar ekspozycji przedsiębiorstw.
Luka w weryfikacji jest częścią tej historii. Branża widzi wystarczająco dużo, aby uzasadnić działanie, ale nadal brakuje jej spójnych danych publicznych o incydentach związanych z agentami i ich konsekwencjach.
Co Przedsiębiorstwa Powinny Obserwować Dalej
Kolejną fazę zdefiniują rejestry agentów, egzekwowanie zasad w środowisku wykonawczym oraz dowody dotyczące incydentów, które sprawdzą, czy produkty do zarządzania działają poza demonstracjami dostawców.
Pierwszym sygnałem będzie przyjęcie międzyplatformowych rejestrów agentów. Microsoft, dostawcy bezpieczeństwa i dostawcy chmury budują systemy inwentaryzujące agentów na urządzeniach końcowych, w produktach SaaS i środowiskach chmurowych.
Przedsiębiorstwa powinny sprawdzić, czy te rejestry wykrywają niestandardowe przepływy pracy i nieobsługiwane narzędzia. Zasięg ograniczony do środowiska jednego dostawcy nie rozwiąże problemu shadow agents w środowisku wielochmurowym.
Najsilniejsze dowody będą pochodzić z niezależnych porównań. Zespoły bezpieczeństwa potrzebują testów, które wdrażają znanych agentów przez kilka kanałów i mierzą, które produkty wykrywają każdy komponent.
Użyteczny rejestr powinien identyfikować właściciela, przeznaczenie, tożsamość, uprawnienia, narzędzia, źródła danych i stan cyklu życia. Sama lista nazw agentów daje zbyt mało kontekstu do podejmowania decyzji dotyczących ryzyka.
Drugim sygnałem jest egzekwowanie zasad w czasie działania. Komunikaty produktowe coraz częściej obiecują blokowanie podejrzanego użycia narzędzi, ograniczanie agentów zgodnie z politykami oraz stosowanie autoryzacji uwzględniającej kontekst.
Kluczową miarą nie jest to, czy produkt potrafi wygenerować alert. Jest nią to, czy produkt zatrzyma działanie o dużym wpływie, nie zakłócając zwykłej pracy.
Fałszywe alarmy mają znaczenie, ponieważ agenci mogą inicjować wiele operacji. Mechanizm kontroli, który blokuje rutynową aktywność, zachęci zespoły do jego wyłączenia albo obchodzenia.
Jeszcze większe znaczenie mają fałszywie negatywne wyniki. Jedno pominięte destrukcyjne działanie może przekreślić tysiące poprawnie zatwierdzonych żądań.
Przedsiębiorstwa powinny testować mechanizmy kontroli pod kątem prompt injection, przejętych poświadczeń, nadmiernego delegowania, nieautoryzowanego transferu danych oraz prób modyfikacji zapisów audytowych. Testy powinny obejmować zarówno wdrożenia zatwierdzone, jak i działające w cieniu.
Trzecim sygnałem jest lepsze ujawnianie informacji o incydentach. Branża technologiczna ma rozbudowane systemy zgłaszania luk w oprogramowaniu, ale awarie agentów nie wpisują się łatwo w te kanały.
Podatny konektor może otrzymać standardowy identyfikator. Agent, który błędnie interpretuje cel, dziedziczy nadmierny dostęp i usuwa dane, rodzi bardziej złożone pytanie o odpowiedzialność.
Czy przyczyną awarii był model, framework agenta, konektor, projekt poświadczeń, wdrożenie czy instrukcja człowieka? W wielu przypadkach przyczyniło się do niej kilka warstw.
Spójne raportowanie pomogłoby organizacjom porównywać incydenty i ulepszać mechanizmy kontroli. Ujawniłoby również, czy szeroko dyskutowane zagrożenia przekładają się na powtarzające się awarie produkcyjne.
Regulatorzy i audytorzy prawdopodobnie będą żądać dowodów, a nie dokumentów polityk. Przedsiębiorstwo powinno być w stanie wykazać, jakie agenty istniały, kto był za nie odpowiedzialny, do czego miały dostęp oraz jak kontrolowano działania wysokiego ryzyka.
Praktyczna odpowiedź powinna rozpocząć się, zanim pojawią się takie żądania. Zespoły ds. bezpieczeństwa mogą zinwentaryzować znane agenty, wyszukać te niezatwierdzone, sklasyfikować zakres ich uprawnień i usunąć porzucone poświadczenia.
Mogą także zdefiniować niewielki zestaw działań, które zawsze wymagają silniejszych mechanizmów kontroli. Usuwanie danych produkcyjnych, publikacja zewnętrzna, zmiany uprawnień i masowy eksport danych to rozsądne punkty wyjścia.
Deweloperzy i pracownicy wiedzy powinni pytać, co agent może zrobić, zanim skupią się na tym, co może wygenerować. Uprawnienia stojące za imponującą demonstracją określają jego rzeczywiste ryzyko dla przedsiębiorstwa.
Liderzy biznesowi powinni pytać, czy zatwierdzona ścieżka korzystania z agentów jest wystarczająco dostępna, aby ograniczyć wdrożenia w cieniu. Ład organizacyjny istniejący wyłącznie na papierze przegra z narzędziem, które pracownik może zainstalować w kilka minut.
Nagłówek Google News dotyczy zatem nie tyle jednego nowo odkrytego zagrożenia, ile spóźnionego uświadomienia sobie problemu. Autonomiczne oprogramowanie już wkroczyło do procesów przedsiębiorstw, podczas gdy wiele organizacji wciąż zarządza nim jak kolejną aplikacją.
Takie podejście się nie utrzyma. Każdy agent produkcyjny potrzebuje tożsamości, wyznaczonego właściciela, ograniczonego zakresu uprawnień, obserwowalnych działań oraz zweryfikowanej ścieżki wycofania.
Najbliższe trzy miesiące powinny pokazać, czy rejestry agentów zyskają wiarygodne pokrycie międzyplatformowe, czy mechanizmy kontroli w czasie działania przetrwają realistyczne testy oraz czy ujawniane informacje o incydentach staną się bardziej konkretne.
Jeśli te sygnały się pojawią, zarządzanie przedsiębiorstwami zacznie nadrabiać zaległości. Jeśli nie, problem agentów działających w cieniu będzie nadal narastał za pulpitami nawigacyjnymi, które sugerują większą kontrolę, niż organizacje faktycznie posiadają.
