Google Cloud przenosi ochronę przed zagrożeniami AI na poziom zarządów

Google Cloud przeniósł ochronę przed zagrożeniami AI na poziom zarządów, argumentując, że zautomatyzowane ataki poruszają się dziś szybciej, niż wiele organizacji jest w stanie je ocenić i powstrzymać.

To ostrzeżenie ma znaczenie wykraczające poza najnowszy cykl Google News. Google apeluje do członków rad nadzorczych, by traktowali cyberzagrożenia działające z szybkością maszyn jako kwestię odporności operacyjnej, a nie kolejny techniczny punkt dla CISO.

Stanowisko firmy opiera się na pogłębiającej się luce prędkości. Atakujący mogą wykorzystywać AI do identyfikowania podatności, tworzenia przekonujących technik socjotechnicznych i automatyzowania części włamania. Obrońcy nadal często polegają na ręcznych przeglądach, rozproszonych narzędziach i łańcuchach zatwierdzeń działających w ludzkim tempie.

Google ma też odpowiedź komercyjną. Platforma Google AI Threat Defense łączy technologie Gemini, Mandiant, Google Threat Intelligence, Google Security Operations i Wiz. Google twierdzi, że system może priorytetyzować ekspozycje i przyspieszać usuwanie problemów w kodzie, infrastrukturze chmurowej, tożsamościach i działających aplikacjach.

To połączenie tworzy główne napięcie. Zarządy potrzebują lepszej ochrony przed atakami wspomaganymi przez AI, lecz muszą zdecydować, jak dużą władzę w zakresie bezpieczeństwa przekazać innemu systemowi AI.

Microsoft, Amazon Web Services, Palo Alto Networks, CrowdStrike i inni dostawcy rozwiązań bezpieczeństwa realizują własne strategie automatyzacji. Argument Google jest zatem zarówno ostrzeżeniem, jak i próbą zdefiniowania platformy bezpieczeństwa dla przedsiębiorstw w erze agentów.

Co faktycznie zmienił Google Cloud

Google Cloud pakuje bezpieczeństwo AI jako ciągły model operacyjny, a nie zbiór odizolowanych narzędzi do wykrywania zagrożeń.

Firma zaprezentowała Google AI Threat Defense 27 maja 2026 r. Google opisuje to rozwiązanie jako działający stale system, zaprojektowany do monitorowania ryzyk i pomagania w zatrzymywaniu zagrożeń napędzanych przez AI, zanim wpłyną one na działalność firmy.

Jego konstrukcja obejmuje powierzchnię ataku od tworzenia oprogramowania po środowisko produkcyjne. Platforma analizuje kod, konfiguracje chmurowe, tożsamości, wdrożone obciążenia i dane o zagrożeniach. Następnie wykorzystuje ten kontekst do identyfikowania ekspozycji stanowiących największe praktyczne ryzyko.

To rozróżnienie ma znaczenie, ponieważ skanery podatności regularnie generują więcej ustaleń, niż zespoły bezpieczeństwa mogą obsłużyć. Krytyczna ocena techniczna nie zawsze oznacza, że wada jest osiągalna, możliwa do wykorzystania lub powiązana z wrażliwymi danymi.

Google twierdzi, że jego system wykorzystuje szerszy kontekst organizacyjny, aby określić, które ustalenia zasługują na uwagę. Właściciel zasobu, relacje między aplikacjami, uprawnienia tożsamości, ścieżki ekspozycji i aktywne dane o zagrożeniach mogą wpływać na tę klasyfikację.

Firmowy start ochrony przed zagrożeniami przedstawia cztery połączone etapy. Celem jest ochrona tworzenia oprogramowania, skanowanie i priorytetyzowanie podatności, obrona wdrożonych aplikacji oraz usprawnienie wykrywania i reagowania.

Gemini zapewnia rozumowanie w oparciu o dane bezpieczeństwa. Mandiant wnosi wiedzę o incydentach i doświadczenie z pierwszej linii. Google Threat Intelligence dostarcza informacji o przeciwnikach, podatnościach i aktywnych kampaniach.

Wiz wprowadza dane o stanie bezpieczeństwa chmury i ekspozycjach do szerszego portfolio. Google sfinalizował strategię przejęcia Wiz, aby wzmocnić widoczność w środowiskach wielochmurowych, gdzie obciążenia i tożsamości rzadko pozostają w obrębie jednego dostawcy.

