Platforma CNAPP OX Security łączy ochronę postawy chmurowej i środowiska uruchomieniowego agentów AI

OX Security uruchomiło 16 września platformę CNAPP, która łączy ugruntowane mechanizmy kontroli chmury z monitorowaniem agentów AI w czasie rzeczywistym. Platforma OX Security CNAPP, nazwana OX Cloud, ma wypełnić lukę w bezpieczeństwie powstającą wtedy, gdy autonomiczne oprogramowanie zyskuje tożsamości, uprawnienia i dostęp do narzędzi przedsiębiorstwa.

Premiera nie jest jedynie kolejnym rozszerzeniem listy funkcji bezpieczeństwa chmury. OX twierdzi, że zespoły bezpieczeństwa potrzebują jednego grafu łączącego kod, konfigurację chmury, tożsamości, dane, prompty i bieżące działania agentów. To stwierdzenie stanowi wyzwanie zarówno dla konwencjonalnych produktów CNAPP, jak i odrębnych narzędzi zabezpieczających AI.

Palo Alto Networks i inni duzi dostawcy zabezpieczeń już oferują ochronę środowiska uruchomieniowego, zarządzanie postawą AI i kontrolę agentów. OX musi zatem udowodnić, że jego kontekst od promptu do środowiska uruchomieniowego prowadzi do lepszych decyzji, a nie tylko do szerszego dashboardu.

Kluczowe pytanie brzmi, czy połączenie tych sygnałów pomoże obrońcom wyodrębniać osiągalne ryzyka i niebezpieczne zachowania agentów. Jeśli tak, OX Cloud może zmniejszyć dystans między wykryciem słabości w chmurze a zrozumieniem, w jaki sposób autonomiczny system mógłby ją wykorzystać.

Platforma CNAPP OX Security rozszerza widoczność na bieżącą aktywność agentów

OX Cloud dodaje zachowanie agentów do sygnałów dotyczących infrastruktury, tożsamości, podatności i danych, które już gromadzą platformy bezpieczeństwa chmury.

Platforma ochrony aplikacji chmurowych, czyli CNAPP, łączy kilka funkcji bezpieczeństwa chmury w jednym systemie. Funkcje te zwykle obejmują monitorowanie konfiguracji, ochronę obciążeń roboczych, analizę uprawnień, zarządzanie podatnościami i mapowanie ścieżek ataku.

OX Cloud obejmuje zarządzanie postawą bezpieczeństwa chmury, zarządzanie postawą Kubernetes, zarządzanie postawą bezpieczeństwa danych, wykrywanie podatności w środowisku uruchomieniowym, inwentaryzację chmury oraz opartą na grafie analizę ścieżek ataku. Firma dodaje również AI Detection and Response, które skraca do AIDR.

Różnica polega na tym, co OX chce, aby platforma obserwowała. Konwencjonalne narzędzia postawy analizują zasoby takie jak zasobniki pamięci masowej, kontenery, tożsamości, ścieżki sieciowe i zasady dostępu. OX Cloud chce również identyfikować agentów, modele, prompty i serwery Model Context Protocol działające w tym środowisku.

MCP to standardowy interfejs pozwalający systemom AI łączyć się z zewnętrznymi narzędziami i danymi. Serwer MCP może udostępniać agentowi bazę danych, system plików, usługę obsługi zgłoszeń, repozytorium kodu lub wewnętrzne API.

To połączenie zwiększa użyteczność agenta, ale jednocześnie zamienia wynik modelu w działania. Zmanipulowany agent może pobrać ograniczone rekordy, wywołać niezatwierdzone narzędzie lub użyć prawidłowego poświadczenia poza jego zamierzonym przepływem pracy.

OX twierdzi, że jego platforma łączy te działania z otaczającym je kontekstem chmury. Według firmowego ogłoszenia OX Cloud produkt może inwentaryzować obciążenia robocze, tożsamości, magazyny danych, klastry Kubernetes i aktywnych agentów AI.

