Microsoft Project Perception: agentowy SOC i nowe ryzyko

27 lipca 2026 roku Microsoft przedstawił Project Perception — agentowy system cyberbezpieczeństwa, który ma stale zbierać sygnały, rozumować nad kontekstem i przekładać wnioski na działania obronne. Pierwszy scenariusz dotyczy zarządzania podatnościami oprogramowania. Publiczna wersja zapoznawcza została zapowiedziana na 3 sierpnia 2026 roku.

To nie jest po prostu kolejny chatbot podłączony do SIEM. Microsoft opisuje zamkniętą pętlę współpracy trzech klas wyspecjalizowanych agentów: red team szuka ścieżek kompromitacji, blue team bada sygnały i ustala realne ryzyko, a green team podejmuje działania naprawcze i wzmacnia środowisko. System ma korzystać z danych o tożsamościach, endpointach, aplikacjach, danych, chmurze i samych rozwiązaniach AI.

Najważniejsze zastrzeżenie brzmi: 27 lipca znamy architekturę i wyniki opisane przez producenta, ale nie mamy jeszcze długoterminowych danych z szerokich wdrożeń klientów. Project Perception należy więc oceniać jako zapowiedź produktu i model operacyjny, a nie dowód, że autonomiczny SOC rozwiązuje problem podatności bez nadzoru człowieka.

Co dokładnie ogłosił Microsoft

Project Perception łączy sygnały, kontekst, modele oraz agentów w system, który ma uczyć się wraz ze zmianami środowiska. Według Microsoftu agent red team analizuje środowisko z perspektywy atakującego i identyfikuje możliwe drogi do kompromitacji. Agent blue team koreluje ustalenia z kontekstem biznesowym i technicznym, a agent green team inicjuje działania ograniczające ryzyko.

Pierwszym wdrażanym przypadkiem użycia jest software vulnerability management. Microsoft umieszcza model MAI-Cyber-1-Flash w MDASH — wielomodelowym zespole agentów do analizy podatności. Producent raportuje wynik 96% w benchmarku CyberGym, o 12 punktów wyższy od Mythos, oraz niemal 50% niższy koszt względem obecnej konfiguracji MDASH dostępnej na rynku.

Te liczby wymagają poprawnej interpretacji:

są wynikami przedstawionymi przez Microsoft, a nie niezależnym audytem Breachroad;
benchmark mierzy określone zadania w kontrolowanym środowisku, a nie pełną skuteczność SOC;
wynik nie mówi, ile błędnych działań naprawczych pojawi się w konkretnej organizacji;
oszczędność konfiguracji modelowej nie jest automatycznie oszczędnością całego procesu zarządzania podatnościami.

Zaletą wielomodelowego podejścia może być dobieranie modelu do zadania według jakości, niezawodności, opóźnienia i kosztu. Jednocześnie rośnie liczba zależności: trzeba kontrolować wersję każdego modelu, routing, uprawnienia narzędzi, dane wejściowe i sposób podejmowania decyzji.

Jak działa nowy „Cyber Stack”

Microsoft dzieli architekturę na warstwy, które można przełożyć na praktyczny model bezpieczeństwa:

Sygnały i sensory dostarczają telemetrię z tożsamości, urządzeń, aplikacji, chmury, danych i systemów AI.
Kontekst ma opisywać zależności między aktywami, podatnościami, kontrolami i znaczeniem biznesowym.
Modele wykonują zadania wymagające klasyfikacji, analizy kodu, priorytetyzacji i planowania.
Wyspecjalizowani agenci dzielą pracę na perspektywę ofensywną, defensywną i naprawczą.
Aktuatory zamieniają rekomendację na zmianę w środowisku — na przykład utworzenie zadania, modyfikację polityki lub wdrożenie poprawki.

Największa różnica względem klasycznej automatyzacji SOAR pojawia się między warstwą kontekstu a aktuatorami. Tradycyjny playbook wykonuje wcześniej opisany ciąg warunków. Agent może wybierać kolejne kroki na podstawie bieżących obserwacji. To zwiększa elastyczność, ale utrudnia przewidzenie wszystkich ścieżek wykonania.

Dlatego „human in control” nie może oznaczać wyłącznie przycisku awaryjnego. Człowiek powinien zatwierdzać klasy działań o wysokim wpływie, widzieć podstawę rekomendacji i móc odtworzyć sekwencję narzędzi, danych i decyzji. Bez tego organizacja otrzymuje szybszy system, ale niekoniecznie system rozliczalny.

Threat model dla Project Perception

Agentowy SOC trzeba traktować jak uprzywilejowaną platformę automatyzacji. Ma dostęp do szerokiej telemetrii i potencjalnie do narzędzi zmieniających konfigurację. To tworzy kilka konkretnych powierzchni ataku.

