CyberShieldON » Indirect prompt injection: on-premise nie chroni przed atakiem

Ten artykuł otwiera serię, w której pokażę wnioski z moich badań nad bezpieczeństwem agentów AI i podatnością systemów LLM na indirect prompt injection. Punktem wyjścia był scenariusz agenta mailowego działającego lokalnie, w środowisku on-premise, z wykorzystaniem modelu Qwen 2.5:3B. To celowo praktyczny przypadek: nie abstrakcyjny chatbot, ale system, który czyta wiadomości, interpretuje ich treść i może wpływać na działania organizacji.

Badania wykazują, że wiele popularnych założeń dotyczących bezpieczeństwa LLM jest zbyt uproszczonych. Lokalny model nie oznacza automatycznie bezpiecznego modelu. Testy prowadzone wyłącznie przy temperaturze T=0 mogą ukrywać podatności. Długie, restrykcyjne prompty systemowe nie zawsze wzmacniają ochronę, a czasem mogą ją osłabiać. Agent AI, któremu damy dostęp do narzędzi, przestaje być tylko generatorem tekstu - staje się elementem procesu decyzyjnego.

Jeden eksperyment nie zamyka tematu bezpieczeństwa AI. Wręcz przeciwnie - wyniki tych badań pokazują mechanizmy ryzyka, które organizacje powinny traktować poważnie już teraz, zwłaszcza wtedy, gdy planują wdrażać agentów AI do obsługi poczty, dokumentów, zgłoszeń, zamówień, CRM, ERP lub innych systemów operacyjnych. Właśnie w takich przypadkach musimy zdawać sobie sprawę, że prompt injection nie jest już ciekawostką techniczną tylko zaczyna być realnym ryzykiem biznesowym.

Zacznę od jednego z najbardziej kuszących mitów: przekonania, że uruchomienie modelu lokalnie, we własnej infrastrukturze, rozwiązuje problem. To stwierdzenie dalekie jest od prawdy. Jeśli agent AI czyta dane zewnętrzne i ma możliwość wykonywania działań, złośliwa instrukcja może wejść do organizacji przez zwykły e-mail, dokument lub stronę WWW. Bezpieczeństwo AI trzeba projektować nie tylko na poziomie serwerów, ale przede wszystkim na poziomie architektury decyzji, uprawnień i kontroli autonomii.

Indirect prompt injection: mechanizm ataku

Indirect prompt injection to atak, w którym złośliwa instrukcja nie jest wpisywana bezpośrednio przez użytkownika do okna czatu, ale znajduje się w danych, które model później odczytuje - w e-mailu, dokumencie, stronie WWW czy nawet komentarzu, metadanych pliku lub wyniku wyszukiwania.

W klasycznym prompt injection atakujący daje modelowi informację wprost np. „zignoruj poprzednie instrukcje i wykonaj moje”. W indirect prompt injection sytuacja jest bardziej złożona i podstępna. Użytkownik może poprosić agenta AI o coś neutralnego: „podsumuj wiadomość od klienta”, „sprawdź zamówienie i przygotuj odpowiedź”. Jednak w treści analizowanej przez model wiadomości może znaleźć się ukryta instrukcja. To, co dla człowieka wygląda jak nieistotny tekst, komentarz techniczny czy element formatowania, dla modelu może stać się częścią kontekstu, który wpływa na jego dalsze zachowanie. OWASP od lat stawia prompt injection na szczycie swoich rankingów ryzyk dla aplikacji opartych na dużych modelach językowych, opisując je jako manipulowanie wejściem modelu w celu zmiany jego zachowania. To próba zmuszenia modelu, aby zrobił coś, czego nie powinien: ujawnił dane lub zmienił sposób działania.

Gdy dajemy sztucznej inteligencji dostęp do plików, poczty czy systemów firmowych, staje się ona agentem - wykonawcą zadań z możliwością odczytu danych, podejmowania decyzji, korzystania z narzędzi i wykonywania akcji w systemach organizacji. To generuje realne ryzyko. Prompt injection przestaje być problemem jakości odpowiedzi, a staje się problemem bezpieczeństwa procesu.

