Alerty Intezer AI SOC gwałtownie wzrosły, ale niemal wszystkie były szumem

Liczba alertów Intezer AI SOC wzrosła o 685% od lutego do czerwca 2026 r., choć stanowiły one zaledwie 0,43% alertów bezpieczeństwa uwzględnionych w badaniu. Konflikt jest już wyraźny. AI w przedsiębiorstwach nie wywołała fali włamań napędzanych przez agentów, której obawiało się wiele zespołów bezpieczeństwa. Wytworzyła szybko rosnący strumień legalnej aktywności, która często przypomina intruzję.

Intezer przeanalizował około 16,9 mln alertów w wielu środowiskach przedsiębiorstw. Około 73 000 dotyczyło narzędzi lub agentów AI. Badacze sklasyfikowali 94,1% jako szum, 5,8% jako rzeczywiste ryzyko bezpieczeństwa, a zaledwie 0,02% jako faktyczne ataki.

Ta dysproporcja stawia po jednej stronie utrwaloną logikę detekcji, a po drugiej normalną pracę wspomaganą przez AI. Claude, Codex, Cursor, ChatGPT i podobne narzędzia mogą uruchamiać procesy, obsługiwać pliki, wywoływać powłoki i łączyć się z usługami. Działania te przypominają zachowanie atakującego, gdy ocenia się je bez znajomości intencji użytkownika.

Rezultatem nie jest po prostu większa ilość pracy dla centrum operacji bezpieczeństwa, czyli SOC. To problem kontekstu. Zespoły muszą odróżnić legalną aktywność agentów od niebezpiecznego zachowania agentów, zanim fałszywe alarmy przysłonią istotne zagrożenia.

Alerty Intezer AI SOC rosły szybciej, niż sugeruje ich udział

Najważniejszą liczbą nie jest obecny udział AI w wolumenie alertów. Jest nią tempo i struktura tego wzrostu.

Według badania alertów AI firmy Intezer aktywność związana z AI wygenerowała około 73 000 z 16,9 mln przeanalizowanych alertów. To niewielka kategoria w porównaniu z alertami dotyczącymi punktów końcowych, tożsamości, poczty e-mail, chmury i sieci, które już trafiają do korporacyjnych SOC.

Jednak miesięczny wolumen związany z AI rósł przez cały stabilny okres raportowania. Intezer zmierzył wzrost o 685% między lutym a czerwcem 2026 r. Firma opisała ten wzorzec jako monotoniczny, co oznacza, że każdy pełny miesiąc przewyższał poprzedni.

Ta trajektoria ma znaczenie, ponieważ wdrożenie w przedsiębiorstwie nie wymaga formalnego uruchomienia w całej firmie. Pracownicy mogą połączyć konsumenckiego chatbota przez OAuth, który umożliwia aplikacji dostęp do zatwierdzonych zasobów konta. Deweloperzy mogą instalować agentów programistycznych, którzy od razu zaczynają wchodzić w interakcje z systemami lokalnymi.

Każde takie działanie dodaje nowe źródło telemetrii. Może też aktywować reguły stworzone wiele lat przed tym, gdy agenci ogólnego przeznaczenia zaczęli działać na komputerach pracowników.

Intezer podzielił powstałe alerty na trzy kategorie. Szum obejmował legalną aktywność, która uruchomiła istniejącą detekcję. Ryzyko bezpieczeństwa obejmowało niebezpieczne zachowanie lub ekspozycję bez potwierdzonego naruszenia. Prawdziwe ataki wymagały dowodów rzeczywistej operacji atakującego.

Szum dominował z wynikiem 94,1%. Ryzyka bezpieczeństwa stanowiły 5,8%, podczas gdy potwierdzone ataki stanowiły około 0,02%. Klasyfikacje te pochodziły z platformy i metodologii Intezer, dlatego niezależne badania mogą wykazać inne proporcje.

Wewnętrzne dane dotyczące obsługi ujawniły kolejną warstwę tego samego wzorca. Intezer podał, że 79,8% alertów związanych z AI otrzymało werdykt „łagodny”. Jego zautomatyzowany system odrzucił 81,7%, zamykając je bez przedstawiania analitykowi.

Tylko 5,4% przekazano do analityka. Pozostałe alerty oznaczono do dalszej obserwacji, zamiast od razu traktować je jako incydenty.

