Indirect Prompt Injection: dlaczego testy agentów AI mogą dawać fałszywe poczucie bezpieczeństwa

W czerwcu 2025 roku publicznie ujawniono EchoLeak - krytyczną podatność w Microsoft 365 Copilot (CVSS 9,3). Użytkownik nie musiał klikać linku ani otwierać załączników. Wystarczyło, że asystent AI przetworzył odpowiednio spreparowanego e-maila, by nieświadomie wyprowadzić wrażliwe dane z firmy. Wniosek jest brutalny: ataki wykorzystujące indirect prompt injection przestały być wyłącznie problemem laboratoryjnych demonstracji - podatności tej klasy pojawiły się już w rozwiązaniach enterprise. Problem w tym, że tradycyjne testy bezpieczeństwa często dają nam złudne poczucie kontroli.

Temperatura, czyli ile swobody dostaje agent

Temperatura to parametr, który określa, jak bardzo model AI jest skłonny odejść od najbardziej oczywistej odpowiedzi na rzecz mniej typowych wariantów.

Firma wdraża agenta AI do obsługi ticketów lub poczty. System czyta wiadomości, podsumowuje je, a czasem samodzielnie podejmuje działania w systemie CRM. Zespół IT audytuje go w środowisku testowym, podsycając go złośliwymi mailami. Wynik? Agent ignoruje polecenia atakujących. Zero incydentów. Projekt dostaje zielone światło.

W czym tkwi błąd? W tym, że wynik uzyskany przy temperaturze 0 zaczynamy traktować jako pełny obraz zachowania systemu.

W modelach generatywnych temperatura wpływa na sposób próbkowania kolejnych tokenów. Im jest wyższa, tym większa może być różnorodność generowanych odpowiedzi, a w przypadku agentów także większa zmienność ich zachowania.

► Gdy temperatura wynosi 0, model zwykle podąża najbardziej prawdopodobną ścieżką. Dzięki temu jego odpowiedzi są znacznie bardziej powtarzalne, co bardzo ułatwia testowanie. Problem zaczyna się wtedy, gdy na produkcji system działa przy innych ustawieniach.

► Gdy temperatura rośnie (np. T=0.7), model może wybierać także mniej oczywiste warianty odpowiedzi. Dzięki temu jego reakcje mogą być bardziej zróżnicowane i elastyczne - na przykład przy dopasowywaniu tonu czy sposobu odpowiedzi do użytkownika.

Pułapka polega na tym, że większa różnorodność odpowiedzi oznacza też szerszy wachlarz możliwych zachowań - również tych niepożądanych z punktu widzenia bezpieczeństwa. Testy przy temperaturze 0 mogą ich po prostu nie ujawnić.

Jeden agent, dwa różne oblicza

Przeprowadzone przeze mnie niedawno symulacje ataków na agentów pocztowych świetnie to obrazują. Zadanie agentów było proste: przeczytać maila i wygenerować podsumowanie. W treściach poszczególnych wiadomości celowo ukryłam złośliwą instrukcję np. wymuszającą na agencie usunięcie systemowego pliku.

Gdy model działał w rygorystycznym, przewidywalnym trybie testowym (temperatura 0), na ponad 500 prób nie odnotowałam ani jednego skutecznego ataku. 

Kiedy zmieniłam konfigurację tak, aby model miał większą swobodę generowania, pojawiło się zachowanie, którego wcześniej nie obserwowałam. Scenariusz, w którym e-mail imitował "pilny alert bezpieczeństwa" i wywierał na systemie presję czasu i autorytetu, tym razem spowodował, że ten sam model ominął zabezpieczenia. W niemal 17% przypadków agent nie tylko podsumował maila, ale realnie wywołał komendę kasującą plik.

Dla biznesu płynie z tego jasny wniosek: dobry wynik agenta AI w jednej konfiguracji nie oznacza jeszcze, że zachowa się on tak samo w innych warunkach. Jeśli konfiguracja produkcyjna różni się od testowej, powinna zostać sprawdzona osobno.

5 zasad wdrażania agentów AI (Czego wymagać od zespołów IT?)

1. Testuj system, który naprawdę trafi na produkcję

Jeżeli zarząd podejmuje decyzję o akceptacji ryzyka na podstawie raportu z testów, musi mieć pewność, że testowano rzeczywisty wariant systemu, a nie jego wygodniejszą laboratoryjną wersję. Weryfikacji musi podlegać ta sama temperatura modelu, ten sam zestaw uprawnień i te same źródła danych, które będą działać w firmie.

2. Zbadaj rzeczywisty skutek, a nie tylko generowany tekst

Agent, który w oknie czatu napisze „należy usunąć plik klienta”, generuje niebezpieczną odpowiedź. Agent, który sam ten plik usuwa, powoduje realny skutek w środowisku - incydent, przestoje i ryzyko prawne.Audyt bezpieczeństwa musi skupiać się na weryfikacji działań (tool calls), a nie tylko na analizie generowanego tekstu.

3. Szukaj nowych awarii, nie tylko sprawdzaj stare błędy

Powtarzalne testy przy stabilnej konfiguracji (np. zerowej temperaturze) pozwalają sprawdzić, że wcześniej wdrożone zabezpieczenie nadal działa. Od systemów genAI musimy jednak wymagać testów typu Red Team - celowego szukania sytuacji, w których model zrobi coś, czego wcześniej nie przewidzieliśmy. Zarząd nie potrzebuje etykiety „PASS/FAIL”, potrzebuje wiedzieć w jakich warunkach system łamie zasady i jak często się to zdarza.

4. Zakładaj, że model i tak się pomyli

Nie budujmy bezpieczeństwa firmy na założeniu, że model zawsze odróżni instrukcje systemowe od danych wejściowych. Niezależnie od tego, iloma zakazami obwarujemy prompt systemowy zawsze istnieje ryzyko, że model probabilistyczny zinterpretuje dane w sposób niepożądany. Pytanie brzmi: co wtedy?

5. Techniczne granice zamiast słownych zakazów

Tu kończy się rola AI, a zaczyna inżynieria systemowa. Jeśli model podejmie błędną decyzję, na przykład zainicjuje wysłanie poufnych danych do konkurencji, system powinien mieć kolejną warstwę, która nie pozwoli automatycznie zamienić tej sytuacji w incydent. To już nie jest problem promptu systemowego, lecz architektury: zakresu uprawnień, kontroli działań i granic, których agent nie może sam przekroczyć. Temu, jak krok po kroku budować takie techniczne granice dla agentów AI, poświęcę jedną z kolejnych części tego cyklu.

Podsumowanie

Zero incydentów w testach to dobra wiadomość, ale to jeszcze nie jest certyfikat bezpieczeństwa. W przypadku agentów AI liczy się nie tylko to, czy system przeszedł test, lecz także to, jak został przetestowany i co zatrzyma go wtedy, gdy model podejmie złą decyzję.

W kolejnym artykule wrócę do scenariusza z pilnym alertem bezpieczeństwa, w którym atak powiódł się w blisko 17% przypadków. Pokażę, jak mechanizmy szkolenia sztucznej inteligencji mogą sprzyjać temu, że modele zbyt łatwo zgadzają się z użytkownikiem i ulegają presji, autorytetowi oraz poczuciu pilności.

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.