Audyt indirect prompt injection w systemach agentowych
Jak i kiedy użyć
Użyj tej checklisty podczas projektowania albo audytu agenta, który czyta treści spoza Twojego systemu i może wykonywać akcje. Wklej opis architektury, listę źródeł danych, narzędzia, uprawnienia, typowe akcje oraz przykłady wejść, które agent czyta. Przejdź punkt po punkcie i oznacz miejsca, w których nieufna treść może trafić do kontekstu modelu. Najważniejsze są przepływy, w których agent najpierw czyta mail, stronę, dokument albo komentarz, a potem wysyła wiadomość, zmienia rekord, uruchamia narzędzie, wykonuje płatność, publikuje treść albo przekazuje dane dalej.
Checklista
Mapa źródeł nieufnej treści
- Masz listę wszystkich miejsc, z których agent czyta treść spoza kontrolowanego systemu.
- Oddzielasz treści od użytkownika, treści z internetu, wyniki narzędzi, załączniki, komentarze, maile i dane z integracji.
- Dla każdego źródła oznaczasz, czy tekst może zawierać instrukcje próbujące sterować modelem.
- Traktujesz nieufną treść jako dane do analizy, a nie jako instrukcje dla agenta.
- Masz przykłady wejść testowych, w których nieufna treść próbuje zmienić cel zadania albo ujawnić dane.
Minimalizacja kontekstu
- Agent dostaje tylko te fragmenty treści, które są potrzebne do bieżącego zadania.
- Nie doklejasz pełnych maili, stron, historii rozmów i wyników wyszukiwania, jeśli wystarczy wycinek.
- Przed przekazaniem treści do modelu usuwasz albo streszczasz fragmenty ewidentnie niezwiązane z zadaniem.
- Długie dokumenty są dzielone na fragmenty z jasnym opisem źródła i poziomu zaufania.
- Nie mieszacie w jednym kontekście prywatnych danych, instrukcji systemowych i nieufnej treści bez wyraźnych granic.
Rozdzielenie danych od instrukcji
- Prompt systemowy jasno mówi, że tekst z maili, stron, dokumentów i narzędzi jest danymi, nie instrukcjami.
- Agent ma osobne pola na cel zadania, zaufane instrukcje, nieufną treść oraz wynik analizy.
- Przy zapisie danych nie przechowujesz ukrytych instrukcji razem z przyszłymi poleceniami dla modelu.
- Przy odczycie danych agent widzi informację, z jakiego źródła pochodzi treść i jaki ma poziom zaufania.
- W odpowiedziach po analizie nieufnej treści agent najpierw raportuje wnioski, a dopiero potem proponuje akcje.
Ograniczanie możliwości agenta
- Agent nie może samodzielnie wykonywać akcji wysokiego ryzyka po przeczytaniu nieufnej treści.
- Wysyłka maila, publikacja, płatność, zmiana danych i udostępnienie pliku wymagają osobnego potwierdzenia człowieka.
- Narzędzia agenta mają minimalne uprawnienia potrzebne do zadania.
- Agent nie ma jednocześnie szerokiego odczytu prywatnych danych i szerokiego zapisu do systemów zewnętrznych.
- Każda akcja zmieniająca stan pokazuje człowiekowi źródło informacji, plan działania i treść wyniku przed wykonaniem.
Monitoring i reakcja
- Logujesz przypadki, w których agent czyta nieufną treść i zaraz potem próbuje wykonać akcję zmieniającą stan.
- Monitorujesz nietypowe prośby o ujawnienie instrukcji, tokenów, danych klientów albo konfiguracji narzędzi.
- Masz test regresji z przykładowymi próbami indirect prompt injection dla najważniejszych przepływów.
- Wiesz, kto sprawdza alerty i jak szybko blokuje wadliwy przepływ.
- Po incydencie dopisujesz brakujący guard do promptu, walidatora, uprawnień albo interfejsu potwierdzenia.
Priorytet audytu
- Najpierw sprawdzasz przepływy, w których agent czyta maile, strony albo dokumenty i może wysłać wiadomość.
- Drugim priorytetem są przepływy z narzędziami administracyjnymi, CRM, plikami, płatnościami i publikacją treści.
- Trzecim priorytetem są długie konteksty, pamięć agenta i ponowne użycie streszczeń z nieufnych źródeł.
- Nie zakładasz, że filtr słów kluczowych wystarczy, bo atak może być opisowy, pośredni albo rozbity na kilka fragmentów.
- Za gotowy uznajesz dopiero przepływ, w którym model może przeczytać złośliwą treść, ale nie może sam wykonać szkodliwej akcji.
Najczęstsze pytania
Czym jest indirect prompt injection?
Indirect prompt injection to sytuacja, w której model czyta zewnętrzną treść, na przykład maila, stronę albo dokument, a ukryta w niej instrukcja próbuje zmienić zachowanie agenta. Atak nie przychodzi bezpośrednio od operatora, tylko przez dane, które agent ma przeanalizować.
Dlaczego to ryzyko jest ważne w systemach agentowych?
System agentowy nie tylko generuje tekst, ale często używa narzędzi, czyta pliki, wysyła wiadomości i zmienia dane. Jeśli nieufna treść wpłynie na decyzję modelu, zwykła analiza może zamienić się w niechcianą akcję w realnym systemie.
Czy wystarczy dopisać do promptu, żeby ignorować złe instrukcje?
Nie. Instrukcja w prompcie pomaga, ale nie jest pełną ochroną. Potrzebujesz także minimalizacji kontekstu, oznaczania poziomu zaufania danych, ograniczonych uprawnień narzędzi, potwierdzeń człowieka i monitoringu przepływów wysokiego ryzyka.
Które przepływy warto sprawdzić jako pierwsze?
Najpierw sprawdź przepływy, w których agent czyta mail, stronę, załącznik, komentarz albo zgłoszenie, a potem może wysłać wiadomość, opublikować treść, zmienić rekord, udostępnić plik albo wywołać narzędzie administracyjne.
Jak wygląda dobra kontrola człowieka w takim systemie?
Dobra kontrola pokazuje człowiekowi źródło informacji, wykrytą intencję, proponowaną akcję oraz dokładną treść, która ma zostać wysłana albo zapisana. Potwierdzenie nie powinno być ukryte w tym samym kroku, w którym model czyta nieufną treść.
Źródła i odniesienia
Ten zasób jest autorskim opracowaniem praktycznym. Poniższe pozycje pokazują inspiracje i ramy, do których jawnie się odnosimy.