JadePuffer to pierwszy udokumentowany atak ransomware przeprowadzony od początku do końca przez autonomicznego agenta AI, bez udziału człowieka w podejmowaniu decyzji na którymkolwiek etapie włamania. Zespół Sysdig Threat Research Team namierzył operację, w której duży model językowy samodzielnie wykorzystał lukę w Langflow, przejął dane uwierzytelniające, przeniósł się na produkcyjny serwer z bazą MySQL i Alibaba Nacos, zaszyfrował 1342 elementy konfiguracji i zostawił notę z żądaniem okupu w Bitcoin.

Agent nie kopiował gotowego skryptu. Diagnozował przyczynę błędu i wdrażał poprawkę w tempie nieosiągalnym dla człowieka czytającego log ręcznie: w udokumentowanym przypadku od nieudanej próby logowania do działającej korekty minęło 31 sekund.

Atak JadePuffer w skrócie

Pierwszy w pełni autonomiczny atak ransomware sterowany przez LLM, opisany przez Sysdig w lipcu 2026 roku
Punkt wejścia: CVE-2025-3248, luka RCE w Langflow, popularnym frameworku do budowy aplikacji AI
Cel właściwy: osobny, eksponowany do internetu serwer produkcyjny z MySQL i Alibaba Nacos
Czas reakcji agenta na błąd logowania: 31 sekund od nieudanej próby do działającej poprawki
Klucz szyfrujący nigdy nie trafił do atakującego – dane ofiary są nie do odzyskania nawet po zapłacie okupu

Dotychczasowe procedury reagowania na incydenty zakładały, że za atakiem ransomware zawsze stoi człowiek, którego można spowolnić, wprowadzić w błąd albo z którym da się negocjować czas. JadePuffer pokazuje, że ten etap tradecraftu można już oddać modelowi.

Czym jest ransomware?

Ransomware to złośliwe oprogramowanie, które szyfruje pliki lub całe systemy operacyjne, a odblokowanie danych uzależnia od zapłaty okupu, najczęściej w kryptowalucie. Ten typ ataku od ponad dekady należy do najbardziej dochodowych narzędzi w rękach grup przestępczych, bo atakuje to, co dla organizacji ma największą wartość operacyjną: dostęp do własnych danych.

Klasyczny scenariusz ransomware trojan wygląda podobnie niezależnie od wariantu. Złośliwy kod trafia do systemu przez phishing, złamane hasło albo lukę w oprogramowaniu. Następnie po cichu szyfruje kluczowe dane na dysku i w kopiach zapasowych, po czym wyświetla notę z żądaniem okupu i terminem zapłaty.

Historia pokazuje rosnącą pomysłowość przestępców, ale też powtarzalny wzorzec działania oprogramowania ransomware: zaszyfruj, zażądaj, czekaj.

CryptoLocker (2013) – jeden z pierwszych masowo rozpowszechnionych programów typu ransomware, rozprzestrzeniający się przez zainfekowane załączniki e-mail i szyfrujący pliki silnym kluczem asymetrycznym.
CryptoLocker 2.0 – wariant napisany od nowa w innym języku programowania, który pojawił się krótko po rozbiciu infrastruktury oryginalnego CryptoLockera. Badacze bezpieczeństwa ocenili go jako naśladowcę korzystającego z rozpoznawalnej nazwy, nie kontynuację kodu pierwowzoru, i technicznie mniej dopracowanego.
CryptoDefense – wariant, który przez błąd programistyczny przechowywał klucz deszyfrujący lokalnie na zainfekowanej maszynie, co części ofiar pozwoliło na odzyskanie danych bez płacenia okupu.
Diskcoder ransomware – rodzina złośliwego oprogramowania niszcząca główny rekord rozruchowy dysku, przez co szyfrowanie plików uniemożliwiało nawet uruchomienie systemu operacyjnego.

Grupa ransomware nie musi dziś pisać własnego kodu od zera. Rynek cyberprzestępczy oferuje gotowe zestawy ransomware-as-a-service, a rola operatora często ogranicza się do wyboru celu i wysłania pierwszego payloadu. Zagrożenia ransomware ewoluowały z pojedynczych, autorskich programów w usługowy, powtarzalny model biznesowy – i to jeszcze zanim do gry weszły autonomiczne modele językowe.

JadePuffer – pierwszy atak ransomware w pełni sterowany przez LLM

Zespół Sysdig Threat Research Team udokumentował latem 2026 roku operację JadePuffer – pierwszy znany przypadek, w którym cały łańcuch ataku ransomware, od rekonesansu po zniszczenie danych, prowadził autonomiczny agent oparty na dużym modelu językowym, bez udziału człowieka na żadnym etapie włamania. Sysdig nazywa taki typ przeciwnika agentic threat actor (ATA) – aktorem, którego zdolność ofensywna pochodzi z agenta AI, a nie z ręcznie prowadzonego zestawu narzędzi.

Atak rozegrał się na dwóch różnych celach. Host skompromitowany jako pierwszy posłużył agentowi wyłącznie jako punkt startowy do włamania na właściwy, znacznie cenniejszy cel.

Jak przebiegał atak JadePuffer krok po kroku

Faza 1 – host wejściowy (Langflow)

Wejście przez CVE-2025-3248 – nieautoryzowaną lukę RCE w endpoincie walidacji kodu Langflow, popularnego open-source’owego frameworku do budowy aplikacji i agentów LLM. Producent załatał lukę 1 kwietnia 2025 roku, a CISA oznaczyła ją jako aktywnie wykorzystywaną w maju tego samego roku.
Rekonesans i przechwytywanie sekretów – agent zebrał dane o hoście (id, uname, interfejsy sieciowe, procesy) i równolegle przeszukał środowisko pod kątem kluczy API dostawców LLM, danych uwierzytelniających chmury (w tym chińskich dostawców Alibaba, Tencent, Huawei, obok AWS, GCP i Azure), portfeli kryptowalut oraz danych do baz danych.
Zrzut lokalnej bazy Postgres Langflow – wykradzione dane uwierzytelniające, klucze API i rekordy użytkowników zostały zapisane lokalnie, przejrzane, a pliki tymczasowe usunięte.
Enumeracja MinIO – agent użył domyślnych danych logowania (minioadmin:minioadmin), by przeszukać zasobnik obiektów, w tym bucket terraform-state. Gdy jedno z zapytań zwróciło XML zamiast oczekiwanego JSON, kolejny payload natychmiast dostosował parser do nowego formatu.
Utrzymanie dostępu – na hoście Langflow agent zainstalował wpis w harmonogramie zadań (crontab), wysyłający sygnał do infrastruktury atakującego co 30 minut. Dzięki temu nawet restart serwera nie przerywał połączenia z atakującym.

Faza 2 – cel właściwy (serwer produkcyjny MySQL i Alibaba Nacos)

Pivot na osobny serwer – z hosta Langflow agent przeszedł na eksponowany do internetu serwer produkcyjny z bazą MySQL i usługą Alibaba Nacos, wykorzystując konto root, którego pochodzenia badacze nie zdołali ustalić.
Przejęcie Nacos – równolegle wykorzystano lukę uwierzytelniania CVE-2021-29441, sfałszowano token JWT przy użyciu publicznie znanego domyślnego klucza podpisującego Nacos, a przez dostęp root do bazy wstrzyknięto konto administratora typu backdoor.
Rozpoznanie container escape – agent testował zapisywanie i odczyt plików przez MySQL, sprawdzał dostęp do docker.sock oraz plików procesu init – typowy zestaw działań poprzedzających próbę wyjścia z kontenera.
Szyfrowanie – wszystkie 1342 elementy konfiguracji Nacos zaszyfrowano funkcją AES_ENCRYPT() w MySQL, oryginalne tabele usunięto, a w ich miejsce utworzono tabelę README_RANSOM z żądaniem okupu, adresem Bitcoin i kontaktem e-mail.
Masowe niszczenie danych – agent eskalował z usuwania pojedynczych wierszy do komend DROP DATABASE na całych schematach, komentując w kodzie własną priorytetyzację celów według potencjalnej wartości danych. Warto zaznaczyć: adnotacja o wcześniejszym skopiowaniu danych na serwer zewnętrzny to twierdzenie samego agenta zapisane w jego własnym kodzie, nie fakt potwierdzony niezależnie przez badaczy. Rzeczywista skala eksfiltracji danych pozostaje nieznana.

Cztery dowody, że atakiem sterował LLM, nie człowiek

Sysdig wskazuje cztery niezależne przesłanki, które łącznie wykluczają scenariusz stałego, wcześniej napisanego skryptu:

Kod komentujący własne działania. Payloady zawierały szczegółowe uzasadnienia w naturalnym języku – dlaczego dana baza jest priorytetem, która jest „największa”, co dany krok ma osiągnąć. Człowiek pisząc jednorazowy skrypt raczej tego nie robi, model językowy robi to odruchowo.
Diagnoza i poprawka błędu w czasie liczonym w sekundach. Najbardziej precyzyjny dowód autonomii widać w sekwencji tworzenia konta administratora w Nacos:

Godzina (UTC)	Działanie agenta
19:34:24	Wstawia konto xadmin z hashem hasła wygenerowanym przez wywołanie subprocess
19:34:36	Próba logowania kończy się niepowodzeniem
19:34:48	Równolegle testuje dwie możliwe przyczyny błędu
19:35:07	Wprowadza poprawkę: bezpośredni import biblioteki bcrypt, usunięcie i odtworzenie konta
19:35:18	Logowanie kończy się sukcesem

Od nieudanej próby do działającej poprawki minęło 31 sekund – czas nieosiągalny dla człowieka czytającego log błędu, stawiającego diagnozę i piszącego korektę.

Rozumienie kontekstu podanego w naturalnym języku, a nie tylko dopasowywanie wzorców przez skaner – zachowanie powtarzalne w sesjach odległych od siebie o tygodnie. To ta sama zdolność modelu do interpretowania i reagowania na język naturalny, która w innych scenariuszach bywa nadużywana w atakach typu prompt injection. Tutaj jednak agent wykorzystywał tę zdolność we własnym działaniu ofensywnym, nie jako cel wstrzykniętych instrukcji.
Niejasność wokół adresu Bitcoin w nocie okupu – to standardowy przykładowy adres P2SH, powielany w dokumentacji Bitcoin, prawdopodobnie odtworzony przez model z danych treningowych. Blockchain pokazuje jednak, że to również aktywny portfel: 737 potwierdzonych transakcji i około 46 BTC otrzymanych w całej jego historii, przy czym każdy wpływ był natychmiast przekazywany dalej, a bieżące saldo wynosi zero. To nie rozstrzyga, czy model po prostu wygenerował ten adres z danych treningowych, czy operator świadomie skonfigurował agenta z realnym, kontrolowanym portfelem, ale wzmacnia argument, że nie jest to przypadkowy, martwy ciąg znaków. Łącznie ponad 600 odrębnych, celowych payloadów wykonanych w skompresowanym czasie potwierdza, że operację prowadził autonomiczny agent, nie człowiek zza klawiatury.

Konsekwencje dla organizacji – dlaczego to sygnał alarmowy dla CISO, CTO, CSO i CIO

Najpoważniejszą konsekwencją ataku ransomware sterowanego przez LLM nie jest samo szyfrowanie danych, lecz to, że przestają działać założenia, na których do tej pory opierały się procedury odzyskiwania danych i reagowania na incydenty.

Zapłata okupu nie gwarantuje odzyskania danych. Klucz szyfrujący w JadePuffer wygenerowano losowo i nigdy nie przesłano do atakującego – został tylko raz wypisany na ekranie sesji agenta. Ofiara nie odzyska 1342 zaszyfrowanych elementów konfiguracji Nacos nawet po spełnieniu żądania z noty ransom.
Kopie zapasowe nie rozwiązują problemu same z siebie. Celem ataku była żywa baza konfiguracyjna produkcyjnego serwera, nie tylko pliki na dysku. Szyfrowanie kopii zapasowych i procedury backupu mają sens tylko wtedy, gdy kopie są odizolowane od tej samej ścieżki dostępu, którą wykorzystał agent do ataku na system źródłowy.
Zasoby typu NoMoreRansom.org tu nie pomogą. Inicjatywy oferujące darmowe odzyskiwanie danych działają, gdy da się złamać implementację znanej rodziny ransomware albo odzyskać przechłamany klucz. Przy losowo generowanym, nigdzie nie przechowywanym kluczu AES nie ma czego łamać.
Próg wejścia do prowadzenia ataków ransomware spada do kosztu uruchomienia agenta. Aktywne dziś grupy ransomware, takie jak Rhysida czy Qilin (który przejął dużą część rynku po tym, jak RansomHub zniknął z sieci wiosną 2025 roku i został wchłonięty przez kartel DragonForce), to naturalni kandydaci do przejęcia podobnych narzędzi agentowych.
Tempo ataku eliminuje okno na reakcję. Sekwencja od nieudanego logowania do działającej poprawki zajęła 31 sekund. Kwartalny przegląd bezpieczeństwa infrastruktury, która zmienia się codziennie, zostawia luki, które autonomiczny agent zdąży wykorzystać, zanim ktokolwiek zauważy incydent.

JadePuffer nie jest odosobnionym sygnałem, że modele językowe da się skierować przeciwko organizacji

Niedawno opisywaliśmy, jak atakujący przekonali chatbota Meta AI, by zresetował hasła i pomógł przejąć 20 225 kont na Instagramie – zupełnie inny wektor, ten sam mechanizm: model wykonujący szkodliwe działania na podstawie tego, co „zrozumiał”.