Platforma następnie wykorzystuje analizę osiągalności do priorytetyzacji ustaleń. Osiągalność określa, czy wystawiony komponent, podatny pakiet lub nadmierne uprawnienie może faktycznie połączyć się z wartościowym zasobem albo ścieżką wykonania.

To podejście ma znaczenie, ponieważ skanery chmurowe mogą generować długie listy technicznie prawidłowych ustaleń. Podatny pakiet w odizolowanym obciążeniu roboczym nie stwarza takiego samego bezpośredniego ryzyka jak ten sam pakiet w usłudze dostępnej z internetu i mającej dostęp do danych klientów.

OX stosuje tę logikę do agentów. Wątpliwy prompt lub nietypowe wywołanie narzędzia stają się ważniejsze, gdy odpowiedzialny agent może dotrzeć do danych produkcyjnych, administracyjnych API lub systemów wdrożeniowych.

Firma twierdzi również, że OX Cloud może powiązać aktywność środowiska uruchomieniowego z promptem lub kodem, który ją zainicjował. To połączenie mogłoby pomóc badaczom odtworzyć, dlaczego agent podjął działanie, zamiast jedynie rejestrować fakt jego wystąpienia.

Są to nadal twierdzenia dostawcy. OX opisało możliwości i architekturę produktu, ale nie opublikowało dla tej premiery porównawczych wskaźników wykrywalności, pomiarów fałszywych alarmów, narzutu wdrożeniowego ani niezależnych ocen.

Ta luka dowodowa nie czyni produktu nieistotnym. Określa, co nabywcy korporacyjni muszą zweryfikować, zanim potraktują nową platformę jako skonsolidowaną płaszczyznę kontroli.

Dlaczego agenci AI wywierają presję na tradycyjne bezpieczeństwo chmury

Agenci skupiają kilka dobrze znanych problemów bezpieczeństwa w jednej szybko działającej tożsamości, która może rozumować, wybierać narzędzia i inicjować zmiany.

Tradycyjne obciążenie robocze zwykle wykonuje kod, który inżynierowie mogą przejrzeć przed wdrożeniem. Jego uprawnienia mogą nadal być nadmierne, a zależności mogą nadal zawierać podatności. Oczekiwana ścieżka wykonania jest jednak stosunkowo stabilna.

Agent zachowuje się inaczej. Interpretuje instrukcje, pobiera kontekst, wybiera narzędzia i tworzy sekwencję działań w środowisku uruchomieniowym. Niewielkie zmiany w promptach, pobranych dokumentach, wersjach modeli lub opisach narzędzi mogą zmienić tę sekwencję.

Ta zmienność nie oznacza, że zachowanie agenta jest niepoznawalne. Oznacza, że obrońcy potrzebują telemetrii obejmującej zarówno ścieżkę decyzyjną, jak i wynikające z niej wywołania systemowe.

Tożsamość jest kluczową częścią tego problemu. Agent działający przez współdzielone konto usługi może utrudniać interpretację logów. Badacze mogą zobaczyć zapytanie do bazy danych lub zmianę pliku, nie wiedząc, który agent je zainicjował, dlaczego działał ani kto zatwierdził przepływ pracy.

Wytyczne Microsoft dotyczące zasady najmniejszych uprawnień zalecają traktowanie każdego agenta jako odrębnego podmiotu. Każdy agent powinien mieć zarządzaną tożsamość, jasno wskazanego właściciela, role o wąskim zakresie oraz zatwierdzony manifest narzędzi.

Ten model tworzy mierzalną granicę. Zespoły mogą ustalić, które narzędzia agent powinien wywoływać, do których zasobów może uzyskiwać dostęp oraz czy jego aktywność w środowisku uruchomieniowym pozostaje zgodna z przypisanym celem.

Problem staje się poważniejszy, gdy serwery MCP dziedziczą szerokie poświadczenia. MCP obsługuje mechanizmy autoryzacji, w tym OAuth, ale protokół nie wymusza automatycznie bezpiecznej polityki dla każdego wdrożenia.

