Snyk ostrzega: przedsiębiorstwa nie widzą dwóch trzecich swojej powierzchni ataku AI

Snyk przedstawił alarmującą liczbę dotyczącą ryzyka AI w przedsiębiorstwach: niemal dwie trzecie istotnej powierzchni ataku może pozostawać poza bezpośrednią widocznością zespołów bezpieczeństwa. Ostrzeżenie, nagłośnione przez Google News, dotyczy agentów, wtyczek, zestawów danych i potoków danych połączonych w codziennej pracy. Liczba tych komponentów rośnie, gdy firmy przenoszą eksperymenty z AI do środowisk produkcyjnych.

Liczba pochodzi od Snyk, a nie z niezależnego audytu całego rynku przedsiębiorstw. Analiza pomocnicza wykorzystuje zanonimizowane informacje z ponad 500 środowisk przedsiębiorstw związanych z Snyk Evo. To rozróżnienie ma znaczenie. Dane dają wgląd w środowiska uczestniczące w badaniu, podczas gdy szersze twierdzenie nadal wymaga potwierdzenia na innych platformach i w innych branżach.

Nawet z tym zastrzeżeniem Snyk opisuje problem wykraczający poza telemetrię jednego dostawcy. Badanie Cloud Security Alliance wykazało, że 68% ankietowanych organizacji nie potrafiło wyraźnie odróżnić działań agentów AI od aktywności ludzi. OWASP osobno udokumentował prompt injection, nadmierne uprawnienia i niekontrolowaną autonomię jako istotne zagrożenia dla aplikacji.

Główny konflikt nie dotyczy więc wdrażania AI kontra oporu wobec niej. Chodzi o szybkie, zdecentralizowane wdrożenia zestawione z systemami bezpieczeństwa zbudowanymi wokół znanych aplikacji, tożsamości ludzkich i stabilnych rejestrów zasobów. Przedsiębiorstwa upoważniają coraz więcej oprogramowania do rozumowania i działania, jednocześnie tracąc pewność co do tego, co jest połączone z ich danymi.

Ta luka wywiera presję na zespoły bezpieczeństwa, ale dotyczy także programistów, inżynierów platformowych, osób odpowiedzialnych za zakupy i właścicieli biznesowych. Każda z tych grup może wprowadzić zależność od AI. Niewiele organizacji ma jeden system zdolny mapować wynikający z tego łańcuch od modelu przez wtyczkę, tożsamość, zestaw danych i API aż po działanie produkcyjne.

Dlaczego ostrzeżenie Snyk trafiło do Google News

Najważniejsze twierdzenie Snyk nie brzmi, że AI tworzy nowe podatności. Chodzi o to, że przedsiębiorstwa nie potrafią wiarygodnie zobaczyć systemów, które je tworzą.

Snyk zaprezentował swoją AI Security Fabric w lutym 2026 roku jako warstwę obejmującą rozwój oprogramowania i systemy agentowe. Firma poinformowała, że jej podejście będzie łączyć widoczność, prewencję i zarządzanie w całym cyklu życia rozwoju oprogramowania.

Zapowiedź produktu obejmowała ustalenia z badania Snyk 2026 State of Agentic AI Adoption. Według firmy analiza objęła zanonimizowane dane z ponad 500 środowisk przedsiębiorstw Evo. Snyk podał, że każdy wdrożony model AI był powiązany z niemal trzykrotnie większą liczbą ukrytych komponentów, w tym zestawów danych i narzędzi zewnętrznych.

Główne twierdzenie rozwija tę obserwację. Snyk twierdzi, że około dwie trzecie ryzyka AI w przedsiębiorstwach znajduje się poniżej najbardziej widocznej warstwy modelu. Ukryta część obejmuje narzędzia agentów, wtyczki, połączone repozytoria, usługi zewnętrzne i potoki danych, które pracownicy dołączają podczas rozwoju lub codziennej pracy.

Komponenty te nie są automatycznie złośliwe. Wtyczka może po prostu pobierać dokument, wywoływać wewnętrzne API albo wysyłać zatwierdzoną wiadomość. Problem bezpieczeństwa wynika z relacji między komponentem, jego uprawnieniami, źródłami wejściowymi i zdolnością do uruchamiania działań w dalszych etapach procesu.

