Prompt injection: gdy agent AI wykona cudze polecenie

Agenty AI coraz częściej nie ograniczają się do podpowiedzi. Działają: wysyłają maile, uruchamiają kod, sięgają do systemów firmy. To zmienia charakter ryzyka. Jedno spreparowane polecenie, ukryte w mailu, dokumencie albo na stronie, może skłonić agenta do wykonania czynności, której nikt nie zlecił. 1 września 2026 Anthropic opublikował kartę systemową modeli Claude Fable 5.1 i Claude Mythos 5.1, w której odporność na pośredni prompt injection podano jako mierzalny wskaźnik. Dla zarządów i managerów oznacza to prostą zmianę: bezpieczeństwo agenta przestaje być tematem abstrakcyjnym, a staje się liczbą, o którą można zapytać dostawcę, oraz decyzją o tym, co agent w ogóle może zrobić.

Co się wydarzyło

1 września 2026 Anthropic wydał kartę systemową modeli Claude Fable 5.1 i Claude Mythos 5.1. Istotny jest sposób, w jaki opisano tam bezpieczeństwo. Odporność na atak typu prompt injection podano jako liczbę, rozbitą według powierzchni ataku, liczby prób atakującego i tego, czy włączono zabezpieczenia. Mythos 5.1 opisano jako najbardziej odporny model Anthropic na zewnętrznym benchmarku pośredniego prompt injection.

Znaczenie tego kroku wykracza poza pojedynczy model. Do tej pory pytanie „jak trudno przejąć tego agenta" nie miało wspólnej odpowiedzi. Anthropic pokazuje, że da się ją podać w formie, którą można porównywać między modelami i konfiguracjami. Z tych danych płynie też trzeźwy wniosek: pojedyncza próba ataku udaje się rzadko, ale skuteczność rośnie, gdy napastnik ponawia próby, a włączone zabezpieczenia mocno obniżają ryzyko, lecz go nie zerują.

Nie jest to odosobniony sygnał. Już w grudniu 2025 OpenAI, opisując wzmacnianie agenta przeglądarki Atlas, stwierdziło, że prompt injection prawdopodobnie nigdy nie zostanie w pełni rozwiązany, że tryb agentowy poszerza powierzchnię ataku i że nawet zaawansowane zabezpieczenia nie dają gwarancji deterministycznych. Innymi słowy: dostawcy modeli sami mówią, że tego ryzyka nie da się usunąć, można je tylko ograniczać.

Dlaczego to ma znaczenie dla firm

Prompt injection przestaje być ciekawostką techniczną w momencie, w którym agent dostaje prawo do działania. Dopóki model tylko odpowiada tekstem, spreparowana instrukcja jest co najwyżej błędną odpowiedzią. Gdy agent może wysłać maila, wystawić fakturę, pobrać dane albo zmienić rekord, ta sama instrukcja staje się czynnością o realnych skutkach.

Rośnie też skala. Gartner prognozuje, że do końca 2026 roku do 40% aplikacji firmowych będzie zawierać wyspecjalizowane agenty AI, wobec mniej niż 5% w 2025. Każdy taki agent, który ma prawo cokolwiek zrobić, powiększa powierzchnię, którą trzeba pilnować.

Najważniejsze jest jednak, gdzie leży decyzja. Gartner przewiduje, że do 2027 roku 40% przedsiębiorstw zdegraduje lub wyłączy autonomiczne agenty z powodu luk w nadzorze wykrytych dopiero po incydentach produkcyjnych. Analityk Gartnera Shiva Varma wskazuje, że firmy traktują nadzór nad agentami zero-jedynkowo, jako pełne zablokowanie albo pełne zaufanie, i to jest źródłem porażek. Zbyt luźne ograniczenia podnoszą ryzyko, zbyt sztywne spowalniają pracę i pchają ludzi w kierunku rozwiązań poza kontrolą. Bezpieczeństwo agenta jest więc decyzją zarządczą o zakresie uprawnień, a nie wyłącznie zadaniem dla działu IT.

Use case'y

Poniższe przykłady pokazują, gdzie ryzyko prompt injection przekłada się na konkretny proces i jaką decyzję trzeba przy nim podjąć.

Agent obsługi klienta czytający wiadomości z zewnątrz

