Prompt Injection w chatbotach na stronie: ochrona RAG, narzędzi i danych

Chatbot na stronie internetowej przetwarza nie tylko niegroźne pytania. Odwiedzający mogą próbować przepisać jego zasady, ujawnić wewnętrzne instrukcje lub wywołać niedozwolone akcje. Jeszcze trudniejsze do wykrycia są polecenia, które nie znajdują się bezpośrednio w czacie, lecz są ukryte na pobranej stronie internetowej, w przesłanym dokumencie lub w podłączonym systemie zewnętrznym.

Każdy, kto chce ograniczyć Prompt Injection w chatbotach na stronie, nie może polegać wyłącznie na szczególnie rygorystycznie sformułowanym prompcie systemowym. Konieczna jest wielowarstwowa architektura: dane wejściowe i źródła są traktowane jako niezaufane, uprawnienia są technicznie ograniczone, dane wyjściowe są sprawdzane przed dalszym przetwarzaniem, a ryzykowne akcje muszą być potwierdzone przez deterministyczny kod lub człowieka.

Co oznacza Prompt Injection w przypadku chatbota na stronie

OWASP opisuje Prompt Injection jako dane wejściowe, które nieumyślnie zmieniają zachowanie lub dane wyjściowe modelu językowego. Bezpośrednie Prompt Injection pochodzi bezpośrednio od użytkownika, na przykład jako polecenie zignorowania wcześniejszych zasad. Z kolei pośrednie Prompt Injection kryje się w treściach zewnętrznych, które system pobiera później: stronach internetowych, dokumentach wiedzy, wiadomościach e-mail, danych o produktach lub plikach.

Różnica ta jest istotna dla właścicieli witryn. Zwykły chatbot FAQ ma mniejszą powierzchnię ataku niż system, który stale indeksuje strony internetowe, przeszukuje dokumenty wewnętrzne, odczytuje dane z CRM lub wykonuje funkcje. Retrieval-Augmented Generation (w skrócie RAG) poprawia merytoryczną podstawę odpowiedzi, ale nie eliminuje ryzyka wstrzyknięcia poleceń. Nawet dobrze utrzymana baza źródeł może zawierać zmanipulowane lub błędnie zinterpretowane instrukcje.

Oceniaj ryzyko według funkcji, a nie nazwy modelu

Decydujące pytanie brzmi nie tylko: „Jakiego modelu używamy?”, lecz także: „Jaki wpływ może mieć zmanipulowana odpowiedź?”. Stwórz prostą mapę funkcji i danych dla chatbota:

• Do jakich źródeł publicznych i wewnętrznych ma dostęp odczytu?
• Jakie dane osobowe, poufne lub krytyczne dla biznesu są dostępne?
• Czy potrafi tylko generować tekst, czy może także tworzyć zgłoszenia, leady, e-maile, spotkania lub zamówienia?
• Jakie akcje zmieniają systemy zewnętrzne?
• Jakie decyzje są podejmowane automatycznie, bez weryfikacji przez człowieka?

Im większe prawa odczytu, zapisu i poziom automatyzacji, tym ważniejsze stają się ograniczenia techniczne poza samym modelem. Istniejący przegląd częstych błędów przy chatbotach AI pomaga w ogólnej inwentaryzacji. W przypadku Prompt Injection należy dodatkowo udokumentować przepływy danych, granice zaufania i prawa do wykonywania akcji.

Wyraźne rozdzielenie czterech stref zaufania

Praktyczny model bezpieczeństwa wyróżnia cztery strefy, nawet jeśli technicznie są one przetwarzane w tej samej aplikacji.

Strefa 1: Zasady systemowe i wytyczne

Znajdują się tu rola, dozwolony cel, granice odpowiedzi i zasady eskalacji. Zasady te dają modelowi orientację, ale nie stanowią niezawodnej kontroli dostępu. OWASP wyraźnie ostrzega przed traktowaniem promptów systemowych jako tajemnicy lub mechanizmu bezpieczeństwa. Dane dostępowe, klucze połączeń i poufne informacje wewnętrzne nie powinny się tam znajdować.

