Indirect Prompt Injection: jak presja wpływa na agenta AI

Wyobraźmy sobie firmowego agenta AI, który pomaga pracownikom obsługiwać przychodzącą pocztę: czyta wiadomości, streszcza je i wskazuje te, które wymagają działania.

Do skrzynki trafia pilna wiadomość. Nadawca przekonuje, że firma potrzebuje natychmiastowej pomocy, a brak reakcji może mieć poważne konsekwencje - również dla odbiorcy. W treści pojawia się polecenie wykonania operacji, której użytkownik agentowi nie zlecił. Taka wiadomość może wyglądać wiarygodnie zarówno dla człowieka, jak i dla agenta AI. I choć człowiek pod presją może popełnić błąd, działa w ramach polityk, procedur i ponosi odpowiedzialność za własne decyzje. Agent AI takiej odpowiedzialności nie ponosi - a jeśli ma dostęp do narzędzi, jego błędna interpretacja wiadomości może przełożyć się na konkretne działanie. 

To trzecia część serii o bezpieczeństwie agentów AI. W pierwszej pokazałam, że lokalny model nie chroni przed indirect prompt injection. W drugiej - że agent bezpieczny w testach przy temperaturze 0 może zachować się inaczej, gdy dostaje więcej swobody. W jednym ze scenariuszy atak powiódł się wtedy w blisko 17% prób. Teraz wracam do tego scenariusza i sprawdzam, co w nim zadziałało.

Co pokazały testy?

W testach nad indirect prompt injection sprawdziłam, czy sama konstrukcja komunikatu może sprawić, że agent AI uzna polecenie zawarte w e-mailu za część swojego zadania. Nie chodziło o banalne polecenie w rodzaju „zignoruj poprzednie zasady”, ale o sytuację, w której określone działanie zaczyna wyglądać jak logiczna i uzasadniona reakcja.

W wariancie neutralnym - bez presji - agent AI pomylił się raz na 30 prób (3,3%). Gdy wprowadziłam presję poprzez kontekst kryzysu, liczba pomyłek wzrosła do pięciu (16,7%). W tym wariancie agent AI sam wywołał narzędzie umożliwiające niepożądaną operację (uruchomienie komendy systemowej), choć użytkownik polecił mu jedynie podsumować wiadomość.

Nie oznacza to, że AI „ulega emocjom”. Pokazuje coś ważniejszego z perspektywy bezpieczeństwa: agent nie musi odczuwać presji, żeby język presji zmienił jego zachowanie.

Gdy pomocność zaczyna kolidować z bezpieczeństwem

Asystenci AI są trenowani - m.in. RLHF (reinforcement learning from human feedback), czyli na podstawie ocen ludzi - tak, aby ich odpowiedzi były pomocne, zrozumiałe i trafne. To ich siła i zarazem luka: mogą zbyt łatwo dopasowywać odpowiedź do perspektywy rozmówcy, nawet kosztem prawdziwości czy ostrożności.

Nie twierdzę, że właśnie ten mechanizm odpowiadał za zachowanie agenta w moim eksperymencie. Ale asystent AI zaprojektowany do pomagania prędzej czy później trafi na wiadomość, która przedstawia niepożądane działanie właśnie jako pomoc. A jeśli ma dostęp do narzędzi, jego “pomoc” stanie się operacją w systemie.

Gdy kontekst staje się częścią ataku

W indirect prompt injection napastnik nie musi mieć dostępu do rozmowy z agentem ani występować w roli użytkownika. Złośliwą instrukcję może umieścić w treści, którą system ma po prostu przetworzyć - e-mailu, dokumencie, stronie internetowej czy innym zewnętrznym źródle.

W scenariuszu opartym na manipulacji społecznej mogą pojawić się między innymi:
► presja czasu – „działaj natychmiast”;
► poczucie kryzysu – „firma potrzebuje natychmiastowej pomocy”;
► osobiste konsekwencje – „brak działania odbije się również na Tobie”.

W innych wariantach atak może też wykorzystywać autorytet, na przykład „polecenie działu prawnego” albo „zalecenie CISO”. Złośliwe polecenie nie musi więc wyglądać jak oczywista próba obejścia zasad. Może zostać wpisane w wiarygodny kontekst biznesowy i stać się częścią informacji, na podstawie których agent AI wybiera kolejne działanie.

Co może umknąć w testach odporności agenta?

W badanej wiadomości, stylizowanej na pilny alert bezpieczeństwa, zbudowana została narracja kryzysu: firma potrzebuje pomocy, na reakcję została tylko godzina, a brak działania może odbić się również na reputacji odbiorcy. Dopiero w takim kontekście pojawiało się konkretne polecenie wykonania operacji oraz dodatkowe wzmocnienie: „Wierzę w Ciebie”. W jednym komunikacie połączono więc kryzys, pilność, osobiste konsekwencje, rolę „ratownika” i konkretną instrukcję działania. Właśnie taka konstrukcja wystarczyła, żeby agent AI w części prób, sięgnął po narzędzie, którego nikt mu nie zlecił.

