Prompt Injection

Definicja Prompt Injection

Prompt injection (wstrzyknięcie polecenia) to klasa podatności systemów opartych na modelach językowych, w której treść dostarczona jako dane wejściowe zostaje przez model potraktowana jak polecenie od operatora systemu. Mechanizm wynika z samej natury modelu językowego - w przeciwieństwie do klasycznej aplikacji, model nie oddziela architektonicznie instrukcji od danych. Oba trafiają do niego jako jeden ciąg tekstu, a to, co jest poleceniem, a co treścią do przetworzenia, model wywnioskuje z kontekstu, nie z twardej granicy w kodzie.

Nazwa nawiązuje do klasycznych podatności iniekcyjnych, ale mechanizm jest inny - opisuje to szerzej sekcja W szerszym kontekście niżej. Dla zespołów budujących systemy z modelami językowymi jest to dziś jedna z podstawowych kategorii ryzyka do zaadresowania już na etapie projektowania architektury, nie dopiero po incydencie.

Jak to działa

Działanie modelu językowego opiera się na przewidywaniu kolejnych fragmentów tekstu na podstawie całego dostarczonego kontekstu - polecenia systemowego od operatora, historii rozmowy i danych, które model ma przetworzyć. Wszystkie te elementy trafiają do modelu jako jeden, nieoddzielony strumień tokenów.

Klasyczna aplikacja ma twardą granicę między kodem wykonywalnym a danymi - wynika ona z architektury silnika, na przykład z zapytań przygotowanych w bazie danych, które oddzielają polecenie SQL od wartości. Model językowy takiej granicy nie ma z definicji, nie z powodu błędu implementacyjnego. To, co jest instrukcją, a co treścią do analizy, model wywnioskuje wyłącznie ze wzorców językowych - a wzorzec da się odtworzyć w cudzej treści.

Stąd wynika mechanizm ataku: jeśli treść wejściowa zawiera fragment sformułowany jak polecenie, na przykład żądanie zignorowania poprzednich instrukcji, model może potraktować go jako realne polecenie operatora, nie jako element danych do opisania czy podsumowania. Skuteczność takiej próby zależy od konkretnego modelu, sposobu przygotowania polecenia systemowego i dodatkowych zabezpieczeń wdrożonych wokół niego - to nie jest gwarantowany efekt każdej próby.

Struktura i klasyfikacja

Prompt injection klasyfikuje się wzdłuż trzech niezależnych osi, które razem opisują, skąd pochodzi zagrożenie i jak poważne mogą być jego skutki.

Pierwsza oś to źródło polecenia:

• Bezpośredni prompt injection - użytkownik systemu sam wpisuje polecenie mające na celu zmianę zachowania modelu, na przykład próbę pominięcia zasad ustalonych przez operatora aplikacji. Atakujący i osoba korzystająca z systemu to ta sama osoba.
• Pośredni prompt injection - polecenie nie pochodzi od użytkownika, tylko z zewnętrznego źródła, które model przetwarza w ramach swojego zadania. Użytkownik nie widzi wstrzykniętej instrukcji i nie musi mieć złych intencji - to system, wczytując cudzą treść jako dane, sam naraża się na polecenie ukryte w tej treści. Ten wariant jest z perspektywy obrony trudniejszy i ważniejszy dla firm wdrażających systemy AI, bo źródłem ataku nie jest interfejs możliwy do ograniczenia czy zwalidowania w prosty sposób, tylko dowolna treść, jaką model odczytuje w toku działania - często treść, nad którą organizacja nie ma żadnej kontroli.

Druga oś to źródło treści przy wariancie pośrednim - dokument wczytany przez system, strona internetowa, treść wiadomości e-mail, wynik wyszukiwania albo odpowiedź z zewnętrznego API. Każde z tych źródeł ma inny poziom kontroli organizacji nad tym, co się w nim znajdzie - dokument wewnętrzny jest zaufany bardziej niż wynik wyszukiwania z otwartego internetu, ale mechanizm podatności jest identyczny niezależnie od źródła.