Sam rejestr modeli nie jest w stanie uchwycić tych relacji. Dwa zespoły mogą używać tego samego modelu za pośrednictwem różnych agentów o całkowicie odmiennych profilach ryzyka. Jeden agent może streszczać publiczne dokumenty. Inny może odczytywać kod źródłowy, przeszukiwać rejestry klientów i zapisywać zmiany w systemach produkcyjnych.

Dlatego ta historia zasługuje na więcej niż znane ostrzeżenie przed pracownikami używającymi niezatwierdzonych chatbotów. Shadow AI obejmuje obecnie funkcje osadzone w zatwierdzonym oprogramowaniu, modele wdrażane lokalnie, frameworki agentowe, rozszerzenia przeglądarek, usługi automatyzacji i tożsamości maszynowe. Część z nich trafia do firmy poprzez formalne zakupy. Inne pojawiają się, gdy pracownik podłącza jeszcze jedno narzędzie, aby ukończyć zadanie.

Google News zapewnia temu twierdzeniu szeroki kanał dystrybucji, ale agregacja nie potwierdza stojącej za nim liczby. Czytelnicy powinni traktować szacunek dwóch trzecich jako ustalenie dostawcy oparte na danych Snyk dotyczących środowisk klientów. Silniejszy wniosek opiera się na potwierdzających dowodach: przedsiębiorstwa mają trudności z inwentaryzacją zachowań agentów, uprawnień i zależności między komponentami.

To rozróżnienie chroni analizę przed przekształceniem się w marketing produktu. Precyzyjny, ogólnorynkowy szacunek Snyk pozostaje otwarty na weryfikację. Sam problem widoczności jest już potwierdzony przez wiele niezależnych źródeł i źródeł zorientowanych na standardy.

Powierzchnia ataku AI nie jest już listą aplikacji

Praktyczna powierzchnia ataku zachowuje się teraz jak zmieniający się graf, w którym modele, tożsamości, narzędzia i magazyny danych tworzą ryzyko poprzez swoje połączenia.

Tradycyjne bezpieczeństwo aplikacji zaczyna się od względnie stabilnego obiektu. Zespół jest właścicielem aplikacji, utrzymuje jej repozytorium, śledzi zależności i wdraża ją przez znaną infrastrukturę. Narzędzia bezpieczeństwa mogą skanować kod, pakiety, obrazy kontenerów, konfigurację chmury i wystawione punkty końcowe.

Systemy natywnie wykorzystujące AI dodają więcej ruchomych elementów. Analiza Snyk dotycząca aplikacji natywnie wykorzystujących AI opisuje łańcuch dostaw, który może obejmować wstępnie wytrenowane modele, embeddingi, agentów zewnętrznych, zestawy danych i usługi zewnętrzne. Każdy komponent może zmieniać się niezależnie od kodu źródłowego aplikacji.

Embedding to numeryczna reprezentacja służąca do porównywania znaczenia treści. Wektorowa baza danych może przechowywać miliony takich reprezentacji na potrzeby wyszukiwania. Jeśli uprawnienia lub etykiety źródeł są błędne, agent może odzyskać informacje, do których jego użytkownik nigdy nie powinien mieć dostępu.

Generowanie wspomagane wyszukiwaniem, często skracane do RAG, przekazuje modelowi wybrane dokumenty lub rekordy przed wygenerowaniem odpowiedzi. RAG może poprawiać dokładność, ale tworzy też kolejną granicę zaufania. Warstwa wyszukiwania musi decydować, jakie źródła agent może przeszukiwać i jakie treści powinien zwracać.

Narzędzia tworzą granicę o większym znaczeniu. Agent połączony z pocztą e-mail, kontrolą źródłową, infrastrukturą chmurową lub bazą danych klientów może wyjść poza generowanie tekstu. W zależności od uprawnień nadanych przez programistów może odczytywać, zapisywać, wykonywać, zatwierdzać lub przesyłać informacje.

Tworzy to niedopasowanie względem rejestrów bezpieczeństwa organizowanych wokół zakupionych aplikacji. Firma mogła zatwierdzić dostawcę modelu i framework agentowy. Nadal może jednak nie mieć kompletnego rejestru każdego punktu końcowego narzędzia, konta usługi, zestawu danych, szablonu promptu lub wtyczki dołączonej po wdrożeniu.