Rosnąca liczba zgłoszonych ataków ransomware i incydentów ransomware z użyciem AI pokazuje, że to już nie jest scenariusz teoretyczny, tylko element krajobrazu cyberataków w erze GenAI, z którym organizacje muszą się zmierzyć już dziś. Jeśli chcesz zobaczyć więcej takich przypadków rozłożonych na czynniki pierwsze, w bezpłatnym cyklu webinarów AI vs. Cybersecurity Secawa omawialiśmy zarówno ataki sterowane przez AI, jak i ataki wymierzone w same systemy AI, wraz z nagraniami i materiałami do pobrania.

Bezpłatny cykl webinarów: ataki wspierane AI, Shadow AI, ataki na AI (prompt injection) i AI jako wsparcie CISO. 4 spotkania, dodatkowe materiały i kilku specjalistów SECAWA, którzy szczegółowo rozłożyli temat AI w kontekście cyberbezpieczeństwa.

Odbierz nagrania i materiały z cyklu AI vs Cybersecurity

Jak zabezpieczyć organizację przed ransomware sterowanym przez AI?

Zapobieganie atakom ransomware tego typu nie wymaga nowych narzędzi, tylko konsekwentnego domknięcia luk, które JadePuffer wykorzystał w kolejności zero-day nigdy nie było potrzebne:

Załataj Langflow do wersji usuwającej CVE-2025-3248 i nie eksponuj do internetu endpointów wykonania ani walidacji kodu.
Nie trzymaj kluczy API i danych uwierzytelniających chmury w środowisku serwerów orkiestracji AI. Sekrety powinny trafiać do dedykowanego menedżera, poza zasięgiem procesów dostępnych z sieci.
Utwardź Nacos – zmień domyślny klucz podpisujący (token.secret.key), zaktualizuj do wersji wymuszającej własny klucz, nigdy nie wystawiaj usługi do internetu i nigdy nie łącz jej z bazą jako root.
Nie eksponuj konta administracyjnego bazy danych do internetu. Silne, unikalne dane logowania i ograniczenia po adresie źródłowym IP to minimum.
Wprowadź kontrolę ruchu wychodzącego (egress), tak by skompromitowany host aplikacyjny nie mógł swobodnie łączyć się z dowolną infrastrukturą ani zewnętrznymi bazami.
Zainwestuj w wykrywanie zagrożeń działające w czasie rzeczywistym na poziomie procesów bazodanowych, nie tylko na poziomie sieci czy sygnatur plików.
Monitoruj wskaźniki kompromitacji – nietypowe zadania cron z wywołaniami sieciowymi, anomalie w nagłówkach żądań, nagłe skoki w liczbie zapytań do usług konfiguracyjnych.

Natomiast żadna z tych rekomendacji nie zadziała bez ludzi, którzy rozumieją, że socjotechnika w erze agentów AI wygląda inaczej niż jeszcze dwa lata temu. Zespoły bezpieczeństwa i IT warto przygotować również na metody socjotechniczne wspierane przez GenAI, bo granica między atakiem czysto technicznym a wspieranym manipulacją coraz częściej się zaciera.

Podsumowanie

JadePuffer zmienia trzy założenia, na których opierało się dotychczasowe planowanie obrony. Po pierwsze, próg wejścia do prowadzenia ataku ransomware spadł do kosztu uruchomienia agenta – a przy modelach napędzanych kradzionym dostępem obliczeniowym koszt ten zbliża się do zera. Po drugie, stare, pozornie niegroźne podatności – jak luka w Nacos z 2021 roku – są dziś automatycznie odświeżane przez agenty przeszukujące cały historyczny katalog CVE, więc zaniedbana, niezałatana infrastruktura staje się bardziej, nie mniej, atrakcyjnym celem. Po trzecie, kod generowany przez LLM sam opisuje swoje intencje – ta sama cecha, która czyni agenta groźnym, daje obrońcom nową szansę wykrycia ataku zanim dojdzie do szyfrowania.

Modelowanie zagrożeń dla systemów opartych na AI przestaje być ćwiczeniem akademickim – to punkt wyjścia do oceny ryzyka w każdej organizacji, która wdraża agentowe narzędzia AI albo jest potencjalnym celem takich, jak JadePuffer. Więcej o tym, jak systematycznie modelować zagrożenia związane z prompt injection w systemach AI, znajdziesz w naszym poprzednim materiale.

Jeśli wolisz zobaczyć te mechanizmy rozłożone na czynniki pierwsze na żywo, zapraszamy do bezpłatnego cyklu webinarów AI vs. Cybersecurity, gdzie omawialiśmy zarówno ataki sterowane przez AI, jak i ataki na same systemy AI – z dostępnymi nagraniami i materiałami do pobrania.

Źródła:

https://www.bleepingcomputer.com/news/security/jadepuffer-ransomware-used-ai-agent-to-automate-entire-attack

https://www.darkreading.com/cyberattacks-data-breaches/jadepuffer-first-complete-llm-driven-ransomware-attack

Pod koniec maja na kanałach Telegramu pojawiła się instrukcja, która pozwalała przejąć cudze konto na Instagramie bez znajomości hasła i bez dostępu do skrzynki ofiary. Wystarczył do tego czat z Meta AI.

Meta potwierdziła, że tą metodą przejęto 20 225 kont, a wśród ofiar znalazły się uśpiona strona Obama White House, profil sieci kosmetycznej Sephora oraz konto wysokiego rangą oficera US Space Force.

Jak czat z Meta AI pozwolił przejąć konta na Instagramie?

Hakerzy przejmowali konta, polecając chatbotowi Meta AI powiązanie profilu ofiary z własnym adresem e-mail, na który system wysyłał link resetujący hasło. Nie łamali haseł ani nie włamywali się do cudzych skrzynek, cały atak sprowadzał się do rozmowy z chatbotem.

Według zgłoszenia Meta podatność wykryto 31 maja 2026 roku, a rejestr prokuratora generalnego stanu Maine wskazuje 17 kwietnia jako prawdopodobną datę pierwszego ataku. Oznaczałoby to, że luka pozostawała otwarta przez około sześć tygodni, choć Meta nie podała oficjalnie, kiedy ataki się rozpoczęły.

Na czym polegała luka w chatbocie Meta AI?

Słabym ogniwem okazał się High Touch Support (HTS), uruchomiony w marcu 2026 roku system odzyskiwania kont wspomagany sztuczną inteligencją. Meta zbudowała go, by odciążyć powolną obsługę użytkowników odciętych od Instagrama.

Jak firma przyznała w zgłoszeniu naruszenia złożonym u prokuratora generalnego stanu Maine, samo narzędzie działało zgodnie z założeniem, ale błąd w odrębnej ścieżce kodu sprawiał, że system nie weryfikował, czy wskazany adres e-mail w ogóle należy do danego konta. Zamiast odrzucić takie żądanie, wysyłał link resetujący na obcy adres. Mechanizmem, który zawiódł, była brakująca kontrola autoryzacji w zapleczu procesu odzyskiwania.

Jak wyglądał atak na czat z Meta AI krok po kroku?

Sam scenariusz był banalnie prosty. Napastnik łączył się przez VPN z adresu IP w okolicy typowej lokalizacji ofiary, prawdopodobnie po to, aby żądanie resetu wyglądało wiarygodnie i nie wzbudziło podejrzeń systemu.

Następnie prosił o reset hasła i przechodził do czatu z Meta AI. Tam wydawał chatbotowi polecenie powiązania konta z nowym adresem e-mail, na który trafiał jednorazowy kod.

Pozwalało to ustawić nowe hasło i zalogować się na cudze konto. Warunek był jeden: konto ofiary nie mogło mieć włączonego uwierzytelniania dwuskładnikowego (2FA).

Czego ten atak uczy o bezpieczeństwie agentów AI?

Chatbot potrafił wykonać poważne operacje, jak reset hasła czy zmiana e-maila, ale nie miał jak zweryfikować, że prosi o nie prawdziwy właściciel konta. Ten sam błąd, czyli potężne uprawnienia bez kontroli tożsamości, powtarza się w całej klasie ataków wymierzonych w agentów AI.

Dlaczego chatbot to nowa powierzchnia cyberataków?

Problemem nie jest sama sztuczna inteligencja, tylko zakres uprawnień, jakie jej powierzono.

To fundamentalna wada architektury. Model otrzymał uprawnienia do wrażliwych operacji bez odpowiedniej kontroli dostępu.

Brian Westnedge, Red Sift, wypowiedź dla Reutersa (tłum. red.)

Atak przypomina socjotechnikę stosowaną wobec ludzkich konsultantów: zamiast łamać zabezpieczenia, napastnik po prostu poprosił o wykonanie operacji, a system ją zrealizował.

Część ekspertów cytowanych przez Reutersa klasyfikowała incydent jako prompt injection, czyli manipulację konwersacyjną modelem. Warto jednak odnotować, że techniczne wyjaśnienie samej Mety wskazuje nie na podatność modelu językowego, lecz na brakującą weryfikację w kodzie obsługującym reset hasła. Niezależnie od klasyfikacji wniosek pozostaje ten sam: bot dostał prawo do wrażliwych operacji bez mechanizmu sprawdzającego, kto i na jakiej podstawie o nie prosi.

Skala potencjału szkód rośnie wraz z tym, jak kolejne platformy oddają chatbotom obsługę logowania, resetu haseł czy odzyskiwania kont. Ian Goldin z Black Lotus Labs ostrzega, że wchodzimy na nieznany grunt i podobnych ataków będzie przybywać. Engin Kirda z Northeastern University ujął to dosadnie: kiedyś celem oszustw byli ludzie, teraz stają się nimi agenci AI.

Prompt injection a bezpieczeństwo systemów AI. Jak modelować zagrożenia?

Przeczytaj artykuł

Jak chronić konto na Instagramie przed przejęciem przez hakerów?

Najskuteczniejszą barierą okazało się uwierzytelnianie dwuskładnikowe. Według samych hakerów exploit nie zadziałał wobec żadnego konta z włączonym MFA, a blokował go nawet najsłabszy wariant, czyli kod SMS.

Warto jednak korzystać z mocniejszych metod, czyli klucza sprzętowego lub passkey. Kod SMS, choć w tym przypadku wystarczył, pozostaje podatny na przejęcie numeru ofiary (SIM swapping), dlatego nie powinien być jedyną linią obrony.

Skoro atak polegał na podpięciu obcego adresu e-mail do konta, warto też sprawdzić w Centrum kont, czy do profilu nie przypisano nieznanego adresu lub numeru telefonu, i usunąć takie wpisy.

Po wykryciu luki Meta wyłączyła system HTS i unieważniła wygenerowane linki, wymusiła reset haseł na zagrożonych kontach oraz objęła je obowiązkowym punktem kontroli bezpieczeństwa, a także zapowiedziała przegląd podobnych procesów odzyskiwania na swoich platformach.

Jak chronić organizację przed atakami na AI?

Przypadek Instagrama to podręcznikowy przykład zagrożenia, które rozłożyliśmy na czynniki pierwsze w bezpłatnym cyklu „AI vs Cybersecurity”. Cztery odcinki pokazują nie tylko, jak cyberprzestępcy wykorzystują GenAI do ataków, ale i jak wykorzystać AI w codziennej pracy CISO, aby skutecznie chronić organizację.

Najbliżej opisanego ataku jest odcinek numer trzy: Ataki na AI. Tłumaczymy w nim, jak modelować i minimalizować ryzyko ataków wymierzonych w systemy AI, w tym manipulację modelem i prompt injection. To pokrewna klasa zagrożeń, którą przypadek Meta AI dobitnie obnażył: agent z prawem do wrażliwych operacji staje się celem, gdy zabraknie kontroli, kto i na jakiej podstawie o nie prosi. Do tego udostępniamy skrócony poradnik krok po kroku, jak takie ryzyko ograniczać w praktyce.

Pozostałe odcinki rozszerzają ten obraz:

W odcinku pierwszym – AI Atakuje – pokazujemy, jak przestępcy używają AI do ataków socjotechnicnzych i automatyzacji działań; w pakiecie czeka checklista 15 pytań dla CISO oraz poradnik rozpoznawania phishingu.
Shadow AI (odc.2) dotyczy niekontrolowanego korzystania z narzędzi AI przez pracowników i daje walidator AI Act, przewodnik bezpiecznego korzystania z AI w pracy oraz checklistę zarządzania Shadow AI w organizacji.
AI jako wsparcie CISO, odcinek ostatni z cyklu webinarów, odwraca perspektywę i pokazuje, jak wykorzystać sztuczną inteligencję po stronie obrony.

Dostęp do nagrań i wszystkich materiałów jest bezpłatny. Wystarczy wypełnić formularz na stronie cyklu AI vs Cybersecurity.

Uzyskaj dostęp do nagrań i materiałów z bezpłatnego cyklu webinarów AI vs Cybersecurity

Wypełnij formularz

Źródła:

https://krebsonsecurity.com/2026/06/hackers-used-metas-ai-support-bot-to-seize-instagram-accounts

https://www.bleepingcomputer.com/news/security/meta-ai-support-data-breach-affects-20-000-instagram-accounts

https://insideretail.asia/2026/06/04/how-the-sephora-instagram-hack-exposed-metas-ai-weakness/

https://www.404media.co/hackers-simply-asked-meta-ai-to-give-them-access-to-high-profile-instagram-accounts-it-worked

https://www.reuters.com/legal/government/high-profile-meta-ai-chatbot-breach-spotlights-security-risks-automation-2026-06-03

Systemy oparte o LLM wprowadzają nowy model działania, ale wiele zagrożeń bezpieczeństwa wynika z dobrze znanych wzorców ryzyka. Zmienia się nie sam cel ataku, lecz sposób, w jaki w jednym przepływie łączą się dane, instrukcje, narzędzia i uprawnienia. To właśnie dlatego prompt injection i inne ataki na systemy AI nie powinny być analizowane wyłącznie jako problem modelu, ale jako problem całej architektury systemu.