CodeMender zajmuje się podatnościami oprogramowania na wcześniejszym etapie rozwoju. Google twierdzi, że może pomagać w znajdowaniu, weryfikowaniu i naprawianiu błędów, zanim aplikacje trafią do produkcji.

Każdy z tych komponentów miał już osobną wartość. Zmiana polega na próbie połączenia ich przez Google w ramach jednej architektury bezpieczeństwa i wspólnej warstwy priorytetyzacji wspomaganej przez AI.

To podejście platformowe odzwierciedla również ekonomię współczesnych operacji bezpieczeństwa. Przedsiębiorstwa zgromadziły liczne narzędzia, lecz każdy produkt może tworzyć kolejną kolejkę alertów. Więcej wykryć nie przekłada się automatycznie na szybsze powstrzymywanie incydentów.

Google przekonuje, że kontekst może zmniejszyć to obciążenie. System AI może analizować relacje, które analitycy musieliby w przeciwnym razie odtworzyć na podstawie zgłoszeń, pulpitów, repozytoriów i systemów tożsamości.

Praktycznym przykładem jest podatna aplikacja połączona z uprzywilejowanym kontem usługi. Skaner może zgłosić wadę oprogramowania, podczas gdy inny produkt oznaczy nadmierne uprawnienia. Trzecia platforma może rozpoznać aktywne wykorzystywanie podatności.

Jeśli te ustalenia pozostają rozdzielone, analitycy muszą połączyć je ręcznie. Google AI Threat Defense ma zostać zaprojektowane tak, aby składać ten łańcuch w całość i podnosić ocenę łącznego ryzyka.

Platforma nie eliminuje potrzeby korzystania ze specjalistów. Ktoś nadal musi zdecydować, czy proponowana poprawka jest bezpieczna, czy aplikacja może tolerować przestój oraz czy automatyzacja właściwie zinterpretowała kontekst biznesowy.

Google zmienił jednak rozmowę zakupową. Firma nie oferuje już AI wyłącznie jako asystenta podsumowującego alerty. Pozycjonuje AI jako warstwę koordynującą obronę przedsiębiorstwa.

Dlaczego Google News o bezpieczeństwie AI powinno teraz trafić na agendę zarządów

Kwestią na poziomie zarządu nie jest to, czy atakujący używają AI. Chodzi o to, czy firma potrafi podejmować możliwe do obrony decyzje w coraz krótszym oknie reakcji.

Raport Google Cloud H1 2026 Threat Horizons wskazuje, że w drugiej połowie 2025 r. okres między publicznym ujawnieniem podatności a jej aktywnym wykorzystaniem skrócił się z tygodni do dni.

Raport opisuje również próbę ataku na łańcuch dostaw wspomaganą przez AI. Sprawcy wykorzystywali duże modele językowe do automatyzowania wyłudzania poświadczeń i przechodzenia ze środowiska deweloperskiego w kierunku administracyjnego dostępu do chmury.

Według Google sprawcy nadużyli zaufania związanego z OpenID Connect, protokołem pozwalającym usługom weryfikować tożsamości bez bezpośredniej wymiany haseł. Działanie rozwinęło się w mniej niż 72 godziny.

Ten przypadek nie oznacza, że autonomiczna AI przeprowadziła całe włamanie bez udziału człowieka. Pokazuje, że atakujący mogą używać modeli do przyspieszania poszczególnych zadań w ramach szerszej kampanii.

Inne ustalenia raportu podkreślają mniej futurystyczny problem. Przejęcie tożsamości pozostało kluczowe dla incydentów chmurowych, a kradzież danych była nadal jednym z głównych celów.

Wyniki Google dotyczące zagrożeń chmurowych wskazują, że problemy z tożsamością umożliwiły początkowy dostęp w 83% analizowanych incydentów dotyczących dużych środowisk chmurowych i software-as-a-service. Sprawcy kierowali się na dane w 73% incydentów związanych z chmurą.

Dane te pochodziły z działań Mandiant w zakresie reagowania i obrony w drugiej połowie 2025 r. Reprezentują zaobserwowaną przez Google strukturę przypadków, a nie wszystkie naruszenia na świecie.

