Prawda o agentach AI w SOC: rzeczywistość vs. marketing hype #EN336

TL;DR

Prawdziwe agenty AI są skomplikowane – pojedyncza analiza alertu wymaga ponad 100 wywołań modeli językowych, nie jest to „prosty chatbot”
Pełna autonomia to mit – w pełni autonomiczny SOC (Tier 1-3) jest technicznie niemożliwy ze względu na halucynacje LLM i brak kontekstu organizacyjnego
Wpływ na wydajność jest mierzalny – MTTR spada do minut, zespoły zyskują 2-10x większą capacity i mogą badać wcześniej ignorowane alerty
Tradycyjne SOAR to za mało – playbooki to tylko drzewa decyzyjne „if-else”, podczas gdy AI potrafi myśleć kontekstowo
Zaufanie buduje się stopniowo – przez trzy poziomy autoryzacji: od generowania raportów, przez zamykanie fałszywych alarmów, aż po blokowanie kont
Transparentność to minimum – każdy agent musi pokazywać pełny łańcuch dowodów i reasoning prowadzący do decyzji
Atakujący (jeszcze) nie używają AI masowo – wybierają ścieżkę najmniejszego oporu, a podstawowe luki wciąż działają

To są moje notatki z rozmowy Ashisha Rajana z Edwardem Wu, założycielem i CEO Dropzone AI. Wu od kilku lat buduje rozwiązania oparte na agentach AI dla Security Operations Centers i posiada liczne patenty w obszarze AI security.

Warto zaznaczyć kontekst: Wu wcześniej w swojej karierze sam tworzył systemy detekcji AI/ML. Przyznaje, że jego motywacją do pracy nad Dropzone jest częściowo „odkupienie win” za stworzenie tego, co nazywa „armatkami z alertami” (alert cannons). Obecnie skupia się na rozwiązaniu problemu „zmęczenia alertami” (alert fatigue), który sam pomagał generować.

Wszystkie przemyślenia, obserwacje i wnioski przedstawione poniżej pochodzą z tej rozmowy i stanowią perspektywę rozmówców, nie moje własne opinie.

Dlaczego tradycyjne SOAR to za mało?

Według Wu, większość organizacji korzystających z narzędzi SOAR (Security Orchestration, Automation and Response) napotyka fundamentalne ograniczenie wynikające z samej natury playbooków.

Playbooki to w istocie drzewa decyzyjne oparte na instrukcjach warunkowych. Działają według schematu „jeśli warunek A, to akcja X; w przeciwnym razie akcja Y”. Sprawdza się to przy prostych, powtarzalnych scenariuszach, jednak cyberbezpieczeństwo rzadko jest proste i przewidywalne.

Prawdziwe agenty AI różnią się fundamentalnie. Zamiast podążać za sztywnym skryptem, analizują kontekst, łączą różne źródła danych i podejmują decyzje na podstawie reasoning, nie tylko pattern matching. Wu nazywa to „dynamicznym planowaniem” – zdolnością do dostosowania śledztwa do unikalnej sytuacji alertu.

Mit w pełni autonomicznego SOC

Wu jest w tej kwestii stanowczy: w pełni autonomiczny SOC, zastępujący ludzi od Tier 1 do Tier 3, jest obecnie technicznie niemożliwy.

Wymienia dwa główne powody:

Problem halucynacji: Modele LLM wciąż mają tendencję do generowania nieprawdziwych informacji. W środowisku security, gdzie każda decyzja ma konsekwencje, nie można polegać na systemie, który może „zmyślać” fakty.

Brak pełnego kontekstu organizacyjnego: Ogromna część wiedzy o politykach, preferencjach, wyjątkach i niuansach istnieje wyłącznie „w głowach ludzi”, a nie w cyfrowych bazach danych. AI nie ma dostępu do tej wiedzy plemiennej.

W praktyce realne zastosowanie AI w SOC to delegowanie zadań. Agent może przeprowadzić wstępne dochodzenie i dostarczyć człowiekowi gotowy raport z rekomendacją (np. „true positive” lub „false positive”) do ostatecznej weryfikacji. Wu używa metafory wojskowej: agenci AI to „żołnierze piechoty”, podczas gdy ludzie-analitycy to „generałowie”. Żołnierze wykonują powtarzalne zadania w terenie, z kolei generałowie planują misje, podejmują strategiczne decyzje i nadzorują całość.

