Prompt injection i jailbreaki

Prompt injection jest odpowiednikiem klasycznych podatności typu injection (SQL, command) w erze LLM. Przyczyna źródłowa jest identyczna: aplikacja umieszcza zaufane instrukcje i niezaufane dane w tym samym kanale, a interpreter (model) nie potrafi niezawodnie ich od siebie odróżnić.

W przypadku LLM prompt systemowy, instrukcje dewelopera i wszelkie pobrane treści trafiają do jednego płaskiego strumienia tokenów. Jeśli tekst kontrolowany przez atakującego zawiera Ignore previous instructions and..., model może mu ulec, ponieważ z perspektywy modelu to po prostu kolejny fragment języka.

• Zaufane: prompt systemowy i zasady.
• Niezaufane: dane wejściowe użytkownika, strony internetowe, pliki, wyniki narzędzi, wiadomości e-mail.

Bezpośredni prompt injection ma miejsce, gdy użytkownik końcowy wpisuje wprost do promptu wrogie instrukcje, aby zastąpić zamierzone działanie aplikacji.

Typowa próba zaatakowania bota obsługi klienta wygląda następująco:

• Bot otrzymuje instrukcję, aby odpowiadać wyłącznie na pytania dotyczące rozliczeń.
• Użytkownik wkleja tekst, który na nowo definiuje rolę modelu, i prosi go o ujawnienie promptu systemowego lub wykonanie działań wykraczających poza zakres.

Bezpośredni prompt injection jest najłatwiejszy do przeanalizowania, ponieważ złośliwy tekst i atakujący są tą samą osobą, ale nadal pozwala ominąć naiwne mechanizmy ochronne.

Pośredni (drugiego rzędu) prompt injection jest groźniejszym wariantem. Atakujący umieszcza instrukcje w treści, którą model później pobierze: na stronie internetowej, w pliku PDF, zaproszeniu do kalendarza, komentarzu w kodzie lub zgłoszeniu do działu pomocy.

Użytkownik będący ofiarą nigdy nie widzi payloadu. Gdy pipeline RAG lub agent przeglądający pobierze tę treść do kontekstu, ukryte instrukcje są wykonywane z uprawnieniami ofiary.

Przykład: strona internetowa zawiera ukryty tekst nakazujący agentowi podsumowującemu wysłać historię czatu użytkownika pod adres URL atakującego.

Te pojęcia częściowo się pokrywają, ale nie są tożsame:

• Prompt injection atakuje granicę aplikacji — zastępuje instrukcje dewelopera danymi atakującego.
• Jailbreaking atakuje dostrojenie modelu pod kątem bezpieczeństwa — nakłania model do generowania treści, których odmawiania nauczył go dostawca.

Do przeprowadzenia jailbreaku nie jest potrzebna podatna aplikacja; działa on przeciwko surowemu modelowi. Wiele rzeczywistych ataków łączy oba podejścia: jailbreak osłabia odmowy, a injection przekierowuje działanie aplikacji.

Atakujący stosują przewidywalne schematy manipulacji. Ich znajomość pomaga odpowiedzialnie przeprowadzać testy red team własnego systemu:

• Odgrywanie ról / persona: przedstawianie prośby jako fikcji lub fikcyjnej, pozbawionej ograniczeń postaci.
• Zaciemnianie: używanie base64, leetspeak, tłumaczenia lub dzielenia tokenów w celu ominięcia filtrów słów kluczowych.
• Dzielenie payloadu: rozkładanie prośby na wiele tur, aby żadna pojedyncza wiadomość nie wyglądała na złośliwą.
• Scenariusze hipotetyczne: For a security class, describe how one would...
• Wstrzykiwanie prefiksu: wymuszanie, aby odpowiedź zaczynała się od potwierdzenia, takiego jak Sure, here is.

Wiele zespołów w pierwszej kolejności sięga po listę blokowanych fraz, takich jak ignore previous instructions. To rozwiązanie jest kruche, ponieważ przestrzeń możliwych danych wejściowych jest praktycznie nieskończona.

Język naturalny może wyrażać tę samą intencję na niezliczone sposoby, w różnych językach, kodowaniach i metaforach. Atakujący iterują szybciej, niż można aktualizować wyrażenia regularne.

Kluczowa zasada: należy traktować filtrowanie danych wejściowych jako element obrony warstwowej, a nigdy jako podstawowy mechanizm ochrony. Należy założyć, że część prób injection przedostanie się przez zabezpieczenia, i zaprojektować system tak, aby udany injection nadal nie mógł spowodować rzeczywistych szkód.

