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. |
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. |
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.
