Bezpieczne wdrażanie AI. Jak dynamicznie analizować ryzyko?

Artykuł sponsorowany

W opracowaniu „Security for AI blueprint” od TrendAI wskazano trzy główne wyzwania związane z rozwojem aplikacji AI. Mowa o poniższych zagadnieniach:

• ograniczone zrozumienie modeli AI, ich zastosowań oraz architektury wśród zespołów bezpieczeństwa;
• presja wywierana na szybkie dostarczanie innowacyjnych aplikacji AI (wraz z poprawkami), co często prowadzi do tego, że zespoły deweloperskie pomijają zasady bezpiecznego projektowania w architekturach i pipeline'ach AI;
• niepewność zespołów bezpieczeństwa odnośnie tego, jakie warstwy ochrony są niezbędne dla aplikacji AI - w środowiskach brakuje świadomości ryzyka i jego wpływu, co powoduje dezorientację w niektórych firmach.

Szerokie myślenie o ryzyku

Podczas wdrażania systemów AI konieczne jest uwzględnienie wielu rodzajów ryzyka. Wśród płaszczyzn ataku wyróżnia się m.in.:

• manipulowanie danymi wejściowymi;
• nieuprawnione wykorzystanie API;
• wstrzykiwanie złośliwego kodu z poziomu interfejsu użytkownika;
• podatności w bibliotekach i frameworkach;
• błędy w konfiguracji chmury, umożliwiające np. ataki DoS.

Wspomniane kategorie pokazują jasno, że cyberbezpieczeństwo powinno zostać uwzględnione już na samym początku wdrażania AI w organizacji. W ramach identyfikacji zagrożeń można wykorzystać OWASP TOP 10 dla LLM (dużych modeli językowych), mając na uwadze konieczność dynamicznego podejścia do ryzyka – dziś statyczne podejście do zagrożeń staje się nieefektywne wskutek nieustannego rozwoju AI.

Świadomość korzystania z AI

TrendAI w raporcie poświęconym wdrażaniu AI w przedsiębiorstwach jasno wskazuje konieczność nadzoru i zarządzania AI (ang. AI governance) przed szerokim korzystaniem z rozwiązań sztucznej inteligencji. W dokumencie jasno wskazano konieczność określenia osoby odpowiedzialnej za ryzyko związane z AI (właściciela ryzyka) oraz opisanie sposobów wykorzystania rozwiązań sztucznej inteligencji.

Kolejnym aspektem wskazanym w opracowaniu jest posiadanie pełnej widoczności podczas korzystania z LLM-ów. Kontrola przepływu danych między endpointami, usługami chmurowymi a wewnętrznym środowiskiem jest kluczowa dla bezpieczeństwa informacji.

Należy przy tym dodać obowiązki wynikające z RODO w przypadku przetwarzania danych osobowych, co również powinno zostać uwzględnione w analizie ryzyka.

Ekspert o ryzyku

Oskar Klimczuk, CyberDefence24: Jakie nowe rodzaje ryzyka wiążą się z wykorzystaniem AI?

Joanna Dąbrowska, Cybersecurity strategist, TrendAI: Rok 2026 przynosi fundamentalną zmianę w krajobrazie cyberbezpieczeństwa. Systemy Agentic AI - autonomiczni agenci zdolni do planowania, wykorzystywania narzędzi, podejmowania decyzji i działania w świecie cyfrowym bez stałego nadzoru człowieka - stają się standardem w organizacjach każdej wielkości. Klasyczny model Cyber Kill Chain, opracowany przez Lockheed Martin w 2011 roku, który pomagał w mapowaniu zagrożeń i rozpoznaniu ryzyka - wymaga przemyślenia, bo agenci AI są jednocześnie nowym typem celu i nowym typem broni. Ta dualność generuje kategorie zagrożeń, które jeszcze dwa lata temu nie istniały.

Rozważając osiem potencjalnych etapów ataku, już na pierwszym (rekonesans/rozpoznanie) możemy zaobserwować tę dualność. Niekontrolowane wykorzystywanie narzędzi AI w codziennej pracy, beztroskie wklejanie danych do chatbotów czy korzystanie z nieautoryzowanych pluginów może prowadzić do wycieku informacji, które staną się paliwem dla atakującego. Przechwycone dane pozwalają AI zbudować szczegółowy profil ofiary i przygotować kampanię precyzyjnie dostosowaną do konkretnej osoby. Dochodzi do tego zdolność technologii agentowej do analizy powierzchni ataku szybciej i kompletniej niż jakikolwiek zespół ludzki. Raport TrendAI „Fault Lines in the AI Ecosystem” dokumentuje, że liczba podatności AI wzrosła z ok. 300 w 2023 do ponad 1000 w 2025 roku, z prognozą 2800–3600 CVE w 2026.

