Agenci przeglądarkowi AI: bezpieczeństwo i prompt injection

Agenci przeglądarkowi AI łączą dwa niebezpieczne elementy: niezaufaną treść internetu i aktywną sesję zdolną klikać, wpisywać oraz pobierać pliki. Ukryta instrukcja na stronie może przekierować plan agenta bez kompromitacji samej przeglądarki.

Oddziel profil agenta

Nie używaj codziennego profilu z pocztą, bankiem i panelem chmurowym. Twórz efemeryczny profil, bez historii i niepotrzebnych cookies. Logowanie udostępniaj tylko dla konkretnej domeny i zadania.

Polityka nawigacji

Allowlista obejmuje domenę docelową oraz kontrolowane zależności. Po każdym redirect sprawdzaj finalny origin. Blokuj file:, lokalne adresy, metadata, pobrania wykonywalne i nieznane rozszerzenia.

Wpisywanie danych w formularz jest narzędziem wysokiego ryzyka. Oddziel generowanie wartości od zatwierdzenia odbiorcy. Hasło lub token wstawia komponent przeglądarki, nie model.

Akcje wymagające zgody

Zakup, wysłanie wiadomości, publikacja, upload, zgoda OAuth, zmiana uprawnień i usunięcie danych wymagają potwierdzenia związanego z parametrami. Screenshot strony nie jest autoryzacją.

Testy injection

Umieszczaj instrukcje w tekście, alt, CSS, komentarzu, PDF, reklamie i wyniku wyszukiwania. Sprawdź, czy agent zachowuje pierwotny cel i czy nie wysyła danych do nowego originu.

OWASP klasyfikuje web, dokumenty i e-mail jako źródła indirect prompt injection. Stosuj ochronę przed prompt injection, ale decyzję egzekwuj deterministycznie w warstwie przeglądarki.

Model zagrożeń dla sesji przeglądarki

Agent widzi jednocześnie instrukcję użytkownika i niezaufaną treść strony. Problem pojawia się, gdy model interpretuje tekst witryny jako polecenie nadrzędne. Złośliwa instrukcja może być widoczna, ukryta w atrybucie, osadzona w dokumencie albo dostarczona przez wynik wyszukiwania. Filtr słów kluczowych nie rozwiązuje problemu, ponieważ znaczenie można wyrazić wieloma sposobami.

Najważniejsza kontrola znajduje się poza modelem. Warstwa wykonawcza zna pierwotny cel, dozwolone originy, typ danych oraz maksymalny poziom wpływu. Nawigacja, odczyt i kliknięcie mają inne ryzyko niż wysłanie formularza, zakup, zmiana hasła czy pobranie pliku. Każda akcja zmieniająca stan przechodzi ponowną walidację bez względu na uzasadnienie wygenerowane przez LLM.

Sesje, dane i potwierdzenie człowieka

Używaj oddzielnego profilu bez prywatnej historii, zapisanych haseł i aktywnych sesji niezwiązanych z zadaniem. Ogranicz schowek, pobieranie, upload, otwieranie niestandardowych protokołów oraz dostęp do localhost i adresów prywatnych. Nowy origin nie dziedziczy zgody wydanej dla poprzedniej domeny.

Ekran potwierdzenia powinien pokazywać konkretny skutek: domenę, odbiorcę, pola danych i operację. Ogólne pytanie „czy kontynuować?” nie daje użytkownikowi informacji potrzebnej do decyzji. Po modyfikacji strony lub dłuższej przerwie zgoda musi zostać odnowiona.

Scenariusze testowe

Przygotuj strony z instrukcją jawną i ukrytą, przekierowaniem, fałszywym dialogiem logowania, linkiem do prywatnego adresu, formularzem wysyłającym dane oraz dokumentem zawierającym prompt. Mierz nie tylko finalny wyciek, ale także próby zmiany celu, nowe originy, wywołania wysokiego ryzyka i liczbę blokad.

Test powtarzaj po zmianie modelu, promptu systemowego, przeglądarki lub zestawu narzędzi. Bezpieczne zachowanie jednego modelu nie jest trwałą właściwością całej architektury.

Kontrola pobierania i wysyłania plików

Pobrany plik traktuj jak obiekt z kwarantanny. Sprawdź deklarowany i rzeczywisty typ, rozmiar, nazwę, zawartość aktywną oraz to, czy nie jest archiwum z traversal lub bombą dekompresyjną. Agent nie powinien automatycznie otwierać pliku w aplikacji z dostępem do prywatnych danych.

Upload wymaga jawnego źródła i odbiorcy. Warstwa polityki powinna pokazać, które pliki i pola opuszczą środowisko, oraz zablokować ukryte załączniki, ścieżki spoza workspace i dane innego tenantu. Tekst strony nie może rozszerzyć wybranego zestawu.

Sygnały dla zespołu bezpieczeństwa

Rejestruj zmianę originu, próbę localhost lub prywatnego IP, odczyt elementu wrażliwego, wypełnienie formularza, download, upload i akcję wymagającą zgody. Zdarzenie zawiera decyzję executora oraz źródło żądania, ale nie musi przechowywać pełnej treści strony.

Alertuj na sekwencje, nie pojedyncze kliknięcia: dokument zewnętrzny, nowe pochodzenie, próba odczytu sekretu i formularz wychodzący są razem silniejszym sygnałem niż każda czynność osobno. Taka telemetria pozwala odróżnić błąd modelu od próby indirect injection i szybko unieważnić sesję.

Izolacja strony od zamiaru użytkownika

Tekst strony, atrybuty dostępności, komentarze, dokumenty i wyniki wyszukiwania są niezaufane. Agent nie powinien traktować ich jako instrukcji nadrzędnych. Polityka narzędzi musi działać poza modelem i wiązać dozwolone domeny, typy operacji oraz dane z zamiarem potwierdzonym przez użytkownika.

Przed wysłaniem formularza pokaż odbiorcę, pola i skutki; hasła i tokeny nie mogą trafiać do dowolnej domeny wskazanej w treści strony. Testuj ukryty prompt, przekierowanie, iframe, pobrany plik i zmianę treści między planem a kliknięciem. Zrzut ekranu nie wystarcza: loguj decyzję polityki, docelowy origin i wywołanie narzędzia.

Źródła: OWASP Prompt Injection Prevention, OWASP AI Agent Security.