Prompt injection w pracy agentów AI: na czym polega i jak się bronić

Prompt injection to dziś najczęściej demonstrowany atak na systemy oparte o modele językowe, a w przypadku agentów, które same wykonują pracę, jego skutki wychodzą poza „zła odpowiedź”. Ten tekst tłumaczy, na czym polega, dlaczego agenci podnoszą stawkę, co już wydarzyło się w praktyce i jak realnie ograniczać ryzyko, bez straszenia i bez obietnicy „odpornego modelu”.

Szybka odpowiedź

Prompt injection to podatność, w której dane wejściowe czytane przez model zawierają ukrytą instrukcję i zmieniają jego zachowanie. Model nie odróżnia twardo „polecenia od twórcy systemu” od „treści do przetworzenia”: jedno i drugie trafia do tego samego okna kontekstu. Dla zwykłego chatbota efektem jest błędna odpowiedź. Dla agenta z dostępem do narzędzi (poczta, pliki, API, baza danych) efektem może być niechciana akcja wykonana w imieniu firmy: wysłany mail, zmieniony rekord, pobrane dane.

OWASP wpisuje prompt injection na pierwsze miejsce listy zagrożeń dla aplikacji LLM (LLM01) w edycjach 2023 i 2025, a w grudniu 2025 publikuje osobną listę dla aplikacji agentowych. To nie jest błąd jednego dostawcy, tylko cecha architektury: dopóki instrukcje i dane płyną jednym kanałem, ryzyko trzeba ograniczać warstwami, a nie „załatać” jednym filtrem.

Na czym polega prompt injection

Bezpośredni prompt injection to instrukcja wpisana wprost przez użytkownika („zignoruj poprzednie polecenia i...”). Groźniejszy bywa injection pośredni: instrukcja ukryta w treści, którą agent czyta po drodze, w mailu, w dokumencie PDF, na stronie WWW, w zgłoszeniu od klienta, w opisie narzędzia albo w pamięci z poprzedniej sesji. Agent traktuje tę treść jako kontekst do pracy, a w rzeczywistości czyta cudze polecenie.

OWASP odróżnia prompt injection od jailbreaku: jailbreak celuje w obejście zabezpieczeń modelu, a injection zmienia funkcjonalne zachowanie aplikacji. Dla firmy ważniejszy jest zwykle ten drugi przypadek. Nie chodzi o to, czy model powie coś nieprzyzwoitego, tylko czy wykona akcję, której nie zlecił żaden człowiek.

Dlaczego agenci podnoszą stawkę

Trzy cechy wdrożeń agentowych sprawiają, że ten sam atak boli mocniej:

• Wspólne okno kontekstu. System prompt, wiadomość użytkownika, pobrane dokumenty, wynik narzędzia, historia i pamięć trafiają do jednego strumienia tokenów, bez twardej granicy zaufania między „instrukcją” a „danymi”.
• Trwała pamięć. Injection zapisany do pamięci długoterminowej, korpusu RAG albo bazy wektorowej zatruwa każdą kolejną sesję, która z tego źródła czyta.
• Wykonywanie akcji. Gdy wyjście modelu uruchamia narzędzia (pliki, shell, poczta, API chmury, serwery MCP, podagenci), zasięg rażenia rozciąga się z okna czatu na wszystko, do czego sięgają narzędzia. Wyniki narzędzi wracają do kontekstu, co umożliwia łańcuchy akcji.

OWASP nazywa powiązane ryzyko „Excessive Agency” (LLM06): im szersze uprawnienia agenta, tym wyższy sufit szkody przy udanym ataku. To jest sedno wyceny ryzyka. Nie pytasz „czy model się pomyli”, tylko „co najgorszego może zrobić, gdy się pomyli”.

Realne incydenty 2024–2026

To nie jest ryzyko teoretyczne. Poniżej publicznie udokumentowane przypadki, każdy z innym wektorem, ale z tym samym źródłem:

Badania nad skutecznością ataków pokazują, że przy odpowiedniej liczbie prób injection przebija nawet czołowe modele (rzędu 89% dla GPT-4o i 78% dla Claude 3.5 Sonnet w jednym z testów), a dotychczasowe zabezpieczenia raczej spowalniają atak, niż go eliminują. Do zatrucia odpowiedzi systemu RAG potrafi wystarczyć kilka spreparowanych dokumentów.

Jak się przed tym bronić

Nie ma jednego filtra, który „wyłącza” prompt injection. Działa obrona warstwowa, w której każda warstwa odbiera atakowi część zasięgu. Tak właśnie czytamy siedem kryteriów agenta: nie jako listę cech, tylko jako miejsca, w których ogranicza się szkodę.