Microsoft podał, że 15 procent zdalnych serwerów MCP zaobserwowanych za pośrednictwem sygnałów Defender for Cloud zezwalało na nieuwierzytelniony dostęp do wrażliwych danych lub możliwości operacyjnych. Jego ustalenia dotyczące ekspozycji MCP obejmowały połączenia z systemami obsługi zgłoszeń, prywatnymi repozytoriami i narzędziami działów kadr.

Ta liczba nie opisuje wszystkich wdrożeń MCP. Pokazuje jednak, że łączność agentów może wystawiać na ryzyko rzeczywiste systemy przedsiębiorstwa, gdy konfiguracja uwierzytelniania i granice wykonania są błędne.

Skan postawy może zidentyfikować wystawiony serwer. Produkt tożsamościowy może wykryć jego poświadczenie. Narzędzie środowiska uruchomieniowego może zarejestrować podejrzane wywołanie. OX zakłada, że wspólny graf może połączyć wszystkie trzy elementy, zanim analityk ręcznie złoży cały łańcuch.

To najsilniejszy argument za połączeniem danych CNAPP z ochroną środowiska uruchomieniowego agentów AI. Zagrożenie nie jest ani wyłącznie problemem aplikacyjnym, ani wyłącznie problemem chmurowym.

Rozważmy agenta, któremu powierzono rozwiązywanie zgłoszeń wsparcia. Może on czytać zgłoszenia, przeszukiwać wewnętrzną dokumentację i aktualizować rekordy klientów. Pośredni prompt ukryty w zgłoszeniu mógłby nakazać agentowi pobranie niepowiązanych rekordów lub wysłanie danych do zewnętrznego punktu końcowego.

Filtr promptów może oznaczyć taką instrukcję. Jej waga zależy jednak od tożsamości używanej przez agenta, narzędzi, które może wywołać, oraz rekordów, do których narzędzia te mogą uzyskać dostęp.

Z kolei nietypowe wywołanie API nie zawsze wskazuje na atak. Agent może wykonywać uzasadnione zadanie po napotkaniu rzadkiego żądania. Obrońcy potrzebują wystarczającego kontekstu, by odróżnić nieoczekiwane zachowanie od zachowania nieautoryzowanego.

OX Cloud zaprojektowano wokół tego rozróżnienia. Jego obietnica nie polega po prostu na wykrywaniu dziwnych promptów. Ma łączyć bieżące zachowanie z osiągalnymi zasobami, efektywnymi uprawnieniami i źródłową ścieżką oprogramowania.

OX Cloud czyni osiągalność swoim głównym wyróżnikiem

Centralnym mechanizmem platformy jest priorytetyzacja powiązana z dowodami, w której zachowanie środowiska uruchomieniowego i ścieżki ataku określają, które ustalenia zasługują na uwagę.

Zespoły bezpieczeństwa chmury już zmagają się z liczbą alertów. Skanery postawy wykrywają błędne konfiguracje, narzędzia do obsługi podatności wyliczają pakiety, systemy tożsamości identyfikują nadmierne uprawnienia, a narzędzia do danych klasyfikują wrażliwe magazyny.

Dodanie agentów może utworzyć kolejny rejestr bez rozwiązania problemu fragmentacji. Zespół bezpieczeństwa może dowiedzieć się, że agent istnieje, używa określonego modelu i łączy się z kilkoma narzędziami. Fakty te nadal nie pokazują, czy jego zachowanie tworzy ścieżkę możliwą do wykorzystania.

OX opisuje czteroetapowy przepływ pracy: identyfikację, priorytetyzację, badanie i zarządzanie. Etapy wykorzystują te same dane kontekstowe, zamiast działać jako rozłączne moduły produktu.

Identyfikacja obejmuje obciążenia robocze, tożsamości, agentów, magazyny danych i zasoby chmurowe. OX twierdzi, że obejmuje to zasoby wykryte na podstawie obserwowanej aktywności, a nie tylko zasoby zadeklarowane w plikach konfiguracyjnych.