Mimo to pokazują, dlaczego zarząd nie może traktować bezpieczeństwa AI wyłącznie jako ćwiczenia z zakresu nadzoru nad modelami. Podatnym systemem może być agent, lecz decydująca słabość może nadal tkwić w nadmiernie uprzywilejowanej tożsamości, wystawionej aplikacji lub niezałatanej zależności.

Dyrektorzy już odpowiadają za nadzór nad porównywalnymi ryzykami przedsiębiorstwa. Amerykańska Securities and Exchange Commission wymaga od spółek publicznych opisywania nadzoru zarządu nad zagrożeniami cyberbezpieczeństwa oraz roli kierownictwa w zarządzaniu istotnym ryzykiem cybernetycznym.

Istotny incydent zasadniczo musi zostać ujawniony w ciągu czterech dni roboczych od momentu, gdy firma stwierdzi jego istotność. Reguła koncentruje uwagę na wpływie na biznes, nadzorze i jakości decyzji, a nie na technicznej nowości.

Zasady ujawniania informacji SEC nadają więc argumentowi Google wagę regulacyjną. Dyrektorzy potrzebują wystarczających informacji, aby zrozumieć potencjalne szkody finansowe i operacyjne, zanim incydent osiągnie etap ujawnienia.

Agenci AI komplikują tę odpowiedzialność. Agent może uzyskiwać dostęp do dokumentów, wywoływać narzędzia programowe, tworzyć kod lub działać za pośrednictwem poświadczeń użytkownika. Jego tożsamość operacyjna może stać się ważniejsza niż model, na którym się opiera.

Pracownik zazwyczaj działa w ramach ustalonych procesów wdrażania, przeglądu dostępu i zakończenia współpracy. Agent AI może zostać szybko utworzony przez jednostkę biznesową, połączony z kilkoma systemami i pozostawiony do działania bez równoważnego nadzoru.

Tworzy to ryzyko „shadow agent”. Termin ten opisuje agentów AI wdrożonych poza widocznością lub kontrolą centralnych zespołów bezpieczeństwa.

Zarząd nie potrzebuje katalogu każdego agenta. Potrzebuje dowodów, że kierownictwo wie, które agenty mogą dotrzeć do wrażliwych systemów, kto za nie odpowiada i jakie ograniczenia obowiązują w ich działaniach.

Potrzebuje także miarodajnych wskaźników odporności. Liczba wykrytych alertów mówi dyrektorom niewiele o tym, czy organizacja może przetrwać atak.

Bardziej użyteczne pytania dotyczą ekspozycji i odzyskiwania sprawności. Ile krytycznych systemów zależy od tożsamości bez uwierzytelniania odpornego na phishing? Jak szybko można odebrać uprzywilejowany dostęp? Czy organizacja potrafi odtworzyć atak, jeśli przeciwnik usunie zwykłe logi?

Przekaz Google przesuwa cyberbezpieczeństwo od kwestii własności kontroli do wyników operacyjnych. Polityka może istnieć, podczas gdy łatanie pozostaje powolne, uprawnienia tożsamości są nadmierne, a dowody incydentu niepełne.

Dla dyrektorów obrona przed AI staje się tym samym kwestią alokacji kapitału. Finansowanie kolejnego pulpitu ma ograniczoną wartość, jeśli firma nie potrafi powiązać ustaleń z zasobami krytycznymi dla biznesu.

Istotne pytanie brzmi, czy inwestycja w bezpieczeństwo zmniejsza oczekiwane zakłócenia. Wymaga to od kierownictwa przełożenia technicznej ekspozycji na potencjalne przestoje, utratę danych, obowiązki prawne i koszty odzyskania sprawności.

Google News uwidacznia wyścig między zautomatyzowanym atakiem a zautomatyzowaną obroną

Głównym przeciwnikiem Google nie jest inny dostawca chmury. Jest nim model bezpieczeństwa działający z ludzką szybkością, który nadal kieruje reakcjami wielu przedsiębiorstw.

Prognoza Google na 2026 r. przewiduje szersze wykorzystanie AI w całym cyklu życia ataku. Sprawcy mogą używać modeli do tworzenia przynęt, badania celów, modyfikowania złośliwego kodu i analizowania skradzionych informacji.

Agentowa AI podnosi stawkę, ponieważ agent może realizować cel poprzez kilka kroków. Może wybierać narzędzia, działać na podstawie wyników i dostosowywać kolejne posunięcie przy mniejszym bezpośrednim nadzorze człowieka.