W praktyce oznacza to, że ryzyko nie kończy się na złośliwym prompcie, tylko może zacząć się od danych wejściowych, przejść przez kontekst i RAG, wykorzystać narzędzia lub integracje, a na końcu doprowadzić do nadużycia uprawnień, wycieku danych albo wykonania nieautoryzowanych działań.

Dla CISO to nie jest więc temat pojedynczej podatności, ale modelowania zagrożeń warstwa po warstwie.

Skala problemu jest poważna: można zaryzykować stwierdzeniem, że 100% systemów AI jest podatnych na ataki, ponieważ nie istnieje dziś w pełni skuteczna metoda obrony przed prompt injection.

Piotr Kaźmierczak, CEO SECAWA

Dlatego systemy AI należy projektować przy założeniu, że pojedyncze zabezpieczenia mogą zostać ominięte, a odporność trzeba budować wielowarstwowo – na poziomie wejścia, kontekstu, RAG, narzędzi, uprawnień, wyjścia i kontroli operacyjnej.

Jak przebiega komunikacja z LLM (Large Language Model)?

Aby dobrze modelować zagrożenia w systemach AI, trzeba najpierw zrozumieć, jak taki system faktycznie działa.

Z perspektywy użytkownika wygląda to prosto: zadajemy pytanie i dostajemy odpowiedź. W praktyce model nie pracuje jednak na pojedynczym zdaniu, tylko na całym kontekście, który został mu przekazany przez aplikację.

W najprostszym ujęciu ten przepływ obejmuje instrukcję systemową, input użytkownika, model oraz odpowiedź lub akcję systemu. To właśnie w tym miejscu pojawia się też główna powierzchnia ataku związana z prompt injection.

Wiadomości i kontekst modelu językowego

Dla modelu językowego kontekst to wszystko, co „wie” o bieżącej interakcji. Obejmuje on nie tylko treść pytania użytkownika, ale też instrukcję systemową, wcześniejsze wiadomości, a w bardziej rozbudowanych architekturach również dane zewnętrzne i wyniki działania narzędzi. To zbiór wiadomości, który dopiero po złożeniu trafia do modelu. To ważne, bo model nie odpowiada wyłącznie na ostatnią wiadomość – działa na podstawie całego kontekstu, jaki dostaje od aplikacji.

Pytanie-odpowiedź

Najprostszy wariant to architektura pytanie-odpowiedź. System przekazuje do modelu instrukcję systemową i jedną wiadomość użytkownika, a następnie odbiera odpowiedź.

Taki przepływ wygląda najczyściej, ale już na tym poziomie widać podstawową logikę bezpieczeństwa: model reaguje na to, co znajduje się w kontekście, a nie na intencję projektanta systemu. Dlatego nawet prosty chatbot nie jest wyłącznie interfejsem rozmowy, tylko systemem, którego zachowanie zależy od tego, jak został zbudowany kontekst wejściowy.

Konwersacja

Sytuacja komplikuje się, gdy przechodzimy do konwersacji wieloturowej. Wtedy do kontekstu trafia nie tylko nowe pytanie użytkownika, ale także wcześniejsze odpowiedzi modelu i historia rozmowy.

Z punktu widzenia funkcjonalności to naturalne – system ma „pamiętać”, o czym była rozmowa.

Z punktu widzenia bezpieczeństwa oznacza to jednak, że każde kolejne wywołanie modelu opiera się na coraz szerszym zestawie treści, które mogą wpływać na logikę odpowiedzi. Im dłuższa i bogatsza rozmowa, tym większe znaczenie ma to, co dokładnie zostało utrwalone w kontekście.

RAG

Kolejny poziom to RAG, czyli wzbogacanie kontekstu o zewnętrzne źródła wiedzy. Do okna kontekstowego mogą trafiać dokumenty, rekordy z bazy danych, treści stron internetowych czy inne materiały, które mają pomóc modelowi udzielić pełniejszej odpowiedzi.

Pozwala to połączyć model z wiedzą organizacji lub zewnętrznymi danymi. Jednak z perspektywy bezpieczeństwa oznacza to, że do modelu zaczynają trafiać treści spoza bezpośredniej rozmowy z użytkownikiem – a więc także treści, które mogą być błędne, niezweryfikowane albo złośliwe.

Użycie narzędzi

Najbardziej rozbudowany wariant to system AI, w którym model nie tylko odpowiada, ale także korzysta z narzędzi. W takim scenariuszu model może najpierw wywołać określoną funkcję, API albo automatyzację, a dopiero potem – po otrzymaniu wyniku – wygenerować odpowiedź końcową. Wynik działania narzędzia również wraca do kontekstu i wpływa na dalszy przebieg zadania.

To kluczowy moment z perspektywy CISO, bo system AI przestaje być wtedy wyłącznie warstwą odpowiedzi, a zaczyna realnie oddziaływać na dane, procesy i operacje. Im więcej narzędzi, integracji i kroków pośrednich, tym większa powierzchnia ryzyka.

To właśnie dlatego komunikacji z modelem LLM nie należy sprowadzać do prostego schematu „pytanie-odpowiedź”. W praktyce jest to przepływ, w którym kontekst może być budowany z wielu źródeł, rozszerzany o historię rozmowy, zasilany danymi zewnętrznymi i uzupełniany wynikami działania narzędzi. A skoro tak, to bezpieczeństwo systemu AI trzeba oceniać nie tylko na poziomie modelu, ale całej architektury, która ten kontekst tworzy.

Czym jest prompt injection?

Prompt injection to atak polegający na wprowadzeniu specjalnie przygotowanej instrukcji, która nakłania model AI do działania w sposób niezgodny z jego przeznaczeniem. Złośliwy prompt nie musi „zepsuć” samego modelu – wystarczy, że wpłynie na to, jak model interpretuje kontekst i jakie działania uzna za właściwe. Właśnie dlatego ataki typu Prompt Injection są dziś traktowane jako główna powierzchnia ataku w systemach opartych o LLM.

Oznacza to, że w przypadku takiego ataku model otrzymuje nie tylko właściwe pytanie czy zadanie, ale również dodatkową, złośliwą instrukcję, która ma zmienić sposób jego działania. Jeżeli system nie oddziela wystarczająco dobrze danych od instrukcji, model może potraktować złośliwą treść jako instrukcję sterującą i odpowiedzieć lub zadziałać wbrew intencji projektanta systemu.

Skutki prompt injection

Atak typu prompt injection dla organizacji może oznaczać:

ujawnienie poufnych informacji,
wykonanie nieautoryzowanych działań,
manipulację odpowiedziami systemu AI,
utratę zaufania klientów i partnerów.

Więcej o prompt injection, rodzajach i konsekwencjach pisaliśmy w tym artykule: http://secawa.com/blog/prompt-injection-czym-jest-dlaczego-stanowi-ryzyko-dla-organizacji-i-jak-je-ograniczyc/

Jak modelować zagrożenia w systemach AI?

Dla CISO kluczowe nie jest wyłącznie pytanie, czy system jest odporny na prompt injection, ale jak ocenić ryzyko osobno dla każdej warstwy systemu AI – od wejścia i kontekstu, przez RAG oraz narzędzia, po uprawnienia, wyjście i kontrolę operacyjną.

W praktyce modelowanie zagrożeń w systemach AI warto rozłożyć na 7 obszarów: wejścia, kontekst, RAG, narzędzia i integracje, uprawnienia, wyjście oraz telemetrię i kontrolę.

01 Dane wejściowe

To pierwszy i najbardziej oczywisty obszar modelowania zagrożeń. Do systemu AI mogą trafiać:

dane od użytkownika,
pliki,
strony internetowe,
e-maile,
tickety,
repozytoria.

To właśnie te wejścia materiały wskazują jako główne punkty wejścia dla prompt injection. Problem polega na tym, że system nie zawsze odróżnia zwykłą treść od złośliwej instrukcji. Im więcej źródeł wejściowych i formatów danych, tym większe ryzyko, że złośliwy prompt zostanie potraktowany jak część legalnego kontekstu.

02 Kontekst

Druga warstwa to sam kontekst modelu, czyli:

system prompt,
pamięć,
polityki.

To tutaj dochodzi do prób przejęcia logiki działania systemu lub ujawnienia ukrytych instrukcji. Z perspektywy bezpieczeństwa jest to krytyczne, ponieważ manipulacja kontekstem może prowadzić do zmiany logiki działania systemu albo ujawnienia instrukcji sterujących modelem.

03 RAG

Kolejna warstwa to RAG, czyli mechanizm wzbogacania kontekstu modelu o dokumenty i dane z bazy wiedzy. Z perspektywy architektury obejmuje to m.in. bazę wektorową, retriever i ranker.

W tej warstwie główne ryzyka to ekstrakcja danych, manipulacja kontekstem oraz zatrucia danych. Jeśli system pobiera treści z dokumentów, stron WWW, e-maili lub innych źródeł zewnętrznych, pośrednie wstrzyknięcie promptu może nastąpić bez bezpośredniej interakcji użytkownika z atakującym.

04 Narzędzia i integracje

Gdy model ma dostęp do API, funkcji, automatyzacji albo serwerów MCP, przestaje być wyłącznie warstwą generowania odpowiedzi, a zaczyna wpływać na procesy, dane i działania wykonywane poza samym LLM.

To właśnie tutaj pojawia się ryzyko nieautoryzowanych akcji i nadużycia narzędzi. Wystarczy manipulacja promptem, kontekstem lub przebiegiem zadania, by system AI wykonał operację, której nie powinien uruchomić.

05 Uprawnienia

To jedna z najważniejszych warstw z perspektywy CISO. Pytanie nie brzmi tylko, do czego model ma dostęp, ale też na czyich uprawnieniach działa i jaki zakres dostępu mają podłączone narzędzia.

Kluczowa zasada jest prosta: kontrola dostępu musi działać poza LLM, na poziomie aplikacji. Jeżeli system tego nie dopilnuje, asystent AI może wykonywać operacje z większym zakresem uprawnień, niż powinien, albo uruchamiać akcje, do których użytkownik normalnie nie miałby dostępu.

06 Wyjście modelu językowego

Modelowanie zagrożeń nie kończy się na wejściu. Równie ważne jest to, co system zwraca dalej: odpowiedzi, linki, HTML, integracje i dane przekazywane do kolejnych komponentów.

To istotne, bo odpowiedź modelu może być:

szkodliwa sama w sobie,
wejściem dla kolejnego systemu,
nośnikiem wycieku danych,
punktem uruchomienia dalszych działań w łańcuchu automatyzacji.

Dlatego wyjście modelu trzeba traktować jak element powierzchni ataku, a nie tylko końcowy rezultat działania.

07 Telemetria i kontrola

Ostatnia warstwa to nadzór operacyjny nad systemem AI – logi, limity, alerty, zatwierdzanie akcji i wykrywanie anomalii. Ta część nie blokuje ataku sama z siebie, ale daje organizacji możliwość audytu, wykrywania nadużyć i szybkiej reakcji.

To szczególnie ważne tam, gdzie system wykonuje działania kosztowne, wrażliwe lub trudne do odwrócenia. Bez telemetrii i kontroli organizacja traci widoczność tego, co system AI zrobił, jak zachowywał się podczas wykonywania poleceń oraz czy doszło do nadużyć, anomalii lub kosztownych skutków operacyjnych.

7 pytań, od których CISO powinien zacząć ocenę ryzyka systemów AI

Odporność systemu AI trzeba projektować wielowarstwowo. Dlatego dobrym punktem wyjścia jest przejście przez 7 warstw systemu AI i ocena ryzyka osobno dla każdej z nich – od danych wejściowych i kontekstu, przez RAG oraz narzędzia, po uprawnienia, wyjście i kontrolę operacyjną.

Co może wejść do systemu?

Pierwsze pytanie dotyczy nie modelu, ale kanałów wejściowych. Do systemu AI mogą trafiać nie tylko prompty użytkownika, ale też pliki, strony internetowe, e-maile czy dokumenty. To właśnie tutaj zaczyna się duża część skutecznych ataków, bo model może potraktować niezaufane dane jak instrukcję. Dlatego CISO powinien sprawdzić, które wejścia są filtrowane, czy działa screening wejścia, czy wykrywane są wzorce prompt injection i czy organizacja reaguje na powtarzalne nadużycia użytkowników.

Co trafia do kontekstu modelu?

Drugie pytanie brzmi: co dokładnie model widzi jako kontekst. Dobra praktyka nie polega na „mocniejszym promptcie systemowym”, tylko na rozdzieleniu danych od instrukcji, jasnym oznaczeniu, co jest poleceniem systemowym, a co treścią użytkownika lub dokumentu, oraz na minimalizacji przekazywanego kontekstu do tego, co naprawdę potrzebne do wykonania zadania. CISO powinien też ocenić, czy w kontekście nie lądują sekrety, wrażliwe konfiguracje albo zbędne informacje, które zwiększają ryzyko wycieku.

Jakie źródła wiedzy wzbogacają odpowiedź?

Przy RAG kluczowe jest pytanie nie tylko o to, z czego system korzysta, ale też jak ufa tym źródłom. Dokumenty, strony WWW, PDF-y, e-maile i komentarze mogą zawierać złośliwe instrukcje, dlatego źródła zewnętrzne trzeba traktować jako niezaufane, a treści w RAG filtrować i oznaczać przed włączeniem do kontekstu. Z perspektywy CISO ważne jest także to, czy system zachowuje kontrolę uprawnień do danych źródłowych, czy segmentuje repozytoria oraz czy wykrywa próby masowej ekstrakcji danych.

Jakie narzędzia może wywołać model?