1. Zatrucie sygnałów i kontekstu

Atakujący może próbować wytworzyć telemetrię, która skieruje agentów na fałszywy trop, ukryje ważną zależność albo sztucznie podniesie priorytet nieistotnego zasobu. Jeżeli system pobiera opisy podatności, zgłoszenia, dokumentację lub dane z repozytoriów, trzeba sprawdzać pochodzenie i integralność każdego źródła.

Wynik agenta powinien wskazywać, które sygnały były dowodem, a które jedynie hipotezą. Przy niezgodności między źródłami bezpiecznym zachowaniem jest eskalacja, nie pewna automatyczna decyzja.

2. Prompt injection przez dane operacyjne

Złośliwa instrukcja może znaleźć się w opisie zgłoszenia, komentarzu w kodzie, nazwie zasobu albo pliku analizowanym przez model. Treść pochodząca ze środowiska nie może być traktowana jak instrukcja systemowa. Parser powinien oddzielać dane od poleceń, a warstwa narzędzi sprawdzać każdą akcję niezależnie od uzasadnienia wygenerowanego przez model.

Ten problem szerzej opisujemy w analizie prompt injection i ochrony systemów LLM. W agentowym SOC stawka jest wyższa, ponieważ model nie tylko odpowiada tekstem, lecz może wpływać na produkcję.

3. Nadmierne uprawnienia aktuatorów

Agent odpowiedzialny za remediację nie powinien mieć stałego, globalnego administratora. Osobne tożsamości workload identity, krótkotrwałe tokeny i uprawnienia ograniczone do konkretnego narzędzia pozwalają zmniejszyć blast radius. Odczyt, utworzenie rekomendacji, izolacja urządzenia i zmiana polityki to cztery różne poziomy ryzyka — nie jedna rola „security agent”.

Ważne jest również rozdzielenie red i green team. Agent szukający ścieżki ataku nie powinien z automatu dziedziczyć możliwości wykonania tej ścieżki w środowisku produkcyjnym.

4. Błąd modelu i automation bias

Agent może poprawnie wykryć podatność, ale błędnie ocenić ekspozycję. Może też zasugerować patch, który łamie kompatybilność albo pozostawia aktywny inny wektor. Człowiek widzący pewnie sformułowaną rekomendację łatwo zamienia weryfikację w formalność.

Interfejs powinien prezentować dowody, zakres niepewności, alternatywne wyjaśnienia i oczekiwany wpływ zmiany. Akceptacja bez dostępu do tych informacji nie jest realnym nadzorem.

5. Ryzyko łańcucha modeli i narzędzi

W architekturze wielomodelowej błąd routingu może wysłać wrażliwe dane do niewłaściwego modelu lub regionu. Aktualizacja modelu może zmienić zachowanie bez zmiany playbooka. Narzędzie MCP, konektor albo integracja może zostać przejęta niezależnie od samego modelu.

Rejestr wdrożenia powinien obejmować wersję modelu, politykę routingu, zestaw narzędzi, zakres tokenu, źródła kontekstu i identyfikator zatwierdzającego. To podstawa późniejszego dochodzenia.

Jak bezpiecznie uruchomić pilotaż

Najrozsądniejszy pierwszy etap nie daje agentowi prawa do samodzielnej zmiany produkcji. Project Perception może działać w trybie obserwacji i porównywać swoje priorytety z istniejącym procesem vulnerability management.

Pilotaż warto podzielić na cztery bramki:

obserwacja: agent analizuje dane, ale nie tworzy zadań ani zmian;
rekomendacja: tworzy propozycję z dowodami i właścicielem do zatwierdzenia;
działanie odwracalne: może wykonać ograniczoną zmianę z automatycznym rollbackiem;
automatyzacja warunkowa: działa bez ręcznej zgody tylko dla wcześniej zatwierdzonych, niskiego ryzyka przypadków.

Każda bramka wymaga osobnych metryk. Mierz nie tylko liczbę znalezionych podatności, ale też precision, recall na znanym zbiorze, odsetek fałszywych priorytetów, czas do poprawnej decyzji, liczbę ręcznych korekt i wpływ remediacji na dostępność.

Przydatny jest zestaw „golden cases”: realne, zanonimizowane przypadki z poprzednich incydentów i podatności, dla których znamy właściwe rozstrzygnięcie. Po każdej zmianie modelu lub polityki routingu uruchamia się regresję. Jeśli system nie przechodzi krytycznego przypadku, nie powinien otrzymać szerszych uprawnień.

Kontrole, których nie wolno pominąć

Minimalny baseline dla agentowego systemu bezpieczeństwa obejmuje:

izolację danych klienta i jawne zasady retencji;
allowlistę narzędzi, parametrów i docelowych zasobów;
krótkotrwałe poświadczenia zamiast wspólnego sekretu;
zatwierdzenie dwuosobowe dla zmian o dużym wpływie;
pełny, odporny na manipulację log decyzji i wywołań;
limit kosztu, czasu, liczby kroków i liczby modyfikowanych aktywów;
testy prompt injection oraz zatrucia wiedzy;
procedurę odłączenia agentów bez utraty podstawowych funkcji SOC;
cykliczny red teaming agentów AI;
obserwowalność agentów i narzędzi po wdrożeniu.

Nie wszystkie akcje wymagają tej samej bramki. Wzbogacenie zgłoszenia o publiczny identyfikator CVE ma inny profil niż rotacja sekretu, blokada konta czy zmiana reguły sieciowej. Macierz wpływu powinna łączyć klasę aktywa, odwracalność, zakres i pewność modelu.

Co Project Perception oznacza dla SOC

Microsoft trafnie identyfikuje problem: zespoły nie potrzebują kolejnej fali alertów, tylko lepszej selekcji i szybszego przejścia od sygnału do poprawnego działania. Agentowa korelacja może szczególnie pomóc tam, gdzie dane są rozproszone między systemem tożsamości, EDR, chmurą, CMDB i repozytorium kodu.

Nie oznacza to końca analityków. Zmienia się raczej ich punkt ciężkości — z ręcznego zbierania kontekstu na projektowanie granic, ocenę hipotez, zatwierdzanie działań o dużym wpływie i badanie wyjątków. Potrzebne będą kompetencje łączące detection engineering, bezpieczeństwo tożsamości, niezawodność automatyzacji oraz bezpieczeństwo modeli i agentów.

Organizacja kupująca Project Perception nadal odpowiada za własny model operacyjny. Powinna ustalić, kto jest właścicielem błędnej remediacji, jak długo przechowywane są ślady, które dane mogą opuszczać region i jak wygląda reakcja na kompromitację samego agenta.

Jak sprawdzić wynik po publicznym preview

Po uruchomieniu wersji zapoznawczej 3 sierpnia nie warto zaczynać od pytania, czy lokalny wynik dorównuje 96% z CyberGym. Najpierw trzeba ustalić, czy organizacja mierzy ten sam typ zadania. Benchmark producenta i kolejka podatności konkretnej firmy mogą różnić się dostępnością kontekstu, definicją sukcesu, jakością CMDB oraz liczbą systemów niestandardowych.

Lokalna ewaluacja powinna rozdzielić co najmniej wykrycie, priorytetyzację, zaproponowanie poprawki i bezpieczne wykonanie. Agent może dobrze rozpoznać błąd, ale źle ustalić właściciela; poprawnie wybrać patch, ale przeoczyć zależność biznesową; wykonać zmianę, ale nie potwierdzić rezultatu. Jeden łączny procent ukryje te różnice.

Dla każdego etapu zapisz oczekiwany wynik, niedopuszczalny skutek i źródło prawdy. Następnie porównaj agenta z obecnym procesem na tej samej próbce. Przy ocenie kosztu uwzględnij tokeny, integracje, pracę reviewerów, błędne eskalacje, utrzymanie ewaluacji i obsługę incydentów. Dopiero taki rachunek pokaże, czy raportowana oszczędność modelowa przekłada się na środowisko firmy.

Warto też prowadzić osobny rejestr „near miss”: przypadków, w których działanie zostało zatrzymane przez człowieka tuż przed szkodliwą zmianą. Wysoka liczba zaakceptowanych rekomendacji może wyglądać dobrze, podczas gdy near miss ujawnia niewystarczające granice.

Wniosek

Project Perception jest jednym z najbardziej konkretnych przykładów przejścia od asystenta bezpieczeństwa do systemu, który współpracuje w pętli red–blue–green. Ogłoszona architektura jest obiecująca, a raportowane wyniki MAI-Cyber-1-Flash pokazują, dlaczego wyspecjalizowane modele mogą być użyteczne w vulnerability management. Nadal są to jednak dane producenta przed szeroką publiczną weryfikacją.

Bezpieczna adopcja zaczyna się od trybu obserwacji, minimalnych uprawnień i mierzalnych bramek. Dopiero powtarzalna skuteczność na lokalnych przypadkach uzasadnia przejście do odwracalnych działań. Agent działający szybciej od człowieka potrzebuje silniejszych, a nie słabszych granic.

Breachroad może przeprowadzić threat modeling, red team i przegląd uprawnień agentowego SOC przed uruchomieniem produkcyjnym.

Źródła pierwotne: Microsoft — Rethinking security for the age of AI, Microsoft Security — Project Perception.