Wyniki te wspierają automatyczny triage, ale ujawniają też zależność. Automatyzacja musi rozumieć relację między agentem, jego użytkownikiem i wykonywanym zadaniem. Sama nazwa procesu lub polecenie rzadko zapewnia taki kontekst.

Jeden klient wygenerował 55% wszystkich alertów związanych z AI oznaczonych w zbiorze danych jako krytyczne, korzystając z pojedynczej detekcji. Reguła identyfikowała binarny plik Windows Expand.exe jako możliwe narzędzie transferu bocznego.

Bliższa analiza wykazała, że agent programistyczny przygotowywał środowisko powłoki. Aktywność była normalna dla tego przepływu pracy, mimo że jej poszczególne sygnały techniczne przypominały zachowanie atakującego.

Tradycyjna etykieta ważności umieściłaby te alerty blisko początku kolejki analityka. Kontekst przesunął je w kierunku automatycznego zamknięcia. Różnica ta staje się kosztowna, gdy ten sam wzorzec powtarza się na tysiącach punktów końcowych.

Badanie nie pokazuje, że wszystkie alerty AI o wysokiej ważności są nieszkodliwe. Pokazuje, że ważność traci znaczenie, gdy logika detekcji nie potrafi rozpoznać normalnego zachowania agentów.

To pierwsza zmiana operacyjna dla liderów SOC. Aktywność AI potrzebuje własnej bazy odniesienia, obejmującej zatwierdzone narzędzia, oczekiwane procesy nadrzędne, zwykłe miejsca docelowe i dozwolone działania. Bez takiej bazy wzrost adopcji staje się wzrostem fałszywej pilności.

Wdrożenie AI w całej firmie zmienia kształt strumienia alertów

AI w przedsiębiorstwie tworzy jednocześnie dwa strumienie bezpieczeństwa: głośne wykonywanie działań przez agentów i cichy przepływ danych firmowych.

Głośny strumień pochodzi głównie od użytkowników technicznych. Agenci programistyczni mogą tworzyć skrypty, uruchamiać interpretery, instalować pakiety, przeglądać repozytoria, otwierać porty lub wykonywać narzędzia programistyczne. Każde z tych działań może przypominać jeden z etapów intruzji.

Deweloper może poprosić agenta o uruchomienie lokalnego serwera testowego. Agent może uruchomić PowerShell, znaleźć nieużywany port, uruchomić Python i przekierować dane wyjściowe do dzienników projektu. Produkt chroniący punkt końcowy widzi nietypowy łańcuch procesów, zanim dostrzeże nieszkodliwy cel programistyczny.

Intezer stwierdził, że taki wzorzec generował podpisany binarny plik sandboxa OpenAI Codex. PowerShell następnie uruchamiał cmd.exe, python.exe i conhost.exe podczas przygotowywania lokalnego środowiska projektu.

Konwencjonalna reguła zinterpretowała tę sekwencję jako możliwą odwrotną powłokę. Tekst polecenia wskazywał natomiast na lokalną orkiestrację na 127.0.0.1, adresie pętli zwrotnej używanym do łączenia się z tym samym komputerem.

Instalatory powodują podobne kolizje. Intezer poinformował, że legalny instalator Claude Desktop uruchamiał detekcje związane z zachowaniem ransomware i zakodowanym wykonywaniem PowerShell. Jego podpis kodu potwierdził tożsamość pakietu, ale reguły behawioralne nadal traktowały sekwencję instalacji jako podejrzaną.

Nie oznacza to, że detekcja behawioralna jest przestarzała. Podpisane oprogramowanie może stać się złośliwe, a zaufane aplikacje mogą zostać wykorzystane. Oznacza to, że detekcja wymaga dodatkowego kontekstu, zanim analityk będzie mógł przypisać intencję.

Cichy strumień wynika z nietechnicznej adopcji. Pracownicy mogą przyznawać usłudze AI dostęp do firmowych kont, przesyłać dokumenty lub wklejać wrażliwe materiały do promptów. Działania te mogą nigdy nie wygenerować nietypowego procesu na punkcie końcowym.

Intezer zaobserwował zgody OAuth przyznane ChatGPT w wielu tenantach. Zaobserwował również pierwsze logowania do aplikacji OpenAI oraz grupę alertów ochrony danych dotyczących przesyłania treści do generatywnej AI u jednego klienta.

