Krótka odpowiedź

Nie wyeliminujesz prompt injection ustawieniem modelu ani filtrem — na rok 2026 nie ma niezawodnej naprawy na poziomie modelu. To, co możesz zrobić, to uczynić udany injection nieszkodliwym. Cała strategia polega na założeniu, że model zostanie oszukany, i zaprojektowaniu tak, by oszukanie go niczego złego nie umożliwiało. Oznacza to warstwowanie zabezpieczeń, tak by żadna pojedyncza usterka nie prowadziła do naruszenia.

Ten playbook to praktyczne uzupełnienie naszego wyjaśnienia, czym jest prompt injection i jakie incydenty wywołał. Przejdź przez warstwy poniżej po kolei — są z grubsza uszeregowane wedle wpływu.

Warstwa 1: Najmniejsze uprawnienia (zabezpieczenie o największym wpływie)

Niemal każde udokumentowane naruszenie przez prompt injection — eksfiltracja danych w EchoLeak, CVE z wykonaniem kodu w Copilocie i Cursorze — stało się groźne tylko dlatego, że asystent mógł wykonać potężną akcję. Usuń możliwość, a usuniesz szkodę.

  • Daj każdemu asystentowi minimum uprawnień do jego zadania. Bot wsparcia, który odpowiada na pytania, nie potrzebuje prawa zapisu do CRM. Streszczacz nie potrzebuje wysyłać e-maili.
  • Zawęź każdy poświadczenie. Klucze API i tokeny powinny dawać najmniejszą działającą rolę, nigdy dostępu na oślep. Token z pełnym dostępem do konta to token zdolny wyrządzić pełną szkodę na koncie.
  • Domyślnie tylko do odczytu. Uprawnienia zapisu, usuwania czy wysyłki nadawaj tylko tam, gdzie naprawdę trzeba, i każde traktuj jako decyzję o ryzyku.

Jeśli twój asystent nie może wykonać destrukcyjnej akcji bez człowieka, prompt injection każący mu to zrobić staje się nieudaną próbą w twoich logach — nie incydentem.

Warstwa 2: Granice zaufania — traktuj każdą pobraną treść jako niezaufaną

Pośredni prompt injection jedzie wewnątrz treści, którą model czyta: e-maile, strony WWW, dokumenty, pliki od użytkowników, wyniki narzędzi. Naprawa odzwierciedla dekady praktyki bezpieczeństwa webowego: nigdy nie ufaj wejściu spoza twojej granicy.

  • Sklasyfikuj źródła danych. Oznacz, która treść jest zaufana (twoje własne, zweryfikowane instrukcje systemowe), a która niezaufana (cokolwiek od użytkowników, z internetu, od osób trzecich, od dostawców).
  • Nigdy nie pozwól, by czytanie autoryzowało działanie. Model streszczający dokument nie może na mocy tekstu tego dokumentu wywołać płatności ani usunięcia.
  • Szczególnie uważaj na agentów, którzy przeglądają lub wciągają treść. W chwili, gdy asystent czyta dowolną zewnętrzną treść i dzierży potężne narzędzia, odtwarzasz dokładne warunki głośnych CVE. Rozdziel te dwie funkcje.

Warstwa 3: Człowiek w pętli przy ważnych akcjach

Automatyzacja to sens AI, ale nie każda akcja zasługuje na równą automatyzację. Bramkuj mały zbiór operacji, gdzie błąd jest kosztowny lub nieodwracalny.

  • Wymagaj wyraźnej zgody człowieka dla ruchu pieniędzy, usuwania lub eksportu danych, komunikacji na zewnątrz i wykonania kodu.
  • Spraw, by zatwierdzenie było sensowne. Pokaż człowiekowi, co się stanie, prostym językiem, by faktycznie mógł wyłapać anomalię — a nie był oknem na „przyklep”, które się przeklikuje.
  • To także zgodność z AI Act. Sensowny nadzór człowieka jest zarazem zabezpieczeniem i postawą zgodności przy zastosowaniach wyższego ryzyka.

Warstwa 4: Obsługa wejścia i wyjścia

Filtrowanie to warstwa, nie mur — ale warstwy się sumują.

  • Prześwietlaj wejścia pod kątem znanych wzorców injection, godząc się, że zdeterminowani atakujący wyprzedzają filtry. Traktuj to jako próg zwalniający.
  • Ograniczaj i waliduj wyjścia. Jeśli zadaniem modelu jest zwrócić kategorię, liczbę lub obiekt strukturalny, egzekwuj ten kształt — nie podawaj dowolnej treści wprost do wrażliwego systemu.
  • Izoluj generowany kod i polecenia. Nigdy nie wysyłaj kodu wygenerowanego przez model do ścieżki wykonania bez piaskownicy i przeglądu. Ta jedna luka umożliwiła RCE w Vanna AI.

Warstwa 5: Monitoring i wykrywanie

Załóż, że część prób się powiedzie, i zadbaj, byś je widział.

  • Loguj prompty, wywołania narzędzi i wyniki, by przejęcie dało się odtworzyć po fakcie.
  • Alarmuj o anomaliach — nieoczekiwane wywołania narzędzi, dane wychodzące na zewnątrz lub akcje niepasujące do prośby użytkownika. Nasz tekst o wykrywaniu zmanipulowanego asystenta opisuje sygnały.
  • Regularnie przeglądaj logi. Wykrywanie działa tylko wtedy, gdy ktoś patrzy.

Plan działania

  1. Zrób audyt możliwości. Wypisz każdą akcję i integrację każdego asystenta. To twoja powierzchnia ataku.
  2. Wdroż najmniejsze uprawnienia. Odbierz każdą możliwość, która nie jest ściśle potrzebna; zawęź każde poświadczenie do najwęższej roli.
  3. Wykreśl granice zaufania. Oznacz zaufane i niezaufane źródła treści i zadbaj, by czytanie niezaufanej treści nigdy nie mogło autoryzować akcji.
  4. Zabramkuj groźną garstkę. Postaw zgodę człowieka przed płatnościami, usunięciami, wysyłkami na zewnątrz i wykonaniem kodu.
  5. Wsadź generowany kod do piaskownicy i waliduj wyjścia strukturalne, zanim dotkną prawdziwego systemu.
  6. Włącz logowanie i alerty, a potem faktycznie je przeglądaj wedle harmonogramu.

Model, który potrafi tylko sugerować, jest niskiego ryzyka bez względu na to, jak źle go wstrzyknięto. Model, który potrafi działać, potrzebuje każdej z powyższych warstw. Zacznij od najmniejszych uprawnień — to zabezpieczenie, które zamienia najwięcej ataków w nic.

Chcesz wersję w formie checklisty dla zespołu? Pobierz naszą darmową checklistę sygnałów ostrzegawczych deepfake i ataków AI i przerób te warstwy w jednostronicowy przegląd dla własnych wdrożeń.