Na etapie uzbrojenia i dostarczenia AI radykalnie podnosi skuteczność ataków. Deepfake przygotowany na bazie wiedzy z fazy rozpoznania, dostarczony w starannie dobranym momencie, np. późną porą czy w dniu obłożonym spotkaniami, jest w stanie oszukać nawet najbardziej świadomego użytkownika.

Po stronie zagrożeń dla samych agentów kluczowe ryzyka to zatrucie baz wiedzy RAG, wstrzykiwanie poleceń czy kompromitacja łańcucha dostaw narzędzi i pluginów. W dalszych fazach pojawiają się ryzyka w pełni specyficzne dla ery AI: jailbreak omijający zabezpieczenia modelu, ataki tool confusion, propagacja ataku między agentami w architekturach multi-agent czy memory poisoning utrwalający złośliwe instrukcje w pamięci agenta. Finalnie największe ryzyko stanowi wykorzystanie zaufanego komponentu do realizacji celów - wyciek danych przez standardowe funkcje agentowego środowiska czy sabotaż decyzyjny maskowany jako normalna aktywność biznesowa. Obecne zagrożenia materializują się po cichu, podszywają pod uprawnionych użytkowników i ukrywają w legalnych funkcjach systemu.

W jaki sposób można analizować ryzyko dotyczące sztucznej inteligencji?

Przede wszystkim nie myślmy o AI jako o osobnym tworze w infrastrukturze IT. To nowy typ narzędzia, ale działa w środowisku, które znamy - tożsamości cyfrowe i ich uprawnienia, środowiska serwerowe i kontenerowe, aplikacje. Uświadamiając sobie tę perspektywę, dochodzimy do fundamentalnej prawdy: analiza ryzyka powinna dotyczyć całego środowiska, w którym nasze AI „żyje” lub z którego użytkownicy nawiązują interakcje z zewnętrznymi narzędziami sztucznej inteligencji.

Podejście TrendAI „Security for AI Blueprint” potwierdza ten kierunek, wskazując na konieczność ochrony pełnego stosu AI - od infrastruktury i kontenerów, przez modele i dane, po API i użytkowników. Każda zmiana środowiska powinna być przedmiotem analizy pod kątem potencjalnej materializacji zagrożenia. Podatność, błąd konfiguracji czy niesforny użytkownik ignorujący procedury bezpieczeństwa to sygnały do przeliczenia prawdopodobieństwa wykorzystania tej słabości w ataku oraz wpływu na ciągłość działania czy integralność i poufność danych.

Na pierwszy rzut oka ryzyko wygląda znajomo, bo dotyka kluczowych atrybutów bezpieczeństwa systemu informacyjnego, a jednak mamy do czynienia z inną perspektywą i dynamiką, gdzie tempo zmian i autonomiczność decyzji wymuszają ciągłą, nie okresową analizę.

Jak AI zmieniło podejście do zarządzania ryzykiem, m.in. w zakresie dynamiki tego procesu?

Tradycyjne zarządzanie ryzykiem opierało się na założeniu, że krajobraz zagrożeń zmienia się w cyklach mierzonych miesiącami. Era Agentic AI fundamentalnie łamie to założenie. Blisko połowa podatności AI klasyfikowana jest jako wysoka lub krytyczna, a ich liczba rośnie wykładniczo, w takim wypadku kwartalny przegląd rejestru ryzyk staje się fikcją.

Najbardziej odczuwalna jest zmiana dynamiki. Gdy autonomiczny agent może w minuty przeprowadzić rekonesans i dostarczyć spersonalizowany atak, ryzyko staje się strumieniem zdarzeń wymagającym ciągłego monitorowania. Zmienia się też natura ryzyka - AI wprowadza adaptacyjność, gdzie wektor ataku może zmieniać się w trakcie przenikania i przejmowania kolejnych zasobów w organizacji, np. reagując na napotkane zabezpieczenia. Równolegle eksploduje powierzchnia ataku: każdy wdrożony agent to nowy węzeł w grafie ryzyka. Raport „Fault Lines” ujawnił 492 serwery MCP bez jakichkolwiek mechanizmów uwierzytelnienia oraz ponad 8000 publicznie dostępnych paneli administracyjnych - punkty wejścia, których rok temu nie było w żadnym rejestrze.