Google oczekuje, że obrońcy odpowiedzą „agentowym SOC”. Centrum operacji bezpieczeństwa, czyli SOC, to zespół i technologia odpowiedzialne za monitorowanie zagrożeń i reagowanie na nie.

W agentowym SOC systemy AI prowadziłyby analizę alertów, gromadziły dowody, rekomendowały powstrzymywanie zagrożeń i wykonywały wybrane zadania reakcyjne. Analitycy będący ludźmi nadzorowaliby decyzje o najwyższym ryzyku.

Prognoza bezpieczeństwa Google przedstawia to jako wyścig zbrojeń. Atakujący zyskują szybkość i skalę, podczas gdy obrońcy wykorzystują agentów, aby zwiększyć możliwości analityków.

Argument za automatyzacją jest prosty. Analityk nie jest w stanie ręcznie zbadać każdego zdarzenia dotyczącego tożsamości, zmiany w kodzie, podatności i konfiguracji chmurowej wygenerowanych w dużym przedsiębiorstwie.

System AI może szybciej korelować te sygnały. Może też utrzymywać uwagę na większej liczbie równoczesnych dochodzeń.

Sama szybkość nie oznacza jednak solidnego bezpieczeństwa. Zautomatyzowana reakcja może zakłócić produkcję, odebrać legalny dostęp lub nadać priorytet niewłaściwej podatności, gdy jej kontekst jest niepełny.

To ryzyko sprawia, że przekazana władza jest centralnym problemem nadzorczym. Im więcej działań może podjąć agent obronny, tym większy ma potencjał, aby powstrzymać atak. Ta sama władza zwiększa szkody wynikające z błędnej decyzji lub przejęcia agenta.

Organizacje potrzebują więc jasno określonych granic autonomii. Agent może automatycznie gromadzić dowody, ale wymagać zatwierdzenia przed wyłączeniem konta. Może odizolować testowe obciążenie, jednocześnie eskalując decyzję o działaniu wobec systemu generującego przychody.

Granice te powinny odzwierciedlać wpływ na działalność, a nie wyłącznie wagę techniczną. Zawieszenie jednego konta usługi może zatrzymać cały proces klienta, podczas gdy inne konto można wyłączyć bez widocznych zakłóceń.

Strategia platformowa Google ma dostarczać tego kontekstu. Wiz może mapować ekspozycję chmurową, Mandiant może dostarczać wiedzę o incydentach, a Gemini może analizować ustalenia w szerszym kontekście.

Microsoft ma podobną motywację, by łączyć dane bezpieczeństwa za pośrednictwem swoich produktów chmurowych, tożsamościowych, endpointowych i zwiększających produktywność. Amazon Web Services dodaje wsparcie AI do bezpieczeństwa chmury i operacji. Wyspecjalizowani dostawcy budują funkcje autonomicznego dochodzenia i remediacji wokół swoich istniejących platform.

To konkurencyjne tło ma znaczenie, ponieważ przedsiębiorstwa rzadko działają w jednym środowisku bezpieczeństwa. Firma może korzystać z tożsamości Microsoft, infrastruktury AWS, narzędzi produktywności Google oraz produktów bezpieczeństwa od kilku dostawców.

Zautomatyzowany obrońca może analizować jedynie informacje, do których ma dostęp. Luki między platformami mogą ukrywać ścieżkę, którą atakujący wykorzystuje do przemieszczania się z jednego systemu do drugiego.

Google twierdzi, że szeroki kontekst daje jego platformie przewagę. To twierdzenie będzie wymagało dowodów z heterogenicznych środowisk klientów, a nie tylko z infrastruktury zarządzanej przez Google.

Zagrożeniem jest zastąpienie fragmentacji alertów fragmentacją automatyzacji. Kilku agentów defensywnych może badać to samo zdarzenie, rekomendować sprzeczne działania lub działać na podstawie niespójnych danych o zasobach.

Rady nadzorcze powinny więc pytać, jak kierownictwo koordynuje zautomatyzowane systemy. Odpowiedzialna architektura wymaga jasnej hierarchii decyzji, wspólnych dowodów oraz zapisów pokazujących, dlaczego podjęto każde istotne działanie.

Taki zapis staje się ważny podczas przeglądu incydentu. Jeśli agent blokuje dostęp, łata kod lub zmienia politykę chmurową, śledczy muszą odtworzyć tok rozumowania i dane wejściowe stojące za tym działaniem.