Większość zdarzeń była nieszkodliwa. Mimo to oznaczały one przepływ informacji firmowych do usług znajdujących się poza bezpośrednią kontrolą punktu końcowego.

To rozróżnienie wyjaśnia, dlaczego blokowanie kilku plików wykonywalnych nie może rozwiązać problemu bezpieczeństwa AI w przedsiębiorstwie. Część ryzyka znajduje się w procesach. Inna część istnieje w sesjach przeglądarki, uprawnieniach tożsamości, integracjach oprogramowania i przepływach danych.

Użyteczny spis zasobów potrzebuje zatem czegoś więcej niż listy zatwierdzonych aplikacji. Musi łączyć użytkowników, tożsamości, agentów, rozszerzenia, zgody OAuth, miejsca docelowe danych oraz zasoby, do których każde narzędzie może uzyskać dostęp.

Ta praca wykracza poza SOC. Zespoły tożsamości zarządzają zgodami i dostępem. Zespoły zarządzania danymi definiują informacje wrażliwe. Liderzy inżynierii decydują, które konfiguracje agentów są akceptowalne.

Zespoły zakupowe i prawne oceniają warunki przetwarzania przez podmioty trzecie. Menedżerowie biznesowi określają, czy pracownicy mają praktyczne, zatwierdzone alternatywy.

SOC pozostaje miejscem, w którym te sygnały się zbiegają. Otrzymuje alerty, gdy narzędzie uruchamia podejrzane polecenie, otwiera tunel lub dotyka chronionych informacji.

Wdrożenie w całej firmie zmienia również znaczenie atrybucji. Przed pojawieniem się agentów ogólnego przeznaczenia polecenie wykonane na koncie użytkownika zwykle odzwierciedlało albo działania użytkownika, albo atakującego kontrolującego to konto.

Agent wprowadza trzeciego uczestnika. Działa z uprawnieniami użytkownika, ale może wybierać polecenia, których użytkownik nigdy nie sprawdził. Aktywność należy do konta, nie odzwierciedlając w pełni bezpośredniego działania właściciela konta.

Ta luka ma szczególne znaczenie dla osi czasu incydentu. Analitycy muszą wiedzieć, czy człowiek wpisał polecenie, czy wygenerował je zatwierdzony agent, czy też złośliwa treść zmanipulowała agenta.

Zespoły bezpieczeństwa potrzebują także trwałego kontekstu organizacyjnego. Przeszukiwalna baza wiedzy inżynieryjnej może zachować zatwierdzone przepływy pracy i lokalne decyzje techniczne. Dokumentacja musi jednak łączyć się z bieżącymi dowodami dotyczącymi tożsamości i punktów końcowych, aby wspierać triage.

Celem operacyjnym nie jest pełna widoczność każdego promptu. Chodzi o wystarczający, zweryfikowany kontekst, aby odróżniać zatwierdzoną pracę, niebezpieczne zachowanie i aktywność przeciwnika bez monitorowania pracowników szerzej, niż jest to konieczne.

Starsza logika detekcji zderza się z normalnym zachowaniem agentów

Głównym starciem jest konflikt między starszą logiką detekcji a kontekstem agentów AI, a nie między analitykami a automatyzacją.

Produkty bezpieczeństwa często wykrywają techniki, a nie intencję. Dostęp do poświadczeń, wykonywanie poleceń, utrwalanie, tunelowanie i zbieranie danych pozostają niebezpieczne niezależnie od tego, która aplikacja je inicjuje.

Agenci AI komplikują ten model, ponieważ legalne narzędzia wykonują obecnie kombinacje działań kojarzone wcześniej głównie z administratorami, testerami penetracyjnymi i atakującymi. To nakładanie się ma charakter strukturalny, a nie przypadkowy.

Intezer odnotował wskaźniki nieszkodliwości od 77% do 99% wśród najbardziej zaszumionych grup detekcji związanych z AI. Kilka reguł mylnie oceniało zachowanie generowane przez AI ponad cztery razy na pięć.

Jeden przykład dotyczył OpenAI Codex uruchomionego przez Node.js z flagami takimi jak --yolo lub --dangerously-skip-permissions. Powstała aktywność uruchamiała detekcje związane z ClickFix, wyłączonymi narzędziami i wstrzykiwaniem DLL.