Jak naprawdę działają agenty AI w SOC?

Wu odnosi się bezpośrednio do przekonania wielu technicznych specjalistów z obszaru security, którzy słysząc o „agentach AI” myślą: „Jestem wystarczająco inteligentny, zbuduję własnego agenta”.

System Dropzone wykonuje ponad 100 odrębnych wywołań modeli językowych, aby autonomicznie zbadać jeden alert bezpieczeństwa. Nie chodzi tu o proste zapytanie do ChatGPT w stylu „czy ten alert jest groźny?”, lecz o złożoną orkiestrację wielu specjalistycznych wywołań.

Wu podaje przykład generowania poprawnych zapytań SPL (Search Processing Language) dla Splunka, które jest ekstremalnie trudne. Wymaga zrozumienia kontekstu alertu, znajomości struktury logów w konkretnym środowisku, umiejętności formułowania precyzyjnych query i weryfikacji wyników. Każdy z tych kroków to osobne wywołanie modelu. Pomnóż to przez dziesiątki aspektów jednego alertu.

Pułapka DIY: paradoks złożoności

Wu ostrzega przed myśleniem „zbudujemy to sami”. Główne wyzwania to:

Złożoność procesu: Ponad 100 wywołań LLM na jeden alert to skala złożoności, którą trzeba zorkiestrować
Koszmar integracji: Nie wystarczy połączyć się z API Splunka – trzeba „nauczyć” AI generowania poprawnych zapytań w specjalistycznych językach
Rozumienie schematów: Agent musi rozumieć niestandardowe schematy danych w logach danej organizacji

Wu zauważa interesujący paradoks: najbardziej zaawansowane organizacje najchętniej budują systemy DIY, ale ze względu na złożoność ich środowisk, jest to dla nich „wykładniczo trudniejsze” niż dla małego startupu.

Mierzalny wpływ na wydajność

Wu podkreśla konkretne metryki, które klienci Dropzone obserwują:

MTTR (Mean Time To Resolution) spada do minut – zamiast godzin czy dni
2-10x zwiększenie capacity zespołu – te same osoby mogą obsłużyć znacznie więcej alertów
Badanie wcześniej ignorowanych alertów – zespoły mogą skupić się na przypadkach, które normalnie by odpuściły ze względu na ograniczenia czasowe

Są to rzeczywiste wyniki z produkcyjnych wdrożeń, nie teoretyczne obietnice.

AI jako specjalista od technologii cloud

Wu wskazuje na kolejny palący problem w SOC: lukę kompetencyjną. Zespoły analityków są zalewane logami z AWS, Azure i GCP, ale często „nie mają pojęcia”, jak poprawnie je interpretować lub jakie logi są istotne.

Dlatego agenci AI są „wstępnie przeszkoleni” w obsłudze tych specjalistycznych narzędzi (np. Splunk, AWS, CrowdStrike). Działają jak „backstop” – szczególnie w nocy i weekendy, gdy na zmianie nie ma eksperta od danej technologii.

Cztery poziomy dojrzałości AI w SOC

Wu przedstawia framework adopcji AI w security operations, który odpowiada temu, jak organizacje wprowadzają nowych członków zespołu:

Poziom 1: Part-time contractor (niezależny wykonawca)

Na tym etapie wykorzystujesz chatboty do bardzo konkretnych, pojedynczych zadań. Dajesz im zadanie, które nie jest zbyt skomplikowane i które po prostu nie chcesz robić samodzielnie. To poziom eksperymentów z ChatGPT czy Copilot na zasadzie ad hoc.

Poziom 2: Intern (stażysta)

Zaczynasz dawać AI pełne „projekty stażysty”. Agent może np. analizować wszystkie alerty, jednak nadal przeglądasz każde jego odkrycie i każdą konkluzję. Ufasz, że wykona pracę, ale weryfikujesz każdy output. Nie pozostawiasz agenta bez nadzoru.

Poziom 3: Senior individual contributor (senior specjalista)

Budujesz wystarczającą pewność co do technologii. Dokładność analityczna jest na tyle wysoka, że zaczynasz ufać bez przeglądania każdego outputu. Nie stoisz nad AI i nie sprawdzasz każdego szczegółu. Możesz go coachować, żeby robił pewne rzeczy w określony sposób, ale nie trzymasz go za rękę.

Poziom 4: Genius-level team member (członek zespołu z inteligencją geniusza)