Zespoły mogą wspierać ten proces, utrzymując przeszukiwalną bazę wiedzy inżynieryjnej. Runbooki, decyzje architektoniczne, rejestry właścicieli i dowody dotyczące incydentów muszą pozostawać dostępne podczas szybko rozwijającej się reakcji.

Prawdziwym wyzwaniem dla Google jest udowodnienie, że jego automatyzacja zmniejsza obciążenie operacyjne, nie ukrywając przy tym decyzji o istotnych konsekwencjach. System, który działa szybciej, ale nie potrafi wyjaśnić swoich dowodów, może stworzyć kolejny problem w zakresie ładu organizacyjnego.

Kompromis automatyzacji, którego rady nadzorcze nie mogą delegować

Obrona AI potrzebuje uprawnienia do działania, lecz każde dodatkowe uprawnienie rozszerza system, który przedsiębiorstwo musi zabezpieczyć.

Twierdzenia Google dotyczące platformy należy traktować jako deklaracje dostawcy, dopóki klienci nie opublikują niezależnych wyników operacyjnych. Istotną miarą nie jest liczba ustaleń, które Gemini potrafi podsumować.

Rady nadzorcze potrzebują dowodów, że system zmniejsza ekspozycję, przyspiesza bezpieczną remediację i poprawia odzyskiwanie sprawności. Wyniki te powinny być mierzone bez pomijania incydentów, których automatyzacja nie wykryła.

Jednym z problemów są fałszywie pozytywne wyniki. Zautomatyzowany system może uznać legalne zachowanie za złośliwe, zwłaszcza gdy aplikacja nagle się zmienia lub użytkownicy pracują poza ustalonymi wzorcami.

Równie istotne są fałszywie negatywne wyniki. Model może przedstawić pewne siebie wyjaśnienie, jednocześnie przeoczając atakującego, który rozumie jego logikę wykrywania.

Przeciwnicy mogą także atakować warstwę AI. Prompt injection polega na ukrytych lub złośliwych instrukcjach zaprojektowanych tak, by system AI ignorował zamierzone reguły.

Jeśli agent defensywny odczytuje niezaufane logi, komentarze w kodzie, zgłoszenia lub strony internetowe, atakujący mogą umieścić instrukcje w tych danych wejściowych. Agent potrzebuje mechanizmów oddzielających dowody od poleceń.

Kolejnym zagrożeniem jest zatruwanie danych. Atakujący mogą manipulować informacjami używanymi do trenowania lub prowadzenia modelu, osłabiając jego wnioski lub odciągając uwagę od złośliwej aktywności.

Autonomiczny system staje się również uprzywilejowaną tożsamością. Potrzebuje dostępu do telemetrii bezpieczeństwa, inwentaryzacji zasobów, repozytoriów i narzędzi reagowania.

Przejęcie tej tożsamości mogłoby dać atakującemu mapę mechanizmów obronnych przedsiębiorstwa. Nadmierne uprawnienia do reagowania mogłyby także zapewnić drogę do wyłączania systemów lub niszczenia dowodów.

National Institute of Standards and Technology traktuje te kwestie jako powiązane, ale odrębne. Jego wstępny Cyber AI Profile obejmuje zabezpieczanie systemów AI, wykorzystanie AI do obrony oraz udaremnianie ataków wspieranych przez AI.

Ten Cyber AI Profile jest zorganizowany wokół NIST Cybersecurity Framework. Daje organizacjom neutralny wobec dostawców punkt odniesienia do oceny twierdzeń Google dotyczących platformy oraz własnych mechanizmów kontrolnych.

Prace NIST są wartościowe, ponieważ bezpieczeństwo AI przekracza kilka granic. Firmy muszą zabezpieczyć model, otaczającą go aplikację, potok danych, tożsamości oraz infrastrukturę wykonującą działania.

Żaden pojedynczy produkt nie rozwiąże wszystkich tych warstw. Google AI Threat Defense może pomóc je połączyć, ale klienci nadal kontrolują architekturę aplikacji, uprawnienia, zarządzanie zmianami i planowanie odzyskiwania sprawności.

Istnieje również ryzyko koncentracji. Firma, która polega na jednym dostawcy w zakresie infrastruktury chmurowej, analizy zagrożeń, analityki bezpieczeństwa i zautomatyzowanego reagowania, zyskuje integrację.