Problem biznesowy: Agent obsługuje zapytania mailowe i zgłoszenia, czytając treści, które przysyła klient. Wśród nich może trafić się wiadomość ze spreparowanym poleceniem.

Rozwiązanie AI: Agent czyta zgłoszenie, klasyfikuje je i przygotowuje odpowiedź, ale nie wykonuje samodzielnie czynności o skutkach zewnętrznych, jak zmiana danych klienta czy zwrot środków.

Dane i procesy do wdrożenia: Oddzielenie treści od klienta, traktowanej jako niezaufana, od poleceń systemowych. Lista akcji dozwolonych bez zgody człowieka. Procedura eskalacji dla czynności wrażliwych.

Potencjalny efekt: Szybsza obsługa rutynowych zgłoszeń przy zachowaniu kontroli nad tym, co agent może zrobić bez nadzoru.

Ryzyko i ograniczenie: Pośredni prompt injection ukryty w treści zgłoszenia albo w załączniku. Agent, który ma prawo modyfikować konto klienta, jest tu najbardziej narażonym punktem.

Agent kodujący i DevOps uruchamiający kod

Problem biznesowy: Agent generuje i uruchamia kod, ma dostęp do repozytoriów, kluczy i infrastruktury. Spreparowane polecenie może skłonić go do ujawnienia sekretów albo do zmiany w środowisku produkcyjnym.

Rozwiązanie AI: Uruchamianie kodu w izolowanym środowisku, które egzekwuje, do jakich plików i zasobów sieci agent ma dostęp, niezależnie od tego, co każe mu wygenerowana instrukcja.

Dane i procesy do wdrożenia: Kontener wykonawczy na poziomie systemu, na przykład Microsoft MXC, którego izolację procesów przyjął już GitHub Copilot CLI. Rozdzielenie sekretów od kontekstu, do którego agent ma wgląd. Przegląd zmian przed wdrożeniem na produkcję.

Potencjalny efekt: Zachowanie tempa pracy zespołu przy ograniczeniu skutków, gdy agent zostanie przejęty.

Ryzyko i ograniczenie: Zbyt szerokie uprawnienia agenta i sekrety dostępne w tym samym kontekście, w którym agent czyta niezaufane dane.

Agent przeglądający sieć w celu researchu

Problem biznesowy: Agent zbiera informacje z internetu na potrzeby analiz, ofert lub monitoringu rynku. Odwiedzana strona może zawierać ukrytą instrukcję.

Rozwiązanie AI: Agent czyta i streszcza treści, ale nie wykonuje na ich podstawie akcji w systemach firmy bez potwierdzenia. Wybór modelu o wyższej, udokumentowanej odporności na pośredni prompt injection.

Dane i procesy do wdrożenia: Rozdzielenie fazy zbierania treści od fazy działania. Lista dozwolonych domen. Wskaźnik odporności modelu jako kryterium wyboru dostawcy.

Potencjalny efekt: Tańszy i szybszy research bez otwierania firmie furtki do systemów przez zewnętrzną stronę.

Ryzyko i ograniczenie: Odporność bez zabezpieczeń bywa słaba, a rośnie dopiero po ich włączeniu. Konfiguracja domyślna dostawcy nie zawsze jest tą najbezpieczniejszą.

Agent w finansach i zakupach z dostępem do systemów

Problem biznesowy: Agent wspiera obieg faktur, płatności lub zamówień i sięga do systemów księgowych oraz do skrzynek. Spreparowany dokument może próbować skierować płatność lub eksport danych.

Rozwiązanie AI: Agent przygotowuje transakcję i uzupełnia dane, ale zatwierdzenie płatności lub wysyłki wymaga człowieka. Limity kwotowe i progi, powyżej których akcja jest wstrzymywana.

Dane i procesy do wdrożenia: Reguła potwierdzania czynności o dużych skutkach. Limity i alerty. Logowanie każdej akcji z możliwością odtworzenia, kto i co zlecił.

Potencjalny efekt: Skrócenie obiegu dokumentów przy utrzymaniu kontroli nad ruchami pieniędzy i danych.

Ryzyko i ograniczenie: Faktura albo mail z ukrytym poleceniem. Bez progu zatwierdzania i logów przejęty agent działa bez śladu do czasu wykrycia skutku.