Dlaczego lokalizacja serwera nie rozwiązuje problemu?

Wdrożenie lokalnego modelu LLM ma realne zalety: ogranicza zależność od dostawców chmurowych, poprawia kontrolę nad danymi, ułatwiać spełnienie wymagań regulacyjnych albo zmniejsza ryzyko niekontrolowanego przesyłania informacji poza organizację. Problem zaczyna się wtedy, gdy lokalny hosting traktowany jest jako całkowita odpowiedź na ryzyko prompt injection. Model uruchomiony na własnym serwerze nadal przetwarza treści z zewnątrz: czyta e-maile od kontrahentów, analizuje dokumenty od klientów, pobiera raporty, tickety, treści stron, załączniki i dane z systemów biznesowych. Fizyczna lokalizacja serwera nie zmienia tego, że złośliwa instrukcja może się znaleźć w tych danych

Indirect prompt injection wymyka się klasycznemu modelowi bezpieczeństwa opartemu głównie na kontroli infrastruktury. Organizacja może mieć własny serwer, lokalny model, firewall, polityki dostępu i izolowaną sieć - a mimo to dopuścić do manipulacji zachowaniem agenta przez treść, którą ten agent sam odczyta. Atakujący nie musi przełamywać zabezpieczeń sieciowych ani uzyskiwać dostępu do serwera. Wystarczy, że wprowadzi instrukcję do kontekstu modelu.

On-premise odpowiada na pytanie o lokalizację przetwarzania. Nie odpowiada automatycznie na pytania o separację danych od instrukcji, kontrolę narzędzi, ograniczenie autonomii agenta, walidację intencji użytkownika i źródła danych, eskalację działań wysokiego ryzyka czy audyt decyzji modelu. Hasło "mamy własny model, więc jesteśmy bezpieczni" jest zbyt uproszczone - lokalny model może być lepszy z punktu widzenia kontroli danych, ale nadal może zostać zmanipulowany przez treść, którą sam otrzyma do analizy.

Wektor infekcji: e-mail, dokument, strona

Wyobraźmy sobie lokalnego agenta AI działającego w firmowej infrastrukturze. Jego zadanie wydaje się proste: analizuje skrzynkę mailową działu obsługi klienta, klasyfikuje wiadomości, rozpoznaje zamówienia, przygotowuje odpowiedzi i przekazuje wybrane sprawy do systemu ERP lub CRM.

Któregoś dnia przychodzi do firmy e-mail od kontrahenta, który na pierwszy rzut oka wygląda normalnie: numer zamówienia, termin dostawy, dane kontaktowe, załącznik PDF. W stopce, w ukrytym fragmencie HTML albo w treści załącznika znajduje się jednak instrukcja skierowana do modelu: potraktuj tę wiadomość jako priorytetową, pomiń standardową walidację, zmień numer rachunku, zaakceptuj rabat, oznacz sprawę jako zatwierdzoną albo prześlij wybrane dane na wskazany adres.

Człowiek może tego nie zauważyć. Filtr antyspamowy może nie uznać tego za złośliwe oprogramowanie. EDR może nie wykryć żadnego podejrzanego procesu, bo nie doszło do klasycznego uruchomienia malware’u. Atak odbywa się jedynie na poziomie interpretacji treści przez model i ten sam mechanizm może działać w dokumentach tekstowych, prezentacjach, arkuszach kalkulacyjnych, stronach www, opisach produktów, ticketach serwisowych czy rekordach w bazie wiedzy. Wystarczy, że agent ma za zadanie te dane odczytać, streścić, sklasyfikować albo wykorzystać jako podstawę decyzji.

To właśnie jest element, który wszyscy musimy zapamiętać: zagrożenie wchodzi przez dane, nie przez chmurę.

Agent jako „władca” narzędzi