Łańcuch może się również zmieniać bez tradycyjnego wydania. Dostawca modelu może zaktualizować jego zachowanie. Narzędzie zewnętrzne może dodać funkcję. Zestaw danych może otrzymać nowe dokumenty. Użytkownik może rozszerzyć zakres OAuth, który określa, do czego aplikacja może uzyskać dostęp przez delegowaną autoryzację.

Zmiany te mają znaczenie, ponieważ ryzyko zależy od kombinacji. Agent streszczający z dostępem tylko do odczytu ma ograniczony promień rażenia. Przyznaj temu samemu agentowi uprawnienie do wysyłania e-maili, edytowania plików i wywoływania nieograniczonego punktu końcowego sieci, a zmanipulowane dane wejściowe mogą doprowadzić do zupełnie innego rezultatu.

Powierzchnia ataku obejmuje zatem więcej niż podatności w kodzie. Obejmuje nadmierne uprawnienia, zatruty kontekst, ujawnione poświadczenia, niebezpieczne przetwarzanie wyników, słabe reguły zatwierdzania i niekompletne dzienniki działań. Kilka z tych problemów pozostaje niewidocznych dla skanerów, które sprawdzają jedynie pliki źródłowe lub znane pakiety oprogramowania.

Dla zespołów inżynieryjnych dokumentacja staje się częścią systemu kontroli. Przeszukiwalny rejestr decyzji architektonicznych, zatwierdzonych narzędzi, zakresów uprawnień i ustaleń z incydentów pomaga zespołom identyfikować relacje pomijane przez pojedyncze pulpity. Ustrukturyzowana baza wiedzy inżynieryjnej może wspierać tę pracę, choć nie zastępuje monitorowania bezpieczeństwa.

Szersza lekcja jest prosta. Systemu AI nie można zarządzać jak pojedynczym punktem końcowym modelu. Należy go traktować jak połączoną aplikację, której dane, narzędzia, tożsamości i działania pozostają widoczne przez cały okres działania.

Agentowa AI wywiera presję na kontrolę tożsamości

Najszybciej rosnąca martwa strefa znajduje się tam, gdzie autonomiczne oprogramowanie dziedziczy uprawnienia zaprojektowane dla użytkowników będących ludźmi.

Cloud Security Alliance opublikowała badanie dotyczące tożsamości agentów w marcu 2026 roku. Badanie wykazało, że 73% organizacji oczekiwało, iż agenci AI staną się kluczowi w ciągu kolejnego roku. Jednak 68% nie potrafiło wyraźnie odróżnić działań wykonywanych przez agentów od działań wykonywanych przez ludzi.

Podobieństwo między wynikiem 68% a ostrzeżeniem Snyk o około dwóch trzecich jest uderzające, lecz liczby te mierzą różne zjawiska. Snyk omawia ukryte komponenty i ryzyko w środowiskach AI. Ankieta Cloud Security Alliance analizuje przypisywanie tożsamości oraz zarządzanie dostępem.

Razem ujawniają tę samą strukturalną słabość. Organizacje przyznają tożsamościom oprogramowania dostęp do systemów biznesowych szybciej, niż aktualizują praktyki uwierzytelniania, autoryzacji i monitorowania.

Tożsamość maszynowa to poświadczenie używane przez oprogramowanie, a nie przez osobę. Może przyjąć postać klucza API, konta usługi, certyfikatu, tożsamości obciążenia roboczego lub tokenu OAuth. Agenci zależą od tych poświadczeń, aby uzyskiwać dostęp do danych i wykonywać działania.

Systemy tożsamości ludzkich zwykle zakładają, że osoba loguje się, otrzymuje określoną rolę i generuje aktywność powiązaną z tym kontem. Agenci komplikują ten model. Jeden agent może działać w imieniu kilku użytkowników, wywoływać kilka narzędzi i w ciągu sekund tworzyć łańcuch operacji generowanych przez maszyny.

Przypisanie odpowiedzialności staje się szczególnie trudne, gdy agent korzysta ze współdzielonego konta usługi. Dzienniki mogą wskazywać, że konto zmieniło rekord lub pobrało plik. Mogą jednak nie identyfikować żądania pracownika, decyzji modelu, odzyskanego dokumentu ani wywołania wtyczki, które spowodowały działanie.