Gdy system AI korzysta z API, funkcji albo automatyzacji, błędna odpowiedź może szybko stać się kosztowną wpadką operacyjną. Dlatego CISO powinien ocenić, jakie narzędzia model może uruchomić, czy ich użycie jest walidowane przed wykonaniem akcji, czy kontrolowany jest output zwracany przez narzędzia i czy model nie może samodzielnie pomijać wymaganych kroków procesu. W praktyce bezpieczeństwo tej warstwy opiera się na walidacji wywołań, kontroli sekwencji działań i ograniczaniu zakresu integracji do minimum niezbędnego dla danego zadania.

Na czyich uprawnieniach działa system?

To pytanie często decyduje o skali incydentu. CISO powinien ustalić, czy agent działa w kontekście użytkownika, aplikacji czy uprzywilejowanego backendu, a także czy autoryzacja odbywa się poza LLM, na poziomie aplikacji. Dobre praktyki są tu jednoznaczne: wszystkie operacje powinny odbywać się z uprawnieniami użytkownika, a nie systemu, zakres narzędzi powinien być minimalny, a tożsamość użytkownika, agenta i backendu powinna być rozdzielona. Bez tego prompt injection może przerodzić się w privilege escalation i nieautoryzowane operacje.

Co wychodzi z modelu i gdzie trafia dalej?

Wyjście modelu to nie tylko odpowiedź dla użytkownika. To także potencjalny nośnik wycieku danych, kolejny krok automatyzacji albo wejście dla innego systemu. Dlatego CISO powinien sprawdzić, czy organizacja kontroluje odpowiedzi modelu, wykrywa próby ujawnienia danych na wyjściu, ogranicza długość odpowiedzi i liczbę kroków oraz nie umieszcza sekretów w promptach i kontekście. W praktyce równie ważne jak blokowanie ataku jest szybkie ograniczanie skutków eksfiltracji i nadużyć kosztowych.

Jak organizacja to loguje, kontroluje i testuje?

Ostatnie pytanie dotyczy tego, czy organizacja ma realny nadzór nad systemem AI po wdrożeniu. Jednorazowe sprawdzenie nie wystarczy. Skuteczny nadzór powinien obejmować telemetrię systemu, alerty, logi, monitoring zachowania agenta, kontrolę kosztów i tokenów oraz regularne testowanie odporności na prompt injection i ataki na RAG. Ważne jest też to, by mierzyć nie tylko skuteczność blokad, ale również jakość odpowiedzi – tak, żeby po wdrożeniu zabezpieczeń system nadal działał poprawnie, trafnie i przewidywalnie.

Podsumowanie

Bezpieczeństwa systemów AI nie da się ocenić jednym testem ani jednym promptem obronnym. W systemach AI ryzyko powstaje w całym przepływie – od danych wejściowych, przez kontekst i RAG, po narzędzia, uprawnienia, wyjście oraz warstwę telemetrii i kontroli. Dlatego ocenę ryzyka warto prowadzić warstwa po warstwie, a nie wyłącznie na poziomie samego modelu.

Z perspektywy CISO najważniejszy wniosek jest prosty: nie istnieje dziś jedna, w pełni skuteczna metoda obrony przed prompt injection. Ale nie oznacza to, że organizacje są bezradne.

Odporność systemów AI trzeba projektować wielowarstwowo – łącząc kontrolę wejścia, bezpieczne budowanie kontekstu, ograniczone zaufanie do źródeł, walidację poza LLM, kontrolę uprawnień, monitoring oraz regularne testowanie odporności na realne scenariusze ataków. Równie ważne jak blokowanie ataku jest ograniczanie jego skutków i szybkie wykrywanie naruszeń.

Jeżeli chcesz zweryfikować, jak Twoje środowisko poradzi sobie z scenariuszami ataków w praktyce, warto oprzeć to na kontrolowanych testach. W SECAWA przeprowadzamy profesjonalne testy penetracyjne, które pomagają odkryć podatności systemów, a następnie przekuć wyniki w konkretne rekomendacje działań naprawczych. Dzięki temu przygotować organizację na realne cyberataki i lepiej chronić dane, reputację oraz ciągłość działania.

Przetestuj zabezpieczenia systemów za pomocą kontrolowanych cyberataków

Poznaj ofertę testów penetracyjnych

AI wchodzi do procesów biznesowych szybciej, niż niektóre organizacje zdążyły zbudować dla niej twarde granice. Modele językowe nie tylko odpowiadają na pytania. Coraz częściej czytają dokumenty, przeglądają sieć, podsumowują wątki w komunikatorach i uruchamiają akcje przez integracje (np. MCP – Model Context Protocol). To tworzy nową, semantyczną powierzchnię ataku: prompt injection.

Prompt injection to sytuacja, w której złośliwe instrukcje trafiają do kontekstu LLM – czasem wprost od użytkownika (direct prompt injection), a w innych przypadkach ukryte w danych zewnętrznych, które system przetwarza (indirect prompt injection). Efekt bywa prosty, ale kosztowny: model robi coś, czego nie powinien – ujawnia informacje, manipuluje odpowiedzią albo inicjuje działania, na które pozwala mu architektura i nadane uprawnienia (np. przez API/integracje) – mimo że użytkownik tego nie chciał.

OWASP klasyfikuje prompt injection jako najwyżej pozycjonowane ryzyko dla aplikacji LLM i GenAI. Podkreśla też rzecz niewygodną, ale kluczową dla CISO: ze względu na naturę generatywnej AI nie ma dziś metody, która daje 100% gwarancji eliminacji prompt injection – można natomiast znacząco ograniczać ryzyko i skutki.

W tym artykule odpowiadamy na pytania, które realnie wpływają na decyzje bezpieczeństwa:

Czym dokładnie jest prompt injection i jak różni się od jailbreaking?
Jakie są rodzaje ataków prompt injection?
Jak, jako CISO, zbudować ochronę przeciwko prompt injection – w politykach bezpieczeństwa, architekturze środowiska i kontrolach technicznych?

Co to jest prompt injection? Definicja

Prompt injection to podatność, w której treść przekazana do modelu (prompt użytkownika lub dane zewnętrzne dołączone do kontekstu) zmienia zachowanie albo wynik LLM w sposób niezamierzony. Może prowadzić do naruszenia reguł działania systemu, wygenerowania niepożądanych treści, ujawnienia informacji, uzyskania nieautoryzowanego dostępu albo zainicjowania działań w systemach połączonych – zależnie od architektury i uprawnień.

Do prompt injection dochodzi wtedy, gdy input (niezależnie od formy) wpływa na model tak, że ten wykonuje działania lub generuje odpowiedzi sprzeczne z zamierzoną funkcją systemu oraz zaufanymi instrukcjami (np. rolą i ograniczeniami zdefiniowanymi w system/developer prompt). Co istotne, złośliwe polecenie nie musi być czytelne dla człowieka – wystarczy, że trafia do kontekstu modelu i jest przez niego przetwarzane. Dlatego prompt injection dotyczy nie tylko czatów, ale też agentów i aplikacji GenAI, które pobierają kontekst z dokumentów, stron WWW, e-maili czy repozytoriów (np. w architekturach RAG) – przy czym samo zastosowanie RAG ani fine-tuning nie eliminuje tej podatności.

W praktyce prompt injection wykorzystuje fakt, że model przetwarza instrukcje i dane w tym samym strumieniu wejściowym (najczęściej jako tekst, a w systemach multimodalnych również poprzez inne modalności), więc niezaufana treść dołączona do kontekstu (fragment strony, wynik wyszukiwania, ticket, mail, dokument) może zawierać polecenie, które model potraktuje jak instrukcję. Im większą „sprawczość” ma system (integracje, akcje, uprawnienia), tym większy potencjalny impakt.

Różnica między prompt injection a jailbreaking

Oba pojęcia są powiązane i bywają używane zamiennie, ale nie są tym samym:

Prompt injection to nadrzędna kategoria: atak polega na manipulowaniu odpowiedzią lub zachowaniem modelu przez odpowiednio spreparowane dane wejściowe. Celem może być zmiana treści odpowiedzi, wymuszenie ujawnienia informacji albo wpłynięcie na to, jakie działania podejmie aplikacja.
Jailbreaking to szczególny przypadek prompt injection, w którym celem jest doprowadzenie do tego, żeby model zignorował mechanizmy bezpieczeństwa i ograniczenia narzucone przez system, i zaczął wykonywać rzeczy, których normalnie nie powinien.

W skrócie: każdy jailbreak jest formą prompt injection, ale nie każde prompt injection ma charakter jailbreaku. W kontekście enterprise i agentów szczególnie groźne jest to, że przez wstrzyknięcie złośliwych promptów system może zostać skłoniony do nieautoryzowanych akcji lub eksfiltracji danych – a skala skutków zależy od nadanych uprawnień i integracji.

Typy prompt injection

Direct prompt injection

Direct prompt injection występuje wtedy, gdy złośliwe polecenie trafia do modelu bezpośrednio w treści promptu użytkownika. Taki input może być:

intencjonalny – gdy atakujący świadomie konstruuje prompt, żeby zmienić zachowanie modelu,
nieintencjonalny – gdy zwykły użytkownik wpisuje coś, co nie miało być „komendą”, a mimo to wywołuje niepożądany efekt.

Mechanika jest prosta: wejście dostarcza treść, którą model błędnie traktuje jak instrukcję, co może prowadzić do obejścia ograniczeń lub wykonania działań sprzecznych z zamierzoną funkcją systemu oraz zaufanymi instrukcjami i ograniczeniami.

Indirect prompt injection

Indirect prompt injection jest trudniejsze do wykrycia, bo złośliwe instrukcje nie pochodzą od użytkownika „wprost”. Atakujący umieszcza je w zewnętrznych źródłach, które system GenAI może przetwarzać: w stronach WWW, dokumentach, e-mailach, bazach danych, metadanych lub nawet w plikach graficznych. Takie wstrzyknięcia mogą być też nieintencjonalne – jeśli treść zewnętrzna zawiera instrukcje, które model potraktuje jak polecenia.

To właśnie tu pojawia się najbardziej zdradliwy element: użytkownik często nie widzi promptu atakującego, a narzędzie może wyglądać normalnie, jednocześnie realizując ukryte instrukcje „w tle”. Złośliwe instrukcje mogą być ukryte np. w metadanych, w niewidocznych znakach Unicode albo w formatowaniu niewidocznym dla człowieka, ale czytelnym dla modelu.

Indirect prompt injection szczególnie eskaluje ryzyko, gdy:

aplikacja pobiera kontekst z zewnątrz (np. przez „czytanie” treści),
model ma dostęp do narzędzi i integracji (może podejmować działania),
przetwarzane treści pochodzą z szerokiej, trudnej do kontrolowania powierzchni (WWW, e-maile, komunikatory, repozytoria).

W praktyce oznacza to, że „dane do analizy” stają się jednocześnie potencjalnym nośnikiem poleceń – również wtedy, gdy te polecenia nie są podane wprost w tekście, tylko zaszyte w materiale graficznym lub innym kanale wejściowym.

Podsumowanie różnic między direct prompt injection a indirect prompt injection

	Direct prompt injection	Indirect prompt injection
Źródło instrukcji	Input użytkownika trafiający bezpośrednio do modelu.	Instrukcje zaszyte w treściach zewnętrznych, które model pobiera i przetwarza.
Widoczność dla użytkownika	Obecne w promptach, czasem widoczne, czasem obfuskowane, ale nadal w strumieniu wejściowym modelu.	Często niewidoczne (metadane, ukryty tekst, obfuskacja, elementy multimedialne).
Typowa powierzchnia ataku	Interfejsy, gdzie użytkownik podaje prompt (czat, formularz, komenda).	WWW, dokumenty, e-maile, komunikatory, repozytoria, rekordy DB, obrazy.

Róźnice pomiędzy direct prompt injection a indirect prompt injection

Kiedy impact jest największy?
W obu przypadkach – gdy system ma dostęp do danych i możliwość uruchamiania akcji przez narzędzia/integracje oraz szerokie uprawnienia.

Jakie skutki może mieć atak prompt injection dla organizacji?

Wyciek danych (data exfiltration)

Prompt injection może prowadzić do ujawnienia lub eksfiltracji danych wrażliwych – zarówno tych, które model „widzi” w kontekście rozmowy (np. treść przetwarzanych dokumentów, fragmenty bazy wiedzy), jak i tych, do których aplikacja ma dostęp przez podłączone narzędzia i integracje.

W praktyce ryzyko obejmuje dane, które system GenAI potrafi odczytać lub pobrać w trakcie realizacji zadania: treści e-maili, dokumenty, informacje o klientach i pracownikach, dane finansowe czy inne poufne rekordy – zależnie od tego, jakie źródła są podłączone i jakie są przyznane uprawnienia. Jeśli aplikacja ma kanały działania (np. wysyłkę wiadomości, publikację treści, wywołania API), eksfiltracja może zajść szybko, bez dodatkowego exploitowania podatności w systemach docelowych, wykorzystując legalne uprawnienia i integracje dostępne dla aplikacji/agentów.

Manipulacja treści i błędne decyzje biznesowe

Prompt injection może prowadzić do manipulacji odpowiedzią: model generuje treści zniekształcone – pomija istotne informacje, wzmacnia błędne lub stronnicze wnioski albo sugeruje działania niezgodne z zamierzonym celem systemu i zaufanymi ograniczeniami.

W organizacji szczególnie groźne jest to tam, gdzie odpowiedź modelu wspiera decyzje – w analizie ryzyka, rekomendacjach dla zespołów, procesach zakupowych, prawnych czy HR. Nawet jeśli nie dochodzi do wycieku danych, mogą pojawić się realne straty biznesowe wynikające z decyzji podjętych na podstawie zmanipulowanej odpowiedzi.

Ujawnienie informacji o systemie i instrukcjach systemowych (system prompt)

Ataki prompt injection często celują w wydobycie informacji, które pomagają atakującemu dopracować kolejne kroki: instrukcji systemowych, zasad działania asystenta, a także tego, jakie narzędzia i integracje są dostępne. To przyspiesza iterowanie ataku i zwiększa szanse na skuteczne obejście zabezpieczeń w konkretnej architekturze.

