Wstrzykiwanie promptu (OWASP LLM01) - bezpośrednie i pośrednie wektory ataku na LLM

W skrócie: LLM01 Prompt Injection to pierwsza pozycja listy OWASP dla aplikacji LLM - nie przez przypadek. To fundamentalny mechanizm, z którego wynika spora część pozostałych kategorii na tej liście. Wstrzykiwanie bezpośrednie dzieje się wtedy, gdy to sam użytkownik próbuje zmienić zachowanie modelu. Wstrzykiwanie pośrednie jest groźniejsze - instrukcja trafia do modelu ukryta w treści, którą model dopiero przetwarza: stronie internetowej, mailu, dokumencie, obrazku.

Żaden filtr wejścia nie rozwiąże tego do końca, bo problem leży w architekturze: model nie ma wbudowanego sposobu, żeby odróżnić instrukcję od danych.

To szósty wpis z serii o liście OWASP dla aplikacji LLM, po wycieku promptu systemowego, bezpieczeństwie RAG, nadmiernej sprawczości agentów, niezaufanych odpowiedziach modelu i zatruwaniu danych. Wracamy teraz do pozycji numer jeden, którą ogólny wpis o testach LLM pokrywał tylko jednym akapitem.

Dlaczego to pozycja numer jeden

Prompt injection nie jest jedną podatnością - to brama do wielu innych. Model, który da się nakłonić do zignorowania swoich instrukcji, może też zdradzić treść promptu systemowego, wykonać akcję, do której nie powinien mieć dostępu (nadmierna sprawczość), albo wygenerować treść, która trafi dalej bez kontroli (niebezpieczna obsługa odpowiedzi). Dlatego OWASP stawia tę kategorię na pierwszym miejscu - to nie jest "jeszcze jeden punkt na liście", tylko mechanizm, który otwiera drzwi do reszty.

Przyczyna jest architektoniczna. Model językowy przetwarza jeden ciąg tokenów - instrukcja systemowa, polecenie użytkownika i dowolna treść, którą model akurat czyta, trafiają do tego samego okna kontekstowego. Model nie widzi metadanych w stylu "to jest zaufana instrukcja, a to niezaufane dane". Widzi tekst. Dokładnie ten sam mechanizm stoi za wyciekiem promptu systemowego - różnica jest tylko w tym, co atakujący chce osiągnąć: tam wydobycie treści instrukcji, tutaj zmianę zachowania modelu.

Wstrzykiwanie bezpośrednie

Najprostszy wariant - użytkownik sam pisze polecenie, które ma zmienić zachowanie modelu wbrew instrukcjom aplikacji. Czasem to świadoma próba obejścia ograniczeń, czasem przypadkowy efekt niewinnie wyglądającego polecenia, które akurat koliduje z systemowymi regułami. Chatbot sklepowy, który zaczyna polecać produkty konkurencji, albo asystent HR, który pod wpływem jednego zdania w rozmowie zaczyna ujawniać dane innych kandydatów - to typowe przykłady z tej kategorii.

Wstrzykiwanie pośrednie - groźniejszy wariant

Pośrednie wstrzykiwanie dzieje się wtedy, gdy model przyjmuje dane z zewnętrznego źródła - strony internetowej, dokumentu, maila, pliku - i to źródło zawiera ukrytą instrukcję. Użytkownik nie musi nic robić poza zwyczajnym korzystaniem z asystenta. To właśnie czyni ten wariant trudniejszym do wyłapania: atak nie przychodzi od osoby wchodzącej w interakcję z modelem, tylko z treści, którą model dopiero przetworzy.

Wektor	Jak to działa
Ukryte instrukcje na stronie internetowej	Agent przeglądający sieć napotyka tekst niewidoczny dla człowieka (np. biały na białym), ale czytelny dla modelu
Dokument w bazie RAG	Ktoś modyfikuje plik w repozytorium, z którego model czerpie kontekst, dopisując instrukcję do treści
Treść maila	Asystent czytający skrzynkę napotyka wiadomość z poleceniem przekierowania danych albo wykonania akcji
CV w systemie rekrutacyjnym	Instrukcja rozbita na fragmenty w dokumencie, żeby ominąć proste filtry szukające całych fraz
Obraz w modelu multimodalnym	Tekst wbudowany w grafikę, niewidoczny na pierwszy rzut oka, ale odczytywany przez model
Ciąg znaków adwersarialnych	Pozornie bezsensowny sufiks, który statystycznie zwiększa szansę na zignorowanie ograniczeń modelu
Inny język lub kodowanie	Instrukcja zapisana w języku, którego filtr nie obsługuje, albo zakodowana (base64, ROT13)