Priorytetyzacja stosuje analizę osiągalności do podatności, uprawnień, błędnych konfiguracji i ekspozycji łańcucha dostaw. Ustalenia, których nie można połączyć z aktywnym obciążeniem roboczym lub wartościowym zasobem, otrzymują niższy priorytet.

Badanie wykorzystuje graf chmury do odtworzenia relacji otaczających zdarzenie. Analityk powinien móc zobaczyć, która tożsamość wykonała działanie, którego zasobu dotknęła i jakie dodatkowe systemy były osiągalne.

Zarządzanie nakłada ograniczenia na aktywność agentów i wykorzystanie AI. W tym miejscu funkcje AIDR i agentowej powierzchni ataku OX stają się czymś więcej niż funkcjami wykrywania.

Mechanizm brzmi spójnie, ale jego jakość zależy od wierności danych. OX musi niezawodnie wykrywać zasoby, interpretować uprawnienia, śledzić wywołania agentów i zachowywać wystarczający kontekst na potrzeby badania.

Luki w pokryciu mogą tworzyć fałszywe poczucie pewności. Niezaobserwowane wywołanie narzędzia, niezarządzane poświadczenie, zaszyfrowana ścieżka ruchu lub nieobsługiwany framework agentów mogą przerwać łańcuch łączący prompt z wynikiem.

Korelacja danych może również prowadzić do niejednoznacznych wniosków. Prompt pojawiający się krótko przed wywołaniem API nie dowodzi automatycznie, że spowodował to wywołanie. Długotrwałe przepływy pracy, równolegli agenci, ponowienia i delegowane podzadania komplikują atrybucję.

OX musi zatem rozróżniać korelację od związku przyczynowego w swoim interfejsie. Analitycy potrzebują znaczników czasu, łańcuchów wywołań, zapisów tożsamości, decyzji dotyczących polityk i śladów aplikacji, które potwierdzają proponowaną relację.

Znaczenie ma również architektura wdrożenia. Inspekcja środowiska uruchomieniowego może odbywać się przez przechwytywanie ruchu sieciowego, czujniki obciążeń roboczych, biblioteki aplikacyjne, bramy API, logi chmurowe lub integracje z frameworkami agentów.

Każda metoda zapewnia inną widoczność. Kontrole sieciowe mogą obserwować miejsca docelowe i ładunki, lecz nie dostrzegać wewnętrznego rozumowania. Instrumentacja frameworka może rejestrować wybór narzędzi, ale zapewniać niepełne pokrycie w aplikacjach niestandardowych.

OX twierdzi, że szersza platforma AINAPP łączy etapy promptu, kodu, budowania, wdrażania i środowiska uruchomieniowego. AINAPP to określenie firmy na platformę ochrony aplikacji natywnie wykorzystującą AI.

Koncepcja ta daje OX potencjalnie użyteczną pozycję. Jego produkty do bezpieczeństwa aplikacji już analizują kod źródłowy i łańcuchy dostaw oprogramowania. OX Cloud rozszerza tę historię na wdrożoną infrastrukturę i aktywność agentów w czasie rzeczywistym.

Kupujący powinni jednak zapytać, jak to połączenie działa w przypadku kodu i agentów, które nie są już zarządzane za pośrednictwem produktów OX. Ujednolicona platforma ma ograniczoną wartość, jeśli najbogatszy kontekst pojawia się wyłącznie w ściśle kontrolowanym łańcuchu narzędzi.

Praktycznym testem jest rzeczywisty incydent. Zespół bezpieczeństwa powinien wprowadzić podejrzany opis narzędzia, wywołać próbę nieautoryzowanego dostępu i sprawdzić, czy OX odtwarza pełną ścieżkę.

Takie ćwiczenie powinno pokazać treść inicjującą, tożsamość agenta, wybrane narzędzie, parametry, miejsce docelowe, faktyczne uprawnienia, dane objęte wpływem oraz wynik egzekwowania zasad. Wszystko mniej kompletne zmusza analityków do składania dowodów z różnych systemów.