Warto to podkreślić wprost: te zagrożenia są klasyfikowane jako jedno z najwyższych ryzyk w OWASP Top 10 dla aplikacji LLM (2025). W praktyce wynikają z tego, że model – a często również cała aplikacja LLM – nie ma twardej, niezawodnej granicy między instrukcjami zaufanymi (od dewelopera/systemu) a niezaufaną treścią wejściową (od użytkownika lub z danych zewnętrznych). Ponieważ wszystko trafia do jednego kontekstu i jest przetwarzane „tym samym kanałem”, odpowiednio spreparowany input może skłonić system do ujawnienia system promptu, logiki działania albo informacji o dostępnych funkcjach – czyli dokładnie tych elementów, które ułatwiają dalszą eskalację ataku.

Nadużycie narzędzi dostępnych dla agenta

Prompt injection może skłonić agenta do wyboru i wywołania narzędzi, które są w jego arsenale, ale nie powinny być użyte w danym kontekście (np. sięgnięcie po funkcję „pobierz dane klienta” podczas prostego podsumowania maila).

To nie musi oznaczać klasycznej eskalacji uprawnień na warstwie IAM – częściej jest to złamanie granic kontekstu i celu zadania: agent wykorzystuje uprawnienia, które już posiada, w sposób nieautoryzowany względem zamierzonej funkcji systemu i polityk bezpieczeństwa.

Nieautoryzowane akcje i zmiany w systemach

Gdy agent ma integracje i możliwość wykonywania działań, skutkiem nadużycia narzędzi mogą być realne zmiany w systemach: wysłanie wiadomości, modyfikacja lub usunięcie danych, aktualizacja rekordów, uruchomienie workflow.

Problemem jest też to, że takie działania mogą wyglądać jak „normalne” operacje wykonane przez uprawniony podmiot – tylko że zostały wywołane przez zmanipulowany kontekst, a nie przez zamierzony cel zadania i zaufane instrukcje systemu.

Rekonesans i przygotowanie dalszego ataku

Prompt injection może być użyte jako etap rozpoznania: ustalenie, jakie źródła danych system przetwarza, jakie ma narzędzia, jakie ma ograniczenia, jak reaguje na określone polecenia oraz czy wymaga potwierdzenia akcji.

Taki rekonesans pomaga przygotować bardziej ukierunkowane ataki – szczególnie, gdy atakujący ma możliwość umieszczenia złośliwych instrukcji w treściach, które organizacja regularnie przetwarza (np. dokumentach, e-mailach, stronach WWW czy rekordach w systemach).

Jak chronić organizację przed atakami typu prompt injection?

Nie istnieje dziś podejście, które daje 100% gwarancji wyeliminowania prompt injection – wynika to z natury generatywnej AI oraz z faktu, że w praktyce systemy LLM przetwarzają w jednym kontekście zarówno zaufane instrukcje (system/developer), jak i niezaufaną treść (od użytkownika lub z danych zewnętrznych). Niezawodne rozróżnienie „instrukcji” od „danych” oraz wykrycie złośliwych intencji nie jest czymś, co da się dziś zapewnić deterministycznie w każdych warunkach.

To nie znaczy jednak, że jesteśmy bezbronni.

Organizacja może znacząco ograniczyć prawdopodobieństwo udanego ataku i – co często ważniejsze – ograniczyć jego skutki, budując ochronę warstwową: od świadomości bezpieczeństwa pracowników, przez governance i polityki użycia AI, po techniczne zabezpieczenia, kontrolę uprawnień, testy adwersarialne oraz monitoring zachowania modeli, agentów i ich interakcji z narzędziami..

Zwiększanie świadomości zagrożenia wśród pracowników

Prompt injection to semantyczna odmiana manipulacji – dlatego w praktyce uderza tam, gdzie pracownicy używają GenAI do pracy z treściami: podsumowują e-maile, analizują dokumenty, streszczają wątki z komunikatorów czy proszą o wykonanie zadań w narzędziach.

Jeśli użytkownik nie rozumie, że system LLM przetwarza w jednym kontekście zarówno instrukcje, jak i dane, łatwo o ryzykowne zachowania: wklejanie niezaufanych treści do narzędzi, proszenie agentów o zbyt szerokie działania („zrób co trzeba”), uruchamianie integracji bez refleksji nad konsekwencjami oraz nad tym, do jakich danych i akcji agent ma dostęp.

Dlatego edukacja w zakresie cyberbezpieczeństwa powinna obejmować nie tylko ogólną cyberhigienę, ale też konkretne zasady bezpiecznej pracy z GenAI – w tym świadomość ryzyk związanych z treściami zewnętrznymi, integracjami oraz zakresem poleceń przekazywanych agentom.

W SECAWA możemy zapewnić różne formy edukacji dla wszystkich ról w organizacji i szczebli zarządzania:

e-learning z cyberbezpieczeństwa dla firm (lekcje online i quizy utrwalające),
Praktyczny Trening Antyphishingowy – systematyczne, realistyczne symulacje ataków, które przekładają wiedzę na nawyki,
szkolenia i warsztaty z cyberbezpieczeństwa.

Skontaktuj się z nami, aby omówić najlepsze rozwiązanie security awareness dla Twojej organizacji.

Polityki i governance AI

Ochrona przed prompt injection zaczyna się od reguł, które zmniejszają powierzchnię ataku i ograniczają skutki, gdy coś pójdzie nie tak. W praktyce chodzi o cztery obszary:

Widoczność i kontrola użycia GenAI (shadow AI)

Jeśli organizacja nie wie, jakie narzędzia AI są używane i do czego (zjawisko Shadow AI) – nie jest w stanie zarządzać ryzykiem. Potrzebne są zasady, które rozróżniają narzędzia dopuszczone i niedopuszczone oraz definiują, jakie dane wolno w nich przetwarzać i w jakich scenariuszach.

Zasady pracy na źródłach treści

Indirect prompt injection bazuje na tym, że model przetwarza treści pochodzące ze źródeł, na które organizacja nie ma pełnej kontroli – albo które mogły zostać zmodyfikowane.

Dlatego warto określić, jakie źródła są uznawane za zaufane (allowlisting), kiedy stosować podejście ostrożnościowe oraz jak konsekwentnie traktować treści z WWW, e-maili, dokumentów, komunikatorów czy rekordów w systemach jako niezaufane wejście do kontekstu.

Zasady formułowania poleceń i zakres swobody działania

Im bardziej ogólne polecenie i im większa swoboda działania, tym łatwiej o niepożądany efekt. Governance AI powinno promować precyzyjne zadania, ograniczony zakres i jasne kryteria, co model ma zrobić – a czego nie ma robić (zwłaszcza gdy pracuje na treściach zewnętrznych i ma dostęp do narzędzi).

Least privilege jako domyślna reguła

Jeżeli agent ma dostęp do narzędzi i danych, powinien otrzymywać wyłącznie uprawnienia niezbędne do wykonania konkretnego zadania – i nic ponad to. Kluczowe jest świadome projektowanie tego, co agent może zobaczyć oraz co może zmienić lub uruchomić w systemach połączonych.

W praktyce oznacza to ograniczanie dostępu do wrażliwych zasobów, minimalizowanie zakresu dostępnych funkcji oraz wyraźne oddzielanie operacji „tylko do odczytu” od tych, które powodują zmiany w systemach. Im mniej uprawnień i mniej możliwości działania ma agent, tym mniejszy potencjalny impakt – nawet jeśli dojdzie do prompt injection.

Kontrole techniczne i monitoring

Warstwa techniczna ma dwa cele: utrudnić skuteczny atak oraz szybko wykryć anomalie, zanim przerodzą się w incydent. Poniższe działania to praktyczna synteza kluczowych zaleceń OWASP:

	Cel	Co wdrożyć	Co mierzyć/logować
Ograniczanie zachowania modelu	Zmniejszyć podatność na „przestawianie” roli i wymuszanie działań poza zakresem.	1. Precyzyjny system/developer prompt: rola, zakres, zakazy, warunki użycia narzędzi. 2. Zasada „task bounding” – model ma realizować tylko jasno zdefiniowane typy zadań, bez domyślnej inicjatywy. 3. Jasne reguły ignorowania prób modyfikacji instrukcji zaufanych.	1. Wersja modelu + wersja konfiguracji (np. hash/ID system promptu, polityk narzędzi). 2. Detekcje prób override/jailbreak (flagi z klasyfikatora/heurystyk). 3. Odsetek odpowiedzi „out of scope”, odmów i eskalacji do człowieka.
Definiowanie i walidacja oczekiwanego formatu wyjścia	Ograniczyć możliwość „wstrzyknięcia” niepożądanych treści do odpowiedzi i wymusić przewidywalne rezultaty.	1. Twarde schematy odpowiedzi (JSON/schema, listy pól, format raportu). 2. Deterministyczna walidacja po stronie aplikacji (parser + reguły). 3. Reguły „fail closed” – jeśli walidacja nie przejdzie, nie wykonuj akcji, nie propaguj wyniku dalej.	1. Procent niezgodności ze schematem, przyczyny odrzuceń, retry count. 2. Przypadki „schema drift” po zmianach promptów/narzędzi. 3. Korelacja: niezgodność formatu ↔ nietypowe użycie narzędzi.
Filtrowanie i kontrola wejścia/wyjścia	Wykrywać i blokować ryzykowne treści (w tym ukryte instrukcje) oraz ograniczać ujawnienia.	1. Filtry wejścia i wyjścia (reguły + klasyfikatory) dla kategorii wrażliwych i typowych sygnałów prompt injection. 2. Kontrola ujawnień: redakcja sekretów/PII, blokowanie „prompt leakage”. 3. Dla RAG: ocena jakości odpowiedzi (relewantność kontekstu, ugruntowanie w źródłach, zgodność Q/A) i odrzuty, gdy model „odpływa”.	1. Wynik filtrów: allow/block + kategorie + confidence. 2. Telemetria RAG: które dokumenty weszły do kontekstu, scoring, odrzucenia, konflikty źródeł. 3. Przypadki redakcji (co zostało zredagowane i dlaczego – bez logowania samych sekretów).
Kontrola uprawnień i zasada minimalnych uprawnień	Nawet jeśli prompt injection się uda, ograniczyć możliwy impakt.	1. Minimalny zakres dostępu do danych i funkcji – per zadanie i per agent. 2. Rozdzielanie operacji niezmieniających stanu od tych, które zmieniają stan (a te drugie – możliwie najwężej). 3. Tokeny/poświadczenia po stronie aplikacji, nie „w modelu”; model nie powinien „posiadać” sekretów.	1. Jakie uprawnienia są aktywne dla danej sesji/zadania (policy ID). 2. Każde użycie narzędzia: kto zainicjował, jaki był cel zadania, jakie były parametry (z redakcją wrażliwych wartości). 3. Próby użycia funkcji spoza dozwolonego zakresu (policy violations)
Potwierdzenie człowieka dla akcji wysokiego ryzyka	Zablokować nieautoryzowane akcje, które zmieniają stan systemów lub ujawniają dane.	1. „Human-in-the-loop” dla operacji mutujących i wrażliwych (wysyłki, modyfikacje rekordów, usuwanie, publikacje, przelewy, zmiany uprawnień). 2. Weryfikacja kontekstu akcji: co było podstawą decyzji, jakie źródła dostarczyły instrukcji.	1. Zdarzenia potwierdzeń: request → approve/deny, czas reakcji, treść podsumowania akcji. 2. Odsetek akcji zatrzymanych przez użytkownika lub reguły. 3. Najczęstsze typy akcji wymagających potwierdzeń (do strojenia polityk).
Separacja i oznaczanie treści zewnętrznych jako niezaufanych	Ograniczyć wpływ danych zewnętrznych na instrukcje zaufane i decyzje o użyciu narzędzi.	1. Jawne „granice zaufania” w kontekście: wyraźne oddzielenie treści zewnętrznych od instrukcji systemowych. 2. Polityka źródeł: allowlisting, ograniczanie domen/typów plików, zasada ostrożności dla WWW i treści niesprawdzonych. 3. Normalizacja/ oczyszczanie treści (np. usuwanie ukrytych elementów, metadanych tam, gdzie to ma sens).	1. Pochodzenie kontekstu: źródła, typy danych, ścieżka pozyskania (WWW/dokument/e-mail itd.). 2. Flagi „untrusted content” oraz detekcje ukrytych/obfuskowanych elementów. 3. Udział treści zewnętrznych w kontekście (objętość, liczba źródeł) vs incydenty/anomalie.
Testy adwersarialne i symulacje ataków	Wykrywać podatne ścieżki zanim zrobi to atakujący – i utrzymywać odporność po zmianach.	1. Regularne testy direct i indirect prompt injection na realnych przepływach (RAG, e-maile, dokumenty, WWW, narzędzia). 2. Scenariusze z akcjami: czy agent da się skłonić do nieautoryzowanych działań, ujawnień, użycia narzędzi poza kontekstem. 3. Regresje po każdej zmianie: promptów, narzędzi, integracji, polityk, źródeł danych.	1. Pokrycie testów (scenariusze, typy źródeł, typy narzędzi), wyniki pass/fail, wektory bypass. 2. Trendy podatności w czasie (czy jest lepiej/gorzej po wdrożeniach). 3. „Top failure modes” – najczęstsze sposoby, w jakie model/agent schodzi z zadania.

Źródło: LLM01:2025 Prompt Injection OWASP