Zmienia się wreszcie relacja obrońca–atakujący. AI pogłębia odwieczną asymetrię, ale jednocześnie daje obrońcy nowe narzędzia. W ramach Zero Day Initiative, utrzymywanej przez TrendAI, powstało narzędzie ÆSIR, które wykorzystuje agentów AI do proaktywnego odkrywania podatności zero-day - od połowy 2025 roku ÆSIR wykrył 21 krytycznych CVE w infrastrukturze NVIDIA, Tencent i MCP, skanując w godziny to, co ludzkim zespołom zajmowałoby tygodnie. Zatem zarządzanie ryzykiem musi przejść od statycznych rejestrów do ciągłego, zautomatyzowanego procesu, a każda decyzja o wdrożeniu nowego agenta musi być traktowana jako decyzja o zmianie profilu ryzyka całej organizacji.

W jaki sposób możemy oceniać zagrożenia związane z agentami AI?

Agent AI to nie kolejna aplikacja do przeskanowania - to system autonomiczny, którego zachowanie zależy od kontekstu, danych wejściowych i stanu pamięci. Dla każdego agenta należy zmapować cztery warstwy ekspozycji: model bazowy (parametry, guardrails), prompt systemowy (instrukcje i łatwość ich obejścia), narzędzia (integracje MCP/API i ich uprawnienia) oraz pamięć i kontekst (historia, RAG, dostęp do danych). Skala problemu jest realna: analiza TrendAI Research wykazała, że 36,7% z ponad 7000 serwerów MCP było podatnych na ataki SSRF (Server Side Request Forgery - przyp. red.), a 20% repozytoriów open-source MCP zawierało kod generowany przez AI, z inherentnym ryzykiem halucynowanych zależności.

Samo mapowanie stosu AI nie wystarczy. Kluczowe pytanie brzmi: co najgorszego może zrobić ten agent w ramach nadanych mu uprawnień i dostępów do aplikacji biznesowych? Przy odpowiednio sformułowanym poleceniu (atak typu „prompt injection”) atakujący nie łamie zabezpieczeń, to agent sam wykonuje akcję w imieniu uprawnionego użytkownika. Dlatego ocena powinna obejmować zasięg rażenia każdego agenta i ćwiczenie „assume breach” (zakładamy, ze atak miał miejsce).

Obok tego konieczny jest wprowadzenie dedykowanego procesu AI red teaming, symulującego przejście przez wszystkie etapy Kill Chain. Zdecydowanie warto postawić na automatyczny, ciągły proces – pojawia się zmiana analizujemy potencjalne wystąpienie, przebieg i wpływ ataku na środowisko. Jednorazowy pentest nie jest w stanie pokazać realnej powierzchni ataku, bo nie jest w stanie nadążyć za dynamiką środowisk AI i ich adaptacyjnością. Pamiętajmy też specyfika i zakres działania środowisk agentowych wymusza zmianę podejścia do identyfikacji zagrożeń – należy postawić na analizę behawioralną, sprawdzająca czy obserwowane działanie agenta nie generuje ryzyka samo w sobie, jak też czy nie obserwujemy artefaktów wskazujących na kompromitację elementów lub całego stosu. Ostatni element stanowi analiza ryzyk łańcuchowych w architekturach multi-agent, gdzie kompromitacja jednego ogniwa kaskadowo wpływa na cały system.

W jaki sposób możemy przeciwdziałać zjawisku „shadow AI”?

Raport TrendAI „From Anarchy to Authority” z marca 2026 pokazuje skalę problemu: jedynie 38% organizacji posiada kompleksowe polityki dotyczące AI, a 67% decydentów przyznaje, że zatwierdzało wdrożenia AI mimo obaw o bezpieczeństwo. Co siódma organizacja opisuje swoje obawy jako „skrajne”, ale mimo to je ignoruje.

Zakazy nie działają. Powodują jedynie, że zjawisko schodzi do podziemia. Pracownik, który musi czekać trzy miesiące na akceptację wniosku, znajdzie alternatywę w trzy minuty. Fundamentem musi być wiarygodna oferta wewnętrzna: narzędzia AI równie wygodne jak publiczne alternatywy, ale w kontrolowanym środowisku z politykami dostępu i monitorowaniem.

Równie ważna jest widoczność. TrendAI adresuje to przez koncepcję Agentic Governance Gateway, umożliwiającą odkrywanie interakcji agentów, identyfikację ryzykownych działań, egzekwowanie polityk w runtime i koncepcję „human in the loop”, zakładającą nadzór człowieka nad procesem w krytycznych punktach. Głównym punktem kontroli powinna być warstwa interakcji - komunikacja między agentami, narzędziami, modelami, danymi i użytkownikami.