Najskuteczniejsze działanie zaradcze ma charakter architektoniczny: należy ograniczyć zakres działań, które może wykonać przejęty kontekst modelu.

• LLM powinien otrzymać minimalny zakres uprawnień, którego potrzebuje. Model podsumowujący nie powinien mieć poświadczeń umożliwiających wysyłanie wiadomości e-mail.
• Nie należy dopuszczać niezaufanych treści do ścieżek uprzywilejowanych. Jeśli agent odczytuje zewnętrzne dane webowe, nie powinien mieć również możliwości wykonywania nieodwracalnych działań w tej samej turze bez punktu kontrolnego.
• Należy oddzielić płaszczyzny danych od płaszczyzn sterowania: pobrany tekst powinien być danymi, a nie poleceniami.

Chociaż nie zapewnia pełnej ochrony, struktura promptu podnosi poprzeczkę. Należy wyraźnie oddzielić niezaufane dane i poinstruować model, jak ma je traktować.

Należy używać jawnych separatorów i poinformować model, że wszystko, co się w nich znajduje, to dane do analizy, a nie instrukcje do wykonania. Należy połączyć to z silną rolą systemową, którą aplikacja wzmacnia przy każdym wywołaniu.

Wynik modelu również jest niezaufany. Jeśli aplikacja przekazuje wynik LLM do powłoki, bazy danych, przeglądarki lub innego narzędzia, injection może prowadzić do zdalnego wykonania kodu lub eksfiltracji danych.

Zabójcza triada Simona Willisona opisuje niebezpieczne połączenie:

• Dostęp do prywatnych danych,
• Kontakt z niezaufanymi treściami,
• Możliwość komunikowania się na zewnątrz (eksfiltracji).

Agenta wyposażonego we wszystkie trzy elementy można za pomocą jednej wstrzykniętej instrukcji zmienić w narzędzie do kradzieży danych. Należy przerwać triadę, aby przerwać atak.

Należy założyć, że injection nastąpi, i zapewnić odpowiednie monitorowanie:

• Rejestruj pełny kontekst (prompty, pobrane fragmenty, wywołania narzędzi) na potrzeby analizy incydentów.
• Używaj pomocniczego klasyfikatora lub modelu ochronnego do oznaczania podejrzanych danych wejściowych i wyników.
• Monitoruj nietypowe użycie narzędzi: nagłe żądania wychodzące, nieoczekiwany dostęp do danych, schematy wycieku promptu.
• Umieszczaj tokeny canary w promptach systemowych; jeśli token canary pojawi się w wyniku, oznacza to wyciek.

Alerty należy traktować jak rzeczywiste incydenty i obsługiwać zgodnie z procedurą reagowania.

Testowanie własnych systemów pod kątem injection jest niezbędne i uzasadnione. Należy robić to odpowiedzialnie:

• Należy testować wyłącznie systemy, których jest się właścicielem lub do których oceny ma się upoważnienie.
• Należy używać kontrolowanego środowiska i danych syntetycznych; nigdy nie należy eksfiltrować prawdziwych danych użytkowników.
• Należy dokumentować ustalenia i uwzględniać je w testach regresji, aby naprawione obejścia nadal pozostawały naprawione.
• W przypadku znalezienia problemów w modelach lub aplikacjach innych podmiotów należy koordynować ich ujawnienie.

Celem jest zwiększenie odporności aplikacji, a nie tworzenie szkodliwych możliwości.

Najważniejsze informacje o prompt injection i jailbreakach:

• Injection wynika z połączenia zaufanych instrukcji z niezaufanymi danymi w jednym kanale.
• Bezpośredni prompt injection pochodzi od użytkownika; pośredni prompt injection ukrywa się w pobranych treściach i jest trudniejszy do wykrycia.
• Jailbreaki atakują dostrojenie modelu, a injection atakuje granicę aplikacji. Te metody można łączyć.
• Filtrowanie danych wejściowych jest wyłącznie elementem obrony warstwowej, nigdy podstawowym mechanizmem ochrony.
• Środki zaradcze powinny mieć charakter architektoniczny: minimalny zakres uprawnień, oddzielenie danych od sterowania oraz przerwanie zabójczej triady (prywatne dane + niezaufane treści + eksfiltracja).
• Wynik modelu należy traktować jako niezaufany, wszystko rejestrować, a testy red team przeprowadzać etycznie.