Nie jest to wyłącznie niedogodność audytowa. Słabe przypisanie utrudnia ograniczanie incydentów. Zespół bezpieczeństwa nie może z przekonaniem unieważnić właściwego poświadczenia, jeśli nie wie, który agent, użytkownik lub przepływ pracy zainicjował podejrzaną aktywność.

Nadmiernie uprzywilejowany dostęp zwiększa skalę szkód. Narzędzie stworzone wyłącznie do streszczania wiadomości może otrzymać uprawnienie do ich wysyłania lub usuwania. Asystent kodowania może uzyskać dostęp do zapisu w wielu repozytoriach, choć potrzebuje jedynie przejrzeć jeden projekt.

OWASP opisuje ten stan jako nadmierną autonomię. Jego wytyczne wskazują nadmierną funkcjonalność, uprawnienia i autonomię jako przyczyny źródłowe. OWASP zaleca ograniczanie dostępnych narzędzi, zawężanie uprawnień, wykonywanie działań w kontekście użytkownika oraz wymaganie zatwierdzenia dla operacji o dużym wpływie.

Kontrole te przypominają dojrzałe praktyki zero trust. Każde żądanie powinno być oceniane z użyciem konkretnej tożsamości, zdefiniowanej autoryzacji i bieżącego kontekstu. Model nie powinien samodzielnie decydować, czy operacja jest dozwolona.

Agent potrzebuje też tożsamości odrębnej od tożsamości jego ludzkiego operatora. Dzienniki powinny zachowywać związek między żądaniem użytkownika, instancją agenta, wybranym narzędziem, użytymi poświadczeniami oraz wynikową akcją. Bez tego łańcucha firmy mogą gromadzić ogromne ilości telemetrii, a mimo to pozostawać ślepe.

W tym miejscu wdrażanie AI wywiera presję na architekturę bezpieczeństwa. Zespoły biznesowe chcą asystentów, którzy eliminują powtarzalne zatwierdzenia i wykonują wieloetapowe zadania. Zespoły bezpieczeństwa potrzebują punktów kontrolnych, wąskich uprawnień i decyzji, które można odtworzyć. Usunięcie każdego punktu kontrolnego zwiększa szybkość, ale poszerza też potencjalny zasięg szkód wynikających z błędnego lub zmanipulowanego działania.

Konfliktu nie da się rozwiązać przez wybór pełnej autonomii albo zakazanie agentów. Przedsiębiorstwa potrzebują różnych poziomów autonomii w zależności od konsekwencji. Tworzenie szkicu podsumowania może pozostać automatyczne. Wysyłanie środków, usuwanie rekordów, zmienianie infrastruktury produkcyjnej lub ujawnianie chronionych danych powinno wymagać silniejszych mechanizmów kontroli.

Rzeczywisty kompromis dotyczy szybkości i weryfikowalnej kontroli

Przedsiębiorstwa zyskują wartość, gdy agenci przekraczają granice systemów, ale każde dodatkowe połączenie utrudnia weryfikację ich zachowania.

Agentowa AI jest atrakcyjna dla firm, ponieważ może łączyć odrębne kroki w jeden przepływ pracy. Agent wsparcia może odczytać zgłoszenie, pobrać historię konta, sklasyfikować pilność, zaproponować odpowiedź i zaktualizować rekord klienta. Taka sekwencja może ograniczyć potrzebę ręcznej koordynacji.

Ta sama sekwencja obejmuje kilka granic bezpieczeństwa. Zgłoszenie może zawierać niezaufany tekst. Historia konta może zawierać chronione dane. Model może wygenerować niebezpieczną instrukcję dla narzędzia. System klienta może zaakceptować aktualizację o trwałych konsekwencjach.

Wstrzykiwanie promptów konkretyzuje ten kompromis. Prompt injection występuje, gdy spreparowana treść zmienia sposób, w jaki model wykonuje instrukcje. Treść może pochodzić bezpośrednio od użytkownika albo pośrednio ze strony internetowej, dokumentu, e-maila, repozytorium lub pobranego rekordu.

Tradycyjna aplikacja rozdziela polecenia od danych za pomocą ścisłej składni i kontroli dostępu. Modele językowe przetwarzają oba jako tokeny w obrębie kontekstu. Taka konstrukcja utrudnia zagwarantowanie, że model zawsze potraktuje zewnętrzny tekst jako niezaufane dane, a nie jako instrukcję.