Tworzy jednak także większą zależność od dostępności tego dostawcy, jego założeń dotyczących wykrywania i mapy rozwoju produktów. Awaria wspólnej płaszczyzny kontrolnej może jednocześnie wpłynąć na kilka warstw.

Wsparcie dla wielu chmur może zmniejszyć część tej zależności, ale tylko wtedy, gdy działa wystarczająco głęboko, by egzekwować spójne mechanizmy kontrolne. Podstawowa widoczność nie jest tym samym co niezawodne reagowanie u różnych dostawców.

Przed rozszerzeniem uprawnień automatyzacji rady nadzorcze powinny zażądać konkretnych dowodów. Kierownictwo powinno pokazać, jakie działania agent może wykonywać, które systemy są wyłączone z jego zakresu oraz jak zmieniają się zatwierdzenia w sytuacji awaryjnej.

Liderzy bezpieczeństwa powinni również testować tryby awarii. Co dzieje się, gdy informacje o zagrożeniach są opóźnione, dane o tożsamościach są niekompletne lub usługa modelu staje się niedostępna?

Bezpieczny projekt wymaga ręcznego rozwiązania awaryjnego. Analitycy powinni móc wstrzymać automatyzację, cofać działania i kontynuować dochodzenie, korzystając z zachowanych dowodów.

Organizacje powinny testować te mechanizmy podczas ćwiczeń. Dyskusja typu tabletop może ujawnić niejasny podział odpowiedzialności, ale do zmierzenia, czy systemy zachowują się zgodnie z założeniami, potrzebne są symulacje techniczne.

Ocena powinna obejmować próby prompt injection, zatrute dowody, przejęte poświadczenia usług oraz sprzeczne rekomendacje z odrębnych narzędzi.

Dyrektorzy nie muszą zatwierdzać poszczególnych playbooków. Powinni sprawdzić, czy kierownictwo ustanowiło progi ryzyka, niezależne testy i odpowiedzialnych właścicieli.

Powinni również opierać się traktowaniu metryk generowanych przez AI jako obiektywnych. Jeśli ta sama platforma identyfikuje ryzyka, ustala ich priorytety, usuwa je i raportuje sukces, niezależna walidacja staje się niezbędna.

Ostrzeżenie Google jest wiarygodne, ponieważ szybkość ataków rośnie. Jego odpowiedź produktowa nadal wymaga dowodów od klientów, że automatyzacja poprawia bezpieczeństwo w rzeczywistych ograniczeniach operacyjnych.

Na co rady nadzorcze powinny zwracać uwagę w ciągu najbliższych trzech miesięcy

O kolejnej fazie zdecydują wyniki klientów, integracja konkurencyjna i dowody dotyczące ładu organizacyjnego, a nie kolejna fala zapowiedzi bezpieczeństwa AI.

Pierwszym sygnałem są mierzalne dowody wdrożenia Google AI Threat Defense. Klienci powinni informować, czy platforma skraca czas między wykryciem podatności, ustaleniem priorytetu a bezpieczną remediacją.

Przydatne wyniki obejmowałyby zmiany w czasie ekspozycji, czasie dochodzenia i skuteczności odzyskiwania sprawności. Sama liczba alertów nie dowiodłaby, że system poprawił bezpieczeństwo.

Niezależne studia przypadków wzmocniłyby pozycję Google, jeśli obejmowałyby złożone środowiska wielochmurowe. Dowody ograniczone do kontrolowanych demonstracji pozostawiłyby nierozstrzygnięte centralne twierdzenie dotyczące integracji.

Rady nadzorcze powinny także szukać szczegółów dotyczących zatwierdzania przez człowieka. Wynik klienta znaczy więcej, gdy odbiorcy wiedzą, które działania były zautomatyzowane, a które wymagały interwencji analityka.

Jeśli Google zademonstruje szybszą remediację bez wzrostu liczby przestojów lub pominiętych incydentów, argument za jego platformą stanie się silniejszy. Jeśli klienci zgłoszą intensywne strojenie i utrzymującą się ręczną korelację, wąskie gardło ludzkiej szybkości pozostanie.

Drugim sygnałem jest reakcja konkurencyjnych platform bezpieczeństwa. Microsoft, AWS, Palo Alto Networks, CrowdStrike i inni będą nadal łączyć rozumowanie AI z wykrywaniem i reagowaniem.