Właściwa technologia to element konieczny, ale niewystarczający. Równoległy wysiłek musi iść w edukację opartą na konkretach - uświadomienie pracownikom konsekwencji ich działań, np. jak dane wklejone do chatbota mogą pojawić się w odpowiedzi dla kogoś innego. Proces dopuszczania nowych narzędzi musi nadążać za rzeczywistością i uwzględniać kontekst i dynamikę środowiska – powinien zawierać jak najbardziej zautomatyzowaną ocenę ryzyka dla różnych przypadków użycia co na końcu doprowadzi do sprawnego wprowadzania nowych aplikacji i zaspokajaniu potrzeb użytkowników przy jednoczesnej świadomości konsekwencji tej decyzji. Shadow AI nie zniknie, pytanie brzmi, czy organizacja będzie świadomie nim zarządzać, czy dowie się o nim z raportu po incydencie.

Jak można eliminować ryzyko kaskadowych halucynacji modelu AI?

W środowisku Agentic AI halucynacja przestaje być błędem w tekście, staje się fałszywą przesłanką, na której kolejni agenci budują pozornie logiczne, ale oderwane od rzeczywistości wnioski i działania. Problem jest już realny: raport TrendAI „The Mirage of AI Programming” dokumentuje slopsquatting - asystenci kodowania halucynują nazwy nieistniejących pakietów, a atakujący rejestrują te nazwy i dostarczają przez nie malware. Kaskadowa halucynacja z fizycznym skutkiem w łańcuchu dostaw.

Najskuteczniejszą odpowiedzią jest ograniczenie długości nienadzorowanych łańcuchów decyzyjnych, wprowadzenie punktów kontrolnych danych wyjściowych, zanim wynik stanie się punktem wejścia kolejnego kroku. Sprawdza się też architektura z wbudowanym krytycyzmem: agenci weryfikujący z innym modelem bazowym, oceniający wyłącznie wynik bez dostępu do śladu rozumowania (reasoning trace) modelu realizującego zadanie - odpowiednik zasady „four-eyes principle”. Istotne jest zakotwiczenie agentów w weryfikowalnych źródłach danych: RAG znacząco redukuje halucynacje, ale sama baza wiedzy jest wektorem ataku.

Podejście AI Blueprint Trend Micro podkreśla konieczność zabezpieczenia danych na każdym etapie pipeline’u, włącznie z danymi zasilającymi RAG. Na poziomie całego łańcucha kluczowy jest monitoring spójności śladów rozumowania - detekcja skoków logicznych i eskalacji pewności bez dowodów. Niemniej ważna jest kultura organizacyjna: im bardziej „przetworzony” wynik AI, tym trudniej psychologicznie zakwestionować go jako zmyślony. Pełna eliminacja halucynacji nie jest dziś możliwa, ale połączenie tych strategii redukuje ryzyko do poziomu akceptowalnego. Może to ciężkie do zaakceptowania ale nie powinniśmy bezgranicznie ufać AI i weryfikować prawidłowość i wiarygodność wytworzonych elementów.

Jakie działania powinniśmy podjąć, aby minimalizować ryzyka związane ze sztuczną inteligencją, zarówno na płaszczyźnie technicznej i organizacyjnej? Jak powinniśmy rozumieć termin „AI governance”?

Skuteczna minimalizacja ryzyka wymaga działania na płaszczyźnie technicznej i organizacyjnej jednocześnie, a spoiwem jest AI governance. Na poziomie technicznym fundamentem jest dobrze już znana zasada minimalnego dostępu (least privilege) dla każdego agenta oraz wielowarstwowa walidacja: filtrowanie i inspekcja danych wejściowych, utwardzanie prompt’ów, walidacja wywołań narzędzi, inspekcja danych wyjściowych i monitoring behawioralny - siła tkwi w niezależności tych warstw. Krytyczne jest bezpieczeństwo łańcucha dostaw: analiza TrendAI ujawniła, że podatności w supply chain AI wykazują 46,5% wskaźnik krytyczności - najwyższy ze wszystkich kategorii.

Podkreślę jeszcze raz – na bazie naszych analiz rekomendowane jest podejście do ochrony pełnego stosu: infrastruktury, modeli, danych, API i użytkowników. Agent bez nadzoru to czarna skrzynka z uprawnieniami do krytycznych aplikacji w infrastrukturze.

Na poziomie organizacyjnym niezbędna jest jasna struktura odpowiedzialności (RACI dla każdego agenta jako warunek uruchomienia produkcyjnego), realistyczna polityka akceptowalnego użycia AI oraz ciągła edukacja - od SOC, przez developerów, po kadrę zarządzającą i zwykłych użytkowników.