Aktualne wytyczne OWASP stwierdzają, że nie jest znana niezawodna metoda zapobiegania prompt injection. Zalecają ograniczanie zachowania, walidację oczekiwanych formatów wyjściowych, filtrowanie wejść i wyjść oraz ograniczanie uprawnień dostępnych dla modelu.

Te środki łagodzą skutki, ale nie tworzą pewności. Agent, który może jedynie odczytywać wąski zbiór dokumentów, stanowi mniejsze zagrożenie niż agent mogący wykonywać polecenia powłoki. Krok zatwierdzenia przez człowieka może wychwycić podejrzane działania, ale tylko wtedy, gdy osoba oceniająca otrzyma wystarczający kontekst, aby podjąć świadomą decyzję.

Szybkość wywiera presję na każde zabezpieczenie. Zespoły mogą przyznawać szeroki dostęp, aby uniknąć powtarzalnej pracy integracyjnej. Mogą używać współdzielonych poświadczeń, ponieważ autoryzacja per użytkownik wymaga więcej czasu na wdrożenie. Mogą wyłączać komunikaty o zatwierdzeniu, gdy użytkownicy skarżą się na utrudnienia.

To sprawia, że sednem rywalizacji jest kompromis między szybkością wdrożenia a weryfikowalną kontrolą. Snyk twierdzi, że bezpieczeństwo musi stać się procesem ciągłym, ponieważ systemy AI zmieniają się zbyt szybko na okazjonalne przeglądy. Interes handlowy firmy jest oczywisty, ponieważ sprzedaje ona produkty pozycjonowane wokół tego wymogu.

Kupujący powinni zatem oddzielić diagnozę od proponowanej platformy. Ujednolicona warstwa bezpieczeństwa może poprawić widoczność, ale żaden dostawca nie udowodnił, że jeden produkt może obserwować każdy model, lokalne wdrożenie, narzędzie przeglądarkowe, zbiór danych, tożsamość i zewnętrzną integrację w dużym przedsiębiorstwie.

Twierdzenia o zasięgu zależą od integracji i telemetrii. Zatwierdzony model chmurowy może być łatwy do wykrycia. Lokalnie hostowany model na stacji roboczej dewelopera — niekoniecznie. Funkcja AI w znanym pakiecie oprogramowania może generować aktywność wyglądającą jak zwykły ruch aplikacyjny.

Szyfrowane połączenia i zasady prywatności wprowadzają kolejne ograniczenia. Monitorowanie promptów lub pobranych dokumentów może ujawniać wrażliwe dane pracowników i klientów. Zespoły bezpieczeństwa potrzebują wystarczającego kontekstu, aby wykrywać nadużycia, bez budowania drugiego repozytorium poufnych informacji.

Regionalne przepisy dotyczące danych dodają kolejne ograniczenie. Międzynarodowa firma może nie być w stanie scentralizować wszystkich dzienników interakcji AI. Może potrzebować lokalnego przetwarzania, selektywnych metadanych, kontroli retencji oraz różnych polityk monitorowania dla różnych jurysdykcji.

Te komplikacje nie podważają ostrzeżenia Snyk. Wzmacniają jego główną tezę, jednocześnie kwestionując każde proste rozwiązanie. Widoczność jest konieczna, ale sama w sobie tworzy koszty projektowe, związane z prywatnością i operacyjne.

Czego twierdzenie o dwóch trzecich nie dowodzi

Dane Snyk sygnalizują poważną lukę w zarządzaniu, ale nie dowodzą, że dwie trzecie każdego środowiska przedsiębiorstwa jest naruszone lub podatne na wykorzystanie.

Najważniejszym ograniczeniem jest dobór próby. Snyk opisuje zanonimizowane wnioski z ponad 500 środowisk enterprise Evo. Organizacje korzystające z tego środowiska mogą różnić się od szerszego rynku pod względem wielkości, praktyk programistycznych, dojrzałości AI lub priorytetów bezpieczeństwa.

Firma nie wykazała publicznie, że jej próba reprezentuje każdą branżę lub region geograficzny. Ma też handlowy powód, aby definiować problem w sposób sprzyjający szerszemu zakresowi bezpieczeństwa. Żadna z tych kwestii nie czyni danych fałszywymi, ale obie wymagają ostrożnego przypisania źródła.