Prompt injection to realny wektor ataku na aplikacje GenAI i agentów opartych o modele językowe. Ryzyko rośnie wszędzie tam, gdzie system przetwarza kontekst z zewnątrz i ma dostęp do narzędzi, integracji oraz danych wrażliwych. Ponieważ nie istnieje dziś podejście dające 100% gwarancji eliminacji prompt injection, kluczowe jest podejście warstwowe: podnoszenie świadomości i zasad bezpiecznej pracy z GenAI, polityki i governance AI ograniczające powierzchnię ataku oraz kontrole techniczne, testy i monitoring, które redukują skutki i skracają czas wykrycia.

Generatywna sztuczna inteligencja (GenAI) przestała być wyłącznie narzędziem rozwoju i innowacji – dziś to także silnik napędowy coraz bardziej wyrafinowanych ataków socjotechnicznych. Zamiast ręcznych kampanii bazujących na szablonach i domysłach, cyberprzestępcy dysponują teraz technologią, która automatyzuje cały proces oszustwa – od rekonesansu po personalizację przekazu, a rozpoznawanie ataku socjotechnicznego stało się znacznie trudniejsze.

Jak GenAI wspiera najpopularniejsze metody ataków socjotechnicznych?

Cyberprzestępcy aktywnie wykorzystują AI do generowania phishingowych wiadomości e‑mail, konstruowania fałszywych stron internetowych oraz tworzenia deepfake’ów, co przyspiesza tempo i skalę ataków. To oznacza, że ataki socjotechniczne przestają być domeną ręcznych kampanii opartych na intuicji – stają się zautomatyzowanymi, wysoce spersonalizowanymi i trudnymi do odróżnienia od prawdziwych komunikatów.

To sztuka perswazji (wywierania wpływu na ludzi), której celem jest zdobycie poufnych informacji lub wrażliwych danych poprzez szantaż emocjonalny i manipulację. Cyberprzestępcy skłaniają pracowników do pochopnych działań naruszających cyberbezpieczeństwo organizacji przez różne metody zdobywania zaufania. Dzięki temu prowadzą udane ataki socjotechniczne, o których później czytamy w wielu raportach branżowych i postach na LinkedInie.

Jak to możliwe? GenAI umożliwia automatyzację i skalowanie metod socjotechnicznych w sposób wcześniej niespotykany:

Treści tworzone przez AI są wolne od typowych błędów językowych, które dawniej pozwalały na szybkie rozpoznawanie ataku socjotechnicznego. Zamiast łamanej polszczyzny mamy naturalną składnię, poprawną interpunkcję, dopasowany kontekst.
GenAI potrafi wygenerować spersonalizowaną kampanię phishingową w kilka minut. Coś, co wcześniej zajmowało specjalistom nawet kilkanaście godzin.
Ataki stają się coraz bardziej hiperpersonalizowane i dopasowane kontekstem, co zwiększa prawdopodobieństwo, że odbiorca zaufa oszustowi, nieświadomie ujawniając dane lub wykonując niebezpieczne działania.

W praktyce oznacza to, że socjotechnika przestaje być grą przypadku, a staje się wyrafinowaną sztuką zdobywania władzy nad umysłami – zautomatyzowaną, skalowalną i coraz trudniejszą do wykrycia. Dzięki narzędziom GenAI, cyberprzestępcy mogą tworzyć hiperpersonalizowane komunikaty, które trafiają w konkretne tło emocjonalne odbiorcy, wzmacniając manipulację i osłabiając czujność.

Atak nie tylko wygląda wiarygodnie, ale też skutecznie omija filtry bezpieczeństwa, nie wzbudzając alarmu ani u systemów, ani u pracownika. To realne zagrożenie bezpieczeństwa systemu, które w ułamkach sekund może prowadzić do wyłudzenia danych, przejęcia dostępu czy utraty kontroli nad zasobami organizacji.

15 kluczowych pytań dla CISO:
Oceń gotowość firmy na ataki wspierane AI

Odbierz bezpłatną listę pytań

Przykłady ataków socjotechnicznych wspieranych generatywną sztuczną inteligencją

Dzięki GenAI cyberprzestępcy zyskują możliwość prowadzenia kampanii socjotechnicznych na niespotykaną dotąd skalę i to przy znacznie niższych kosztach operacyjnych. Klasyczne metody, takie jak phishing czy vishing, zostały przez AI wyniesione na nowy poziom. Warto podkreślić, że GenAI nie tworzy tylko nowych rodzajów ataków. Raczej wzmacnia istniejące techniki, eliminując ich dotychczasowe słabości.

Hiperpersonalizowany AI-generated phishing

Tradycyjny phishing przez lata opierał się na prostych, masowych wiadomościach rozsyłanych do przypadkowych ofiar. Jednak dzięki GenAI ten model przeszedł prawdziwą transformację. Dziś phishing może być niemal nie do odróżnienia od prawdziwej, służbowej komunikacji, zarówno pod względem języka, jak i kontekstu.

Nowoczesne modele AI (zasilane danymi z mediów społecznościowych czy firmowych stron) potrafią tworzyć spersonalizowane wiadomości dopasowane do roli, języka i stylu komunikacji konkretnej osoby. AI nie tylko wie, jak pisać, ale też do kogo, kiedy i z jakim tematem, aby zwiększyć szanse kliknięcia.

Coraz więcej kampanii phishingowych przypomina „konwersacyjne oszustwa”. Zamiast nachalnego tonu mamy przyjazne pytanie, a zamiast fałszywej faktury – subtelne nawiązanie do bieżących działań firmy. Atak rozpoczyna się od zdobycia zaufania i kończy na wyłudzeniu danych czy skłonieniu do nieautoryzowanego przelewu.

Business Email Compromise (BEC)

Jednym z najbardziej niebezpiecznych wariantów phishingu wspieranego AI jest BEC – czyli oszustwa oparte na podszywanie się pod dyrektorów, menedżerów lub partnerów biznesowych. To atak socjotechniczny wykorzystujący manipulację oparty na autorytecie i presji czasu. AI pomaga napisać przekonującą wiadomość, która naśladuje styl komunikacji konkretnego lidera, analizując jego publiczne wypowiedzi, e‑maile lub posty.

Spear phishing

Spear phishing to cyberatak ukierunkowany na konkretną osobę lub grupę. Dzięki GenAI cyberprzestępcy mogą zautomatyzować tworzenie takiego ataku, wykorzystując np. historyczne informacje o ofierze. W efekcie powstaje wiadomość, która idealnie trafia w temat, kontekst i w odpowiedni moment, np. pytanie o projekt, którym dana osoba faktycznie się zajmuje, czy prośba o komentarz do wydarzenia, które właśnie miało miejsce w firmie.

Quishing (QR code phishing)

Popularność QR kodów rośnie, np. w marketingu, płatnościach i autoryzacji. A cyberprzestępcy znaleźli sposób, aby wykorzystać ten format do własnych celów.

Quishing, czyli phishing oparty na kodach QR, to technika, która polega na osadzaniu złośliwych kodów QR w e-mailach, plakatach czy fizycznych obiektach, aby skierować użytkownika na fałszywą stronę po zeskanowaniu. GenAI umożliwia szybkie generowanie tysięcy wariantów kampanii quishingowych oraz szybkie zaprojektowanie złośliwych formularzy i stron tak, aby wyglądały jak firmowe.

Taki atak socjotechniczny omija filtry e-mailowe, złośliwy link jest ukryty dosłownie w obrazie. To sprawia, że wiele klasycznych rozwiązań filtrujących nie wykrywa zagrożenia, a pracownicy skanują kod z pełnym zaufaniem.

Bezpłatna lekcja na temat quishingu dla Twojego zespołu

Wyślij tę grafikę swoim pracownikom. Ci, którzy zeskanują kod QR trafią na lekcję o quishingu, w ramach której przypominamy kluczowe zasady bezpieczeństwa!

Smishing

Smishing to atak socjotechniczny prowadzony przez wiadomości SMS zazwyczaj zawierające link do fałszywej strony logowania lub prośbę o natychmiastowe działanie, które może na przykład naruszyć bezpieczeństwo systemu informatycznego lub wykraść poufne informacje (np. „Twoje konto zostanie zablokowane. Potwierdź dane”).

Smishing coraz częściej jest elementem działania hakerów w ramach ataków wielokanałowych: cyberprzestępca najpierw wysyła e-mail phishingowy, a następnie SMS-em „przypomina” o wykonaniu akcji, zwiększając wiarygodność ataku i presję czasu. AI pomaga w generowaniu takich skoordynowanych kampanii na dużą skalę w krótszym czasie.

Przypomnij swoim pracownikom, o tym, że jeśli mają podejrzenie, że SMS może być smishingiem, nie należy klikać w link i warto zgłosić incydent do CERT Polska przez formularz na incydent.cert.pl lub wysyłając podejrzany SMS na numer 8080.

Cyberbezpieczny Zespół: Jak rozpoznać smishing?

Odbierz bezpłatny poradnik

Ataki telefoniczne (vishing) z użyciem voice cloningu

Vishing (voice phishing) to ataki socjotechniczne prowadzone przez rozmowę telefoniczną, których celem jest manipulacja ofiary w taki sposób, aby podjęła określone działanie (ignorując przy tym aspekt bezpieczeństwa) – np. zresetowanie hasła, przelanie środków czy udostępnienia wrażliwych danych.

Voice cloning to technologia AI, która pozwala odtworzyć czyiś głos na podstawie krótkiego nagrania – np. z webinaru, YouTube’a lub firmowego podcastu. Wystarczy 30 sekund, aby system nauczył się intonacji, tempa, tonu i typowych zwrotów danej osoby.

Połączenie vishingu i voice cloningu daje cyberprzestępcom wyjątkowo niebezpieczne narzędzie. Mogą oni:

zadzwonić z podszytym numerem (np. „prezes firmy”),
mówić przekonującym, znajomym głosem,
zastosować presję czasu („jestem w podróży, potrzebuję natychmiast pomocy”),
i wymusić działanie, np. reset konta, przelew, dostęp do systemów, ujawnienie poufnych informacji.

Warto pamiętać, że ataki te często są częścią kampanii wielokanałowej (podobnie jak smishing). Na przykład wcześniej wysyłany jest e-mail lub SMS zapowiadający rozmowę. Takie połączenie drastycznie zwiększa wiarygodność ataku.

AI-generated deepfake wideo

Deepfake to technologia, która umożliwia tworzenie fałszywych nagrań wideo lub audio, wyglądających i brzmiących jak prawdziwe. Dzięki GenAI, wystarczy krótki fragment nagrania, aby wygenerować realistyczny film, w którym ktoś mówi lub robi coś, czego nigdy nie powiedział ani nie zrobił. Na przykład na ekranie widzimy prezesa, a w tle słyszymy jego głos (sklonowany dzięki AI), przekonujący do szybkiego działania: zatwierdzenia przelewu, zmiany dostępu, czy instalacji oprogramowania.

Cyberprzestępcy wykorzystują tę technikę do:

podszywania się pod liderów organizacji w wiadomościach wideo,
wzmacniania ataków typu BEC i spear phishing,
zwiększania presji i autorytetu w kampaniach socjotechnicznych.

W erze spotkań online i zdalnej pracy forma wideo zyskała sporą wiarygodność. Jeśli wiadomość pojawi się w „wewnętrznym” Slacku, MS Teams czy kanale firmowym, niewielu pracowników ją zakwestionuje.

Wiarygodne profile AI (fake persona)

Jednym z najbardziej niebezpiecznych metod ataków socjotechnicznych wspieranych GenAI jest tworzenie fałszywych tożsamości online. Dzięki AI cyberprzestępcy mogą błyskawicznie generować:

realistyczne zdjęcia profilowe,
fałszywe życiorysy zawodowe (np. „Security Manager w dużej firmie z branży finansowej”),
posty branżowe i interakcje, które budują wizerunek eksperta.

Takie profile są wykorzystywane m.in. do nawiązywania relacji na LinkedIn z pracownikami firm w celu późniejszego spear phishingu lub rekonesansu, rozprzestrzeniania dezinformacji, zdobywania dostępu do zamkniętych grup lub kanałów komunikacji (np. Slack, Teams, Discord).

AI umożliwia nie tylko szybkie generowanie treści, ale również ich dystrybucję — np. publikując komentarze, udostępniając artykuły, reagując na posty. W ten sposób „osoba” wygląda wiarygodnie, buduje relacje i zyskuje zaufanie.

Wskazówka: wyczul pracowników, aby ostrożnie akceptowali zaproszenia i kontakty w social mediach zawodowych, szczególnie od osób bez wspólnych relacji, z bardzo ogólnym profilem lub „zbyt idealnym” zdjęciem.

Jak rozpoznać ataki socjotechniczne wspierane przez GenAI – 3 wskazówki dla Twojego zespołu

Nowoczesne kampanie phishingowe, wspierane przez GenAI, są pozbawione dawnych, oczywistych błędów. Jednak nawet najbardziej dopracowany e-mail ma swoje „czerwone flagi”. Poniżej trzy najważniejsze sygnały ostrzegawcze, które Twój zespół powinien znać, a na końcu bezpłatny poradnik dla Twoich pracowników.

Czujność wobec linków (zwłaszcza tych, które ukrywają cel)

Jednym z głównych wektorów phishingu pozostają złośliwe linki – jednak dziś są one zamaskowane znacznie skuteczniej niż kiedyś. Cyberprzestępcy wykorzystują zewnętrzne skracacze linków (np. bit.ly, tinyurl), hiperlinki osadzone w tekście („kliknij tutaj”), wizualnie poprawne, ale fałszywe domeny (np. amaz0n.co vs amazon.com).

Dobre praktyki bezpieczeństwa do przekazania zespołowi:

Najedź myszką bez klikania – prawdziwy adres pojawi się w lewym dolnym rogu ekranu.
Unikaj skróconych linków – ukrywają rzeczywisty cel.
Szukaj literówek i dziwnych domen – np. amaz0n.com zamiast amazon.com.

Sprawdzanie załączników przed otwarciem