Strefa 2: Dane wejściowe od odwiedzających

Każda wiadomość na czacie jest traktowana jako niezaufana. Ogranicz długość, typy plików i dozwolone funkcje; znormalizuj dane wejściowe do przetwarzania technicznego i wyraźnie oznacz je w prompcie jako dane użytkownika. Filtr może wykrywać znane wzorce ataków, ale nie powinien hurtowo blokować uzasadnionych pytań. Odwiedzający pytający w dokumentacji bezpieczeństwa o „ignore previous instructions” może mieć uzasadniony interes.

Strefa 3: Pobrane źródła i kontekst RAG

Pobrane treści, pliki PDF i wyniki z usług zewnętrznych nadal pozostają danymi, a nie instrukcjami. Wyraźnie oddziel ich treść od kontekstu sterującego, przechowuj pochodzenie oraz czas pobrania i zezwalaj tylko na zatwierdzone źródła. Artykuł na temat utrzymywania aktualności bazy wiedzy chatbota AI pokazuje, jak współpracują ze sobą inwentaryzacja źródeł, częstotliwość indeksowania i kontrola jakości (QA).

Strefa 4: Narzędzia, akcje i dane wyjściowe

Wywołania funkcji nie mogą być wykonywane tylko dlatego, że model wygenerował pasujący tekst. Deterministyczny kontroler sprawdza nazwę funkcji, parametry, uprawnienia, kontekst sesji i dozwolone systemy docelowe. Wyjścia modelu, które zostaną później użyte jako HTML, Markdown, SQL, ścieżka do pliku lub parametry API, wymagają odpowiedniej dla danego kontekstu walidacji i kodowania.

Zasada najmniejszych uprawnień (Least Privilege) ogranicza skutki ataku

Na obecnym stanie wiedzy technicznej nie można niezawodnie wykluczyć Prompt Injection za pomocą pojedynczego środka. Dlatego aplikacja musi być zbudowana w taki sposób, aby udana próba manipulacji miała jak najmniejszy wpływ. OWASP i Microsoft zalecają stosowanie zasady najmniejszych uprawnień (Least Privilege).

• Używaj osobnych tożsamości technicznych dla odczytu i zapisu.
• Udzielaj dostępu tylko do tych danych, które są niezbędne dla konkretnego celu chatbota.
• Ogranicz funkcje do małych, ściśle zdefiniowanych schematów parametrów.
• Korzystaj z krótkotrwałych uprawnień, jeśli akcja w ogóle ich wymaga.
• Wymagaj wyraźnego potwierdzenia w przypadku ryzykownych lub nieodwracalnych kroków.
• Nigdy nie powierzaj autoryzacji swobodnemu tekstowi generowanemu przez model.

Na przykład chatbot wsparcia technicznego może przygotować wersję roboczą zgłoszenia, ale nie powinien automatycznie decydować o dowolnych odbiorcach, priorytetach czy wewnętrznych prawach dostępu. Chatbot do pozyskiwania leadów może przyjmować ustrukturyzowane dane kontaktowe bez uzyskiwania przy tym praw odczytu do całego systemu CRM.

Weryfikacja i izolowanie źródeł RAG

Pośrednie Prompt Injection sprawia, że potok pobierania źródeł staje się elementem architektury bezpieczeństwa. Zmanipulowana strona może wyglądać niegroźnie, a mimo to zawierać tekst, który model zinterpretuje jako instrukcję. W systemach multimodalnych rolę mogą odgrywać również obrazy lub inne formaty plików.