• Rozdziel uprzywilejowany model od treści. We wzorcu dual-LLM (opisanym przez Simona Willisona) model, który trzyma narzędzia, nie czyta wprost treści niezaufanej, a model „kwarantanny” czyta treść, ale nie może działać. To rozcina drogę, którą instrukcja musiałaby przejść, żeby dotrzeć do akcji. (Narzędzia, Granice)
• Najmniejsze uprawnienia narzędzi. Agent dostaje tylko te akcje i dane, których realnie potrzebuje. Klucz service_role, który omija zabezpieczenia na poziomie wiersza, to gotowy scenariusz wycieku. (Granice)
• Kontrola akcji względem pierwotnego celu. Każde wywołanie narzędzia jest sprawdzane wobec tego, o co poprosił człowiek, a nie wobec tego, co model „wymyślił” po drodze. (Granice, Pomiar)
• Człowiek w pętli przy akcjach nieodwracalnych. Wysyłka do klienta, zmiana w ERP, płatność czy usunięcie danych wymagają zatwierdzenia. (Eskalacja)
• Ślad audytowy. Każda decyzja i każde wywołanie narzędzia są logowane, więc po fakcie wiadomo, co agent zrobił i dlaczego. (Ślad)
• Modele-strażnicy obok kontroli deterministycznych, nie zamiast nich. Filtry typu Llama Guard czy NeMo Guardrails pomagają, ale same w sobie nie są granicą.

W Syntalith ograniczanie jest domyślną częścią projektu, nie dodatkiem. Używamy LangGraph, gdy każdy krok ma być audytowalny, i OpenClaw, gdy zadanie jest otwarte: w izolowanych maszynach wirtualnych, z zakresowanymi danymi, logiem i zgodą człowieka przed wpływem na produkcję. Różnica nie polega na tym, czego używamy. Polega na tym, że wiemy, kiedy i jak to ograniczyć.

Co to znaczy przy wyborze wykonawcy

Prompt injection jest też praktycznym testem na agent-washing. Zanim zapłacisz za „agenta AI”, zapytaj wykonawcę o pięć rzeczy, które wprost odpowiadają na to ryzyko:

1. Co agent może zrobić sam, a co tylko przygotowuje do zatwierdzenia?
2. Jakie dane i narzędzia widzi i czy ma najmniejsze potrzebne uprawnienia?
3. Jak oddzielacie treść niezaufaną od instrukcji?
4. Co jest logowane i czy po incydencie da się odtworzyć, co się stało?
5. Gdzie działa agent i jak odizolowane są jego narzędzia?

Jeśli wykonawca nie ma odpowiedzi na te pytania, najpewniej sprzedaje chatbota z dostępem do systemów, a nie kontrolowanego agenta. Jak czytać te kryteria krok po kroku, tłumaczymy w przewodniku czym jest agent AI.

Prompt injection a AI Act

Od 2 sierpnia 2026 obowiązek z art. 50 AI Act wymaga, by systemy rozmawiające z ludźmi ujawniały, że są AI. To osobny obowiązek przejrzystości, nie zabezpieczenie przed injection, ale idzie w parze z tym samym podejściem: jawność, ślad rozmowy i możliwość przejęcia kontroli przez człowieka.

Najważniejsze w jednym zdaniu

Prompt injection to problem architektury, nie pojedynczy błąd do załatania. Model traktuje instrukcje i dane jako jeden strumień, więc bezpieczny agent powstaje przez granice, najmniejsze uprawnienia, eskalację i ślad, a nie przez obietnicę „odpornego modelu”. Najbezpieczniejsze założenie brzmi: traktuj model jak niezaufanego interpretatora, nie jak samodzielnego decydenta.

Zacznij od procesu, nie od modelu

Jeśli planujesz agenta, który ma sięgać do Twoich systemów, zacznij od bezpłatnego skanu procesów. W 30 minut z inżynierem ustalimy, co agent ma robić, czego mu nie wolno i gdzie wchodzi człowiek. To samo myślenie, które ogranicza prompt injection, ogranicza też koszt i ryzyko wdrożenia.

Umów bezpłatny skan procesów | Czym jest agent AI | Oferta wdrożenia agenta AI

Źródła

• OWASP Top 10 for LLM Applications, 2025 (LLM01: Prompt Injection, LLM06: Excessive Agency)
• OWASP Top 10 for Agentic Applications, grudzień 2025
• EchoLeak: CVE-2025-32711 (Aim Security)
• Slack AI data exfiltration (PromptArmor, 2024)
• Cursor + Supabase MCP (General Analysis, 2025)
• Amazon Q: AWS-2025-015
• Simon Willison: wzorzec dual-LLM przeciw prompt injection

Powiązane artykuły

• Czym jest agent AI: siedem kryteriów
• Ile kosztuje agent AI: cennik wdrożenia 2026
• Oferta wdrożenia agenta AI