Czym to się różni od jailbreakingu

Te dwa pojęcia często się mylą, bo w praktyce bywają połączone. Jailbreaking to próba nakłonienia modelu do zignorowania jego wbudowanych ograniczeń bezpieczeństwa (tych z treningu, nie z promptu aplikacji) - zwykle robi to sam użytkownik, wprost. Prompt injection to szersze pojęcie: manipulacja zachowaniem aplikacji przez dowolną treść, którą model przetwarza, niekoniecznie w celu złamania filtrów bezpieczeństwa modelu. Można wstrzyknąć instrukcję, która nie łamie żadnej reguły etycznej modelu, a mimo to każe mu wykonać akcję szkodliwą dla konkretnej aplikacji - na przykład ujawnić dane innego użytkownika. Jailbreak bywa narzędziem do przeprowadzenia wstrzyknięcia, ale nie każde wstrzyknięcie jest jailbreakiem.

Dlaczego walidacja wejścia nie wystarcza

Intuicyjna odpowiedź - "filtrujmy podejrzane słowa na wejściu" - rozbija się o tę samą ścianę co przy wycieku promptu. Filtr oparty na dopasowywaniu fraz da się obejść parafrazą, innym językiem, podziałem instrukcji na fragmenty albo zakodowaniem. A przy wstrzykiwaniu pośrednim problem jest jeszcze głębszy: aplikacja często nie kontroluje treści źródłowej. Nie da się "zwalidować" całego internetu, zanim agent go przeczyta.

Dlatego skuteczna obrona nie polega na jednym filtrze, tylko na kilku niezależnych warstwach, z których żadna nie musi być idealna sama w sobie.

Warstwy obrony

Ograniczenie zachowania modelu - precyzyjny system prompt, który jasno definiuje rolę i granice możliwych działań, zamiast ogólnego "bądź pomocny".
Walidacja formatu wyjścia - wymuszanie struktury odpowiedzi i, gdzie to możliwe, cytowania źródeł, co utrudnia ukrycie wstrzykniętej treści w swobodnym tekście.
Filtrowanie wejścia i wyjścia - metody semantyczne i tekstowe, świadomie traktowane jako jedna z wielu warstw, nie jako jedyne zabezpieczenie.
Najmniejsze uprawnienia - tokeny API i dostęp do narzędzi ograniczone do minimum potrzebnego do zadania. To ten sam temat co przy nadmiernej sprawczości agentów.
Zatwierdzenie człowieka dla akcji wysokiego ryzyka - przelew, wysyłka maila, zmiana uprawnień: żadna z tych rzeczy nie powinna dziać się automatycznie na podstawie samej decyzji modelu.
Segregacja treści zewnętrznej - traktowanie danych z internetu, dokumentów i maili jako danych, nie jako instrukcji, na poziomie architektury aplikacji, nie tylko promptu.
Regularne testy adwersarialne - symulacja prób wstrzyknięcia na bieżąco, nie tylko przy wdrożeniu.

Co sprawdzamy w teście

Przy testach penetracyjnych aplikacji LLM w kontekście LLM01 sprawdzamy między innymi:

Czy bezpośrednie polecenia zmieniające rolę modelu (różnymi sformułowaniami, w różnych językach) przechodzą przez system prompt.
Czy treść osadzona w dokumentach, stronach i plikach, które aplikacja podaje modelowi, może zmienić jego zachowanie.
Czy agent z dostępem do narzędzi (mail, przeglądarka, baza danych) wykonuje akcje na podstawie treści przetwarzanej, a nie wprost zleconej przez użytkownika.
Czy akcje wysokiego ryzyka wymagają potwierdzenia poza modelem, czy wystarczy jedna udana manipulacja.
Czy filtr wyjścia (jeśli istnieje) łapie próby zakodowane, podzielone na fragmenty albo sformułowane w innym języku.

Czego to nie załatwi

Żadna kombinacja filtrów nie da stuprocentowej pewności, że żadna parafraza, żadne kodowanie i żaden nowy wariant ataku się nie przebije. To jest powód, dla którego OWASP stawia na obronę warstwową, a nie na jeden skuteczny mechanizm. Cel nie jest taki, żeby wstrzyknięcie było niemożliwe - cel jest taki, żeby nawet udane wstrzyknięcie nie dawało modelowi możliwości zrobienia czegoś nieodwracalnego. To już nie jest kwestia samego promptu, tylko architektury wokół niego - ograniczonych uprawnień, zatwierdzeń człowieka i segregacji treści, o których pisaliśmy przy nadmiernej sprawczości agentów.