Flagi omijające uprawnienia usuwają prośby o zatwierdzenie, zanim agent podejmie działania. Deweloperzy używają ich, aby ograniczyć przerwy, ale ta sama wygoda osłabia ważną granicę kontrolną.

Klaster ClickFix był wyjątkiem wśród ustaleń Intezer dotyczących szumu. Tylko 37% tych alertów było nieszkodliwych. Nie oznacza to, że każdy alert jest atakiem, ale nadaje temu klastrowi większą wartość dochodzeniową.

W tym miejscu proste dodawanie do listy dozwolonych nie działa. Uznanie Codex, Claude lub Cursor za zaufane zmniejszyłoby szum, ale mogłoby też ukryć niebezpieczne działania uruchamiane za pośrednictwem tych narzędzi.

Bezpieczniejsze podejście ocenia cały łańcuch. SOC powinien uwzględniać podpisaną aplikację, użytkownika inicjującego, konfigurację agenta, zlecone zadanie, procesy potomne, zasoby, do których uzyskano dostęp, miejsce docelowe w sieci oraz wynikający z tego przepływ danych.

Macierz zagrożeń AI MITRE odzwierciedla tę szerszą perspektywę. Obejmuje wywoływanie narzędzi przez agentów, przechwytywanie poświadczeń, prompt injection, odwrotne powłoki oraz eksfiltrację za pośrednictwem mechanizmów związanych z AI.

Techniki te pokazują, dlaczego zatwierdzony agent nie może otrzymać trwałego, bezwarunkowego zaufania. Narzędzie może być legalne, podczas gdy konkretne wywołanie pozostaje niebezpieczne.

Inżynieria detekcji musi zatem stać się bardziej warunkowa. Lokalny serwer uruchomiony w znanym repozytorium programistycznym może być rutynowy. Ten sam interpreter tworzący zewnętrzny tunel ze stacji roboczej działu finansów zasługuje na inne traktowanie.

Agent programistyczny odczytujący własny token konfiguracyjny może działać zgodnie z oczekiwaniami. Zrzucenie całego pęku kluczy macOS do pliku tymczasowego nie jest proporcjonalne do tego zadania.

Intezer zaobserwował dokładnie taki wzorzec. Agent użył security dump-keychain i przekierował wynik do lokalizacji tymczasowej, próbując odzyskać zapisane poświadczenia.

Zamierzone zadanie nie wymagało złośliwych zamiarów. Wybrana metoda nadal ujawniła więcej informacji, niż było to konieczne, i stworzyła cenny cel na dysku.

Inny przypadek dotyczył edytora kodu AI, który uruchomił PowerShell, a następnie ngrok — usługę tworzącą tunele dostępne z internetu. Otworzył nazwany tunel zwrotny, używając tokenu uwierzytelniającego pracownika.

Cel użytkownika mógł być uzasadniony, na przykład związany z rozwiązywaniem problemów lub programowaniem. Mimo to działanie utworzyło rzeczywistą ścieżkę z publicznego internetu do środowiska przedsiębiorstwa.

Trzeci przykład dotyczył Cursor, który zainicjował łańcuch procesów wykorzystujący znaną metodę zrzucania pamięci. Cursor uruchomił PowerShell, który wywołał rundll32.exe oraz funkcję MiniDump w comsvcs.dll.

Ta technika może wydobywać sekrety z pamięci procesu. Nawet gdy agent wybiera ją do celów debugowania, takie zachowanie stwarza ryzyko dostępu do poświadczeń, które zasługuje na zbadanie.

Przykłady te wspierają politykę opartą na działaniach i granicach, a nie wyłącznie na nazwach produktów. Zatwierdzeni agenci powinni nadal podlegać ograniczeniom dotyczącym magazynów poświadczeń, systemów produkcyjnych, publicznych tuneli i wrażliwych repozytoriów.

Pomóc może izolacja. Intezer zaleca uruchamianie narzędzi AI w środowiskach o ograniczonych uprawnieniach, w tym w kontenerach lub maszynach wirtualnych, gdy pozwala na to przepływ pracy.