Ważne pytanie nie brzmi, który dostawca doda kolejnego asystenta. Chodzi o to, która platforma potrafi koordynować dowody i działania w obszarze tożsamości, kodu, zasobów chmurowych, endpointów i aplikacji biznesowych.

Otwarte integracje będą miały znaczenie. Klienci potrzebują sposobów wymiany ustaleń, zachowywania dowodów i kontrolowania działań ponad granicami dostawców.

Jeśli konkurencyjne platformy opublikują interoperacyjne podejścia, przedsiębiorstwa zyskają większą swobodę w tworzeniu architektury obronnej. Jeśli każdy dostawca zbuduje zamkniętą warstwę agentową, fragmentacja automatyzacji stanie się większym ryzykiem.

Przejęcia i partnerstwa również mogą zmienić rywalizację. Połączenie przez Google Wiz, Mandiant i Gemini pokazuje, jak szybko dostawca chmury może zbudować szerokie portfolio bezpieczeństwa.

Trzecim sygnałem są silniejsze wytyczne dotyczące ładu organizacyjnego od regulatorów i instytucji normalizacyjnych. NIST rozwija Cyber AI Profile, podczas gdy istniejące wymogi dotyczące ujawnień już zmuszają rady nadzorcze do wyjaśniania nadzoru nad cyberbezpieczeństwem.

Przyszłe wytyczne powinny wyjaśnić oczekiwania wobec autonomicznych agentów bezpieczeństwa. Organizacje potrzebują wspólnych sposobów dokumentowania uprawnień, testów, zapisów audytowych, nadzoru człowieka i odpowiedzialności za incydenty.

Wytyczne te mogą wzmocnić albo osłabić argument Google na poziomie rady nadzorczej. Jasne wymagania dotyczące ciągłego monitorowania i reagowania opartego na dowodach sprzyjałyby zintegrowanym platformom.

Reguły wymagające ścisłego rozdzielenia, niezależnej weryfikacji lub szczegółowej odpowiedzialności za model mogłyby spowolnić szerokie delegowanie uprawnień agentom zarządzanym przez dostawców. Nie wyeliminowałyby automatyzacji, ale mogłyby ograniczyć jej uprawnienia.

Rady nadzorcze powinny wykorzystać te sygnały do sprawdzenia strategii kierownictwa, zamiast czekać na ostateczne standardy. Bezpośrednim zadaniem jest wskazanie miejsc, w których procesy o szybkości człowieka tworzą istotną ekspozycję.

Taki przegląd powinien rozpocząć się od tożsamości, łatania, zależności oprogramowania i gotowości kryminalistycznej. Obszary te regularnie pojawiają się w dowodach dotyczących incydentów, niezależnie od tego, czy atakujący używa zaawansowanej AI.

Dyrektorzy powinni poprosić o niewielki zestaw miar powiązanych z działalnością. Czas usunięcia krytycznej ekspozycji, czas powstrzymania przejęcia uprzywilejowanej tożsamości oraz zdolność odzyskania kluczowych usług są bardziej użyteczne niż surowe łączne liczby alertów.

Powinni również zażądać inwentaryzacji automatyzacji bezpieczeństwa. Inwentaryzacja powinna pokazywać właściciela każdego agenta, dostępne dane, dozwolone działania, progi zatwierdzania oraz proces awaryjnego wyłączenia.

Relacje medialne o Google nadal będą koncentrować się na coraz bardziej autonomicznych atakach i mechanizmach obronnych. Rady nadzorcze powinny skupić się na tym, czy ich organizacje potrafią wyjaśnić i kontrolować automatyzację już obecną w ich środowiskach.

Natychmiastowym działaniem jest wspólny przegląd z udziałem bezpieczeństwa, inżynierii, działu prawnego, ryzyka i operacji biznesowych. Należy zapytać, które decyzje dotyczące reagowania nadal zależą od powolnej ręcznej koordynacji, a następnie ustalić, które z nich można bezpiecznie zautomatyzować.

Google Cloud ma rację, że roczne cykle przeglądów są zbyt wolne wobec zagrożeń działających z szybkością maszyn. Nierozstrzygnięte pozostaje pytanie, czy jego platforma może zapewnić szybszą obronę bez tworzenia nieprzejrzystej koncentracji uprawnień. To test, którego dyrektorzy powinni zażądać w następnej kolejności.