OX Security mierzy się z uznanymi platformami CNAPP i bezpieczeństwa AI

OX konkuruje o konsolidację platform z większymi dostawcami, a nie ze statycznymi skanerami chmurowymi, które całkowicie ignorowały AI.

Rynek już przesunął się w kierunku ochrony całego cyklu życia. Główni dostawcy łączą obecnie wykrywanie AI, analizę stanu bezpieczeństwa, red teaming, inspekcję w czasie rzeczywistym, kontrolę tożsamości i egzekwowanie polityk.

Palo Alto Networks przedstawia Prisma AIRS jako platformę obejmującą aplikacje AI, modele, dane i agentów. Jej dokumentacja Prisma AIRS opisuje firewalle czasu rzeczywistego, API, red teaming, bezpieczeństwo modeli, zarządzanie stanem bezpieczeństwa i ochronę agentów.

Palo Alto integruje również wykrywanie AI z Cortex Cloud. To połączenie może identyfikować modele, endpointy, zestawy danych, agentów i relacje zależności w Amazon Web Services, Microsoft Azure oraz Google Cloud.

Sprawia to, że podstawowa rywalizacja jest szersza niż OX kontra konwencjonalny CNAPP. To integracja OX stawiająca kontekst na pierwszym miejscu przeciwko zasiedziałym platformom bezpieczeństwa, które składają podobne mechanizmy kontroli z istniejących portfolio produktów.

Dotychczasowi dostawcy dysponują bazami zainstalowanych klientów, telemetrią chmurową, analizą zagrożeń, integracjami tożsamości oraz ugruntowanymi relacjami zakupowymi. Kupujący mogą woleć rozszerzyć istniejący kontrakt zamiast wprowadzać kolejną platformę bezpieczeństwa.

OX może odpowiedzieć koncentracją na tym obszarze. Mniejszy dostawca może projektować rozwiązanie wokół przepływów pracy agentów bez konieczności zachowywania każdego założenia architektonicznego starszego pakietu produktów.

Narracja od kodu do środowiska uruchomieniowego może również przemawiać do zespołów bezpieczeństwa aplikacji. Zespoły te chcą wiedzieć, czy problem wykryty podczas tworzenia oprogramowania pozostaje osiągalny po wdrożeniu oraz czy agent może aktywować podatną ścieżkę.

To połączenie może ograniczyć spory między programistami a analitykami bezpieczeństwa. Programiści często otrzymują wyniki ze skanerów bez dowodów, że dotknięty kod jest wystawiony na działanie. Kontekst środowiska uruchomieniowego może ustalić, które problemy mają bezpośrednie znaczenie operacyjne.

Więksi dostawcy przedstawiają jednak ten sam argument za konsolidacją. Palo Alto podało około 120 mln USD rocznego przychodu powtarzalnego dla Prisma AIRS po roku od ogólnej dostępności.

Firma podała także ponad 800 klientów Prisma AIRS w prezentacji za czwarty kwartał roku fiskalnego 2026. Dane te opierają się na własnych definicjach Palo Alto dotyczących alokacji przychodów i zakontraktowanych ofert, ale wskazują na istotny popyt komercyjny.

Ta presja konkurencyjna zmusza OX do wykazania konkretnych przewag. Dłuższa lista funkcji nie wystarczy, ponieważ platformy chmurowe już obejmują wiele tych samych kategorii.

OX może wyróżnić się szybszym dochodzeniem, lepszym priorytetyzowaniem, szerszą obsługą frameworków lub wyraźniejszym przypisaniem od promptu do środowiska uruchomieniowego. Może także konkurować elastycznością wdrożenia i mniejszą złożonością operacyjną.

Klienci powinni porównywać przepływy pracy, a nie etykiety kategorii. Oba produkty mogą deklarować wykrywanie agentów, ochronę w czasie rzeczywistym i zarządzanie stanem bezpieczeństwa, jednocześnie zbierając odmienną telemetrię lub egzekwując polityki w różnych punktach.