AI governance łączy obie płaszczyzny w spójny system zasad, procesów i mechanizmów kontrolnych. W praktyce obejmuje rejestr wszystkich systemów AI z klasyfikacją ryzyka (większość organizacji nie potrafi dziś odpowiedzieć, ilu agentów działa w ich infrastrukturze), ocena wpływu AI (Impact Assessment) przed wdrożeniem, ciągły monitoring po wdrożeniu do środowiska produkcyjnego oraz przygotowanie na wymogi EU AI Act, NIST AI RMF i rekomendacji ENISA. Raport „From Anarchy to Authority” podkreśla, że zarządzanie musi przejść od dokumentów na półce do polityk egzekwowanych automatycznie w czasie rzeczywistym. W erze Agentic AI zdolność do odpowiedzialnego zarządzania AI przestaje być opcjonalna - staje się warunkiem operacyjnej dojrzałości.

Bezpieczne wdrażanie AI

Bezpieczeństwo aplikacji AI wymaga od nas szerokiego myślenia o zagrożeniach oraz działaniu infrastruktury. W opracowaniu „Security for AI Blueprint” autorstwa TrendAI wyróżniono sześć płaszczyzn ochrony, dzięki czemu wdrażanie rozwiązań AI staje się bezpieczniejsze.

Pierwszym krokiem jest zadbanie o zarządzanie stanem bezpieczeństwa danych (DSPM). Podejście to polega na przyłożeniu szczególnie dużej wagi do identyfikowania rodzajów informacji, kontroli dostępu oraz niwelowaniu wszelkich luk bezpieczeństwa. Podejście jest szczególnie ważne dla środowisk chmurowych i wielochmurowych.

DSPM opiera się na zastosowaniu poniższych pięciu kroków:

1. Poszukiwanie (skanowanie);
2. Klasyfikacja (w oparciu m.in. o regulacje, np. RODO);
3. Ocena ryzyka
4. Korekta ryzyka (zakładająca m.in. wdrożenie odpowiednich środków zapobiegawczych);
5. Ciągłe monitorowanie

Kolejnym aspektem jest bezpieczeństwo modeli AI. W tym celu rekomenduje się wykorzystanie konteryzacji, regularnych skanów podatności oraz segmentacji sieci. W ramach ochrony modeli nie możemy zapominać o logowaniu zdarzeń, co pozwala odpowiednio reagować na incydenty.

Powinniśmy również zwrócić uwagę na bezpieczeństwo infrastuktury, na której działa nasze rozwiązanie. W dużej mierze mowa o środowiskach chmurowych, gdzie kluczowymi działaniami będą:

• proaktywne zarządzanie ryzykiem (zamiast reaktywnego);
• identyfikowanie błędów w konfiguracjach;
• zarządzanie podatnościami.

Bezpieczeństwo aplikacji AI

Następnym zagadnieniem bezpieczeństwa aplikacji AI jest ochrona użytkowników oraz lokalnych aplikacji. Eksperci TrendAI podkreślają m.in. konieczność wykrywania deepfake’ów po stronie urządzeń użytkowników, np. podczas wideokonferencji.

Piątym aspektem bezpiecznego wdrażania AI jest ochrona przed nieuprawnionym dostępem - w tym zakresie kluczowe pozostaje podejście „zero trust”. Szóstym punktem jest ochrona przed tzw. „0-day’ami”, czyli dotychczas niezałatanymi podatnościami. Tutaj ważne jest monitorowanie i reagowanie na zagrożenia w czasie rzeczywistym.

Ekspert o wdrażaniu AI

Oskar Klimczuk, CyberDefence24: Z czym związane są główne trudności we wdrażaniu AI? Jak im przeciwdziałać?

Bartosz Kamiński, Strategic Account Manager, TrendAI: Wdrożenie AI w organizacji przypomina przygotowanie do maratonu - sama chęć startu nie pozawali ukończyć takich zawodów. Wymagana jest solidna strategia, odpowiednie zasoby, czas i plan działania, który wykracza daleko poza zakup gotowego narzędzia. Statystyki i badania z obszaru oceny skuteczności wdrażania technologii AI wydają się potwierdzać tę tezę i mogą budzić sporo dodatkowych pytań i wątpliwości. Zgodnie z raportem Deloitte AI Institute, ”State of AI in the Enterprise: The Untapped Edge”, który obejmuje odpowiedzi od 3235 liderów biznesowych z 24 krajów - „jedynie 25% organizacji przeniosło 40% lub więcej swoich projektów pilotażowych AI do środowiska produkcyjnego”. W raporcie McKinsey Global Survey, ”The State of AI in 2025: Agents, Innovation, and Transformation” uwagę zwraca fakt, że „tylko 39% organizacji przypisuje AI jakikolwiek wpływ na EBIT”, a 61% nie widzi żadnego.

