Agent odczytuje załącznik od dostawcy. W środku znajduje zdanie proszące o przesłanie innych dokumentów na wskazany adres. Dla człowieka to fragment obcego materiału. Dla źle zaprojektowanego obiegu AI może stać się kolejnym poleceniem do wykonania. Tego rodzaju próbę wpływania na zachowanie modelu przez przetwarzaną treść określa się jako prompt injection.
OWASP opisuje ten problem w zestawieniu ryzyk dla aplikacji korzystających z modeli językowych. W firmowym rozwiązaniu trzeba potraktować go jako część projektu dostępu i działania. Nie wystarczy dopisać w instrukcji „ignoruj podejrzane polecenia” i uznać sprawę za zamkniętą.
Oddziel instrukcję właściciela od treści źródła
Dokument, strona i wiadomość mogą być materiałem do analizy. Nie powinny same nadawać agentowi nowych uprawnień ani zmieniać celu zlecenia. W opisie obiegu wskaż, kto określa zadanie oraz które źródła dostarczają danych. Zewnętrzny plik nie staje się przełożonym aplikacji tylko dlatego, że używa stanowczego trybu rozkazującego.
Przy asystencie szukającym odpowiedzi w dokumentach oznacz materiał źródłowy i kontroluj sposób przekazania go modelowi. To pomaga zachować rozróżnienie, lecz nie jest samodzielną gwarancją bezpieczeństwa. Model nadal pracuje na tekście, dlatego potrzebuje ograniczeń również poza samym poleceniem.
Wybór materiałów do bazy nie usuwa całego problemu. Dokument wewnętrzny może zawierać cytowaną wiadomość albo skopiowany fragment z innego miejsca. Ustal, jak traktować takie treści i jak zgłaszać próbę działania spoza zakresu. Celem nie jest blokowanie każdego cytatu, tylko zachowanie właściwego źródła upoważnienia.
Narzędzie powinno umieć tylko to, co potrzebne
Jeżeli zadanie polega na przygotowaniu szkicu, agent nie musi otrzymywać prawa do wysyłania plików. Jeśli ma odczytać wskazany rejestr, szeroki dostęp do całego dysku wymaga osobnego uzasadnienia. Takie granice powinny istnieć technicznie w integracjach, a nie jedynie w zdaniu kierowanym do modelu.
W tekście o uprawnieniach dokumentów w RAG opisujemy ograniczanie źródeł dla konkretnego użytkownika. Filtr dostępu nie powinien zależeć od polecenia znalezionego w pliku. Model nie może sam rozszerzyć zbioru, który aplikacja uznała za niedozwolony.
Przy integracji AI z API sprawdzaj parametry i dozwolone operacje po stronie aplikacji. Oddziel dostęp do odczytu od zapisu oraz kontroluj cel wysyłki. Dokumentacja OpenAI dotycząca bezpieczeństwa agentów omawia ograniczanie skutków niezaufanych danych; konkretny zakres kontroli trzeba dobrać do możliwości używanych narzędzi.
Ograniczenie dotyczy również danych zwracanych przez narzędzie. Odpowiedź z zewnętrznego systemu może zawierać opis pochodzący od klienta lub dostawcy. Nie traktuj całej odpowiedzi API jak nowej instrukcji tylko dlatego, że przyszła z poprawnie uwierzytelnionego połączenia. Zaufanie do transportu nie zmienia autorstwa treści. W projekcie warto więc wskazać, które pola niosą dane źródłowe i gdzie zachowują one swój status.
Zatwierdzenie ma dotyczyć skutku, nie samego przycisku
Gdy operacja wymaga decyzji człowieka, pokaż gotową treść, odbiorcę i załączniki. Osoba zatwierdzająca musi rozpoznać, czy wynik nadal odpowiada zadaniu. Mechanizm zatwierdzania działań agenta AI powinien unieważniać zgodę po istotnej zmianie propozycji.
Nie kieruj każdej podejrzanej treści do człowieka z ogólnym pytaniem „kontynuować?”. Pokaż, co system próbował zrobić i dlaczego wymaga to decyzji. Inaczej kontrola sprowadzi się do akceptowania niezrozumiałych alertów. Pracownik nie powinien potrzebować analizy całej rozmowy, aby zauważyć obcego adresata dopisanego do wysyłki.
Zaplanuj odmowę i zatrzymanie. Agent nie powinien szukać innego połączenia pozwalającego wykonać to samo niedozwolone działanie. Ograniczenia muszą więc obejmować dostępne ścieżki, a nie tylko jedną funkcję widoczną podczas demonstracji.
Przygotuj kontrolowaną próbę przed wdrożeniem
W dopuszczonym środowisku testowym umieść dokument zawierający polecenie wykraczające poza zadanie. Sprawdź odpowiedź, wywołane narzędzia i stan systemu docelowego. W testach asystenta AI zachowaj ten przypadek jako próbę regresji. Samo zapewnienie modelu, że nie wykonał operacji, wymaga jeszcze sprawdzenia.
Archifutura może uwzględnić te kontrole w projekcie systemu AI i zakresie integracji narzędzi. Zaczynamy od danych, uprawnień i możliwych skutków. Dzięki temu ochrona nie zależy wyłącznie od rozpoznania „podejrzanego zdania”, lecz również od tego, czego aplikacja rzeczywiście nie pozwala zrobić.
Do próby dodaj treść sugerującą zmianę adresata oraz próbę wydobycia materiału spoza uprawnień użytkownika. Nie wykorzystuj prawdziwych poufnych plików do sprawdzania skutku. Wystarczą kontrolowane materiały o rozpoznawalnej treści i testowe cele operacji. Zapisz oczekiwany wynik dla każdej warstwy: odpowiedzi modelu, wywołania narzędzia i stanu aplikacji. Dzięki temu błąd nie ukryje się między poprawnie wyglądającymi komunikatami.
Źródła i dokumentacja
Materiały sprawdzone przy opracowaniu tekstu. Przy wyborze usługi lub technologii potwierdzamy warunki dla konkretnego projektu.