Kontener pakietuje proces wraz z określonymi zasobami i granicami dostępu. Maszyna wirtualna zapewnia odrębne środowisko operacyjne, oferujące w wielu konfiguracjach silniejszą izolację.

Żaden z tych mechanizmów nie jest absolutny. Kontenery mogą być błędnie skonfigurowane, a maszyny wirtualne nadal wymagają kontroli tożsamości, sieci, pamięci masowej i aktualizacji. Oba rozwiązania mogą ograniczyć liczbę zasobów, do których agent ma domyślnie dostęp.

Poprawiają też atrybucję. Aktywność pochodzącą z przypisanego środowiska agenta łatwiej odróżnić od zwykłej aktywności użytkownika na komputerze.

Zmiana wymaga starannego pomiaru. Zespoły powinny śledzić wskaźniki fałszywych trafień według detekcji, agenta, konfiguracji i jednostki biznesowej. Powinny też rejestrować, które wyciszenia wymagały później korekty.

Powszechne ograniczenie liczby alertów nie oznacza sukcesu. Użyteczną miarą jest to, czy dostrajanie eliminuje przewidywalny szum bez ukrywania dostępu do poświadczeń, zewnętrznej ekspozycji lub przepływu wrażliwych danych.

Ciche zagrożenia bezpieczeństwa AI mają większe znaczenie niż głośne alerty

Najpoważniejsze ryzyka AI w danych Intezer częściej wynikały z ekspozycji niż z potwierdzonych naruszeń lub alertów o najwyższym poziomie istotności.

Intezer sklasyfikował 5,8% populacji związanej z AI jako rzeczywiste zagrożenia bezpieczeństwa. Zdarzenia te nie dowodziły, że atakujący uzyskał dostęp. Wskazywały na warunki, które mogły uczynić późniejszy kompromis bardziej szkodliwym.

Centralnym przykładem było omijanie uprawnień. Agent działający bez monitów o zatwierdzenie może wykonać długi ciąg działań, zanim użytkownik zobaczy szczegóły.

Taki projekt staje się bardziej niebezpieczny, gdy agent odczytuje niezaufany kod, strony internetowe, zgłoszenia, e-maile lub dokumenty. Złośliwe instrukcje ukryte w tych źródłach mogą wpływać na wybory agenta.

Prompt injection to próba nakłonienia modelu do wykonania wrogich instrukcji osadzonych w jego danych wejściowych. Staje się poważniejsza, gdy agent może korzystać z narzędzi lub uzyskiwać dostęp do danych biznesowych.

Pośrednie wstrzyknięcie może dotrzeć przez treść, której użytkownik nigdy nie uznaje za instrukcję. Strona internetowa lub plik w repozytorium może zawierać tekst przeznaczony dla agenta, a nie dla ludzkiego czytelnika.

Profil generative AI NIST zaleca zarządzanie, mapowanie, mierzenie i kontrolowanie ryzyk AI przez cały cykl życia systemu. Model ten pasuje do agentów przedsiębiorstw, ponieważ ryzyko przekracza granice technologiczne i organizacyjne.

Alert z punktu końcowego może ujawnić końcowe polecenie, ale nie treść, która wpłynęła na model. Dziennik tożsamości może wskazać przyznanie OAuth bez pokazania, które dokumenty później trafiły do usługi.

Produkt zapobiegający utracie danych może wykryć przesłanie pliku, ale nie znać jego biznesowego celu. Każde narzędzie obserwuje tylko jeden fragment zdarzenia.

SOC potrzebuje korelacji między tymi fragmentami. Gdy pozwalają na to dostępne dane telemetryczne, powinien łączyć użytkownika, agenta, źródło promptu, uprawnienia, aktywność procesów, miejsce docelowe i klasyfikację danych.

Nie wymaga to gromadzenia każdej rozmowy pracownika. Prywatność i proporcjonalność pozostają ważne. Organizacje powinny pozyskiwać minimalny zakres dowodów potrzebny do egzekwowania ustalonej polityki i badania istotnego ryzyka.

Jasna polityka ma również znaczenie, ponieważ to samo działanie może mieć różne konsekwencje w różnych działach. Przesłanie publicznej treści marketingowej różni się od przesłania danych klientów, nieopublikowanych informacji finansowych lub kodu źródłowego zawierającego sekrety.