Technologia jest na tyle dojrzała, że zaczynasz myśleć o tym, co może zrobić ponad możliwości obecnego zespołu. Wu podaje przykład: daj LLM 2000 alertów bezpieczeństwa i poproś o znalezienie wzorców. Według niego, nikt na planecie nie lubi tego typu pracy, natomiast GenAI nie ma nic przeciwko i często świetnie radzi sobie z identyfikowaniem wzorców w bardzo zaszumionych zbiorach danych.

To są projekty przekraczające typową ludzką inteligencję lub zainteresowanie, ale mogące być bardzo wartościowe dla organizacji.

Budowanie zaufania do AI w bezpieczeństwie

Wu podkreśla, że zaufania nie da się zmierzyć jak metryk technicznych. Nie ma wskaźnika „agent AI zyskał 2 dodatkowe punkty zaufania” – to podświadome odczucie.

Budowanie zaufania do agenta AI przebiega bardzo podobnie jak budowanie zaufania do nowych współpracowników. Nie ufasz komuś pierwszego dnia, obserwujesz jak działa, widzisz konsystencję i stopniowo zwiększasz zakres odpowiedzialności.

Trzy poziomy autoryzacji

Wu opisuje konkretny framework wdrażania, który Dropzone stosuje u klientów:

Poziom 1 – Początkowy zakres:

Przeanalizuj alerty bezpieczeństwa
Zrozum ich kontekst
Wygeneruj raport
Wyślij do analityka

To bezpieczny start. Agent nie podejmuje żadnych działań, tylko asystuje.

Poziom 2 – Rozszerzone uprawnienia:

Przeanalizuj wszystkie alerty
Jeśli alert jest benigny – zamknij sprawę z notatkami
Jeśli alert jest pilny i złośliwy – eskaluj do człowieka

Tu agent już podejmuje decyzje, ale tylko o zamykaniu fałszywych alarmów. Krytyczne przypadki trafiają do ludzi.

Poziom 3 – Autonomiczne działania:

Przeanalizuj wszystkie alerty
Zamykaj benigne alerty, eskaluj złośliwe
Dla specyficznych typów alertów lub zasobów – blokuj konta użytkowników lub umieszczaj endpointy w kwarantannie

To najwyższy poziom, w którym agent ma autoryzację do działań wpływających na infrastrukturę.

Kluczowa obserwacja Wu: zaufanie to nie binarny przełącznik, to spektrum. Organizacje przechodzą przez te poziomy w tempie dopasowanym do swojego komfortu.

Transparentność jako fundament

Rajan pyta o rolę transparentności w budowaniu zaufania. Wu jest jednoznaczny: na tym etapie transparentność to nie „nice to have”, to table stakes.

Każdy produkt badający alerty bezpieczeństwa musi dostarczać pełny łańcuch dowodów, reasoning prowadzący do decyzji i wszystkie metadane zebrane w procesie. To analogiczne do chain of custody w tradycyjnym śledztwie.

Każda decyzja – czy to uznanie alertu za fałszywy alarm, czy wezwanie analityka w środku nocy – musi być uzasadniona. Wu podkreśla, że uzasadnienie typu „obudzę Ashisha w środku nocy” wymaga pełnego udokumentowania dlaczego ta decyzja została podjęta. Agent AI musi „pokazać swoją pracę domową”, w przeciwnym razie security teams nie będą w stanie mu zaufać.

Prywatność danych i uczenie modeli

Wu wyjaśnia, że istnieją techniki pozwalające unikać dostępu do wrażliwych danych klientów przy trenowaniu modeli.

Dropzone stosuje single-tenant architecture – dane każdego klienta są segregowane w dedykowanych komponentach compute, network i storage. Jednak to dopiero początek. Kiedy Dropzone ulepsza swój system, wykorzystuje wyłącznie zdeidentyfikowaną telemetrię. Klienci mogą audytować dokładnie, co jest udostępniane zapleczu systemowemu i mogą również zrezygnować.

Analogia medyczna

Wu używa przykładu ze świata medycyny, który ilustruje koncepcję federated learning:

Lekarze nie uczą się na rzeczywistych pacjentach z imionami i nazwiskami, lecz z zdeidentyfikowanych case studies: „70-letni mężczyzna z północnego stanu Nowy Jork, objawy A, B i C, wyniki testów X, Y i Z – zdiagnozowano rzadką chorobę”.