Tak wysoki koszt i niski zwrot mogą mieć swoją przyczynę właśnie w braku konkretnej  strategii. Trzy bariery które najczęściej wracają w dialogu z Klientami i niezależnymi badaniami to:

1. Luka kompetencyjna (brak ekspertów zdolnych do skalowania rozwiązań od pilotażu do produkcji);
2. Nieodpowiednia infrastruktura/struktura danych – składają się na to takie problemy, jak: rozproszenie po różnych systemach ERP, CRM, pliki excel i systemy typu legacy. Jakość danych stanowi również wyzwanie ponieważ niespójne i błędne dane wpływają na jakość modeli i rezultatów pracy AI – w tym przypadku wpadamy w pułapkę GIGO (Garbage In Garbage Out);
3. Brak jasno zdefiniowanej odpowiedzialności za projekty o charakterze AI.

Przy tak dynamicznym rozwoju i zachodzących zmianach trudno stosować sprawdzone metody wdrażania projektów IT. Jednocześnie trzeba zaznaczyć, że odpowiedzią nie jest spowolnienie adopcji AI, lecz z całą pewnością zmiana podejścia.

Organizacje, które odnoszą trwałe sukcesy, opierają się na trzech filarach: bezpieczeństwie wbudowanym od pierwszego dnia realizacji projektu (a nie nakładanym retrospektywnie), jasnym zdefiniowaniu właściciela projektu AI i mierzalnego celu biznesowego oraz ciągła edukacja całej organizacji, a nie tylko zespołu IT. Jak wskazuje Deloitte w raporcie State of AI 2026, podnoszenie tzw. biegłości w AI całej firmy jest priorytetem numer jeden wśród organizacji, którym udaje się skutecznie wdrożyć AI. Technologia nie zawodzi, to kultura i gotowość organizacyjna mają największy wpływ na skuteczne wdrożenie AI.

Jak wykorzystanie AI przez cyberprzestępców przesunęło ciężar zagrożeń?

Jeszcze kilka lat temu przeprowadzenie zaawansowanego ataku cybernetycznego wymagało znacznych kompetencji technicznych, czasu i zasobów. Dziś, dzięki AI, ta bariera niemal całkowicie zniknęła. Mamy do czynienia z kolejnym etapem demokratyzacji cyberprzestępczości, a jej konsekwencje zaczynamy dopiero w pełni rozumieć jednak już solidnie odczuwać.

Jak wskazuje raport ”Trend Micro Security Predictions for 2026: The AI-fication of Cyberthreats”, cyberprzestępcy nie tylko przyspieszyli, ale zmienili również model operacyjny. Atak przestał być jednorazowym zdarzeniem, a stał się ciągłą, zautomatyzowaną operacją prowadzoną w tle.

Zmiana jest jakościowa, nie tylko ilościowa. AI umożliwia generowanie unikalnego malware’u, dostosowanego do architektury konkretnej ofiary (na podstawie fingerprintingu celu ataku), tworzenie kampanii phishingowych bez błędów językowych i pełnych kontekstu oraz autonomiczne podejmowanie decyzji o tym, które dane eksfiltrować i jaką cenę wyznaczyć jako okup. Duże modele językowe wykorzystywane są do analizowania skradzionych danych w poszukiwaniu wartościowych informacji. Następnie modele trenowane są na autentycznych, przechwyconych treściach komunikacyjnych, by tworzyć kampanie phishingowe brzmiące naturalnie i wiarygodnie, skrojone pod konkretną ofiarę. Równolegle rekonesans w opraciu o AI pozwala na automatyczne i precyzyjne mapowanie całej infrastruktury sieciowej organizacji.

Deepfake’i i syntetyczne media skutecznie kompromitują procesy oparte na tradycyjnej weryfikacji tożsamości. Operatorzy wykorzystują dziś AI do tworzenia syntetycznych tożsamości, zdolnych do infiltrowania organizacji od środka. Gdy już się w niej zadomowią, mogą po cichu modyfikować kod, wykradać dane lub sabotować systemy działając pod pozorem legalnej pracy.

Czy „klasyczny” sposób zabezpieczania się przed cyberatakami musi ulec zmianie?

Prawidłowa i krótka odpowiedź brzmi: zdecydowanie tak.