Jedna platforma może blokować złośliwe prompty przed przetworzeniem przez model. Inna może przechwytywać wywołania narzędzi, ograniczać uprawnienia tożsamości lub izolować obciążenie po wykryciu podejrzanej aktywności.

Te mechanizmy kontroli się uzupełniają, lecz ich umiejscowienie wpływa na opóźnienia, zasięg ochrony i tryby awarii. Produkt działający poza ścieżką wykonania może bezpieczniej obserwować, ale nie mieć możliwości natychmiastowego blokowania.

Mechanizm kontroli inline może zatrzymać działanie, ale staje się również częścią ścieżki dostępności aplikacji. Kupujący muszą rozumieć, co dzieje się, gdy usługa bezpieczeństwa działa wolno, traci łączność lub nie potrafi sklasyfikować żądania.

OX nie przedstawił publicznie wystarczających, specyficznych dla premiery dowodów, aby rozstrzygnąć te porównania. Jego bezpośrednim wyzwaniem jest przełożenie wiarygodnej architektury na powtarzalne rezultaty dla klientów.

Ochrona czasu rzeczywistego nie zastąpi projektowania agentów i kontroli dostępu

Żaden CNAPP nie zrekompensuje agentów współdzielących tożsamości, otrzymujących nadmierne uprawnienia lub wykonujących działania o dużym wpływie bez niezależnej autoryzacji.

Monitorowanie w czasie rzeczywistym często przyciąga uwagę, ponieważ potrafi wykryć zachowania pomijane przez przeglądy statyczne. Ta zaleta może też zachęcać zespoły do traktowania obserwacji jako substytutu bezpieczniejszej architektury.

Agent nie powinien uzyskiwać szerokiego dostępu tylko dlatego, że produkt monitorujący rejestruje jego działania. Rejestrowanie nieautoryzowanego transferu danych nie cofa tego transferu.

Taksonomia ryzyk agentowych organizacji OWASP obejmuje niewłaściwe użycie narzędzi, nadużycia tożsamości i uprawnień, zatruwanie pamięci, awarie kaskadowe oraz zachowanie nieautoryzowanych agentów. Ryzyka te przekraczają granice modeli, aplikacji, tożsamości i infrastruktury.

Obrońcy powinni zacząć od odrębnych tożsamości agentów. Współdzielone poświadczenia zaciemniają odpowiedzialność i utrudniają cofnięcie dostępu. Każdy agent produkcyjny potrzebuje wskazanego właściciela, udokumentowanego celu i ograniczonego zestawu dozwolonych zasobów.

Dostęp do narzędzi również powinien być jawnie określony. Agent zaprojektowany do podsumowywania zgłoszeń wsparcia nie powinien dziedziczyć dostępu administracyjnego do platformy zgłoszeniowej. Powinien otrzymać wyłącznie operacje odczytu niezbędne do tego zadania.

Dostęp do zapisu wymaga odrębnej decyzji. Jeśli przepływ pracy rozszerza się o modyfikowanie rekordów, zespół powinien utworzyć nowe uprawnienia i zasady zatwierdzania zamiast poszerzać istniejącą rolę bez przeglądu.

Działania o dużym wpływie wymagają deterministycznego egzekwowania zasad. Usuwanie danych, zmienianie infrastruktury produkcyjnej, realizacja płatności lub publikowanie zewnętrznych treści nie powinny opierać się wyłącznie na interpretacji instrukcji w języku naturalnym przez model.

Zatwierdzenie przez człowieka pozostaje właściwe w przypadku działań o dużych konsekwencjach finansowych, operacyjnych lub prawnych. Automatyczne zatwierdzanie może sprawdzać się w zadaniach o mniejszym wpływie, gdy warunki polityki są wąskie i egzekwowane niezależnie.