Profesjonaliści medyczni mają całe bazy takich anonimowych przypadków, co pozwala odkrywać nowe choroby i ulepszać diagnostykę globalnie bez naruszania prywatności konkretnych pacjentów.

Dropzone działa analogicznie. Zbiera zdeidentyfikowane przypadki różnych typów alertów, różnych determinacji systemu, różnych setupów organizacyjnych. Pozwala to systemowi widzieć więcej wariantów i lepiej obsługiwać nowe scenariusze – całość bez dostępu do PII.

Rajan podsumowuje: to właśnie ta możliwość prostego wyjaśnienia bez wchodzenia w rolę data scientista i mówienia „nie zrozumiesz, bo model jest zbyt skomplikowany” buduje prawdziwe zaufanie. Transparentność oznacza unikanie black boxów.

Gdzie podziała się AI atakujących?

Rajan zapytał o wzrost liczby ataków z użyciem AI. Wu jednak studzi emocje – choć wolumen ataków rośnie „stabilnie”, nie zaobserwował skoku 5x czy 10x.

Jego zdaniem powód jest prosty: atakujący wciąż odnoszą ogromne sukcesy bez GenAI. Wybierają „ścieżkę najmniejszego oporu”, a dotychczasowe metody wciąż działają. Dopóki obrońcy nie podniosą poziomu swojej gry, motywacja atakujących do nauki i adopcji GenAI jest niska.

Gdzie w takim razie trafia talent AI? Wu żartobliwie wskazuje na… e-maile sprzedażowe (AI SDRs). Zauważa, że jako założyciel firmy widzi w swojej skrzynce radykalny wzrost jakości personalizacji zimnych maili. W tematach pojawiają się nazwiska członków jego zespołu, nazwy klientów, niedawne nagrody czy podcasty, w których występował. To te same techniki, co spear phishing – tylko wykorzystywane legalnie.

Przyszłość analityków SOC Level 1

Wu jest pragmatyczny, ale optymistyczny w kwestii przyszłości analityków Level 1.

Tak, rola Level 1 SOC analyst jako stanowisko pracy będzie z czasem zastąpiona przez software. Jest to nieuniknione, jednak nie oznacza to, że ludzie stracą pracę.

Osoby pracujące obecnie na Level 1 będą awansowane do ról Level 2 lub Level 3 albo przejdą do innych obszarów cyberbezpieczeństwa.

Wu wskazuje konkretne możliwości:

Większość security teams chciałaby mieć więcej red teamerów
Potrzeba security architects, którzy mogą przebić się przez organizacyjne bariery
Ktoś musi ewangelizować i implementować Zero Trust networking
Ciągła walka z higieną infrastruktury – np. przestać wystawiać 1000 stacji Windows przez RDP na publiczny internet

Wu podkreśla kluczowy punkt: w cyberbezpieczeństwie jest tak wiele dodatkowych projektów, potrzeb i usprawnień, że osoby pracujące obecnie jako analitycy L1 bez problemu znajdą bardziej interesujące role.

Rajan dodaje analogię: ludzie pracujący na maszynach do pisania nie zostali wyeliminowani, zostali przekwalifikowani do pracy na komputerach i Microsoft Word. Wciąż piszemy, tylko na lepszych narzędziach.

Gdzie jeszcze AI zmieni cyberbezpieczeństwo?

Wu przedstawia prosty framework identyfikacji obszarów gotowych na AI automation: szukaj pracy manualnej i powtarzalnej.

Badanie alertów to oczywisty element, jednak jest znacznie więcej obszarów:

Vulnerability management – bardzo manualne, bardzo powtarzalne
Zadania GRC (Governance, Risk, Compliance) – pełne powtarzalnych procesów
Patching – niekończący się cykl
Czytanie raportów threat actor – relewanatnych dla konkretnego biznesu
Code review – szczególnie przy skali
Uruchamianie Metasploit – przeciwko setkom publicznych IP

Każdy z tych obszarów powinien być gotowy na automatyzację.

Jak SOC teams już dziś używają AI?

Wu dzieli się konkretnymi przykładami, które słyszy od zespołów security operations. Technologie jak ChatGPT i Copilot sprawiły, że wiele możliwości stało się dostępnych dla członków SOC.

Przykłady z praktyki:

Analiza obfuskowanego kodu:

SOC analysts z sukcesem używają ChatGPT do analizy zaciemnionego JavaScriptu oraz interpretacji skomplikowanych PowerShell scripts.

OCR i analiza obrazów:

Wykorzystanie AI do zrozumienia, co pokazuje konkretny obrazek lub attachment, oraz ekstrakcja tekstu z screenshotów.

Pisanie raportów:

Wu podkreśla, że ChatGPT i Copilot są „tremendous” w tym zadaniu. Gdy masz alert, przeprowadziłeś śledztwo i wypisałeś 5 bulletów, AI „hydruje” te 5 punktów w pełne, dobrze napisane 1-2 paragrafy.

To małe, ale sprytne zadania, które pojawiają się w codziennej pracy analityka SOC.

Praktyczne prompty dla SOC teams

Na podstawie rozmowy Wu z Rajanem, oto konkretne prompt patterns do wykorzystania:

1. Deobfuskacja i analiza skryptów

Kiedy stosować: Gdy natrafiasz na zaciemnionych JavaScript, PowerShell lub inny kod w alertach

Przykładowy prompt:

Przeanalizuj poniższy obfuskowany skrypt JavaScript i wyjaśnij:

1. Co ten skrypt robi krok po kroku
2. Jakie są potencjalne zagrożenia
3. Czy zawiera znane techniki MITRE ATT&CK

[wklej kod]


---

 2. OCR i analiza załączników graficznych

Kiedy stosować:** Gdy otrzymujesz alerty z załącznikami obrazkowymi lub screenshotami

Przykładowy prompt:

Przeanalizuj ten załącznik obrazkowy z alertu phishingowego i powiedz mi:
1. Jaki tekst jest widoczny na obrazie
2. Czy są podejrzane linki lub domeny
3. Jakie techniki social engineeringu są użyte
4. Jaki jest poziom zagrożenia (niski/średni/wysoki)

[załącz obraz]


---

3. Hydratacja raportów z bulletów

Kiedy stosować: Po zakończeniu śledztwa, gdy masz notatki ale potrzebujesz formalnego raportu

Przykładowy prompt:

Przekształć poniższe 5 punktów ze śledztwa bezpieczeństwa w 2 dobrze napisane paragrafy raportu dla managementu:

- Alert: Suspicious login from IP 192.168.1.100
- Investigation: IP belongs to company VPN pool
- User: John Smith, verified via Slack
- Determination: False positive - legitimate remote work
- Action: None required, updated firewall rules documentation

Styl: profesjonalny, zwięzły, skupiony na faktach


---

4. Analiza wzorców w dużych zbiorach danych

Kiedy stosować: Gdy masz setki lub tysiące alertów i szukasz wspólnych mianowników

Przykładowy prompt:

Przeanalizuj poniższą listę 500 alertów bezpieczeństwa z ostatniego tygodnia i zidentyfikuj:
1. Najczęstsze typy alertów
2. Wspólne IP, domeny lub usernames pojawiające się wielokrotnie
3. Nietypowe wzorce czasowe (np. alerty o konkretnych godzinach)
4. Potencjalne kampanie lub skoordynowane ataki
5. Rekomendacje co do priorytetyzacji

[wklej dataset]


---

5. Interpretacja logów cloud (AWS/Azure/GCP)

Kiedy stosować: Gdy analyst nie zna specyfiki platform cloud lub potrzebuje szybkiej interpretacji

Przykładowy prompt:

Jestem SOC analyst i otrzymałem ten log z AWS CloudTrail. Pomóż mi zrozumieć:
1. Co konkretnie się wydarzyło (w prostych słowach)
2. Czy to normalne działanie czy potencjalne zagrożenie
3. Jakie dodatkowe logi powinienem sprawdzić
4. Czy wymaga to eskalacji

[wklej log]

Kontekst: Nasza organizacja używa AWS głównie dla środowisk dev/staging

---

6. Generowanie SPL/KQL queries

Kiedy stosować: Gdy potrzebujesz szybko stworzyć query w Splunk, Sentinel lub innym SIEM

Przykładowy prompt:

Wygeneruj SPL query dla Splunka, które znajdzie:
- Wszystkie failed login attempts
- Z ostatnich 24 godzin
- Dla użytkowników z grupy "admins"
- Pogrupowane po source IP
- Posortowane od najwyższej liczby prób

Index: main
Sourcetype: WinEventLog:Security

---