Dlatego należy wprowadzić proces przyjmowania źródeł z zasadami zatwierdzania: dozwolone domeny i obszary dokumentów, jednoznaczni właściciele, wersjonowanie, skanowanie pod kątem złośliwego oprogramowania i plików oraz przegląd nowych lub nietypowo zmienionych treści. Wyraźnie oznaczaj pobrane fragmenty w kontekście modelu jako treści niezaufane (untrusted content). Wynik wyszukiwania może dostarczać informacji, ale nie może zmieniać reguł systemowych ani uprawnień do narzędzi.

Sprawdź również, czy odpowiedź rzeczywiście znajduje pokrycie w źródłach. Przewodnik dotyczący mierzenia jakości odpowiedzi chatbota AI za pomocą zestawu Golden Set i testów RAG opisuje pojęcie ugruntowania (groundedness) i weryfikację ze źródłami. Ta kontrola jakości uzupełnia mechanizmy bezpieczeństwa, ale ich nie zastępuje.

Filtry wejścia i wyjścia to jedna z warstw, a nie całe rozwiązanie

Specjalistyczne usługi ochronne mogą wykrywać bezpośrednie i pośrednie próby ataków. Na przykład Microsoft Prompt Shields odróżnia ataki w danych wejściowych użytkownika od ukrytych instrukcji w dokumentach. Google w swoich wytycznych dotyczących bezpieczeństwa również zaleca środki ochrony przed Prompt Injection, ściślej zdefiniowane zadania, identyfikatory użytkowników, limity ilościowe oraz nadzór człowieka przy wyższym ryzyku.

Takie filtry dostarczają sygnałów probabilistycznych. Dlatego zaplanuj stopniowanie reakcji: zablokuj, odpowiedz w sposób bezpieczny, przełącz się na mocno ograniczony tryb lub przekaż rozmowę człowiekowi. Rejestruj klasę decyzji i wersję techniczną w logach, ale unikaj zbędnego przechowywania pełnego tekstu. W przypadku danych osobowych obowiązują dodatkowo obszary kontroli opisane w artykule o chatbotach AI i RODO. Artykuł ten nie stanowi porady prawnej.

Walidacja danych wyjściowych modelu przed dalszym przetwarzaniem

Bezpieczne dane wejściowe nie gwarantują bezpiecznych danych wyjściowych. OWASP wymienia niewystarczające przetwarzanie danych wyjściowych jako odrębne ryzyko: tekst z modelu może później trafić do HTML, skryptów, zapytań SQL lub ścieżek plików. Dlatego każde dane wyjściowe z modelu należy traktować jako niezaufane.

W przypadku automatycznych procesów wymagaj ścisłego ustrukturyzowanego formatu i waliduj go ze schematem. Stosuj białe listy dla nazw funkcji i systemów docelowych. Koduj widoczny tekst odpowiednio do kontekstu wyjściowego. Odrzucaj nieoczekiwane pola, zewnętrzne adresy URL i parametry wykraczające poza dozwolone wartości. Dane poufne przed wyświetleniem lub przesłaniem powinny przejść ponowną weryfikację polityk bezpieczeństwa.

Testowanie Prompt Injection za pomocą zestawu testów bezpieczeństwa

Uzupełnij merytoryczny zestaw testowy (Golden Set) o przypadki testów wrogich (adversarial test cases). Testy muszą sprawdzać rzeczywisty system produkcyjny, w tym wyszukiwanie, narzędzia i logikę uprawnień, a nie tylko model podstawowy. Przydatny zestaw zawiera:

• bezpośrednie próby zastąpienia zasad lub zapytania o instrukcje wewnętrzne;
• warianty wielojęzyczne, zakodowane i rozłożone na wiele wiadomości;
• niegroźne pytania dziedzinowe zawierające podobne słowa kluczowe, które nie powinny być błędnie blokowane;
• zmanipulowane fragmenty w testowym źródle wiedzy;
• niedozwolone nazwy funkcji, dodatkowe parametry i obce adresy docelowe;
• próby wyciągnięcia poufnych danych lub treści z poprzednich sesji;
• testy dla danych wyjściowych HTML, Markdown i linków;
• ścieżki przerwania, przekazania i potwierdzenia przy ryzykownych akcjach.