Zatwierdzone narzędzia nie eliminują tej różnicy. Licencjonowanie przedsiębiorstwa może poprawić kontrolę administracyjną, lecz nie jest w stanie rozstrzygnąć, czy każda informacja powinna znaleźć się w każdym prompcie.

Podobnej uwagi wymaga zgoda OAuth. OAuth pozwala użytkownikowi autoryzować aplikację bez przekazywania hasła. Powstały token może jednak nadal zapewniać szeroki dostęp do poczty, plików, kalendarzy lub innych usług.

Zakresy dostępu wymagane przez legalną aplikację AI mogą wykraczać poza bezpośrednie zadanie. Przejęte konto lub zmanipulowany agent mogą wówczas wykorzystać te uprawnienia w sposób, którego pracownik nigdy nie zamierzał.

Zespoły SOC powinny analizować zgody o wysokim ryzyku, nietypowe aplikacje używane po raz pierwszy oraz uprawnienia przekraczające granice wrażliwych systemów. Powinny też zapewnić użytkownikom szybką ścieżkę składania wniosków o zatwierdzone integracje.

Jeśli nadzór postępuje zbyt wolno, pracownicy będą go omijać. Powstaje w ten sposób shadow AI, czyli narzędzia lub zastosowania działające poza ustaloną organizacyjną akceptacją i nadzorem.

Odpowiedzią nie jest bezkrytyczny zakaz. Zakaz może ograniczyć widoczną aktywność, jednocześnie wypychając użyteczną pracę do prywatnych kont i niezarządzanych sesji przeglądarki.

Zespoły bezpieczeństwa potrzebują praktycznej, zatwierdzonej ścieżki z odpowiednimi mechanizmami kontroli. Pracownicy powinni rozumieć, z których narzędzi mogą korzystać, jakimi informacjami mogą się dzielić i kiedy agent potrzebuje izolowanego środowiska.

CISA i partnerzy międzynarodowi podobnie podkreślili znaczenie odpowiedzialności, przejrzystości i bezpiecznego projektowania w swoich wytycznych dotyczących bezpieczeństwa AI. Zasady te dotyczą dostawców, lecz nabywcy korporacyjni również muszą je oceniać.

Pytania w procesie zakupowym powinny obejmować rejestrowanie zdarzeń, retencję, trenowanie modeli, zakresy dostępu, kontrolę administracyjną, powiadamianie o incydentach i usuwanie danych. Testy techniczne powinny, tam gdzie to możliwe, weryfikować istotne deklaracje.

Playbooki SOC muszą następnie przełożyć politykę na kroki dochodzeniowe. Analityk, który dostrzeże nieznany tunel, powinien móc szybko ustalić odpowiedzialnego agenta, użytkownika, zadanie i miejsce docelowe.

Playbook nie powinien automatycznie zamykać zdarzenia tylko dlatego, że uruchomiło je zatwierdzone narzędzie. Powinien ustalić, czy działanie pozostało w zatwierdzonych granicach.

Ta sama zasada dotyczy dostępu do poświadczeń. Agent odczytujący ograniczony sekret przez zatwierdzonego brokera różni się od eksportowania całego magazynu poświadczeń.

Ten model skoncentrowany na działaniach zachowuje użyteczne detekcje, jednocześnie ograniczając możliwy do uniknięcia szum. Dostosowuje też alerty do ryzyk, którymi organizacja faktycznie postanowiła zarządzać.

Czego dane Intezer jeszcze nie dowodzą

Ustalenia Intezer są użytecznym operacyjnym obrazem sytuacji, ale nie stanowią uniwersalnego pomiaru ryzyka AI w przedsiębiorstwach.

Badanie obejmuje alerty widoczne w środowiskach połączonych z platformą Intezer. Nie reprezentuje każdej firmy, stosu zabezpieczeń, branży, regionu geograficznego ani sposobu wdrażania AI.

Intezer nie opublikował w artykule pełnej liczby klientów ani szczegółowego podziału według sektorów. Zanonimizował również informacje o klientach, hostach, użytkownikach i identyfikatorach.

Chroni to organizacje, ale ogranicza niezależną możliwość odtworzenia wyników. Czytelnicy nie mogą określić, w jakim stopniu jedno duże środowisko wpłynęło na każdą kategorię poza przykładami ujawnionymi przez Intezer.

