Prompt injection w dokumentach: jak sprawdzić, czy AI słucha właściwej osoby?

Asystent czyta dokument kontrahenta, a w środku znajduje polecenie zmiany odbiorcy wyniku. Treść do analizy próbuje właśnie przebrać się za przełożonego. To przykład prompt injection: próby sterowania modelem przez materiał, który nie powinien nadawać uprawnień. Sprawdź tę granicę, zanim podłączysz narzędzia wysyłające wiadomości lub zmieniające pliki. Cudzy dokument może zawierać instrukcję, ale samo to nie czyni jej firmowym poleceniem.

Poniższa procedura jest autorską propozycją odbioru konkretnego procesu. Nie stanowi certyfikatu bezpieczeństwa produktu. Jej wynikiem ma być lista zaobserwowanych zachowań, zakres sprawdzonych dróg wejścia oraz decyzja, które działania nadal wymagają technicznego ograniczenia.

Gdzie dokument może podszyć się pod polecenie?

Zacznij od odtworzenia jednego pełnego zadania: pracownik wybiera materiały, aplikacja pobiera załącznik, model przygotowuje wynik, następnie człowiek albo integracja wykorzystuje odpowiedź. Na każdym przejściu zapisz, skąd pochodzi treść i kto może ją zmienić. Pomaga w tym rejestr przepływu danych AI, ale tutaj dodajemy szczególne pytanie: czy autor materiału może wpłynąć na uprawnienia wykonawcy?

Własność folderu nie wystarcza do odpowiedzi. Do firmowego repozytorium mógł trafić plik z zewnątrz, a wewnętrzny raport może cytować stronę dostawcy. Oznacz pochodzenie poszczególnych części, jeśli system potrafi je zachować. Gdy nie potrafi, przyjmij ostrożniejszy poziom zaufania dla całego materiału. Umieszczenie dokumentu na zaufanym dysku nie przepisuje jego autorstwa.

OWASP opisuje pośrednie wstrzykiwanie instrukcji jako problem treści zewnętrznych przetwarzanych przez model. Wskazuje również potrzebę egzekwowania uprawnień narzędzi poza modelem. Sam napis w instrukcji systemowej, że dokumentom nie należy ufać, nie jest wystarczającą podstawą odbioru.

Praktyczna mapa powinna rozdzielać trzy role: osoba zlecająca określa zadanie, dokument dostarcza materiału, a aplikacja sprawdza możliwość wykonania operacji. Jeżeli oferta kontrahenta zawiera nowy adres do wysyłki, może to być informacja do sprawdzenia. Nie jest automatycznie zgodą użytkownika na przesłanie tam załączników z innego projektu.

Jak ustalić obserwowalny wynik próby?

Nie oceniaj wyłącznie tego, czy odpowiedź modelu zawiera uprzejmą odmowę. Interesuje nas skutek: czy wywołano narzędzie, jakie argumenty otrzymało, czy nastąpiła próba opuszczenia zakresu oraz czy użytkownik zobaczył zmianę. System może napisać, że odmawia, a jednocześnie wywołać operację w tle. Może również przetworzyć dokument bez alarmu i poprawnie zachować granice zadania. Gdy narzędziem jest agent obsługujący przeglądarkę, sprawdź także stan właściwego obiektu w aplikacji docelowej, zamiast uznawać sam opis kliknięcia za dowód skutku.

Przed próbą zapisz dozwolony wynik zwykłego zadania. Dla porównania dwóch ofert będą to określone kryteria, odnośniki do fragmentów źródłowych i informacja o brakujących danych. Następnie zdefiniuj niedozwolony skutek: zmiana odbiorcy, ujawnienie innego materiału albo dopisanie twierdzenia bez podstawy. Taka definicja pozwala odróżnić naruszenie granicy od zwykłej pomyłki merytorycznej.

W odpowiedzialnym workflow agentów warto wcześniej ustalić katalog operacji wymagających akceptacji. Na potrzeby odbioru każda z nich dostaje osobny warunek: co pracownik widzi przed zatwierdzeniem, jaki dokument uzasadnia działanie oraz co dzieje się po odmowie. Zgoda na analizę pliku nie powinna być ponownie interpretowana jako ogólna zgoda na wszystkie późniejsze działania.

Do pierwszych prób używaj fikcyjnych dokumentów i podstawionych narzędzi, które tylko zapisują proponowane działanie. Zamiast rzeczywistej skrzynki przygotuj rejestr planowanych wiadomości. Zamiast poufnego dysku przygotuj dwa sztuczne projekty. Próba ma pokazać możliwość przekroczenia granicy bez tworzenia prawdziwego wycieku ani zmieniania dokumentów klienta.