Co może zrobić polska firma

Punkt wyjścia jest ten sam dla dużej i małej organizacji: bezpieczeństwo agenta to nie kwestia lepszego zaklęcia w promptcie, tylko tego, co agent w ogóle może zrobić.

1. Nadaj uprawnienia według zasady minimum. Agent dostaje dostęp tylko do systemów i akcji, których wymaga jego zadanie. Wszystko poza tym jest domyślnie zamknięte.
2. Wskaż czynności, które wymagają człowieka. Płatność, wysyłka na zewnątrz, zmiana w systemie produkcyjnym i eksport danych to progi, przy których agent proponuje, a decyzję podejmuje osoba.
3. Traktuj treści z zewnątrz jako niezaufane. Mail, dokument, strona i wpis z bazy wiedzy nie są poleceniem, nawet gdy tak brzmią. Oddziel je od instrukcji systemowych.
4. Uruchamiaj agenta w środowisku, które egzekwuje granice. Kontener wykonawczy pokroju Microsoft MXC narzuca ograniczenia niezależnie od tego, co każe wygenerowana instrukcja.
5. Włącz logowanie i wyłącznik. Każda akcja agenta ma zostawiać ślad, a firma ma mieć sposób na zatrzymanie agenta w trakcie pracy.
6. Zrób z odporności kryterium zakupu. Pytaj dostawcę o skuteczność ataków prompt injection rozbitą według powierzchni, liczby prób i zabezpieczeń, i wybieraj mierzalne.
7. Wyznacz właściciela. Za zakres uprawnień i za reakcję na incydent musi odpowiadać konkretna osoba, nie „zespół".

Mierzalność jest tu warunkiem, nie dodatkiem. Jeśli firma nie loguje działań agenta i nie zna jego uprawnień, nie oceni, czy wdrożenie jest bezpieczne, ani nie odtworzy, co się stało po incydencie.

Ryzyka

Bezpieczeństwo danych. Najczęstszym skutkiem przejętego agenta jest wyciek. Agent z szerokim dostępem i bez rozdzielenia sekretów od kontekstu jest gotowym kanałem eksfiltracji.

Shadow AI. Zbyt sztywne blokady pchają zespoły do korzystania z narzędzi poza kontrolą firmy. Wtedy agenty działają na danych firmy bez żadnych ograniczeń, a organizacja nawet o tym nie wie. Gartner wprost wiąże nadmierne restrykcje z napędzaniem tego zjawiska.

Koszty. Zabezpieczenia, izolacja i przeglądy człowieka kosztują czas i pieniądze. Pominięcie ich jest tańsze do momentu pierwszego incydentu, którego koszt bywa wielokrotnie wyższy.

Błędne wdrożenie. Agent dołożony do procesu bez ograniczenia uprawnień wygląda jak sukces do dnia, w którym wykona cudze polecenie. Sam działający agent nie jest dowodem, że jest bezpieczny.

Brak właściciela procesu. Jeśli nikt nie odpowiada za uprawnienia agenta i za reakcję na incydent, decyzje o zakresie działania zapadają przypadkiem albo wcale.

Brak kontroli jakości wyników. Agent, którego nikt nie sprawdza, może przez długi czas działać błędnie lub pod dyktando spreparowanej treści, zanim skutek stanie się widoczny. Logowanie i progi zatwierdzania są tu jedyną siatką bezpieczeństwa.

Wnioski

Prompt injection to nie chwilowa luka, którą załata kolejna aktualizacja. Dostawcy modeli sami mówią, że tego ryzyka nie da się usunąć, można je tylko ograniczać.

Zmiana z 1 września 2026 jest praktyczna: odporność agenta na przejęcie staje się liczbą, o którą można zapytać i którą można porównać. To przenosi rozmowę z poziomu deklaracji na poziom danych.

Dla firmy oznacza to trzy decyzje. Ograniczyć uprawnienia agenta do niezbędnego minimum. Postawić człowieka przy czynnościach o dużych skutkach. Wybierać dostawców, którzy podają mierzalną odporność, a nie zapewnienia. Bezpieczeństwo agenta zaczyna się od pytania „co ten agent może zrobić", nie „co mu każemy".