Pamięć wprowadza kolejne ryzyko. Agent może przechowywać historię rozmów, preferencje, pobrane fakty lub plany pośrednie między sesjami. Złośliwa treść może pozostać w tej pamięci i wpływać na późniejsze decyzje.

Produkt działający w czasie rzeczywistym powinien, tam gdzie to możliwe, ujawniać odczyty i zapisy pamięci. Powinien również pokazywać, czy agent korzystał z pobranej treści podczas wyboru narzędzia lub konstruowania parametrów.

Dostęp do pamięci może jednak zachodzić wewnątrz frameworka lub usługi modelowej zapewniającej ograniczoną telemetrię. Kupujący powinni sprawdzić, czy OX Cloud rejestruje te interakcje w ich rzeczywistym stosie wdrożeniowym.

Fałszywe alarmy stanowią odrębne wyzwanie. Przepływy pracy agentów naturalnie generują nietypowe sekwencje działań, ponieważ dostosowują się do żądań użytkowników. Proste wykrywanie anomalii może oznaczać prawidłowe różnice jako zagrożenia i przytłaczać analityków.

OX twierdzi, że osiągalność pomaga ograniczać ten szum. Twierdzenie jest wiarygodne, ale osiągalność nie dowodzi złośliwego zamiaru. Osiągalna ścieżka może obsługiwać prawidłowy przepływ pracy, a nieosiągalna wada oprogramowania może stać się istotna po zmianie konfiguracji.

Przedsiębiorstwa powinny mierzyć precyzję podczas kontrolowanego wdrożenia. Przydatne wskaźniki obejmują potwierdzone incydenty, fałszywe alarmy, czas dochodzenia, zablokowane prawidłowe zadania, nieobsługiwane przepływy pracy i luki w telemetrii.

Powinny również mierzyć wpływ na wydajność. Inspekcja w czasie rzeczywistym może zwiększać opóźnienia, gdy synchronicznie ocenia prompty, wywołania narzędzi, przepływy danych lub polityki tożsamości.

OX nie opublikował ogólnych danych dotyczących opóźnień ani narzutu dla OX Cloud. Wyniki będą prawdopodobnie zależeć od metody wdrożenia, wolumenu ruchu, złożoności polityk i ilości zebranego kontekstu.

Kolejną niewiadomą jest spójność egzekwowania. Organizacja może korzystać z agentów zbudowanych przy użyciu kilku frameworków w wielu chmurach i platformach SaaS. Polityka musi przetrwać te różnice architektoniczne.

Panel, który wykrywa każdego agenta, lecz zarządza tylko częścią z nich, tworzy nierównomierną ochronę. Zespoły bezpieczeństwa potrzebują jasnej macierzy kompatybilności oraz dowodów, że nieobsługiwane ścieżki pozostają widoczne.

Właściwy wniosek nie jest taki, że ochrona czasu rzeczywistego nie ma wartości. Polega on na tym, że monitorowanie czasu rzeczywistego działa najlepiej jako jedna warstwa większego systemu kontroli.

Bezpieczne projektowanie agentów zaczyna się od ograniczonych uprawnień. Ochrona czasu rzeczywistego następnie weryfikuje, czy zachowanie pozostaje w tych granicach, i pomaga badaczom zrozumieć odchylenia.

Trzy sygnały pokażą, czy OX Cloud spełnia obietnice

Kolejnym testem są dowody operacyjne, w tym walidacja przez klientów, mierzalne ograniczenie szumu oraz szerokie egzekwowanie zasad w rzeczywistych stosach agentowych.

Pierwszym sygnałem są niezależne dowody od klientów. OX powinien pokazać, jak platforma działa w środowiskach produkcyjnych obejmujących wiele chmur, frameworków agentowych, dostawców tożsamości i serwerów MCP.

Przydatne studia przypadków powinny określać liczbę wykrytych agentów i tożsamości nieludzkich. Powinny także raportować, które ryzykowne ścieżki zostały potwierdzone, ile alertów pominięto oraz jak zmienił się czas dochodzenia.

