Playbook G · Prompt injection i ataki na AI

Procedura reagowania na wstrzyknięcie instrukcji do modelu lub agenta AI. W systemach agentowych — gdzie prompt przekłada się na realną akcję (wywołanie narzędzia, zapytanie do bazy, wysłanie danych) — prompt injection to nie „ciekawostka", lecz ścieżka od tekstu do skutku. Playbook obejmuje wektor direct (bezpośredni prompt użytkownika) i indirect (wstrzyknięcie przez dokumenty/RAG/treść zewnętrzną).

Problem — prompt staje się akcją

Model językowy nie rozróżnia z natury „to jest zaufana instrukcja systemowa" od „to jest treść, którą mam tylko przetworzyć". Atakujący wykorzystuje tę lukę, umieszczając instrukcje tam, gdzie system spodziewa się danych.

• Direct prompt injection — użytkownik wprost próbuje nadpisać politykę: „zignoruj poprzednie instrukcje", „ujawnij system prompt", „wywołaj narzędzie X z parametrem Y".
• Indirect prompt injection — instrukcja ukryta w treści, którą model pobiera: dokument w RAG, strona WWW, e-mail, pole rekordu, metadane pliku. Model czyta „dane" i wykonuje ukrytą w nich komendę. To najgroźniejszy wariant — ofiara nie wpisała nic złośliwego.
• Skutki w systemie agentowym — nieautoryzowane wywołanie narzędzia, eksfiltracja danych przez kanał wyjścia (link, e-mail, zapytanie), obejście barier bezpieczeństwa, wykonanie akcji o wysokim ryzyku, ujawnienie sekretów lub system promptu.
• Dlaczego banki — agent z dostępem do danych klienta, systemów transakcyjnych czy narzędzi wewnętrznych zamienia „psucie odpowiedzi" w realne ryzyko operacyjne i prawne.

Rozwiązanie 1 — Separacja instrukcji (dane ≠ polityka)

Fundament: treść przetwarzana przez model nie może zmieniać jego polityki ani zakresu narzędzi.

• System prompt ≠ dane użytkownika — twarde rozdzielenie kanału instrukcji systemowych od kanału treści; polityka bezpieczeństwa nie jest nadpisywalna przez wejście.
• RAG jako treść niezaufana — wszystko, co model pobiera (dokumenty, wyniki wyszukiwania, strony), traktowane jest jako dane potencjalnie wrogie, nie jako instrukcje. Oznaczanie/ramkowanie kontekstu zewnętrznego.
• Treść dokumentu nie zmienia polityki narzędzi — żaden fragment pobranej treści nie może rozszerzyć allowlisty narzędzi ani podnieść uprawnień agenta.
• Least-context — model dostaje tylko niezbędny kontekst; im mniej niezaufanej treści w oknie, tym mniejsza powierzchnia indirect injection.

Rozwiązanie 2 — Tool firewall (kontrola akcji agenta)

Nawet jeśli injection przejdzie do modelu, nie może zamienić się w dowolną akcję. Bariera między „model chce" a „system wykonuje".

Rozwiązanie 3 — Output validation (walidacja wyjścia)

Kontrola tego, co agent zwraca i wysyła — ostatnia linia obrony przed skutkiem.

• Walidator zgodności — sprawdzenie, czy odpowiedź/akcja mieści się w polityce i oczekiwanym formacie; odrzucenie wyjść poza schematem.
• Detektor sekretów — skan wyjścia pod kątem kluczy, tokenów, danych osobowych, fragmentów system promptu — blokada zanim opuszczą system.
• Walidacja linków i źródeł — kontrola adresów wychodzących (możliwy kanał eksfiltracji przez URL), weryfikacja, że cytowane źródła istnieją i pokrywają twierdzenie.
• claim ≤ proof — twierdzenia bez pokrycia dowodowego są oznaczane jako GAP, nie prezentowane jako fakt. Doktryna systemu przenosi się na warstwę agentową.

Rozwiązanie 4 — Agent sandbox (bezpieczne środowisko)

• Środowisko testowe — nowe agenty/łańcuchy narzędzi uruchamiane najpierw w izolowanej piaskownicy, odseparowanej od produkcji.
• Brak produkcyjnych sekretów — sandbox nie ma dostępu do realnych kluczy, danych klientów ani systemów transakcyjnych.
• Symulacja przed egzekucją — akcje o skutku (dry-run) są symulowane i walidowane, zanim zostaną wykonane na realnych zasobach.
• Red-teaming injection — regularne testy odpornościowe znanymi wzorcami direct/indirect injection przed wdrożeniem i po każdej zmianie.

Playbook operacyjny — 7 kroków

Powiązania systemowe