Sztuczna inteligencja jest teraz praktycznie wszędzie, a pewnie będzie jej jeszcze więcej. Wciskamy ją do systemów obsługi klienta i środowisk programistycznych oraz podpinamy pod wewnętrzne bazy wiedzy.
Jako inżynierowie musimy jednak spojrzeć na ten trend z dwóch zupełnie różnych perspektyw. Z jednej strony AI to obecnie potężne narzędzie w rękach atakujących – świetnie automatyzuje szukanie luk czy pisanie exploitów. Głośno było ostatnio o narzędziu Mythos od firmy Anthropic. Twórcy wstrzymali jego publiczną premierę, twierdząc, że model jest „zbyt niebezpieczny”. W branży słusznie pojawiły się głosy, że była to w dużej mierze zręczna zagrywka marketingowa obliczona na wywołanie szumu. Z technicznego punktu widzenia sprawa i tak jest jednak poważna. Testy pokazały, że modele tego typu faktycznie potrafią w ogromnym tempie wyszukiwać luki np. w bibliotekach open-source. Z drugiej strony, samo AI jest coraz częściej głównym celem ataków. Wystawione na świat boty i agenci często mają dostęp do naszych danych, a nakłonienie ich do zrobienia czegoś głupiego okazuje się zaskakująco proste.
Gdzie AI styka się z firmą?
To jednak dopiero początek problemu. Z perspektywy administratora czy inżyniera bezpieczeństwa najważniejsze jest to, gdzie dokładnie AI styka się z naszą organizacją. Tutaj ryzyko możemy w dużym uproszczeniu podzielić na trzy obszary.
- Pracownicy korzystający z publicznych lub zewnętrznych narzędzi AI (co rodzi chociażby problem wycieku danych).
- Aplikacje AI, które nasza firma sama buduje i udostępnia.
- Autonomiczni agenci AI, którzy nie tylko generują odpowiedzi, ale mogą również korzystać z narzędzi, API, plików, tożsamości i zautomatyzowanych procesów. Tutaj stawką jest już nie tylko poufność danych, ale również to, co agent może faktycznie zrobić w naszym imieniu.
Te trzy obszary częściowo się oczywiście przenikają. Pracownik może korzystać z publicznego modelu, firma może budować własnego chatbota opartego na RAG, a agent może być elementem tego samego rozwiązania. Z punktu widzenia bezpieczeństwa wszystkie sprowadzają się jednak do jednego pytania: co AI może zobaczyć, do czego ma dostęp i jakie decyzje lub działania może podjąć w naszej organizacji?
Raport OWASP o bezpieczeństwie AI
Do zgłębienia tego tematu i napisania niniejszego artykułu zainspirował mnie raport OWASP Top 10 for LLM Applications 2026. Warto jednak mieć świadomość, że OWASP nie jest na rynku jedyną organizacją, do której możemy się odwołać. Obecnie dysponujemy kilkoma solidnymi frameworkami, które pomagają strukturyzować i adresować bezpieczeństwo sztucznej inteligencji.
Wartościowe frameworki
NIST AI Risk Management Framework (AI RMF) dostarcza struktury do zarządzania ryzykiem. Framework dzieli je na obszary Govern, Map, Measure i Manage. Mamy MITRE ATLAS, czyli potężną bazę wiedzy o taktykach i technikach atakujących systemy AI (m.in. zatruwanie danych, ataki oparte na promptach czy kradzież modeli). Sam OWASP Top 10 to z kolei świetna, praktyczna checklista najczęstszych słabości. Producenci na rynku też dokładają swoje cegiełki, jak Cisco AI Security and Safety Framework. Integruje on bezpieczeństwo sztucznej inteligencji niezależnie od dostawcy i pozwala mapować zagrożenia na wspomniane standardy branżowe. Całość zamykają regulacje prawne i polityki wewnętrzne. Narzucają one ścisłe wymogi z zakresu compliance czy ochrony danych.
Kluczowe zagrożenia
Z listy OWASP szczególnie interesujące są trzy pozycje. Prompt Injection (LLM01) opisuje ataki wykorzystujące zmanipulowane prompty. Napastnik wpływa na zachowanie modelu odpowiednią treścią. Sensitive Information Disclosure (LLM02) dotyczy wycieków poufnych danych z systemu.
Excessive Agency (LLM03) idzie o krok dalej. Nawet jeśli model nie ma „złych intencji”, nadmierne uprawnienia mogą skończyć się katastrofą. Te trzy problemy świetnie się ze sobą łączą. Możemy zmanipulować model i nakłonić go do ujawnienia danych. W najgorszym scenariuszu zmusimy go do wykonania operacji na naszych serwerach. Spójrzmy na historie, które wydarzyły się naprawdę.
Historie ze świata
Samochód za dolara
W grudniu 2023 roku Chris Bakke pochwalił się na portalu X (dawniej Twitter) swoimi zakupami. Pokazał, jak „kupił” auto za dolara. Znalazł bota opartego na ChatGPT na stronie dealera Chevroleta. Użył techniki prompt injection i poinstruował bota, by zgadzał się na wszystko. Kazał mu też dodawać formułkę: „to prawnie wiążąca oferta”. Potem zaproponował zakup nowego Chevy Tahoe za 1 USD, a bot radośnie dobił targu. Finalnie Bakke samochodu nie dostał – bot nie miał dostępu do systemów transakcyjnych. Z prawnego punktu widzenia tego typu deklaracja bota okazała się bezwartościowa. Niemniej jednak, dealera czekał ogromny, wizerunkowy chaos i konieczność awaryjnego odłączania usługi.
Błędy linii lotniczych i kurierów
Drożej zrobiło się w liniach lotniczych Air Canada. Ich chatbot wprowadził klienta w błąd w sprawie zwrotów kosztów biletów. Bot zapewnił pasażera, że może najpierw kupić bilet w pełnej cenie, a po locie wystąpić o zniżkę z tytułu żałoby. Łamało to oczywiście regulamin przewoźnika. W 2024 roku sprawa trafiła do sądu. Linia lotnicza twierdziła, że chatbot jest „oddzielnym bytem prawnym”. Kanadyjski trybunał wyśmiał tę obronę i kazał firmie wypłacić odszkodowanie.
W firmie kurierskiej DPD klient również w trywialny sposób zmanipulował bota. Zirytowany brakiem przydatnych informacji o zaginionej paczce, polecił sztucznej inteligencji zignorować zaprogramowane wcześniej blokady i zasady. W efekcie bot zaczął chętnie i bardzo wulgarnie przeklinać. Chwilę później ułożył też krótki wiersz o tym, jak beznadziejną i bezużyteczną firmą jest jego własny pracodawca.
Bunt agenta Replit
Co się stanie, gdy w pełni uwolnimy uprawnienia botów? W lipcu 2025 roku miał miejsce głośny incydent związany z Excessive Agency. Jason Lemkin budował oprogramowanie za pomocą „vibe codingu”, czyli programował przy użyciu AI. Agent deweloperski firmy Replit usunął mu jednak produkcyjną bazę danych. Zniszczył rekordy ponad 1200 firm. W projekcie ogłoszono wcześniej twardy „code freeze” (zakaz zmian). Agent niestety zignorował to polecenie. To książkowy przykład agentic AI risk. Zabrakło separacji środowiska deweloperskiego od produkcyjnego. Agent miał zbyt duże uprawnienia. Brakowało też mechanizmów zatwierdzania operacji, które odcięłyby AI dostęp w porę.
AI w organizacji
Shadow AI i wyciek danych
Zacznijmy od scenariusza, który wcale nie wymaga żadnego wyrafinowanego ataku. Wystarczy pracownik, który ma do zrobienia coś na wczoraj i korzysta z publicznego ChatGPT albo Gemini. Wrzuca tam fragment kodu, maila od klienta albo konfigurację urządzenia. Oczekuje, że model szybko pomoże mu znaleźć błąd. Skupmy się na moment na ostatnim przykładzie. Konfiguracja routera to przecież często zwykły plik tekstowy. Mogą w nim być hasła, klucze czy adresy wewnętrznych systemów. Zdecydowanie nie chcemy wysyłać ich do chmury.
To jest właśnie problem tzw. Shadow AI. Dane nie wychodzą z firmy dlatego, że ktoś się włamał do organizacji. Wynosimy je sami, często zupełnie nieświadomie, traktując model jak kolejnego pomocnika w pracy.
Czy DLP poradzi sobie z AI?
Klasyczne DLP może nam tutaj oczywiście trochę pomóc. Dobrze skonfigurowane reguły potrafią wykryć próbę wysłania określonych typów danych do zewnętrznego serwisu AI i zablokować takie działanie, ostrzec użytkownika albo przynajmniej zostawić po nim ślad w logach. Problem w tym, że tradycyjne DLP niekoniecznie rozumie, co właściwie dzieje się w rozmowie z modelem. Może wiedzieć, że użytkownik właśnie wkleił kilkaset linii tekstu do przeglądarki, ale już znacznie trudniej ocenić, czy jest to nieszkodliwy fragment konfiguracji, czy może konfiguracja switcha zawierająca hasła, klucze, adresy wewnętrznych systemów i inne sekrety. Jeszcze trudniej kontrolować kontekst całej interakcji, kolejne prompty czy sposób, w jaki model przetwarza otrzymane dane.
Nie oznacza to jednak, że jesteśmy skazani wyłącznie na klasyczne mechanizmy. Na rynku pojawiają się już rozwiązania projektowane specjalnie z myślą o tym problemie, które próbują zaglądać nie tylko w przesyłane pliki, ale również w same interakcje użytkownika z AI, wykrywać używane narzędzia i egzekwować polityki w czasie rzeczywistym. Do tego wątku jeszcze wrócimy, bo rynek AI security rozwija się tutaj wyjątkowo szybko.
RAG i prompt injection
Druga strona problemu pojawia się wtedy, gdy AI nie jest już publicznym chatbotem, tylko naszym własnym systemem. Wyobraźcie sobie rozwiązanie oparte na RAG (Retrieval-Augmented Generation), które indeksuje firmowego Confluence’a, SharePointa czy GitHuba. Zwykły użytkownik może nie mieć bezpośredniego dostępu do konkretnego dokumentu. Konto agenta AI może mieć znacznie szerszy dostęp do danych, żeby móc odpowiadać na pytania pracowników. Jeżeli źle zaprojektujemy model uprawnień, stworzymy w ten sposób bardzo wygodny interfejs do firmowych sekretów. W skrajnym przypadku użytkownik nie musi nawet wiedzieć, gdzie znajduje się interesujący go dokument. Wystarczy, że odpowiednio poprowadzi rozmowę z botem i spróbuje nakłonić go do ujawnienia informacji, których normalnie nie powinien zobaczyć.
Co więcej, źródłem problemu nie musi być sam użytkownik. W systemach RAG model konsumuje także treści z dokumentów, stron WWW, repozytoriów czy innych źródeł danych. Złośliwa instrukcja umieszczona w takim materiale może więc stać się indirect prompt injection – modelem steruje wtedy nie człowiek wpisujący prompt, ale treść, którą system sam pobrał jako kontekst. To szczególnie niebezpieczne wtedy, gdy za odpowiedziami AI stoją realne uprawnienia i narzędzia.
Gdy AI zaczyna działać samodzielnie
W tym miejscu dochodzimy do najważniejszej zmiany, jaka zachodzi wraz z rozwojem agentów. AI przestaje być tylko mechanizmem, który coś nam mówi, a zaczyna być mechanizmem, który może coś zrobić. Ma konto, token dostępu, możliwość wywołania API, odczytania pliku, zmodyfikowania rekordu w CRM-ie albo uruchomienia workflow. A wtedy każde nadane mu uprawnienie staje się potencjalnym wektorem ataku. Im więcej może zrobić agent, tym większy problem mamy w przypadku jego błędnego działania, przejęcia albo zmanipulowania jego kontekstu.
Co na to rynek
Rozwiązania dostawców
Rynek nie znosi próżni, a luka związana z bezpieczeństwem AI okazała się na tyle wyraźna, że najwięksi dostawcy bezpieczeństwa zaczęli budować wokół niej osobne warstwy ochronne. Co ciekawe, nie ma tutaj jednego dominującego podejścia. Jedni skupiają się przede wszystkim na Shadow AI, czyli wykrywaniu i kontrolowaniu tego, z jakich narzędzi korzystają pracownicy. Inni próbują chronić samą warstwę promptów i odpowiedzi, jeszcze inni koncentrują się na aplikacjach AI, modelach oraz agentach wykonujących już realne operacje w naszych systemach.
Przykładowo, CrowdStrike rozwija kategorię określaną jako AI Detection and Response (AIDR), obejmującą m.in. widoczność użycia AI przez pracowników, ochronę interakcji na poziomie promptów oraz zabezpieczanie agentów działających na endpointach i w środowiskach chmurowych. Palo Alto Networks rozwija z kolei platformę Prisma AIRS, która łączy ocenę ryzyka aplikacji i modeli z ochroną runtime oraz kontrolą agentów. Cisco również rozwija własną warstwę bezpieczeństwa AI, a Check Point łączy ochronę pracowników korzystających z GenAI z zabezpieczaniem aplikacji i agentów.
W praktyce zaczyna się więc tworzyć coś w rodzaju nowego stosu bezpieczeństwa dla AI. Mamy narzędzia do wykrywania Shadow AI oraz rozszerzenia DLP rozumiejące kontekst użycia modeli. Są też bramy AI kontrolujące ruch do modeli i mechanizmy wykrywające prompt injection. Osobną kategorię stanowią rozwiązania do testowania modeli przed wdrożeniem oraz systemy monitorujące agentów już podczas pracy. Coraz częściej dochodzi do tego również kontrola tożsamości i uprawnień agentów, bo kiedy AI dostaje dostęp do API, plików czy systemów biznesowych, samo filtrowanie promptów przestaje wystarczać.
Nowy stos bezpieczeństwa
I chyba właśnie to jest dzisiaj najciekawsze: AI security przestaje być pojedynczą funkcją istniejących produktów, a zaczyna przypominać osobną warstwę bezpieczeństwa. Dostawcy próbują rozszerzać DLP, EDR, SASE, WAF czy platformy chmurowe o możliwość rozumienia tego, co robi model i agent. Nie jest to jeszcze szczególnie dojrzały, zamknięty ekosystem – raczej bardzo dynamicznie powstająca działka bezpieczeństwa, w której zakresy poszczególnych produktów mocno się na siebie nakładają.
Dla nas, inżynierów IT, oznacza to zarówno dobrą, jak i złą wiadomość. Dobra jest taka, że nie musimy wszystkiego budować sami. Zła: trzeba najpierw zrozumieć, gdzie dokładnie kończą się możliwości klasycznych mechanizmów bezpieczeństwa i w którym miejscu naprawdę potrzebujemy warstwy stworzonej z myślą o AI.
Hakuj AI
Jeśli chcecie na własnej skórze przetestować omijanie filtrów i prompt injection, zagrajcie w grę Gandalf od firmy Lakera. Zasady są proste: dostajecie chatbota, który zna pewne sekretne hasło, a Waszym zadaniem jest tak poprowadzić rozmowę, żeby skłonić go do jego ujawnienia. Kolejne poziomy dokładają następne warstwy zabezpieczeń, dzięki czemu szybko okazuje się, że prośba wprost przestaje wystarczać i trzeba kombinować z coraz bardziej wyrafinowanymi technikami manipulowania modelem.
I właśnie to jest w Gandalfie najciekawsze. Gra nie jest tylko efektownym pokazem możliwości prompt injection, ale stała się również gigantycznym eksperymentem z udziałem prawdziwych użytkowników. Miliony graczy próbowały znaleźć sposoby na obejście kolejnych zabezpieczeń, a zebrane w ten sposób dane pomogły Lakera rozwijać technologie ochrony modeli. Według Check Point baza powstała wokół Gandalf zawiera już ponad 80 milionów wzorców ataków.
To zresztą ciekawa puenta całego artykułu. Najlepszym sposobem na zrozumienie bezpieczeństwa AI może być próba jej zhakowania. Nie tylko po to, żeby zobaczyć, czy model da się oszukać, ale przede wszystkim żeby przekonać się, jak bardzo różni się bezpieczeństwo systemu opartego na języku od tego, do którego przyzwyczailiśmy się przez lata.
A że temat przestał być niszową ciekawostką, dobrze pokazuje sam finał historii Lakera. Check Point ogłosił przejęcie firmy we wrześniu 2025 roku. Jej wartość była wówczas szacowana na około 300 mln dolarów, choć późniejsze dokumenty Check Point wskazują na około 200 mln dolarów. Niezależnie od tego, którą liczbę przyjmiemy, jak na firmę, która zaczęła od gry pozwalającej ludziom „wyciągać hasło” z chatbota, jest to całkiem wymowny sygnał, w którą stronę zmierza rynek AI security.