Dłuższa jest bardziej skomplikowana i tak jak w większości przypadków, zależy od wielu czynników. Jeśli za klasyczny model przyjemiemy „perimeter security” to ulegał on intensywnej transfomracji jako odpowiedź na zmieniający się krajobraz zagrożeń. Model działał, dopóki świat był oparty na prostych założeniach: pracownik siedział przy biurku w biurze, serwery stały w serwerowni w firmie, a aplikacje działały bezpośrednio w tej serwerowni chronione solidnym firewallem. Jednak szybki rozwój technoligii tj. chmura, eksplozja urządzeń mobilnych, aplikacje SaaS i praca zdalna spowodowały całkowite rozproszenie infrastruktury i przesunięcie granic. AI przyspieszyło ten rozpad/taką zmianę do granic możliwości. Polimorficzny malware generowany przez AI zmienia swój kod w czasie rzeczywistym, omijając sygnatury. Reaktywne modele bezpieczeństwa oparte na założeniu - reaguj, gdy atak już nastąpił, nie nadążają za tempem, w jakim dziś operują nasi przeciwnicy.

Jak wskazuje Eva Chen, współzałożycielka i CEO Trend Micro:

Dziś cyberprzestępcy są nieustępliwi - wykorzystują AI, rozszerzają powierzchnie ataku i działają szybciej niż kiedykolwiek. Reaktywne bezpieczeństwo już nie wystarcza. W TrendAI prowadzimy działania, aby postawić na proaktywne zabezpieczenia i dać liderom bezpieczeństwa narzędzia do pozostania o krok przed zagrożeniami.
Eva Chen, współzałożcielka i CEO Trend Micro

Konieczne jest przejście od reaktywności do proaktywności. Oznacza to ciągłą widoczność całej powierzchni ataku w czasie rzeczywistym wszystkich zasobów znanych i nieznanych, zarządzanych i niezarządzanych, wewnętrznych i zewnętrznych. Ocena ryzyka musi być kontekstowa i uwzględniać krytyczność zasobów w tym również AI, aktywność zagrożeń oraz ich potencjalny wpływ finansowy.

Czy podejścia oparte na SAST i DAST wciąż mają uzasadnienie?

Tak, choć wydarzenia ostatnich tygodni zmuszają do refleksji, że to już nie jest właściwe pytanie. Po tym, co zostało upublicznione w kontekście Claude Mythos możnaby zadać pytanie: czy organizacje są w stanie obsłużyć remediację w tempie, w jakim AI odkrywa podatności?

SAST analizuje kod źródłowy zanim jeszcze zostanie uruchomiony. Ma możliwość identyfikacji błędów logiki, niebezpieczonych wzorców i znanych podatności na etapie, gdy ich naprawa jest najtańsza. Dla odmiany DAST testuje aplikację w trakcie jej działania, symulując zewnętrzny atak, jednocześnie weryfikując to, czego SAST z definicji nie widzi: zachowania runtime, błędów autentykacji czy podatności wstrzykiwanych przez interfejs. Żadne z nich stosowane osobno nie wystarczy. SAST generuje fałszywe alarmy, które wysycają uwagę deweloperów. DAST testuje symptomy, nie przyczyny. Nowoczesna architektura AppSec łączy je z IAST (który działa w runtime, łącząc oba podejścia), SCA do analizy komponentów open-source i RASP jako ostatnią linię obrony na produkcji – wszystko osadzone w pipeline CI/CD, jak najbliżej dewelopera. Statystyki są nieubłagane: usunięcie podatności po wdrożeniu na produkcję kosztuje nawet dziesięciokrotnie więcej niż na etapie pisania kodu.

Jednak obie metody testowania mają głębsze ograniczenie które od dawna sygnalizuje program Zero Day Initiative TrendAI, największy na świecie niezależny program bug bounty. ZDI nazywa to problemem wąskiego łatania (narrow patching): dostawcy zamykają konkretne CVE zgłoszone przez badaczy, ale nie usuwają pierwotnej przyczyny podatności. Podatność istnieje w kodzie dalej tylko pod inną postacią, jako jej wariant. Skaner statyczny tego wariantu nie zobaczy, bo nie ma dla niego sygnatury. Dlatego ZDI praktykuje variant hunting: gdy badacz znajdzie podatność, aktywnie przeszukuje całą bazę kodu w poszukiwaniu podobieństw.

W czasach „umiejętności” zaprezentowanych przez Claude Mythos musimy liczyć się z odkrywaniem tysiący nieznanych podatności zero-day we wszystkich głównych systemach operacyjnych i przeglądarkach internetowych. AI potrafi odkrywać podatności w tempie i skali poza zasięgiem człowieka: 27-letni bug w OpenBSD. 16-letni w FFmpeg czy 22 podatności Firefox w dwa tygodnie, w tym 14 zakwalifikowanych przez Mozillę jako istotne. Żaden skaner statyczny tych luk nie widział przez dekady, bo nie dysponował sygnaturami. Dotychczas rocznie odkrywano około 50 tysięcy CVE. Przy powszechnym dostępie do modeli tej klasy szacunki mówią o ponad 600 tysiącach podatności rocznie.

