Krótka odpowiedź na pytanie z tytułu: AI dziś realnie wspiera audyt bezpieczeństwa środowiska w chmurze w trzech miejscach - zbiera konfigurację, wykrywa odchylenie od polityki i porządkuje ryzyko według priorytetu - a decyzję o naprawie zostawia człowiekowi. Budowa własnego agenta, który robi więcej, jest możliwa, ale ma koszt utrzymania porównywalny z każdym innym systemem produkcyjnym, nie jednorazowy wydatek na wdrożenie.
Co AI dziś realnie robi w audycie bezpieczeństwa chmury
Marketing lubi jedno zdanie: "nasze narzędzie ma AI, więc widzi więcej". W praktyce, tam gdzie da się to sprawdzić, mechanizm jest węższy i bardziej konkretny.
Microsoft Defender for Cloud odkrywa inwentarz sztucznej inteligencji w środowisku klienta - komponenty aplikacji, dane i artefakty modeli, od kodu po chmurę - i ocenia ich konfigurację względem gotowych rekomendacji, zanim błąd trafi na produkcję (Microsoft Learn, "Overview - AI security posture management", odczyt 13.08.2026). To jest dokładnie zakres CSPM: skanowanie konfiguracji kont AWS, Azure i GCP pod kątem znanych błędów, nie analiza treści ani ocena intencji.
Drugi realny mechanizm to priorytetyzacja w ramach zarządzania podatnościami. Zamiast listy stu alertów bez kolejności, analiza ścieżki ataku Defender for Cloud wskazuje, które luki razem tworzą realną drogę do zasobu, a które są izolowane i mniej pilne. To wspiera pracę zespołu threat intelligence, nie zastępuje jej - ocena, czy dana ścieżka faktycznie jest wykorzystywana w praktyce, wciąż wymaga analityka.
Duzi dostawcy modeli traktują to jako osobną kategorię produktową, nie poboczną funkcję. Anthropic pozycjonuje Claude Mythos 5 wprost jako "nasz najbardziej zaawansowany model do cyberbezpieczeństwa i badań biologicznych" (Anthropic, strona produktowa Claude Mythos, odczyt 13.08.2026) - deklaracja producenta o sobie, którą warto czytać z tym samym dystansem, z jakim czyta się dowolną liczbę ze strony sprzedażowej, ale sam fakt wydzielenia osobnego modelu pod tę domenę jest sygnałem, gdzie rynek widzi pieniądze. Wszystkie te sygnały trafiają docelowo do zespołu SOC, który podejmuje decyzję - AI porządkuje kolejkę, nie zamyka jej samodzielnie.
Budowa własnych agentów AI do bezpieczeństwa - jak to wygląda w praktyce
"Zbudować własnego agenta" brzmi jak jedna decyzja. W praktyce to zestaw czterech osobnych decyzji, z których każda ma inny profil ryzyka.
Pierwsza to wybór modelu i narzędzi, do których agent dostaje dostęp - API skanera konfiguracji, baza CVE, może integracja z SIEM. Model sam z siebie nic nie widzi; widzi dokładnie to, do czego dostał narzędzie.
Druga to ograniczenie dostępu - jakie konta i zasoby agent może odpytać, a jakich nie. To ograniczenie musi być twardsze niż dla człowieka z tymi samymi uprawnieniami, bo agent nie ma intuicji co do tego, kiedy się zatrzymać przed granicą uprawnień.
Trzecia to test w izolowanym środowisku, zanim agent dostanie dostęp do czegokolwiek produkcyjnego - dokładnie tak samo, jak testuje się każdą inną zmianę w infrastrukturze, tylko rzadziej się o tym pamięta, bo "to przecież tylko AI".
Czwarta, najczęściej pomijana, to nadzór i logowanie decyzji - zapis tego, co agent zrobił i dlaczego, w formie, którą później da się przejrzeć. Bez tego kroku agent jest czarną skrzynką, a odpowiedź na pytanie "dlaczego system to zrobił" nie istnieje.
Koszty i problemy tej drogi
Cztery decyzje z poprzedniej sekcji nie kończą się po wdrożeniu - są pętlą, którą trzeba powtarzać, gdy zmienia się model, zakres albo infrastruktura pod spodem.
Fragmentacja licencyjna jest już faktem, nie prognozą. Od 1 lipca 2026 wykrywanie i nadzór nad agentami AI - agentami Microsoft Foundry i agentami firm trzecich - przestało być częścią planu Defender CSPM i wymaga osobnej licencji Microsoft Agent 365; funkcja, która wcześniej była wliczona w istniejący plan, dziś jest osobną pozycją budżetu (Microsoft Learn, "Overview - AI security posture management", odczyt 13.08.2026). Firma, która już płaci za CSPM, nie dostaje nadzoru nad agentami za darmo tylko dlatego, że jest klientem.
Druga bariera to dostęp do najmocniejszych modeli. Zarówno Claude Mythos 5, jak i rodzina Daybreak od OpenAI, opisana w poprzednim artykule o AI w SOC, trafiają dziś wyłącznie do wąskiej grupy zweryfikowanych partnerów, nie na wolny rynek. Anthropic opisuje dostęp jako otwarty dla "niewielkiego grona początkowych partnerów testowych" w obszarze cyberbezpieczeństwa, a warunkiem korzystania jest zaakceptowanie 30-dniowej retencji danych na potrzeby monitoringu bezpieczeństwa (Anthropic, strona produktowa Claude Mythos, odczyt 13.08.2026). Zespół, który buduje agenta samodzielnie, dziś robi to na modelach o wyraźnie niższej klasie możliwości niż te, którymi dysponują dostawcy zza bramki partnerskiej.
Trzeci koszt to nowa klasa błędu, której klasyczny skaner nie zna. Wstrzyknięcie polecenia (prompt injection) polega na tym, że dane wejściowe - kod, log, treść strony, którą agent analizuje - same w sobie zawierają instrukcję zmieniającą zachowanie modelu, a mechanizm ten działa niezależnie od tego, czy instrukcja jest czytelna dla człowieka (OWASP GenAI Security Project, "LLM01 Prompt Injection", genai.owasp.org, odczyt 13.08.2026). W klasycznym skanerze tego problemu nie ma, bo skaner nie interpretuje treści jako poleceń. W agencie, który czyta logi i konfigurację, a potem na tej podstawie coś rekomenduje, ta granica znika - i to jest dokładnie powód, dla którego test w izolacji z poprzedniej sekcji nie jest pustą formalnością, tylko realnym elementem procesu.
Blue team i red team - dwa różne zastosowania AI
Dwa terminy, które w tym tekście pojawiają się często, warto zdefiniować raz i wprost, zanim pójdą dalej.
Blue team (blue team) to zespół obronny - wykrywa, klasyfikuje i reaguje na zagrożenia w środowisku, które broni. Pracuje na co dzień z SIEM i SOAR, a jego miarą sukcesu jest to, ile realnych incydentów zostało złapanych, zanim wyrządziły szkodę.
Red team (red team) to zespół, który atakuje własną organizację na zlecenie, żeby sprawdzić, czy obrona faktycznie działa. To nie jest szerszy pentest: pentest dostaje listę systemów i szuka w niej jak najwięcej luk, a red team dostaje cel biznesowy i sam wybiera drogę, przy czym obrońcy zwykle nie znają terminu ani zakresu ćwiczenia - bo to właśnie ich reakcja jest przedmiotem testu.
Oba zespoły dziś dostają wsparcie AI, ale to nie jest jedna oś, tylko dwie niezależne decyzje: kierunek działania - obrona czy atak - i poziom autonomii, jaki dostaje model - sugestia czy samodzielne wykonanie.
Rynek już rysuje ten sam podział, choć nie zawsze wprost. OpenAI dzieli rodzinę modeli Daybreak jawnie na Daybreak Blue do pracy obronnej i Daybreak Red do pentestów, dostępny dopiero po osobnej kwalifikacji zespołu (OpenAI, "AI for Cybersecurity Teams", openai.com/business/solutions/cybersecurity, odczyt 13.08.2026). Anthropic nie dzieli Claude Mythos 5 na osobne warianty blue i red, ale stosuje bramkę inaczej - dwustopniowo. Mythos 5 wymaga kwalifikacji partnera, a poza tą bramką stoi Claude Fable 5: wedle producenta ten sam model bazowy z dodatkowymi zabezpieczeniami, w którym część zapytań z tych domen trafia automatycznie do modeli Opus (Anthropic, strona produktowa Claude Mythos, odczyt 13.08.2026). Filtrowany jest więc nie tylko dostęp, ale i to, co dostaje przepuszczony użytkownik. W obu przypadkach wniosek jest ten sam: im bliżej ofensywnej, wysoko autonomicznej ćwiartki macierzy, tym mocniej dostawca filtruje, kto w ogóle dostaje dostęp.
Purple team, trzeci termin z tej samej rodziny, nie jest osobnym zespołem, tylko sposobem pracy - blue i red team dzielą się wynikami na bieżąco zamiast działać w oddzielnych silosach, żeby wniosek z ataku trafiał do obrony od razu, nie dopiero w raporcie końcowym.
Kiedy i dlaczego oddać to specjalistom
Trzy pytania rozstrzygają, czy budowa własnego agenta ma dziś sens, czy jest tylko kosztownym eksperymentem.
Czy masz inwentaryzację zasobów w chmurze - wiesz dokładnie, co chronisz, zanim jeszcze pomyślisz o AI? Czy masz zespół zdolny nadzorować agenta w trybie ciągłym, nie tylko go włączyć i zapomnieć? Czy wiesz, dokąd trafiają dane wysyłane do modelu - do jakiego dostawcy, na jak długo i kto ma do nich dostęp po drodze?
Brak odpowiedzi "tak" na wszystkie trzy nie dyskwalifikuje budowy własnego rozwiązania, ale zmienia rachunek - koszt utrzymania z poprzedniej sekcji trzeba wtedy policzyć razem z kosztem budowania kompetencji, których jeszcze nie ma.
Luka między tym, co dziś da się kupić, a tym, co da się zbudować samodzielnie, jest większa niż rok temu - najmocniejsze modele są za bramką partnerską, a przeciętna firma buduje na tym, co zostaje poza nią. To jest dokładnie sytuacja, w której audyt bezpieczeństwa chmury zlecony specjaliście daje więcej niż własny, niedojrzały agent - dostawca usług red teamowych albo outsourcingu SOC już przeszedł tę krzywą uczenia się i ponosi to ryzyko zawodowo, nie przy okazji.
| Zadanie w audycie chmury | Co dziś realnie robi AI | Koszt/ryzyko budowy własnego agenta | Kiedy oddać specjaliście |
|---|---|---|---|
| Skanowanie konfiguracji (CSPM) | Wykrywa odchylenia od znanych wzorców błędnej konfiguracji | Niski - to najdojrzalszy, najbardziej ustandaryzowany mechanizm z opisanych w tym tekście | Rzadko - to zadanie da się kupić jako gotowe narzędzie bez budowy własnego agenta |
| Priorytetyzacja ryzyka | Porządkuje alerty według ścieżki ataku, nie ocenia jej sam | Średni - wymaga integracji z inwentaryzacją zasobów, której często brakuje | Gdy inwentaryzacji jeszcze nie ma - bez niej priorytetyzacja i tak nie zadziała |
| Red teaming / symulacja ataku | Producent opisuje zastosowanie jako pentesty i kontrolowany red teaming, po osobnej kwalifikacji zespołu (Daybreak Red) | Wysoki - dostęp do najmocniejszych modeli ofensywnych jest za bramką partnerską | Prawie zawsze - kwalifikacja zespołu i dostęp do modelu rzadko są po stronie klienta |
| Detekcja i klasyfikacja alertów (blue) | Wspiera analityka SIEM/SOAR sugestią klasyfikacji, nie automatyczną decyzją | Średni - błędna klasyfikacja bez nadzoru kosztuje przeoczony incydent | Gdy zespół nie ma zasobów, by przeglądać sugestie modelu na bieżąco |
| Nadzór nad decyzjami agenta | Zapisuje log decyzji do przeglądu - element pętli utrzymania, nie funkcja jednorazowa | Wysoki - to koszt powtarzalny, nie jednorazowy wydatek wdrożeniowy | Gdy nie ma dedykowanego zespołu do stałego przeglądu logów agenta |
Źródła
- Microsoft Learn, "Overview - AI security posture management - Microsoft Defender for Cloud", learn.microsoft.com/en-us/azure/defender-for-cloud/ai-security-posture (odczyt 13.08.2026)
- Anthropic, strona produktowa Claude Mythos, anthropic.com/claude/mythos (odczyt 13.08.2026)
- OpenAI, "AI for Cybersecurity Teams", openai.com/business/solutions/cybersecurity (odczyt 12.08.2026)
- OWASP GenAI Security Project, "LLM01 Prompt Injection", genai.owasp.org/llmrisk/llm01-prompt-injection (odczyt 13.08.2026)
- Cyber Katalog, hasło CSPM
- Cyber Katalog, hasło CTI
- Cyber Katalog, hasło SOC
- Cyber Katalog, hasło SIEM
- Cyber Katalog, hasło SOAR
- Cyber Katalog, hasło pentest
- Cyber Katalog, hasło red team
- Cyber Katalog, hasło blue team
- Cyber Katalog, hasło purple team
- Cyber Katalog, artykuł AI w SOC a obowiązki RODO i NIS2