Traktuj treści od użytkowników, z dokumentów i ze stron internetowych jako niezaufane dane. Autorytet poleceń ustalaj poza modelem, ograniczaj źródła i narzędzia, argumenty waliduj i autoryzuj na serwerze, wrażliwe działania potwierdzaj, a sekretów w ogóle nie udostępniaj modelowi. Na bieżąco testuj ataki bezpośrednie i pośrednie oraz monitoruj nietypowe wywołania.
Prompt injection występuje, gdy niezaufana treść próbuje zmienić zachowanie modelu, ujawnić informacje lub wywołać niedozwoloną akcję. Instrukcję może wpisać użytkownik bezpośrednio albo może być ona ukryta na stronie internetowej, w dokumencie, e-mailu lub wyniku narzędzia. Model językowy przetwarza wszystko jako tekst, dlatego samo zdanie „ignoruj obce instrukcje” nie stanowi pełnej ochrony.
Bezpieczeństwo opiera się na architekturze otaczającej model. System oddziela instrukcje od danych, minimalizuje wczytywany kontekst, egzekwuje uprawnienia po stronie serwera i ogranicza narzędzia w zależności od ryzyka. Wrażliwa akcja wymaga walidacji i potwierdzenia. Testy obejmują łączenie wielu niewinnych kroków, ponieważ atak nie musi się powieść jednym rzucającym się w oczy zdaniem.
Zmapuj bezpośrednie i pośrednie ścieżki wejścia
Bezpośredni atak pojawia się w pytaniu, czacie lub polu formularza. Pośredni może znajdować się w dokumencie wczytanym przez RAG, treści e-maila, stronie HTML, nazwie pliku lub odpowiedzi zewnętrznego API. Spisz wszystkie miejsca, z których model pobiera tekst, i określ ich właściciela oraz poziom zaufania. Wewnętrzne repozytorium nie jest automatycznie zabezpieczone przed szkodliwą treścią.
Następnie należy zmapować możliwe konsekwencje: wyciek promptu systemowego, wyświetlenie cudzego źródła, zmianę parametrów narzędzia, wysłanie danych lub obejście zatwierdzenia. Samo ujawnienie instrukcji może być mniej poważne niż dostęp do sekretu, który nigdy nie powinien się w niej znaleźć. Priorytet ochrony należy ustalać według rzeczywistych możliwości i skutków, a nie według dramatyzmu tekstu.
Oddziel autorytatywne instrukcje od niezaufanych danych
Reguły systemowe i polityka narzędzi powstają w aplikacji, a nie w wczytanym dokumencie. Tekst źródłowy oznaczcie delimiterami i opisem, że jest przeznaczony do analizy. Nigdy nie dawajcie mu możliwości nadpisania roli ani trybu bezpieczeństwa. To rozróżnienie zmniejsza ryzyko, ale model nie zawsze musi go przestrzegać, dlatego nie może być jedyną warstwą obrony.
Proszę ograniczać kontekst do fragmentów potrzebnych do udzielenia odpowiedzi na pytanie i filtrować typy treści, których system nie obsługuje. HTML należy przetwarzać bez elementów aktywnych, a ukryte warstwy i metadane oceniać osobno. Automatyczne streszczanie obcej strony internetowej nie może w konsekwencji uruchamiać zawartych w niej instrukcji. Również wynik modelu należy traktować jako niezaufany przed jego wyświetleniem lub użyciem w kolejnym kroku.
- inwentaryzacja wszystkich zewnętrznych i wewnętrznych tekstowych danych wejściowych
- wyraźna granica między regułami systemowymi a analizowanymi danymi
- zminimalizowany kontekst bez sekretów i zbędnych danych
- bezpieczne przetwarzanie wyniku modelu przed dalszym użyciem
Ogranicz narzędzia i egzekwuj uprawnienia poza modelem
Model ma dostęp wyłącznie do wąskich narzędzi potrzebnych do bieżącego zadania. Argumenty przechodzą przez schemat, reguły domenowe i autoryzację opartą na zweryfikowanej tożsamości użytkownika. Tenanta, roli ani docelowego uprawnienia nie określa wynik tekstowy. Narzędzie do odczytu nie ma ukrytej możliwości zapisu, a ogólne uruchamianie kodu czy dowolnego URL nie jest dozwolone bez wyjątkowego powodu.
Działania wrażliwe lub trudne do odwrócenia wymagają podglądu i potwierdzenia konkretnych wartości. Ograniczaj liczbę wywołań, ilość danych, czas i łańcuchowanie. Jeśli dokument nakaże wysłanie treści na zewnętrzny adres, serwer odrzuci cel niezależnie od uzasadnienia modelu. Sekrety przechowuj w warstwie aplikacji, a narzędzie zwraca jedynie minimum niezbędnego wyniku.
Chroń retrieval, cytowania i wyświetlanie
RAG filtruje źródła według uprawnień przed wyszukiwaniem i zachowuje informację o ich pochodzeniu. Szkodliwy fragment nie może wpływać na wybór kolejnych źródeł ani na zasady cytowania. Podczas indeksowania można oznaczyć typ i poziom zaufania dokumentu, ale filtr wykrywający nie jest nieomylny. Wrażliwe kolekcje należy oddzielić, a przy pytaniu spoza zakresu system w ogóle ich nie przeszukuje.
Wygenerowany tekst należy renderować z bezpiecznym escapowaniem i zezwalać wyłącznie na kontrolowany zestaw formatowania. Linki trzeba walidować, a użytkownika ostrzegać przed przejściem do zewnętrznego celu. Model nie powinien generować kodu wykonywalnego, który aplikacja automatycznie uruchomi. Cytat weryfikuje się względem rzeczywistego źródła, a prawo dostępu sprawdza się również przy jego otwarciu.
Testuj ataki i przygotuj reakcję
Zestaw testowy obejmuje bezpośrednie żądania obejścia reguł, ukryte instrukcje w dokumentach, fałszywe komunikaty systemowe, manipulację cytatami, próby użycia cudzych identyfikatorów i łączenie narzędzi w łańcuchy. Testuj różne języki i formaty. Sukces oznacza nie tylko bezpieczne zdanie, ale także to, że nie wczytano żadnych zabronionych danych ani nie wywołano niedozwolonego narzędzia.
Proszę monitorować odrzucone autoryzacje, nietypowe kombinacje narzędzi, ilość danych wyjściowych i dostęp do wrażliwych kolekcji. Logi nie mogą zawierać ujawnionych sekretów. W razie podejrzenia należy wyłączyć dane narzędzie, unieważnić poświadczenia, zabezpieczyć dowody i zbadać zakres. Każdy incydent powinien przełożyć się na test i poprawkę architektoniczną, a nie tylko na dłuższy prompt.
Najczęstsze pytania
Czy lepszy prompt systemowy rozwiąże problem prompt injection?
Nie sam. Prompt jest tylko jedną warstwą. Potrzebne są minimalne uprawnienia, autoryzacja po stronie serwera, walidowane narzędzia, bezpieczny retrieval, potwierdzanie akcji i bieżące testowanie.
Czy szkodliwe polecenie może znajdować się także w dokumencie wewnętrznym?
Tak. Dokument mógł zostać przesłany przez pomyłkę, zostać zmanipulowany lub zawierać cytowany tekst zewnętrzny. Każda treść analizowana przez model jest przetwarzana jako dane o określonym poziomie zaufania.
Czy system AI powinien znać klucze API swoich narzędzi?
Nie. Sekrety pozostają w warstwie serwerowej, która wykonuje autoryzowaną funkcję. Model otrzymuje wyłącznie bezpieczny wynik potrzebny do kontynuowania zadania.
Źródła i dalsza lektura
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