Drugim sygnałem jest porównywalna wydajność. Kupujący potrzebują testów wykrywania i egzekwowania obejmujących prompt injection, zatrute opisy narzędzi, nadmierne uprawnienia, nietypowe sekwencje API oraz próby eksfiltracji danych.

Testy te powinny uwzględniać prawidłowe warianty, aby mierzyć fałszywe alarmy. System blokujący każde nietypowe działanie ma niewielką wartość dla adaptacyjnych przepływów pracy.

OX powinien także ujawnić, gdzie następuje egzekwowanie zasad. Klienci muszą wiedzieć, czy mechanizmy kontroli działają wewnątrz obciążeń, za pośrednictwem inspekcji sieciowej, w ramach frameworków agentowych czy przez API chmurowe.

Trzecim sygnałem jest reakcja konkurencji. Palo Alto Networks, Microsoft i inni dostawcy bezpieczeństwa integrują tożsamość agentów, stan bezpieczeństwa, inspekcję czasu rzeczywistego i zarządzanie w większych platformach.

Jeśli ci dostawcy połączą kod, prompty, tożsamości, zasoby chmurowe i wywołania narzędzi z podobną precyzją, architektoniczne wyróżnienie OX się zmniejszy. OX będzie wtedy konkurować jakością wdrożenia, szybkością dochodzeń, zakresem ochrony i obsługą klienta.

Jeśli dotychczasowi dostawcy utrzymają rozdrobnienie tych mechanizmów kontroli, OX będzie mógł argumentować, że jeden graf kontekstowy zapewnia szybsze i lepiej uzasadnione decyzje. Oceny klientów określą, który wynik odzwierciedla rzeczywistość produkcyjną.

Liderzy bezpieczeństwa oceniający platformę CNAPP OX Security powinni zacząć od jednego ograniczonego przepływu pracy agenta. Mogą zmapować jego tożsamość, zatwierdzone narzędzia, osiągalne dane, oczekiwane działania i zasady eskalacji przed włączeniem szerszego zakresu ochrony.

Ocena powinna następnie wprowadzić kontrolowane awarie. Należy przetestować wystawiony serwer MCP, tożsamość z nadmiernymi uprawnieniami, zatruty dokument, nieautoryzowane wywołanie narzędzia i podatne, osiągalne obciążenie.

Platforma powinna pokazać nie tylko, że wydarzyło się coś nietypowego, lecz także dlaczego miało to znaczenie. Powinna połączyć instrukcję źródłową z działającą tożsamością, wybranym narzędziem, osiągalnym zasobem, decyzją polityki i końcowym wynikiem.

Ten standard wykracza poza OX. Produkty do bezpieczeństwa agentów muszą przekształcać skomplikowaną telemetrię w niezawodne egzekwowanie zasad i możliwe do wyjaśnienia dochodzenia.

Premiera odzwierciedla rzeczywistą zmianę w bezpieczeństwie chmurowym. Agenci stają się aktywnymi uczestnikami środowiska chmurowego, a nie kolejną klasą zasobów do zinwentaryzowania.

OX Cloud odpowiada na to, umieszczając zachowanie w czasie działania w tym samym grafie co kod, obciążenia robocze, tożsamości i dane. Projekt jest wiarygodny, lecz najmocniejsze twierdzenia nadal wymagają niezależnej weryfikacji.

Zespoły rozważające wdrożenie OX Cloud powinny poprosić o próbę odzwierciedlającą środowisko produkcyjne, a nie o dopracowaną prezentację funkcji. Czy platforma potrafi zidentyfikować każdego agenta, odróżnić uzasadnione warianty działania od nadużyć oraz odtworzyć kompletny łańcuch działań? Czy może egzekwować ograniczenia bez opóźniania zwykłej pracy i bez tworzenia kolejnej kolejki alertów? To właśnie te wyniki zdecydują, czy platforma CNAPP OX Security stanie się istotną płaszczyzną kontroli, czy kolejną warstwą, którą zespoły bezpieczeństwa będą musiały uzgadniać.