7. Tłumaczenie techniczne dla non-technical stakeholders

Kiedy stosować: Gdy musisz wytłumaczyć incydent managementowi lub biznesowi

Przykładowy prompt:

Przetłumacz poniższe techniczne ustalenia ze śledztwa na język zrozumiały dla executive leadership (non-technical):

[wklej techniczne szczegóły]

Uwzględnij:
- Co się stało (w prostych słowach)
- Jaki był business impact
- Co zrobiliśmy żeby to naprawić
- Jak zapobiegamy temu w przyszłości

Maksymalnie 3-4 zdania na każdy punkt.

Checklist: Co wziąć pod uwagę wdrażając AI w SOC?

Na podstawie analizy Wu, oto kluczowe punkty do weryfikacji przy ocenie dostawcy AI lub projektu DIY:

Realizm vs. Hype:

Czy dostawca obiecuje „w pełni autonomiczny SOC”? (Sygnał ostrzegawczy)
Czy przedstawia realistyczne ograniczenia technologii?

Transparentność:

Czy system dostarcza pełny „łańcuch dowodów”?
Czy wyjaśnia swoje rozumowanie dla każdej decyzji?
Według Wu to „absolutna podstawa”

Prywatność danych:

W jaki sposób model jest trenowany?
Czy dostawca stosuje izolację (single-tenant)?
Czy dane są deidentyfikowane?
Czy możesz audytować, co jest udostępniane?

Głębokość integracji:

Czy agent potrafi aktywnie generować zapytania (np. SPL, KQL)?
Czy rozumie schematy danych Twojej organizacji?
Czy wymaga niestandardowej konfiguracji dla Twojego środowiska?

Obsługa kontekstu:

Jaki jest plan na dostarczenie agentowi „wiedzy plemiennej”?
Jak system radzi sobie z kontekstem organizacyjnym, który nie jest zapisany w bazach danych?

Model współpracy:

Czy narzędzie wspiera model „generał-piechota”?
Czy daje ludzkim analitykom kontrolę nad decyzjami?
Jakie są poziomy autoryzacji i jak można je stopniowo rozszerzać?

Co możesz zrobić już teraz?

Wu sugeruje konkretny test drive dla osób rozważających wdrożenie agentów AI w swoim SOC.

Dropzone oferuje publiczne, niezablokowane demo produktu na swojej stronie (dropzone.ai). Nie trzeba rozmawiać z salesem – wystarczy wypełnić prosty formularz z trzema pytaniami. To rzadkość w enterprise security, gdzie zwykle każda rozmowa zaczyna się od „skontaktujmy się z zespołem sprzedaży”.

Wu jest aktywny na LinkedIn – można go znaleźć wyszukując „Edward Wu Dropzone”.

Kluczowy insight

Paradoks ścieżki najmniejszego oporu

Standardowo myślimy: Musimy natychmiast przestawić całą obronę na walkę ze skomplikowanymi atakami AI, ponieważ atakujący już masowo z niej korzystają.

W praktyce okazuje się, że: Jak zauważa Wu, atakujący wciąż odnoszą ogromne sukcesy, nie używając GenAI. Wybierają „ścieżkę najmniejszego oporu”, a nasze obecne, fundamentalne luki (brak MFA, źle skonfigurowane usługi chmurowe, prosty phishing) są wciąż tą ścieżką. Dopóki obrońcy nie podniosą poziomu swojej gry, motywacja atakujących do nauki i adopcji nowych technologii jest niska.

Dlaczego to jest istotne: Panika przed „AI attacks” odciąga zasoby od łatania „nudnych”, podstawowych dziur, które nadal pozostają głównym wektorem ataku. To klasyczne odwrócenie priorytetów – skupiamy się na futurystycznych zagrożeniach, ignorując te, które rzeczywiście nas atakują.

Test na jutro: Następnym razem gdy będziesz planować sprint bezpieczeństwa, zamiast pytać „jak zatrzymamy atak AI?”, spróbuj zapytać „czy nasze obecne luki są wciąż łatwiejsze do wykorzystania niż napisanie ataku AI?”. Sprawdź, czy to zmienia priorytety w Twoim backlogu. Możesz odkryć, że problem nie leży w braku obrony przed AI, ale w podstawowej higienie bezpieczeństwa.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: The Truth About Agentic AI in the SOC: Reality vs. Hype | Edward Wu, Dropzone AI – Cloud Security Podcast