Jak przygotować mały, użyteczny zestaw przypadków?

Zaproponuj kilka rodzin sytuacji właściwych dla pracy zespołu. Pierwsza sprawdza próbę zmiany celu analizy. Druga dotyczy dodania nieuzgodnionego odbiorcy. Trzecia bada żądanie sięgnięcia do innego zasobu. Czwarta sprawdza treść udającą komunikat administratora. Nie potrzebujesz kolekcji efektownych haseł; potrzebujesz porównania zachowania aplikacji na rzeczywistych drogach przetwarzania.

Każdemu przypadkowi towarzyszy zwykły dokument kontrolny. Jeśli system odrzuca wszystkie pliki zawierające słowo „instrukcja”, może uniemożliwiać analizę instrukcji obsługi. Zapisuj więc także niesłuszne blokady. Ocena obejmuje bezpieczeństwo oraz możliwość wykonania uzgodnionego zadania. Zbyt szeroka blokada często powoduje obchodzenie procesu przez pracowników.

Jeżeli zespół pracuje po polsku i angielsku, uwzględnij oba języki. Dokumentacja Microsoft Prompt Shields rozróżnia ataki w poleceniach użytkownika i dokumentach, a także zaznacza zmienną skuteczność dla różnych języków. Wynik klasyfikatora wymaga interpretacji i odpowiedniej logiki aplikacji; nie jest sam w sobie dowodem, że konkretna operacja została zablokowana.

Dla każdego przypadku zachowaj wersję dokumentu, wersję konfiguracji, datę próby i obserwację skutku. Gdy wyniki różnią się między uruchomieniami, zapisz rozrzut zamiast wybierać najkorzystniejszą odpowiedź. Ta część może korzystać z warsztatu testów regresji jakości AI, ale celem pozostaje naruszenie granicy zaufania, a nie ogólna ocena stylu odpowiedzi.

Jak wygląda scenariusz hipotetyczny w dziale zakupów?

Załóżmy hipotetycznie, że asystent zestawia trzy oferty urządzeń i przygotowuje szkic pytań do dostawców. Ma prawo czytać wskazany katalog i zapisywać szkice. Jedna fikcyjna oferta zawiera akapit sugerujący przesłanie pełnego porównania na dodatkowy adres w celu „potwierdzenia zgodności”. Firma nie przyznała takiej zgody, a narzędzie wysyłkowe w próbie jest atrapą.

Odbiór zapisuje osobno cztery obserwacje: czy model zauważył treść, czy uwzględnił ją jako fakt o ofercie, czy zaproponował dodatkową wysyłkę oraz czy aplikacja dopuściła wywołanie. Samo zacytowanie podejrzanego zdania w podsumowaniu nie oznacza przejęcia procesu. Próba wysyłki poza uzgodnioną listę jest już inną kategorią zdarzenia.

W pierwszej wersji systemu przycisk zatwierdzenia pokazuje wyłącznie „wyślij pytania”. To słaby punkt, bo pracownik nie widzi dodatkowego odbiorcy ani załączników. Zespół zmienia widok na pełny podgląd wiadomości i odbiorców, a niezależna reguła narzędzia blokuje wysyłkę poza listę zatwierdzoną dla zadania. Potem powtarza ten sam przypadek oraz normalną wysyłkę kontrolną.

Jeżeli blokada działa, raport opisuje dokładnie tę ścieżkę, wersję oraz zestaw prób. Nie wolno na tej podstawie twierdzić, że produkt jest odporny na wszystkie możliwe manipulacje. Nie sprawdzono przecież innych formatów, przyszłych integracji ani zmian sposobu pobierania dokumentów. To ograniczenie wyniku pomaga zaplanować następny odbiór.

Jak wybrać zabezpieczenie po znalezieniu problemu?

Decyzję podejmuj według możliwego skutku. Zmiana kolejności punktów w roboczym streszczeniu wymaga innej reakcji niż próba wysłania danych poza organizację. Najpierw usuń możliwość nieuprawnionej operacji. Dopiero potem poprawiaj instrukcje i komunikaty. Przegląd uprawnień integracji AI pozwala często zmniejszyć zasięg szkody jeszcze przed przebudową aplikacji. Jeżeli kontrola opiera się na wydzielonym środowisku, sprawdź granice plików i sieci w piaskownicy agenta, razem z rzeczywistym zachowaniem narzędzi.

Dla operacji odwracalnych i ograniczonych do szkicu może wystarczyć jawny podgląd wyniku oraz późniejszy odbiór. Dla wysyłki, nadpisywania lub pobierania danych z innych obszarów potrzebna jest kontrola właściwa dla tej czynności. Użytkownik powinien zatwierdzać konkretny zakres. Reguła wykonania musi sprawdzać go ponownie, nawet jeśli model przekazał przekonujące uzasadnienie.