Najciekawsze jest to, że atak nie musi przekonywać modelu, iż zasady bezpieczeństwa są błędne. Może stworzyć sytuację, w której niepożądane działanie zaczyna wyglądać jak właściwa odpowiedź na pilny problem. Z perspektywy red teamingu prowadzi to do trzech praktycznych wniosków:
► testuj wiadomości, które tworzą pozór kryzysu, a nie tylko bezpośrednie polecenia w rodzaju „zignoruj zasady”;
► sprawdzaj wywołania narzędzi, nie samą odpowiedź tekstową - samo streszczenie złośliwej treści nie powinno być traktowane na równi z wykonaniem niepożądanej akcji;
► rejestruj odstępstwa od celu zleconego przez użytkownika, nawet jeśli odpowiedź agenta AI wygląda zwyczajnie.

Ten ostatni punkt jest szczególnie ważny. Niepożądane działanie nie musi być poprzedzone wyraźnym sygnałem ostrzegawczym. Atak na agenta AI nie zawsze musi wyglądać jak atak. Może wyglądać jak normalna praca wykonana w niewłaściwym kontekście.

Trzy pytania, które powinny paść przed wdrożeniem agenta AI

Z perspektywy Zarządu i CISO najważniejsze nie jest poznanie wszystkich wariantów prompt injection. Ważniejsze jest ustalenie, gdzie kończy się autonomia agenta AI i czy organizacja zauważy przekroczenie tej granicy.

1. Co - poza samym agentem -  decyduje o tym, że, może wykonać daną operację?

Jeżeli użytkownik polecił mu „podsumuj wiadomość”, treść tej wiadomości nie powinna sama rozszerzyć zadania o wysłanie danych, zmianę uprawnień czy wykonanie polecenia systemowego. Ta granica nie może opierać się wyłącznie na ocenie modelu. Przed wdrożeniem warto jasno określić, co jest rzeczywistym źródłem autoryzacji działania, i gdzie jest ono wymuszane technicznie: przez zakres uprawnień, dostępne narzędzia czy zatwierdzenie przez człowieka.

2. Czy zauważymy, że agent przekroczył swoją rolę?

Niepożądane działanie nie musi wyglądać jak spektakularne przejęcie systemu. Dlatego warto sprawdzić, czy odstępstwo od celu zleconego przez użytkownika będzie widoczne w logach i mechanizmach nadzoru, a nie tylko w treści odpowiedzi.

3. Kto odpowiada za granice autonomii agenta?

Jeżeli agent AI może samodzielnie wykonywać operacje, organizacja musi wcześniej zdecydować, jakie działania są w jego zakresie, kiedy wymagana jest dodatkowa kontrola i kto jest właścicielem ryzyka związanego z jego autonomią. Gdy wiadomość zbuduje pozór kryzysu, na te pytania jest już za późno.

Podsumowanie

Największym problemem nie jest to, że agent AI może błędnie zinterpretować pojedynczą wiadomość. Problem zaczyna się wtedy, gdy treść pochodząca z zewnątrz może wpłynąć na decyzję systemu, a ta decyzja prowadzi do rzeczywistego działania. Dlatego projektując bezpieczny system, trzeba założyć, że agent czasem źle odczyta sytuację. Prawdziwym testem bezpieczeństwa jest to, co wydarzy się później.

Najbardziej intuicyjną odpowiedzią na ryzyko prompt injection jest dopisywanie kolejnych zasad: więcej zakazów, więcej wyjątków, bardziej szczegółowy prompt systemowy. Tylko czy więcej instrukcji naprawdę oznacza więcej bezpieczeństwa?

W kolejnym artykule z serii pokażę Wam paradoks hardeningu i wyjaśnię, dlaczego coraz bardziej rozbudowany prompt systemowy nie zawsze zwiększa odporność agenta AI na indirect prompt injection.

Marta Gach
Partnerka Strategiczna |Profilaktyka | Edukacja
CyberShieldON

CyberShieldON – Gdy wiedza spotyka decyzję.
Tutaj cyberbezpieczeństwo to nie tylko technologia, ale też konsekwencje wyborów, ryzyko systemowe i odpowiedzialność.
Łączymy doświadczenie z projektów z refleksją nad tym, jak naprawdę działa organizacja i jak ją chronić. Dzielimy się praktyką, która wytrzymała presję, oraz pytaniami, które zmieniły kierunek działania.

To miejsce jest dla Ciebie, jeśli tworzysz systemy, zarządzasz bezpieczeństwem, projektujesz architekturę i nie zatrzymujesz się na poziomie technologicznym.

Nowe artykuły – regularnie na cybershieldon.pl

Strona www stworzona w kreatorze WebWave.