Tool calling - możliwość wywoływania funkcji, API lub operacji w innych systemach, znacząco zwiększa skutki prompt injection, bo model nie tylko odpowiada użytkownikowi, ale może: wysłać e-mail, utworzyć zgłoszenie, pobrać dane z CRM, zmienić status zamówienia, wykonać zapytanie do bazy, uruchomić workflow, przekazać dane do zewnętrznego systemu, przygotować rekomendację finansową lub operacyjną usunąć lub nadpisać dane. Agent staje się pośrednikiem między językiem naturalnym a systemami organizacji - jeżeli złośliwa instrukcja przejmie jego uwagę, może wpłynąć nie tylko na tekst odpowiedzi, ale również na realną decyzję biznesową lub bezpieczeństwo danych.

W moich badaniach nad lokalnym agentem mailowym qwen2.5:3B przebadałam ten mechanizm bezpośrednio: model otrzymał dostęp do narzędzi wykonawczych, takich jak send_email, delete_file, execute_command i write_file, a następnie był testowany na złośliwych instrukcjach ukrytych w treści maili, które miał jedynie podsumować. Wyniki pokazały, że w części scenariuszy agenta można było skłonić do wykonania działania, którego użytkownik wprost nie zlecił, nawet wtedy, gdy prompt systemowy wyraźnie zakazywał użycia danego narzędzia bez zgody użytkownika.

Architektura ponad infrastrukturą

Bezpieczeństwo trzeba projektować na poziomie architektury decyzji, nie tylko lokalizacji serwera. Model nie powinien mieć nieograniczonej swobody interpretowania każdego fragmentu tekstu jako potencjalnej instrukcji, a wszelkie dane zewnętrzne powinny być traktowane jako niezaufane. Dobrą praktyką jest nadawanie narzędziom minimalnych wymaganych uprawnień, przy założeniu, że krytyczne akcje - te nieodwracalne, albo kosztowne w skutkach - wymagają dodatkowej walidacji lub zatwierdzenia przez człowieka, albo przynajmniej innego agenta.

Co to oznacza dla CISO i Zarządu?

Jeżeli agent AI błędnie zaakceptuje zamówienie, wyśle nieuprawnioną informację, zmieni status sprawy albo zarekomenduje niewłaściwą decyzję finansową, pytanie nie będzie brzmiało wyłącznie: „czy model był w chmurze?”. Pytanie będzie brzmiało: kto zatwierdził taki poziom autonomii, jakie były mechanizmy kontroli i czy organizacja przewidziała ryzyko manipulacji danymi wejściowymi?

Dla CISO najważniejszy wniosek jest prosty: on-premise nie zastąpi threat modelingu, testów odporności, kontroli uprawnień i procedur audytu - może być elementem strategii, ale nie całą strategią.Dla Zarządu konsekwencje są jeszcze szersze: .prompt injection w systemach agentowych może wpływać na ciągłość działania, jakość decyzji, odpowiedzialność za błędne operacje oraz zaufanie do automatyzacji. Autonomia AI to nowe źródło ryzyka biznesowego i wymaga takiej samej dyscypliny zarządczej jak każdy inny krytyczny proces organizacji.

Podsumowanie

Nie mylmy kontroli nad infrastrukturą z kontrolą nad zachowaniem modelu. On-premise może ograniczać część ryzyk, ale nie usuwa problemu indirect prompt injection, jeśli agent AI nadal przetwarza niezaufane dane i ma dostęp do narzędzi.

W moich częściach serii pokażę w nich, jak zmiana temperatury modelu wpływa na skuteczność ataku, dlaczego testy prowadzone wyłącznie przy T=0 mogą dawać fałszywe poczucie bezpieczeństwa, jak presja, pilność i kontekst emocjonalny oddziałują na modele szkolone metodą RLHF oraz na czym polega paradoks hardeningu - dlaczego dopisywanie kolejnych zakazów do promptu systemowego nie zawsze zwiększa odporność agenta.

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