„Ryzyko” jest również pojęciem szerszym niż „podatność”. Ukryty komponent może być niezarządzany lub niewystarczająco zinwentaryzowany, nie zawierając przy tym luki możliwej do wykorzystania. Staje się niebezpieczny, gdy połączy się go ze słabymi uprawnieniami, wrażliwymi danymi, niebezpiecznymi wejściami lub możliwością wykonywania działań o istotnych konsekwencjach.

Podobnie „dwie trzecie” nie oznacza, że zespoły bezpieczeństwa widzą dokładnie jedną trzecią każdego środowiska. Szacunek podsumowuje wzorce w obserwowanych środowiskach. Poszczególne organizacje mogą mieć znacznie lepsze lub gorsze pokrycie.

Określenie „powierzchnia ataku” może dodatkowo zacierać różnice między różnymi problemami. Może obejmować zasoby dostępne z internetu, wewnętrzne API, zależności programistyczne, narzędzia agentów, przepływy danych, tożsamości i zachowanie modeli. Różni dostawcy liczą te elementy inaczej.

Niezależny pomiar będzie wymagał wspólnych definicji. Badacze muszą odróżniać znane zasoby od nieznanych zasobów, dostępne komponenty od nieaktywnych komponentów oraz ekspozycję teoretyczną od wykazanych ścieżek ataku. Bez tych rozróżnień duże wartości procentowe przyciągają uwagę, ale oferują ograniczone wskazówki operacyjne.

NIST zapewnia bardziej neutralną podstawę za pośrednictwem swoich AI Risk Framework. Ramy organizują pracę wokół zarządzania ryzykiem AI, jego mapowania, mierzenia i kontrolowania. Podkreślają również, że zarządzanie ryzykiem powinno trwać przez cały cykl życia systemu.

Mapowanie jest szczególnie istotne dla twierdzenia Snyk. Organizacja musi zidentyfikować model, zamierzone zadanie, użytkowników, dane, zależności, kontekst wdrożenia i strony, których to dotyczy, zanim będzie mogła zmierzyć ryzyko. Skaner nie jest w stanie odtworzyć każdej brakującej polityki lub decyzji dotyczącej odpowiedzialności.

Pomiar wymaga też testowania. Firma może udokumentować zamierzone uprawnienia agenta, ale nigdy nie zweryfikować jego rzeczywistych uprawnień w środowisku produkcyjnym. Może rejestrować zatwierdzone narzędzia, przeoczając funkcje dodane za pośrednictwem zaktualizowanej integracji.

Sceptyczne stanowisko nie polega więc na twierdzeniu, że martwy punkt jest wyimaginowany. Chodzi o to, że telemetria jednego dostawcy nie może jeszcze określić jego dokładnej wielkości w całym rynku. Nagłówek powinien motywować do inwentaryzacji i testowania, a nie stawać się substytutem któregokolwiek z tych działań.

Liderzy bezpieczeństwa powinni pytać dostawców, jak obliczają pokrycie. Powinni prosić o mianownik, metody wykrywania, wykluczone środowiska, częstotliwość aktualizacji oraz proces rozwiązywania problemu zduplikowanych lub nieaktualnych zasobów. Precyzyjny procent bez tego kontekstu może tworzyć fałszywe poczucie pewności.

Powinni też mierzyć wyniki. Odkrywanie większej liczby komponentów jest użyteczne tylko wtedy, gdy organizacja potrafi priorytetyzować niebezpieczne zależności, przypisywać właścicieli, ograniczać uprawnienia i usuwać zweryfikowane ścieżki. Większa inwentaryzacja, która tworzy niemożliwą do opanowania kolejkę alertów, może stać się kolejną formą ślepoty.

Trzy sygnały pokażą, czy martwy punkt się zmniejsza

Kolejna faza będzie mierzona za pomocą przypisania tożsamości, inwentaryzacji komponentów i zweryfikowanego ograniczania niebezpiecznych uprawnień agentów.

Pierwszym sygnałem jest to, czy przedsiębiorstwa potrafią w swoich dziennikach odróżnić aktywność agentów od aktywności ludzi. Ustalenie Cloud Security Alliance na poziomie 68% zapewnia wyraźny punkt odniesienia, choć pochodzi z ankiety, a nie bezpośredniej telemetrii.