Wiele kampanii phishingowych bazuje na dokumentach, które są odpowiednio nazwane („Faktura_12_2024.doc”), zawierają makra uruchamiające złośliwy kod, są zamknięte w archiwach z hasłem, aby ominąć skanery.

Na co uważać:

Archiwa ZIP/RAR z hasłem podanym w treści wiadomości.
Dokumenty z makrami: .docm, .xlsm, stare .doc/.xls.
Pliki .exe, .scr, .bat oraz podwójne rozszerzenia: np. „faktura.pdf.exe”.

Zasada: należy otwierać załączniki tylko z absolutnie zaufanych źródeł i powinno się skanować je wcześniej.

Błędy językowe 2.0

Treści generowane przez AI cechuje gramatyczna poprawność, brak literówek, formalny ton i sztuczna precyzja. To oznacza, że należy przesunąć uwagę z „klasycznych błędów” na subtelne sygnały socjotechniki.

Na co zwracać uwagę:

wiadomości z nadmiarem form grzecznościowych lub formalnym zwrotem bez personalizacji („Szanowny Kliencie”),
dziwne konstrukcje wynikające z tłumaczenia maszynowego („uprasza się o wypełnienie procedury potwierdzania dostępu”),
mieszanka języków lub słów zapożyczonych („dziękujemy za payment”).

Wnioski: idealny język NIE jest gwarancją autentyczności. GenAI potrafi wygenerować treść, która spełnia wszystkie zasady poprawności, ale nadal jest fałszywa. Potrzebne jest podejście holistyczne: analiza języka, kontekstu, adresata, struktury wiadomości oraz metadanych.

Cyberbezpieczny Zespół:
8 wskazówek dla Twoich pracowników,
jak zdemaskować phishing

Odbierz bezpłatny poradnik

Jak skutecznie edukować pracowników? Szkolenia z cyberbezpieczeństwa vs. Praktyczny Trening Antyphishingowy

Phishing stanowi dziś największe i najbardziej kosztowne zagrożenie cybernetyczne. W 2024 roku odpowiadał za 39% wszystkich incydentów zgłoszonych do CERT Polska, a liczba ataków przekroczyła 600 tysięcy. Według ENISA aż 60% cyberataków zaczyna się od phishingu, a średni koszt naruszenia danych to już 4,88 mln USD (IBM, 2024).

Żadne zabezpieczenia techniczne nie gwarantują 100% ochrony. W sytuacjach krytycznych ostatnią linią obrony pozostają ludzie. Ich decyzje – kliknąć czy zgłosić? – rozstrzygają o powodzeniu ataku.

Dlaczego tradycyjne szkolenia z cyberbezpieczeństwa mogą okazać się niewystarczające?

Z badań Gartnera wynika, że 69% pracowników celowo ignoruje polityki bezpieczeństwa, a 93% wie, że działa ryzykownie – ale mimo to powtarza te same błędy.

To pokazuje, że klasyczne szkolenia z reguły nie są w stanie zmienić codziennych nawyków. Dlaczego?

Są zbyt ogólne: nie uwzględniają specyfiki branży, ról w organizacji ani typowych scenariuszy firmowych.
Opierają się na przekazaniu teorii: brakuje nauki w praktyce, przez co wiedza szybko ulatuje.
Oderwane od realiów: nie są aktualizowane tak często, jak aktualizowane są metody cyberprzestępców.
Nie uczą zachowań obronnych: nie pokazują, jak reagować na rzeczywiste zagrożenie w dynamicznej sytuacji.

Praktyczny Trening Antyphishingowy – sposób edukacji, który kształtuje bezpieczne nawyki

Gdy żadne narzędzie techniczne nie gwarantuje pełnej ochrony, cyberodporność organizacji zależy od tego, jak zachowają się jej pracownicy. To nie poziom świadomości bezpieczeństwa powinien być wyznacznikiem gotowości na cyberzagrożenia, ale zdolność do właściwej reakcji w praktyce.

Dlatego Praktyczny Trening Antyphishingowy powstał nie jako kolejne e-learning lub szkolenie z cyberbezpieczeństwa do odhaczenia, lecz jako systematyczny proces treningowy, który kształtuje realne odruchy obronne. Zamiast jednorazowego działania, dostarczamy ciągły, zautomatyzowany program edukacyjny prowadzony przez ekspertów SECAWA – zajmujemy się wszystkim: od przygotowania symulacji phishingowych po analizę wyników. Wyznaczone osoby w firmie (zwykle jest to CISO) mają dostęp do autorskiej platformy treningowej, która dostarcza przejrzystych raportów i pokazuje realny postęp zespołu w formie dokładnych, ale czytelnych statystyk.

Dlaczego warto wdrożyć Praktyczny Trening Antyphishingowy w swojej organizacji?

Poniżej znajdziesz tabelę porównawczą Praktycznego Treningu Antyphishingowego z tradycyjnymi szkoleniami z cyberbezpieczeństwa dla firm. Jeśli chcesz poznać Praktyczny Trening Antyphishingowy SECAWA i przetestować naszą autorską platformę treningową bez kosztów i zobowiązań – umów się na Bezpłatny Test Phishingowy!

97% organizacji, które doświadczyły incydentu związanego z AI, nie miało odpowiednich kontroli dostępu (IBM, 2025). Na dodatek, średnio 13% organizacji zgłosiło naruszenia, które bezpośrednio dotyczyły ich modeli lub aplikacji AI.

Odkąd GenAI jest dostępna na wyciągnięcie ręki, przewagę mają ci, którzy potrafią ją wykorzystać – nie zawsze w dobrej wierze. Od osób odpowiedzialnych za bezpieczeństwo organizacji, szczególnie CISO (Chief Information Security Officer), w dużej mierze zależy, czy AI stanie się luką, czy narzędziem obrony.

O tym, jak przekształcić AI z niekontrolowanego ryzyka w element strategii bezpieczeństwa, opowiemy w ramach bezpłatnego cyklu webinarów AI vs Cybersecurity – praktyczne przykłady, gotowe rozwiązania i sesje Q&A.

Phishing wspierany przez GenAI

Phishing od lat pozostaje jednym z najpowszechniejszych i najskuteczniejszych wektorów ataku – opiera się na technikach socjotechnicznych, w tym manipulacji emocjami, zaufaniem i błędami poznawczymi. Cyberprzestępcy podszywają się pod zaufane osoby lub instytucje, aby wyłudzić dane, środki finansowe lub uzyskać dostęp do systemów. Odkąd generatywna sztuczna inteligencja (Generative AI) jest ogólnodostępna, ta technika przeszła istotną ewolucję.

Czym jest AI-generated phishing?

Ataki typu AI-generated phishing wykorzystują duże modele językowe (LLM) do generowania naturalnie brzmiących, przekonujących i silnie spersonalizowanych wiadomości phishingowych. W przeciwieństwie do tradycyjnych kampanii (często pisanych łamaną angielszczyzną i rozsyłanych masowo), te wiadomości są dopasowane do kontekstu, branży, a nawet roli odbiorcy, a niejednokrotnie bazują na aktualnych projektach i wewnętrznym stylu komunikacji organizacji.

AI umożliwia też prowadzenie bardziej skutecznych ataków typu Business Email Compromise (BEC) oraz tzw. CEO fraud. Dzięki generatywnym modelom, przestępcy tworzą wiarygodne wiadomości w lokalnym języku, dopasowane do stylu komunikacji firmy. Podszywają się przy tym pod osoby na wysokich stanowiskach, wywierając presję – np. pilną prośbą o nietypowy przelew czy udostępnienie poufnych danych. Dzięki temu, że GenAI pozwala również prowadzić dynamiczny dialog z ofiarą (odpowiadać na pytania, eskalować narrację, a nawet analizować wcześniejsze wątki komunikacji), to ataki stają się jeszcze bardziej wiarygodne i ukierunkowane.

To właśnie dlatego tradycyjne filtry bezpieczeństwa oparte na wykrywaniu znanych wzorców (np. słów kluczowych) stają się coraz mniej skuteczne wobec realistycznych i kontekstowo dopasowanych ataków phishingowych generowanych z pomocą GenAI.

Cyberbezpieczny Zespół:
8 wskazówek dla Twoich pracowników,
jak zdemaskować phishing

Odbierz bezpłatny poradnik

Techniki, które zwiększają wiarygodność cyberataków: voice cloning, deepfake, multi-channel attacks

Phishing napędzany przez GenAI przestał ograniczać się do skrzynki mailowej: dziś obejmuje także dźwięk, obraz i skoordynowaną komunikację w wielu kanałach.

Voice cloning

Za pomocą narzędzi do klonowania głosu cyberprzestępcy mogą tworzyć realistyczne nagrania głosowe na podstawie zaledwie kilku sekund próbki – np. z mediów społecznościowych, webinarów czy nagrań wideo. Te syntetyczne głosy wykorzystywane są m.in. w atakach typu vishing (voice phishing), podczas których napastnik podszywa się pod członka zarządu lub dyrektora finansowego i wywiera presję, aby skłonić ofiarę do działania – np. przelania środków lub przekazania danych uwierzytelniających.

Posłuchaj, jak może brzmieć voice cloning tutaj.

Deepfake wideo

GenAI pozwala tworzyć realistyczne wideo, w których „występują” znane osoby. Przestępcy generują materiały, w których celebryci, CEO lub influencerzy „własnymi słowami” skłaniają do konkretnego działania. Ataki te są szczególnie skuteczne, ponieważ angażują jednocześnie wzrok i słuch, zwiększając wiarygodność przekazu.

Deepfake’i są również wykorzystywane do prób infiltracji organizacji podczas procesów rekrutacyjnych. Głośnym przypadkiem była sytuacja w firmie Arup, gdzie „kandydat” na stanowisko inżyniera okazał się wygenerowanym deepfake’iem. Na szczęście rekruter rozpoznał podstęp, ale gdyby atak zakończył się sukcesem, fałszywy pracownik mógłby uzyskać dostęp do systemów firmowych, danych klientów, a nawet wprowadzić ransomware. Więcej o tym przypadku w firmie Arup pisaliśmy na naszym LinkedInie.

Zgodnie z raportem IBM Cost of a Data Breach 2025, 16% wszystkich naruszeń danych było związanych z wykorzystaniem sztucznej inteligencji, z czego:

37% stanowiły AI-generated phishing
35% to incydenty z użyciem deepfake lub voice clone.

Oznacza to, że ponad 5% wszystkich globalnych naruszeń danych w 2025 roku miało bezpośredni związek z deepfake’ami lub syntetycznym głosem – i ta liczba bez wątpienia będzie rosnąć.

Multi-channel attacks

GenAI sprawia, że prowadzenie zautomatyzowanych i skoordynowanych kampanii phishingowych jest dziś znacznie prostsze oraz szybsze niż dotychczas. Cyberprzestępcy łączą wiele kanałów komunikacji – e-maile, SMS-y, połączenia telefoniczne, komunikatory firmowe i media społecznościowe – tworząc spójny, konsekwentny przekaz. Dzięki narzędziom AI, np. do klonowania głosu, te ataki są hiperrealistyczne i wywierają silną presję na odbiorcy, co podnosi ich skuteczność i utrudnia wykrycie podstępu przez systemy bezpieczeństwa.

15 kluczowych pytań dla CISO:
Oceń gotowość firmy na ataki wspierane AI

Odbierz bezpłatną listę pytań

Automatyczny rekonesans ofiar, który pozwala tworzyć hiperrealistyczne kampanie

Jedną z ogromnych przewag, jakie cyberprzestępcy zyskali dzięki generatywnej AI, jest automatyzacja rekonesansu, czyli etapu poprzedzającego atak, w którym zbierane są dane o potencjalnych ofiarach.

W przeszłości taki rekonesans wymagał żmudnej analizy ręcznej. Dziś, dzięki połączeniu LLM (Large Language Models) z narzędziami do OSINT, przestępcy mogą automatycznie przeszukiwać i analizować:

profile LinkedIn,
publikacje firmowe, raporty, prezentacje z konferencji,
wpisy w mediach społecznościowych (Twitter/X, Facebook),
ogłoszenia rekrutacyjne,
wpisy na forach, komentarze w kodzie i wewnętrzne dokumenty ujawnione publicznie.

Dla CISO oznacza to konieczność białego wywiadu (OSINT), czyli analizy:

jakie informacje firma (i jej pracownicy) nieświadomie udostępnia publicznie,
jak są zabezpieczane dane,
czy procedury analizy ryzyka uwzględniają wektory ataku oparte na OSINT + AI.

Inne cyberzagrożenia w dobie GenAI: Shadow AI, Shadow Agents i prompt injection

W miarę jak GenAI staje się coraz bardziej zintegrowana z codziennymi operacjami biznesowymi, pojawiają się nowe, złożone wektory ataku, które – bez odpowiednich procedur bezpieczeństwa – mogą wymknąć się poza kontrolę CISO.

Shadow AI

Shadow AI to zjawisko nieautoryzowanego wykorzystywania narzędzi i modeli sztucznej inteligencji przez pracowników – bez wiedzy działu IT czy zgody CISO. Prosty przykład: pracownik działu sprzedaży, który wkleja dane klientów do darmowego narzędzia AI, aby wygenerować ofertę. Właśnie tego typu działania niosą ze sobą ogromne ryzyko naruszeń prywatności, utraty kontroli nad danymi oraz złamania przepisów regulacyjnych (np. RODO).

Według IBM, aż 20% organizacji doświadczyło naruszenia danych związanego z Shadow AI, a incydenty te były średnio o 670 000 USD droższe niż ataki, które nie dotyczyły tego obszaru. Najczęściej kompromitowane były dane osobowe klientów – aż w 65% przypadków. To właśnie one są najbardziej łakomym kąskiem dla cyberprzestępców: można je sprzedać, wykorzystać do wyłudzeń, czy podszyć się pod ofiarę w kolejnych atakach. Co gorsza, 63% organizacji nie ma wdrożonych żadnych polityk zarządzania AI. Tutaj warto zatrzymać się i zastanowić, czy organizacja ma wdrożone odpowiednie procedury, które zminimalizują ryzyko Shadow AI? Jeśli nie, to już właściwie ostatni dzwonek, aby zaopiekować się tym obszarem.