Badanie mierzy również alerty, a nie całą aktywność AI. Działanie, które nigdy nie uruchamia połączonego mechanizmu kontroli, może nie wystąpić w zbiorze danych.

Ma to największe znaczenie dla narzędzi opartych na przeglądarce, prywatnych kont, niezatwierdzonych rozszerzeń oraz wymian danych, których produkty endpointowe nie potrafią obserwować. Ciche użycie może być niedostatecznie reprezentowane w porównaniu z aktywnością wykonywalnych agentów.

Wskaźnik 94,1% szumu powinien zatem kierować dostrajaniem detekcji, a nie stać się uniwersalnym wskaźnikiem fałszywych trafień. Inna organizacja może mieć innych agentów, polityki, użytkowników lub dane telemetryczne.

Udział ataków wynoszący 0,02% również wymaga ostrożnej interpretacji. Nie dowodzi, że agenci AI są z natury bezpieczni ani że ataki wspierane przez agentów są wszędzie pomijalne.

Pokazuje, że potwierdzone ataki były niezwykle rzadkie w tej konkretnej populacji alertów związanych z AI. Intezer podał, że żaden z tych potwierdzonych ataków nie wynikał z tego, że agent organizacji spowodował kompromis.

Zidentyfikowane rzeczywiste ataki wykorzystywały znane marki AI jako przynęty phishingowe. Atakujący podszywali się pod nazwy takie jak Anthropic, Gemini i OpenAI, ponieważ pracownicy coraz częściej je rozpoznają i im ufają.

Jeden e-mail odnosił się do rzekomej współpracy z Anthropic oraz prośby o płatność. Inny wykorzystywał fałszywe zaproszenie reklamowe Gemini z infrastrukturą niezwiązaną z Google.

Trzeci podszywał się pod wydarzenie partnerskie OpenAI, korzystając z legalnej infrastruktury Zoom, aby zaproszenie wydawało się wiarygodne. W każdym przypadku wdrażanie AI wzmacniało pretekst, zamiast dostarczać nową technikę ataku.

To rozróżnienie jest użyteczne, lecz może się zmienić. Szersze uprawnienia agentów, silniejsze możliwości autonomiczne i głębsze integracje biznesowe zwiększają konsekwencje manipulacji.

Brak wielu potwierdzonych kompromisów spowodowanych przez agentów w tym zbiorze danych nie jest dowodem, że przyszłe wdrożenia pozostaną bezpieczne. To punkt odniesienia do obserwowania tej zmiany.

Na uwagę zasługują również bodźce po stronie dostawcy. Intezer sprzedaje platformę AI SOC oraz usługi automatycznej triage. Jego badania w naturalny sposób eksponują problemy, które może rozwiązać analiza kontekstowa i automatyzacja.

Nie unieważnia to danych. Oznacza, że nabywcy powinni porównać wyniki z własnymi danymi telemetrycznymi, ustaleniami red teamów i historią incydentów przed zmianą mechanizmów kontroli.

Zespoły bezpieczeństwa powinny sprawdzać, czy automatyczne werdykty pozostają trafne w ich środowisku. Powinny próbnie analizować wyciszone alerty, przeglądać niepewne klasyfikacje oraz monitorować późniejsze dowody przeczące wcześniejszej decyzji.

Powinny też dokumentować różnicę między zweryfikowanymi wynikami a deklaracjami dostawcy. Na przykład Intezer twierdzi, że jego szersza platforma może badać alerty na dużą skalę, lecz badanie to nie weryfikuje niezależnie każdej deklaracji dotyczącej wydajności.

Trudniejsze pytanie dotyczy brakujących sygnałów. SOC może ograniczyć widoczny szum, a jednocześnie nadal nie mieć pokrycia dla nieautoryzowanych narzędzi przeglądarkowych lub ryzykownego udostępniania danych.

Dlatego redukcja alertów nie może być jedyną miarą sukcesu. Zespoły potrzebują również pokrycia inwentaryzacji agentów, liczby ryzykownych uprawnień, trendów dotyczących przesyłania wrażliwych danych oraz czasu potrzebnego do prześledzenia działania do jego źródła.

Organizacja z mniejszą liczbą alertów, lecz bez widoczności aktywności OAuth lub przeglądarki, niekoniecznie poprawiła swoje bezpieczeństwo. Mogła jedynie przenieść ryzyko poza mierzony kanał.