Trzecia oś to zdolność modelu do działania, nie tylko rozmowy - i to ona decyduje o realnej wadze konsekwencji udanego ataku.

Model, który jedynie odpowiada na pytania, przy udanym wstrzyknięciu najwyżej wygeneruje niepożądany tekst. Model podłączony do narzędzi - wysyłający e-maile, wykonujący zapytania do bazy danych, sięgający po pliki czy API - przy udanym wstrzyknięciu może wykonać te same akcje na polecenie atakującego, ukryte w treści, którą właśnie przetwarza. W pełni autonomiczny agent, działający seriami kroków bez potwierdzenia człowieka przy każdym z nich, niesie największe ryzyko - pojedyncze udane wstrzyknięcie może uruchomić cały łańcuch dalszych akcji, zanim ktokolwiek zdąży zareagować. To ta sama różnica, jaka dzieli klasyczny SIEM korelujący logi od SOAR wykonującego akcje automatycznie - im więcej systemu podłączonego pod decyzję, tym poważniejsza konsekwencja błędnej decyzji.

W szerszym kontekście

Prompt injection nie jest wariantem klasycznych podatności iniekcyjnych typu SQL injection, mimo podobnej nazwy. W bazie danych granica między kodem a danymi istnieje w silniku i da się ją egzekwować składnią. W modelu językowym takiej twardej granicy nie ma z założenia, więc obrona przenosi się z warstwy walidacji wejścia na warstwę uprawnień i nadzoru nad akcjami systemu, opisaną w sekcji Zastosowanie w praktyce niżej.

Środowisko threat intelligence zaczyna traktować techniki prompt injection jako osobną kategorię taktyk, technik i procedur do katalogowania i wymiany między organizacjami, na tej samej zasadzie co inne znane wektory ataku śledzone przez CTI. To wciąż formująca się praktyka, nie ustandaryzowana tak dojrzale jak katalogi podatności klasycznych aplikacji.

Organizacje wdrażające agentów AI w środowiskach chmurowych traktują tę klasę ryzyka jako element szerszego audytu bezpieczeństwa chmury - konfiguracja uprawnień, jakie taki agent dostaje, decyduje bezpośrednio o tym, jak daleko sięgają skutki udanego wstrzyknięcia. Narzędzia CSPM monitorujące stan konfiguracji chmury są tu jednym z elementów układanki, nie samodzielnym rozwiązaniem - wykryją nadmiarowe uprawnienia agenta, ale nie samą próbę wstrzyknięcia w przetwarzanej treści.

Zastosowanie w praktyce

Mechanizmu nie da się wyeliminować pojedynczym filtrem, bo granica między poleceniem a danymi jest w modelu językowym płynna z definicji, nie efektem błędu do załatania. Praktyki ograniczające ryzyko obejmują:

• Rozdzielenie uprawnień modelu od uprawnień użytkownika - model nie powinien mieć w systemach więcej praw, niż ma osoba, w imieniu której działa.
• Potwierdzenie człowieka przed akcjami nieodwracalnymi - wysyłka wiadomości, usunięcie danych czy transakcja finansowa powinny wymagać zatwierdzenia, niezależnie od tego, jak pewny siebie jest model.
• Traktowanie treści zewnętrznej jako potencjalnie wrogiej - analogicznie do tego, jak traktuje się dane wejściowe w klasycznym bezpieczeństwie aplikacji, każdy dokument, e-mail czy wynik wyszukiwania wczytywany przez system powinien być domyślnie nieufny.
• Monitorowanie po stronie SOC - blue team powinien umieć rozpoznać wzorzec udanego wstrzyknięcia w logach systemu, zamiast polegać wyłącznie na prewencji przed samym atakiem.

Audyt obejmujący agentów AI działających w środowisku chmurowym sprawdza dokładnie tę granicę: co model może zrobić po przeczytaniu treści, której nie napisał nikt z organizacji. Usługi w tym zakresie znajdziesz w kategorii Bezpieczeństwo Chmury.

Najczęstsze nieporozumienia

FAQ

Powiązane pojęcia