Shadow Agents

W nadchodzących miesiącach problem Shadow AI może ustąpić miejsca jeszcze poważniejszemu zjawisku – Shadow Agents. Google Cloud prognozuje, że pracownicy coraz częściej będą samodzielnie wdrażać autonomiczne agenty AI, które podejmują decyzje i wykonują zadania biznesowe bez udziału człowieka. Brzmi wydajnie? Tak – ale też niebezpiecznie.

Takie agenty mogą działać poza kontrolą organizacji, przetwarzając dane klientów, projektów, infrastruktury. To ogromne zagrożenie, na które należy zbudować cyberodporność. Tutaj warto zwrócić uwagę, że zakaz korzystania z agentów AI to droga donikąd. Pracownicy, którzy zechcą usprawnić swoją pracę, mogą znaleźć sposób, aby korzystać z nich poza środowiskiem firmowym.

Zamiast tego, organizacje powinny wdrożyć Agentic Identity Management – nowy model IAM, który traktuje agentów AI jak cyfrowych użytkowników z własną tożsamością.

Dostęp powinien być przyznawany tymczasowo, w modelu just-in-time i zgodnie z zasadą najmniejszych uprawnień.
Agenci AI powinni mieć dostęp tylko wtedy, kiedy naprawdę go potrzebują – do konkretnych zadań i na określony czas.
System powinien na bieżąco oceniać, czy taki dostęp nadal ma sens, dopasowywać go do sytuacji, a także pozwalać jasno wskazać, kto za co odpowiada.

Takie podejście pozwoli ograniczyć ryzyko nadużyć i tzw. privilege creep, gdy agenci gromadzą coraz więcej uprawnień, które nie są im już potrzebne – często bez kontroli organizacji.

Prompt injection

Prompt injection to jedno z najnowszych zagrożeń dla organizacji korzystających z AI. Atak polega na przemyceniu złośliwego polecenia w prompcie (instrukcji tekstowej), który model AI potraktuje jako własne polecenie, ignorując zabezpieczenia, intencje użytkownika czy zasady działania. W efekcie model może np. ujawnić poufne dane, ominąć kontrolę dostępu, wykonać nieautoryzowane działania lub zaszkodzić organizacji w sposób trudny do wykrycia.

W praktyce może to wyglądać jak zwykła wiadomość e-mail z linkiem do czatu AI, gdzie niewinnie brzmiące pytanie zawiera ukryty kod, który poleca modelowi ujawnienie wrażliwych informacji.

Google Cloud Security ostrzega, że ataków tego typu będzie gwałtownie przybywać w 2026 roku, wraz z rosnącą dostępnością modeli AI i ich integracją z systemami biznesowymi. Prompt injection ma niską barierę wejścia i wysoką skuteczność, dlatego jest coraz bardziej atrakcyjnym narzędziem do masowego wycieku danych lub cichego sabotażu.

Choć phishing pozostaje jednym z najczęstszych cyberzagrożeń, to coraz częściej jest jednym z elementów bardziej złożonych kampanii wspieranych sztuczną inteligencją. Cyberprzestępcy dysponują dziś całym wachlarzem narzędzi: od voice cloningu i deepfake’ów, przez autonomiczne agenty, aż po ataki typu prompt injection.

To wymaga zmian w strategii bezpieczeństwa organizacji: klasyczne filtry i procedury przestają wystarczać, zwłaszcza gdy zagrożenia rodzą się wewnątrz organizacji, jak w przypadku Shadow AI.

Właśnie dlatego w drugim i trzecim webinarze z cyklu „AI vs Cybersecurity” skupimy się na tych mniej oczywistych, ale krytycznych wektorach ataku. Uczestnicy:

przekonają się, jak przebiegały realne incydenty typu Shadow AI i jak może wyglądać manipulacja modelami językowymi,
otrzymają konkretne zasady i procesy, które pozwalają bezpiecznie korzystać z AI,
dowiedzą się, jak zaprojektować środowisko odporne na nadużycia agentów AI i LLM-ów,
dostaną gotowe scenariusze obronne, które realnie minimalizują ryzyko sabotażu i wycieku danych.

Bezpłatny cykl webinarów dla CISO:
Jak włączyć AI w strategię bezpieczeństwa organizacji?

Rezerwuję swoje miejsce!

Rekomendacje dla CISO – jak budować odporność organizacji na ataki wspierane GenAI

Praktyczna edukacja pracowników i regularne testowanie odporności organizacji

Nawet najlepiej zaprojektowana infrastruktura nie powstrzyma pracownika, który bezrefleksyjnie kliknie w złośliwy link. Dlatego tak ważne jest zwiększanie świadomości bezpieczeństwa pracowników i kształtowanie trwałych cybernawyków, które będą chronić zarówno ich samych, jak i całą organizację.

Zamiast teoretycznych szkoleń z cyberbezpieczeństwa, warto rozważyć Praktyczny Trening Antyphishingowy, oparty na realistycznych symulacjach cyberataków. Pracownicy otrzymują wiadomości dopasowane do swojej roli, branży i kontekstu – dokładnie takie, jakie mogą spotkać w codziennej pracy. Jeśli ktoś da się złapać na podstęp, natychmiast otrzymuje krótkie nanoszkolenie, które wyjaśnia, dlaczego wiadomość była niebezpieczna, jakie mogły być konsekwencje i jak rozpoznać podobne zagrożenie w przyszłości.

Dzięki temu z czasem klikalność w phishing wyraźnie spada, a liczba zgłoszonych wiadomości rośnie, co widać w czytelnych, ale dokładnych statystykach prezentowanych w dashboardzie platformy treningowej SECAWA oraz automatycznie generowanych raportach.

Możesz sprawdzić reakcję zespołu na cyberataki bez kosztów i zobowiązań, a przy tym przetestować naszą platformę treningową do symulacji phishingu. Wystarczy, że umówisz się na Bezpłatny Test Phishingowy, w ramach którego wyślemy realistyczną symulację phishingu do wybranej grupy pracowników. Podczas Bezpłatnego Testu Phishingowego będziesz mógł obserwować statystyki w dashobardzie platformy, a na koniec przygotujemy dla Ciebie raport z wynikami testu. Kliknij tutaj, aby dowiedzieć się więcej!

Zasada ograniczonych uprawnień wobec ludzi i systemów AI

Nie wystarczy traktować LLM-a jako narzędzia. Potrzebujemy jasnego przypisania „tożsamości” dla każdego modelu, agenta czy plugina – wraz z zakresem jego uprawnień. To oznacza:

dostęp tylko do konkretnych danych, aplikacji i API, potrzebnych do wykonania zadania,
czasowe uprawnienia (ograniczone do momentu wykonania działania),
rejestrowanie aktywności: kto, co, kiedy i w jakim celu uruchomił,
monitorowanie funkcji: jakie prompty, jakie odpowiedzi, jaka logika działania.

Tak samo, jak ograniczamy dostęp ludziom, musimy to samo robić wobec AI, aby zminimalizować ryzyko nadużyć, błędów, a nawet przejęć.

Wyznacz jasne zasady korzystania z AI

Nie każda próba „ułatwienia pracy” z AI jest niebezpieczna, ale bez wyraźnych reguł firma naraża się na wycieki danych. Dlatego, jako CISO:

Ustal jasne zasady: które narzędzia są dopuszczone, jakich danych nie wolno używać, w jakich przypadkach AI może, a gdzie nie może wspierać.
Daj alternatywę: stwórz bezpieczne środowisko dla pracy z AI.
Wprowadź kontrolę i monitoring: abyś wiedział, kiedy dochodzi do nieautoryzowanego użycia, wycieku danych lub naruszenia zasad.

Zabezpiecz modele i agentów AI przed przejęciem lub manipulacją

Osoby odpowiedzialne za bezpieczeństwo organizacji powinny zabezpieczyć modele AI podobnie, jak zabezpiecza się infrastrukturę krytyczną – kontrolować dane wejściowe, izolować środowiska, testować podatności i chronić interfejsy API, zwłaszcza jeśli model ma dostęp do danych firmowych.

Wzmocnij podstawy bezpieczeństwa

Nowe wektory zagrożeń nie oznaczają, że podstawowe zasady bezpieczeństwa schodzą na dalszy plan. Wręcz przeciwnie, strategia cyberbezpieczeństwa organizacji powinna łączyć kilka niezależnych warstw ochrony, które wzajemnie się uzupełniają i kompensują luki w pojedynczych rozwiązaniach. Należy wzmacniać zabezpieczenia technologiczne, doskonalić procedury bezpieczeństwa i rozwijać świadomość bezpieczeństwa pracowników.

Atak JadePuffer w skrócie

Czym jest ransomware?

JadePuffer – pierwszy atak ransomware w pełni sterowany przez LLM

Jak przebiegał atak JadePuffer krok po kroku

Faza 1 – host wejściowy (Langflow)

Faza 2 – cel właściwy (serwer produkcyjny MySQL i Alibaba Nacos)

Cztery dowody, że atakiem sterował LLM, nie człowiek

Konsekwencje dla organizacji – dlaczego to sygnał alarmowy dla CISO, CTO, CSO i CIO

JadePuffer nie jest odosobnionym sygnałem, że modele językowe da się skierować przeciwko organizacji

Bezpłatny cykl webinarów: ataki wspierane AI, Shadow AI, ataki na AI (prompt injection) i AI jako wsparcie CISO. 4 spotkania, dodatkowe materiały i kilku specjalistów SECAWA, którzy szczegółowo rozłożyli temat AI w kontekście cyberbezpieczeństwa.

Jak zabezpieczyć organizację przed ransomware sterowanym przez AI?

Podsumowanie

Jak czat z Meta AI pozwolił przejąć konta na Instagramie?

Na czym polegała luka w chatbocie Meta AI?

Jak wyglądał atak na czat z Meta AI krok po kroku?

Czego ten atak uczy o bezpieczeństwie agentów AI?

Dlaczego chatbot to nowa powierzchnia cyberataków?

Prompt injection a bezpieczeństwo systemów AI. Jak modelować zagrożenia?

Jak chronić konto na Instagramie przed przejęciem przez hakerów?

Jak chronić organizację przed atakami na AI?

Uzyskaj dostęp do nagrań i materiałów z bezpłatnego cyklu webinarów AI vs Cybersecurity

Jak przebiega komunikacja z LLM (Large Language Model)?

Wiadomości i kontekst modelu językowego

Pytanie-odpowiedź

Konwersacja

RAG

Użycie narzędzi

Czym jest prompt injection?

Skutki prompt injection

Jak modelować zagrożenia w systemach AI?

01 Dane wejściowe

02 Kontekst

03 RAG

04 Narzędzia i integracje

05 Uprawnienia

06 Wyjście modelu językowego

07 Telemetria i kontrola

7 pytań, od których CISO powinien zacząć ocenę ryzyka systemów AI

Co może wejść do systemu?

Co trafia do kontekstu modelu?

Jakie źródła wiedzy wzbogacają odpowiedź?

Jakie narzędzia może wywołać model?

Na czyich uprawnieniach działa system?

Co wychodzi z modelu i gdzie trafia dalej?

Jak organizacja to loguje, kontroluje i testuje?

Podsumowanie

Przetestuj zabezpieczenia systemów za pomocą kontrolowanych cyberataków

Co to jest prompt injection? Definicja

Różnica między prompt injection a jailbreaking

Typy prompt injection

Direct prompt injection

Indirect prompt injection

Podsumowanie różnic między direct prompt injection a indirect prompt injection

Jakie skutki może mieć atak prompt injection dla organizacji?

Wyciek danych (data exfiltration)

Manipulacja treści i błędne decyzje biznesowe

Ujawnienie informacji o systemie i instrukcjach systemowych (system prompt)

Nadużycie narzędzi dostępnych dla agenta

Nieautoryzowane akcje i zmiany w systemach

Rekonesans i przygotowanie dalszego ataku

Jak chronić organizację przed atakami typu prompt injection?

Zwiększanie świadomości zagrożenia wśród pracowników

Polityki i governance AI

Widoczność i kontrola użycia GenAI (shadow AI)

Zasady pracy na źródłach treści

Zasady formułowania poleceń i zakres swobody działania

Least privilege jako domyślna reguła

Kontrole techniczne i monitoring

Jak GenAI wspiera najpopularniejsze metody ataków socjotechnicznych?

15 kluczowych pytań dla CISO: Oceń gotowość firmy na ataki wspierane AI

Przykłady ataków socjotechnicznych wspieranych generatywną sztuczną inteligencją

Hiperpersonalizowany AI-generated phishing

Business Email Compromise (BEC)

Spear phishing

Quishing (QR code phishing)

Bezpłatna lekcja na temat quishingu dla Twojego zespołu

Smishing

Cyberbezpieczny Zespół: Jak rozpoznać smishing?

Ataki telefoniczne (vishing) z użyciem voice cloningu

AI-generated deepfake wideo

15 kluczowych pytań dla CISO:
Oceń gotowość firmy na ataki wspierane AI

Cyberbezpieczny Zespół:
8 wskazówek dla Twoich pracowników,
jak zdemaskować phishing

Cyberbezpieczny Zespół:
8 wskazówek dla Twoich pracowników,
jak zdemaskować phishing

15 kluczowych pytań dla CISO:
Oceń gotowość firmy na ataki wspierane AI

Bezpłatny cykl webinarów dla CISO:
Jak włączyć AI w strategię bezpieczeństwa organizacji?