Trzy sygnały pokażą, czy SOC-y się dostosowują

Kolejnym sprawdzianem będzie to, czy zespoły bezpieczeństwa potrafią poprawiać kontekst szybciej, niż rozszerza się aktywność AI.

Pierwszym sygnałem jest skuteczność w zakresie fałszywych trafień dla detekcji związanych z agentami. Liderzy SOC powinni mierzyć odsetek zdarzeń łagodnych przed i po dostrojeniu najbardziej zaszumionych reguł.

Udana zmiana zmniejszy liczbę powtarzających się alertów dotyczących znanych instalatorów, lokalnych serwerów deweloperskich i zatwierdzonych łańcuchów procesów. Zachowa konieczność weryfikacji przypadków obchodzenia uprawnień, zrzucania poświadczeń, zewnętrznych tuneli i nietypowego przepływu danych.

Jeśli odsetek zdarzeń łagodnych spada bez wzrostu liczby pominiętych incydentów, SOC uczy się normalnego zachowania AI. Jeśli analitycy nadal ręcznie zamykają te same wzorce, wdrażanie wciąż wyprzedza inżynierię detekcji.

Drugim sygnałem jest zasięg ochrony w przedsiębiorstwie obejmujący kontrolę tożsamości, przeglądarki, punkty końcowe, chmurę i dane. Lista zainstalowanych agentów programistycznych nie stanowi kompletnego spisu AI.

Zespoły powinny szukać nowych przyznań OAuth, pierwszych logowań do aplikacji AI, niezarządzanych rozszerzeń, użycia prywatnych kont oraz połączeń między agentami a wrażliwymi repozytoriami.

Lepszy zasięg początkowo ujawni więcej ukrytej ekspozycji. Tego przejściowego wzrostu nie należy mylić z pogorszeniem bezpieczeństwa. Lepsze pomiary często uwidaczniają istniejące ryzyko, zanim kontrole je ograniczą.

Trzecim sygnałem jest to, czy wdrożenia agentów domyślnie przyjmują ograniczone środowisko wykonawcze. Monity o uprawnienia, ograniczone poświadczenia, izolowane środowiska i limitowany dostęp do sieci wyznaczają mierzalne granice.

Organizacje powinny obserwować odsetek agentów uruchamianych z flagami obchodzenia zabezpieczeń. Powinny także monitorować, jak często agenci próbują wykonywać zakazane polecenia, nawet gdy mechanizm kontroli blokuje ich uruchomienie.

Spadający wskaźnik obchodzenia zabezpieczeń wzmocniłby argument, że zarządzanie staje się operacyjne. Dalszy wzrost pokazałby, że wygoda nadal przeważa nad izolacją.

Testy bezpieczeństwa powinny obejmować realistyczne przepływy pracy agentów, a nie tylko prompty dla modeli. Ocena może umieścić niezaufane instrukcje w kodzie, dokumentach, zgłoszeniach lub treściach internetowych i obserwować reakcję agenta.

Celem jest przetestowanie całego systemu. Obejmuje to uprawnienia tożsamości, narzędzia, pamięć, zewnętrzne treści, kontrolę wykonania, rejestrowanie oraz zatwierdzanie przez człowieka.

Alerty Intezer AI SOC dają wczesny obraz tej transformacji. Główny wynik jest uspokajający tylko na pierwszy rzut oka. Potwierdzone ataki zdarzały się rzadko, lecz ekspozycja i szum operacyjny już szybko rosły.

Dla zespołów SOC bezpośrednie pytanie jest konkretne: czy potrafią rozpoznać normalne zachowanie agentów, nie obdarzając ich bezwarunkowym zaufaniem?

Zacznij od detekcji generujących najwięcej powtarzających się łagodnych alertów. Następnie porównaj to dostrajanie z przypadkami obchodzenia uprawnień, dostępu do poświadczeń, tuneli, przyznań OAuth i przesyłania wrażliwych danych. Jeśli te sygnały o wyższej wartości stają się łatwiejsze do dostrzeżenia, SOC się dostosowuje. Jeśli liczba alertów spada, podczas gdy widoczność pozostaje fragmentaryczna, pozorna poprawa oznacza jedynie cichszą niepewność.