Nie mierz tylko tego, czy filtr zadziałał. Sprawdź ostateczny rezultat: Czy udało się zapobiec niedozwolonej akcji? Czy poufne dane pozostały chronione? Czy uzasadnione zapytanie nadal działało poprawnie? Czy podejrzany przypadek został przejrzyście zarejestrowany w logach?

Praktyczny plan wdrożenia dla zespołów internetowych

1. Określenie zakresu: udokumentuj źródła danych, narzędzia, prawa zapisu i cele zewnętrzne.
2. Rozdzielenie stref zaufania: technicznie oznacz zasady systemowe, dane wejściowe użytkowników, treści RAG i wyjścia akcji.
3. Ograniczenie uprawnień: usuń nieużywane dostępy i podziel akcje zapisu na małe funkcje.
4. Dodanie walidacji: wprowadź limity wejściowe, ustrukturyzowane wyjścia, białe listy i kodowanie dostosowane do kontekstu.
5. Ustalenie potwierdzeń: zabezpiecz ryzykowne akcje i przepływy danych poufnych za pomocą udziału człowieka (Human-in-the-Loop).
6. Wykonanie zestawu testów: sprawdzaj bezpośrednie, pośrednie i uzasadnione przypadki kontrolne przed każdym istotnym wydaniem.
7. Monitorowanie działania: regularnie przeglądaj zdarzenia filtrów, odrzucone akcje, nietypowe zmiany źródeł i fałszywe alarmy.

Lista kontrolna: Ochrona przed Prompt Injection

• Prompt systemowy nie zawiera sekretów i nie zastępuje autoryzacji.
• Teksty użytkowników i źródła zewnętrzne są domyślnie traktowane jako niezaufane.
• Źródła RAG mają zatwierdzenie, pochodzenie, wersję i wyznaczonych właścicieli.
• Narzędzia stosują zasadę Least Privilege i akceptują tylko zwalidowane parametry.
• Ryzykowne akcje wymagają jednoznacznego potwierdzenia.
• Wyjścia z modelu są sprawdzane przed przekazaniem do HTML, API, CRM lub innych systemów docelowych.
• Filtry bezpieczeństwa są oceniane pod kątem błędów pierwszego i drugiego rodzaju (False Positives i False Negatives).
• Testy ataków bezpośrednich i pośrednich są uruchamiane regularnie oraz po wprowadzeniu zmian.

Podsumowanie

Prompt Injection to nie tylko problem inżynierii promptów. W przypadku chatbotów na stronie internetowej solidna ochrona powstaje dopiero wtedy, gdy aplikacja traktuje dane wejściowe, źródła, wyjścia i akcje jako osobne strefy zaufania. Filtry mogą wykrywać ataki, ale to zasada najmniejszych uprawnień (Least Privilege), deterministyczna walidacja i potwierdzenie przez człowieka ograniczają ich ewentualny wpływ.

Rozpocznij od mapy funkcji i danych swojego chatbota. Usuń zbędne uprawnienia, odizoluj treści RAG i przetestuj całą ścieżkę aż do akcji zewnętrznej. Dzięki temu chatbot pozostanie użyteczny, a swobodny tekst z modelu nie będzie decydował o uprawnieniach ani o krytycznych zmianach biznesowych.

Źródła

• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• OWASP GenAI Security Project: LLM07:2025 System Prompt Leakage
• OWASP GenAI Security Project: LLM05:2025 Improper Output Handling
• NIST: Generative Artificial Intelligence Profile (NIST AI 600-1)
• Microsoft Learn: Defend against indirect prompt injection attacks
• Microsoft Learn: Prompt Shields in Azure AI Content Safety
• Google AI for Developers: Safety and factuality guidance