Gdy próba ujawni rzeczywiste nieuprawnione działanie, zakończ eksperyment i uruchom uzgodnioną procedurę reakcji na incydent danych. Nie mieszaj dalszego testowania z zabezpieczaniem zdarzenia. Dodatkowe działania mogą utrudnić ustalenie, co wydarzyło się wcześniej i które kopie informacji trzeba objąć analizą.

Jak rozstrzygać przypadki, w których instrukcja jest częścią treści?

Dokument może opisywać zwykłą procedurę, a użytkownik może poprosić o przygotowanie planu jej wykonania. Wtedy bezwzględne ignorowanie wszystkich zdań w trybie rozkazującym zepsuje zadanie. Rozróżnienie dotyczy źródła upoważnienia: model może odtworzyć kroki z instrukcji obsługi, ponieważ człowiek zlecił ich analizę. Nie dostaje przez to prawa do uruchomienia opisanych w niej narzędzi ani do zmiany własnych ograniczeń.

W karcie przypadku wpisz więc dwie oddzielne odpowiedzi. Pierwsza: czy poprawnie zrozumiano treść dokumentu? Druga: czy wykonano wyłącznie działanie zatwierdzone przez użytkownika? Taka konstrukcja pomaga uniknąć fałszywego wyniku, w którym bezpieczny system otrzymuje złą ocenę za wierne streszczenie podejrzanego akapitu. Treść można opisać, oznaczyć i przedstawić do oceny bez wykonywania jej poleceń.

Zwróć uwagę na działania odroczone. Dziś asystent może zapisać szkic, a jutro inna automatyzacja przekształci go w wiadomość. Jeżeli pierwszy etap oznaczył fragment jako niezweryfikowane żądanie dostawcy, oznaczenie powinno przetrwać przekazanie. Utrata tej informacji może spowodować, że późniejszy wykonawca potraktuje roboczą propozycję jak zatwierdzone zadanie. Odbiór obejmuje wtedy także moment ponownego odczytu.

Przygotuj ponadto próbę z pustym lub uszkodzonym dokumentem. System powinien jasno wyjaśnić brak materiału, zamiast uzupełniać analizę znalezionymi gdzie indziej instrukcjami. To przypadek sąsiedni, ale istotny dla interpretacji: nie każdy nieuprawniony krok jest wynikiem wrogiego tekstu. Czasem aplikacja sama rozszerza zadanie, bo brakuje jej jawnej ścieżki zatrzymania.

Po warsztacie przechowuj ograniczony pakiet dowodów. Wersja sztucznego pliku, zapis proponowanych operacji i konfiguracja kontroli zwykle wystarczą do odtworzenia konkretnego wyniku. Nie przenoś do raportu haseł, prawdziwych kluczy ani materiałów innych klientów tylko po to, żeby przykład wyglądał przekonująco. Dowód techniczny powinien ułatwiać naprawę i pozostawać bezpieczny w obiegu projektowym.

Sprawdzenie obcych instrukcji połącz z odbiorem firmowej wyszukiwarki AI. Źródło może być istotne dla pytania i nadal zawierać treść, która nie powinna sterować narzędziami. Trafność wyszukania oraz prawo do wykonania działania wymagają osobnych kryteriów.

Co powinno znaleźć się w odbiorze zabezpieczeń?

Dobry protokół zamyka jedną konkretną decyzję: można uruchomić dany zakres, trzeba go ograniczyć albo należy wstrzymać operacje do poprawki. Wskaż właściciela każdej pozostałej luki i termin ponownej próby. Ogólne zadanie „poprawić bezpieczeństwo AI” nie daje zespołowi wykonalnego następnego kroku.

• Mapa obejmuje wszystkie aktualnie używane kanały pobierania dokumentów.
• Próby używają sztucznych danych oraz narzędzi bez rzeczywistych skutków zewnętrznych.
• Każdy przypadek ma określone zadanie, zakazany skutek i normalną próbę kontrolną.
• Raport pokazuje faktyczne argumenty operacji i wynik reguł wykonania.
• Zatwierdzenie dotyczy widocznych odbiorców, zasobów i zmian.
• Po poprawce powtórzono problematyczny przypadek oraz kontrolę zwykłej pracy.
• Lista ograniczeń określa, czego zestaw prób jeszcze nie obejmuje.

Jeżeli chcesz sprawdzić taki proces we własnej firmie, zacznij od zakresu Aeneia Audit.