Poprawa oznaczałaby, że każde działanie o istotnych konsekwencjach zawiera tożsamość agenta, delegowanie przez użytkownika, nazwę narzędzia, kontekst autoryzacji oraz możliwy do prześledzenia wynik. Jeśli późniejsze ankiety pokażą, że mniej organizacji ma trudności z przypisaniem działań, argument za możliwym do opanowania zarządzaniem agentami stanie się silniejszy.

Jeśli liczba pozostanie bliska dwóm trzecim, wynika z tego przeciwny wniosek. Przedsiębiorstwa wdrożą więcej autonomicznych przepływów pracy bez rozwiązania podstawowego problemu rozliczalności. Taki wynik wzmocni ostrzeżenie Snyk, że luka w widoczności rośnie wraz z wdrażaniem.

Drugim sygnałem jest pojawienie się spójnych zestawień materiałów AI. Zestawienie materiałów AI rejestruje modele, zbiory danych, prompty, frameworki, narzędzia, usługi i zależności używane przez system. Rozszerza koncepcję zestawienia materiałów oprogramowania o komponenty specyficzne dla AI.

Użyteczna wersja musi pozostawać zsynchronizowana z wdrożeniem. Statyczny dokument utworzony podczas zakupu nie uwzględni narzędzi i zbiorów danych podłączonych później. Automatyczne wykrywanie, przypisanie właścicieli, historia wersji oraz dowody rzeczywistych uprawnień mają większe znaczenie niż samo stworzenie listy.

Szerokie przyjęcie interoperacyjnych formatów inwentaryzacji wzmocniłoby argument, że przedsiębiorstwa mogą odzyskać widoczność. Dalsze poleganie na pulpitach nawigacyjnych specyficznych dla dostawców pozostawiłoby martwe punkty między produktami bezpieczeństwa, platformami chmurowymi i środowiskami lokalnymi.

Trzecim sygnałem jest to, czy organizacje ograniczają nadmierną sprawczość w środowisku produkcyjnym. Zespoły bezpieczeństwa powinny śledzić, ilu agentów może zapisywać dane, wykonywać kod, wysyłać komunikaty, zmieniać infrastrukturę lub uzyskiwać dostęp do wrażliwych repozytoriów bez oddzielnego zatwierdzenia.

Malejąca liczba pokazałaby, że firmy przekładają zarządzanie AI na techniczne mechanizmy kontroli. Rosnąca liczba wskazywałaby, że cele produktywności nadal przeważają nad ograniczaniem ryzyka. Raporty o incydentach z udziałem agentów o nadmiernych uprawnieniach uczyniłyby ten wskaźnik szczególnie pilnym.

Te sygnały mają większe znaczenie niż liczba polityk AI publikowanych przez firmy. Polityki opisują intencje. Tożsamości, inwentaryzacje, uprawnienia i dzienniki ujawniają rzeczywistość operacyjną.

Nagłówek Snyk w Google News odnosi sukces, ponieważ kondensuje tę rzeczywistość do jednego zapadającego w pamięć ostrzeżenia. Dokładna wartość dwóch trzecich pozostaje szacunkiem pochodzącym od dostawcy, ale trudno zlekceważyć leżącą u jej podstaw rozbieżność. Komponenty AI mnożą się szybciej, niż wiele organizacji jest w stanie je odkrywać, klasyfikować i nimi zarządzać.

Dla deweloperów natychmiastowym pytaniem jest to, czy każde połączenie agenta ma wskazanego właściciela i niezbędne uprawnienie. Dla zespołów bezpieczeństwa chodzi o to, czy dzienniki potrafią odtworzyć działanie od żądania użytkownika, przez decyzję modelu, do wyniku w systemie docelowym. Nabywcy korporacyjni powinni żądać dowodów na oba te aspekty.

Następny kwartał oferuje praktyczny test. Wybierz jednego agenta produkcyjnego, zmapuj każdy model, narzędzie, tożsamość, zbiór danych i wywołanie zewnętrzne, a następnie porównaj tę mapę z istniejącymi zapisami bezpieczeństwa. Jeśli oba widoki wyraźnie się różnią, martwy punkt już znajduje się wewnątrz organizacji. Jeśli są zgodne, sprawdź, czy uprawnienia i mechanizmy zatwierdzania działają zgodnie z dokumentacją. Google News dostarczyło ostrzeżenie; teraz telemetria przedsiębiorstwa musi dostarczyć odpowiedź.