I tu wraca pytanie postawione na początku. SAST i DAST zbudowane są pod rytm ludzkiego odkrywania podatności: znajdź, zaraportuj, połataj, zweryfikuj. Ten rytm był trudny do utrzymania, a teraz to nie detekcja tylko remediacja stałe się wąskim gardłem.

Na jakim etapie wdrażania AI powinniśmy położyć największy nacisk na cyberbezpieczeństwo?

Na każdym i im wcześniej, tym lepiej. Zasada shift-left, znana od lat w DevSecOps, w erze AI nabiera nowego wymiaru. Możemy sobie wyobraźić system AI jak nowego pracownika w naszej organizacji. Nie czekamy z weryfikacją jego uprawnień i dostępów do momentu, gdy zaczynają się szkody, tylko weryfikujemy go zanim dotrze do pierwszego dnia pracy. Podobnie powinniśmy traktować systemy AI: bezpieczeństwo musi być wbudowane w cały cykl życia, nie nakładane post-factum.

Nowy termin AISecOps opisuje właśnie to podejście: bezpieczeństwo wbudowane w cały SDLC specyficznie dla systemów AI. To staje się kluczowe, gdy agentowe systemy AI zaczynają samodzielnie wykonywać akcje w imieniu pracownika, organizacji, często z dostępem do wrażliwych danych i systemów produkcyjnych.

Na czym polega „vibe crime” w oparciu o agentów AI?

Termin „vibe crime” brzmi jak slang z mediów społecznościowych i w pewnym sensie nim jest. Wszystko zaczęło się od niepozornego tweeta Andreja Karpathy, gdy współzałożyciel OpenAI który opisał nowy sposób programowania jako „vibe coding”, gdzie programista w pełni oddaje się AI, akceptując wszystko bez czytania kodu i „zapomina, że kod w ogóle istnieje.”

W ciągu roku prefiks „vibe” stał się kulturowym skrótem dla całej epoki: działania przez AI, bez rozumienia mechanizmów, z naciskiem na rezultat zamiast procesu. Vibe marketing, vibe prospecting, vibe valuation, vibe reporting. Każdy sektor znalazł swoją wersję i nieuchronnie znalazła ją również cyberprzestępczość.

TrendAI jako pierwszy nazwał to wprost jako „vibe crime”. Termin wprowadzony przez Roberta McArdle’a - dyrektora Forward-Looking Threat Research w TrendAI. To opis rzeczywistości i działania, w którym cyberprzestępca działa dokładnie tak jak niedoświadczony deweloper: wydaje polecenie AI, nie rozumie w pełni co tworzy, ale efekt w postaci działających exploitów, kampanii phishingowych czy autonomicznych operacji wymuszeń jest jak najbardziej realny.

Vibe crime to pełna autonomizacja operacji przestępczych przy wykorzystaniu łańcuchów agentów AI. Przestępca definiuje cel, a AI wykonuje poszczególne fazy ataku: rekonesans, włamanie, eksfiltrację danych, a w ostatecznej fazie negocjacje związane z żądaniem okupu.

Model ewoluuje od „Cybercrime as a Service” do „Cybercrime as a Servant” w którym cyberprzestępca wydaje polecenie, a autonomiczny system realizuje całą operację. Skala, prędkość i równoległość operacji stają się nieporównywalne z tym, co znaliśmy do tej pory. Dlatego tak ważne jest, aby zadbać o symetryczną odpowiedź. Jeśli ataki operują z prędkością maszyn to mechanizmy obronne muszą działać równie szybko. Oznacza to ciągłą, zautomatyzowaną widoczność całej powierzchni ataku w czasie rzeczywistym, priorytetyzację ryzyka zamiast ręcznej analizy alertów oraz autonomiczne systemy wykrywania i odpowiedzi, które nie czekają na ludzką decyzję.

Operator SOC’a przesuwa się do roli projektanta i nadzorcy. Paradoksalnie, to ta sama zmiana, którą vibe crime wprowadza po stronie atakujących: przestępca przestaje być technikiem, staje się zleceniodawcą.

Podsumowanie

Wdrażanie AI niewątpliwie wiąże się z koniecznością analizy ryzyka, rozumianej jako procesu, który ciągle ewoluuje. Eksperci TrendAI jasno wskazują, że konieczne jest zmienienie podejścia nie tylko do reagowania na zagrożenia, ale uprzedniego zabezpieczania infrastruktury.

Agent AI nie pozostaje odrębnym bytem, lecz jest integralną częścią naszego środowiska informatycznego. Wymaga to wielopłaszczyznowego podejścia do cyberbezpieczeństwa.

Artykuł sponsorowany