Jak ograniczyć prompt injection, gdy agent czyta treści z zewnątrz

Planuj na wypadek udanego ataku

Wpis OWASP z 2025 roku o prompt injection opisuje pośrednie wstrzyknięcie jako treść ze źródeł zewnętrznych, takich jak strony internetowe czy pliki, która zmienia zachowanie modelu, i zaznacza, że polecenie nie musi być widoczne dla człowieka. Stwierdza też, że nie wiadomo, czy istnieją niezawodne metody zapobiegania. Wśród zaleceń są minimalne uprawnienia, zatwierdzanie ryzykownych akcji przez człowieka, oddzielanie treści zewnętrznych i testy ataków. Z tego wynika nasze założenie: liczy się to, co agent może zrobić, gdy już zostanie oszukany.

Nasz przewodnik po bezpieczeństwie agentów kodujących dotyczy agentów pracujących w repozytoriach. Ten artykuł dotyczy agentów w procesach biznesowych, którzy czytają pocztę, dokumenty, zgłoszenia, strony internetowe i wyniki narzędzi.

Bezpieczeństwo agentów AI do programowania

Zestaw niezaufane wejścia z akcjami

Weźmy hipotetycznego agenta w dziale zobowiązań. Czyta e-maile od dostawców z fakturami w PDF, wyszukuje zamówienia zakupu, a w pierwszej wersji projektu mógłby tworzyć propozycje płatności, odpowiadać dostawcom i zmieniać ich dane bankowe. Jego mapa wygląda tak:

• Treść e-maili i załączniki: niezaufane, pisze je każdy, kto może wysłać wiadomość na tę skrzynkę
• Zamówienia zakupu: zaufane co do kwot, ale pola tekstowe mogą zawierać tekst od dostawcy
• Odpowiedzi do dostawców: kanał wychodzący, którym może wypłynąć wszystko, co jest w kontekście agenta
• Zmiana danych bankowych: zapis o dużych skutkach, w który celowałaby wstrzyknięta wiadomość o zmianie konta

Niebezpieczne połączenie widać od razu: niezaufany tekst w kontekście, zapis, który przesuwa pieniądze, i droga do wysłania danych na zewnątrz. Decyzja dotyczy tego, które połączenie przeciąć. Tutaj całkowicie zabralibyśmy agentowi zmianę danych bankowych, ograniczylibyśmy odpowiedzi do stałych szablonów bez wolnego tekstu i pozwolilibyśmy agentowi jedynie proponować płatności, które człowiek zatwierdza w systemie ERP.

Wzorce projektowe, które usuwają ścieżkę

Praca Beurer-Kellnera i współautorów z 2025 roku opisuje wzorce projektowe oparte na jednej zasadzie: gdy agent przeczytał niezaufane dane, musi być ograniczony tak, by te dane nie mogły wywołać akcji o istotnych skutkach. Cztery z tych wzorców, które pasują do procesów biznesowych:

• Selektor akcji: model wybiera jedną z ustalonych akcji i nigdy nie widzi ich wyników, więc żaden wynik narzędzia nim nie pokieruje
• Najpierw plan, potem wykonanie: model ustala wywołania narzędzi przed przeczytaniem niezaufanych danych, więc wstrzyknięty tekst może zmienić argumenty, ale nie doda wywołań
• Map-reduce: każdy niezaufany dokument jest przetwarzany osobno, więc jeden złośliwy plik nie zmieni obsługi pozostałych
• Dual LLM: uprzywilejowany model z narzędziami nigdy nie czyta niezaufanego tekstu, a odizolowany model bez narzędzi czyta go i zwraca wartości przez referencję

System CaMeL opisany przez Debenedettiego i współautorów wyprowadza przepływ sterowania i danych z zaufanego zapytania i egzekwuje polityki oparte na uprawnieniach przy wywołaniach narzędzi. Jego gwarancje obowiązują w modelu zagrożeń przyjętym przez autorów, który traktuje zapytanie użytkownika jako zaufane, i zależą od polityk bezpieczeństwa zdefiniowanych dla każdego narzędzia. Autorzy podają, że rozwiązuje 77% zadań benchmarku AgentDojo z dowodliwym bezpieczeństwem, wobec 84% dla systemu bez ochrony. Ta różnica to zmierzony koszt użyteczności na ich benchmarku, a nie prognoza dla twojego procesu.

Kontrole, z którymi model nie wygra dyskusji

• Uprawnienia narzędzi dopasowane do zadania i egzekwowane przez serwer lub system biznesowy
• Zatwierdzenia powiązane z dokładną akcją i treścią i weryfikowane przez zaufany kod, dla wszystkiego, co przesuwa pieniądze, zmienia dostęp lub wysyła dane na zewnątrz
• Ograniczenie ruchu wychodzącego środowiska agenta i wyświetlanie wyników bez automatycznego ładowania obrazów czy linków, bo OWASP opisuje wyciek danych przez wstawiony adres obrazu
• Deterministyczne sprawdzanie wyników względem oczekiwanych wartości, na przykład zgodności kwot z zamówieniem i odbiorców z allowlisty
• Traktowanie wyników narzędzi jako niezaufanego wejścia, co odzwierciedla specyfikacja narzędzi MCP, zalecając klientom walidację wyników przed przekazaniem ich modelowi

Wyraźne oznaczanie treści zewnętrznych w prompcie nadal ma sens. Zmniejsza skuteczność ataków, ale model wciąż można namówić, by to oznaczenie zignorował.

Kontrole przed uruchomieniem i po nim

Zbuduj zestaw testów ataków z własnych kanałów wejściowych: biały tekst w PDF-ach, polecenia w stopkach e-maili, tekst w innych językach lub kodowaniach i polecenia w wynikach narzędzi. W każdym przypadku sprawdzaj wynik na granicy, a nie sformułowania modelu: brak zapisu bez zatwierdzenia, nic wychodzącego poza szablonami, podniesiony alert. Uruchamiaj zestaw ponownie po każdej zmianie modelu, promptu lub narzędzi. Po starcie loguj każde wywołanie narzędzia z identyfikatorami i źródłami wejść przeczytanych przed nim oraz z podjętą decyzją. Surową treść przechwytuj tylko przez zatwierdzone, ograniczone i zredagowane przechwytywanie z własnym okresem przechowywania. Przeglądaj odrzucone akcje i traktuj zablokowaną próbę jako sygnał, że ktoś sonduje system.

Ile kosztują granice

Każdy wzorzec zabiera elastyczność. Selektor akcji nie obsłuży prośby spoza swojej listy, schemat najpierw plan, potem wykonanie nie dostosuje się do tego, co znajdzie, a zatwierdzenia dokładają czas człowieka do każdego objętego nimi przypadku. Dopasuj siłę granicy do najgorszej akcji, do której agent może sięgnąć. Agent streszczający dokumenty dla osoby, która je wgrała, może potrzebować lekkich kontroli. Ten, który może płacić, wysyłać lub nadawać dostęp, powinien zacząć z przeciętymi ścieżkami, a możliwości wracać pojedynczo, po testach.

Praktyczny następny krok: narysuj mapę wejść i akcji dla jednego agenta i zaznacz każdą ścieżkę od niezaufanego tekstu do zapisu albo kanału wychodzącego.

Inżynieria i architektura AI