Prompt injection w pracy agentów AI: na czym polega i jak się bronić w 2026
Prompt injection to atak, w którym treść czytana przez model (mail, dokument, strona, opis narzędzia) podszywa się pod instrukcję i zmienia zachowanie agenta. W systemie z dostępem do narzędzi nie kończy się na złej odpowiedzi: agent może wykonać niechcianą akcję. OWASP od dwóch edycji stawia go na pierwszym miejscu (LLM01).
Na czym polega zagrożenie typu "prompt injection" w kontekście pracy agentów AI?
Prompt injection to atak, w którym treść czytana przez agenta AI podszywa się pod instrukcję i zmienia jego działanie. Ponieważ agent ma dostęp do narzędzi, atak może wywołać niechcianą akcję, na przykład wysłanie maila lub pobranie danych. Ryzyko ograniczają najmniejsze uprawnienia, zatwierdzanie działań i pełny ślad audytowy.
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, dlaczego agenci podnoszą stawkę, co już wydarzyło się w praktyce i jak realnie ograniczać ryzyko, bez straszenia i bez obietnicy „odpornego modelu”.
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.
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.
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”.
Czy agent AI może usunąć firmową bazę danych?
Scenariusz „agent AI usunął firmową bazę danych” jest możliwy tylko wtedy, gdy system dostał uprawnienie do usuwania i zabrakło skutecznej granicy przed akcją nieodwracalną. Dlatego agent powinien mieć najmniejszy potrzebny zakres dostępu, wymagać zgody człowieka przed usunięciem oraz zostawiać ślad każdego wywołania narzędzia. Sam prompt nie powinien wystarczyć do zmiany produkcyjnych danych.
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:
| Incydent | Co się stało | Wniosek |
|---|---|---|
| EchoLeak (CVE-2025-32711) | Czerwiec 2025: pierwszy udokumentowany atak „zero-click” na produkcyjny system AI (Microsoft 365 Copilot). Jeden spreparowany mail wystarczał, by Copilot sięgnął po wewnętrzne pliki i wysłał ich treść na serwer atakującego, bez żadnej akcji użytkownika. | Sama treść, którą agent czyta, jest powierzchnią ataku. |
| Slack AI (PromptArmor) | Sierpień 2024: instrukcja umieszczona w publicznym kanale pozwalała wyprowadzić dane z kanałów prywatnych, w tym klucze API. | Pośredni injection przez treść, do której agent ma dostęp. |
| Cursor + Supabase MCP | Lipiec 2025: zgłoszenie do supportu skłoniło agenta z uprawnieniami service_role do zrzucenia produkcyjnej bazy do wątku widocznego dla użytkownika. | Nadmierne uprawnienia narzędzia zamieniają injection w wyciek bazy. |
| postmark-mcp (npm) | Wrzesień 2025: złośliwa paczka MCP przez około 8 dni po cichu wysyłała kopie maili (BCC) do atakującego. | Łańcuch dostaw narzędzi to też kanał ataku. |
| Amazon Q (AWS-2025-015) | Lipiec 2025: do repozytorium rozszerzenia trafił commit z instrukcją usuwania plików i zasobów AWS; wersja dotarła do około miliona instalacji. | Konfiguracja i instrukcje agenta wymagają kontroli jak kod. |
| TrapDoor | 2026: ukryte instrukcje zapisane znakami zero-width w plikach .cursorrules i CLAUDE.md próbowały skłonić asystenta do „skanu bezpieczeństwa”, który wykradał sekrety. Plik wyglądał na pusty. | Treść niewidoczna dla człowieka bywa widoczna dla modelu. |
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ą wdrożenia agenta AI, 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:
- Co agent może zrobić sam, a co tylko przygotowuje do zatwierdzenia?
- Jakie dane i narzędzia widzi i czy ma najmniejsze potrzebne uprawnienia?
- Jak oddzielacie treść niezaufaną od instrukcji?
- Co jest logowane i czy po incydencie da się odtworzyć, co się stało?
- 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.
Ź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
Najczęstsze pytania
- Czym jest prompt injection?
- To podatność, w której treść czytana przez model (mail, dokument, strona, opis narzędzia) zawiera ukrytą instrukcję i zmienia zachowanie modelu. W agentach z dostępem do narzędzi może prowadzić do niechcianej akcji, nie tylko złej odpowiedzi.
- Czym prompt injection różni się od jailbreaku?
- Jailbreak celuje w obejście zabezpieczeń modelu, a prompt injection zmienia funkcjonalne zachowanie aplikacji. Dla firmy groźniejszy jest injection: chodzi o niechcianą akcję, nie o nieprzyzwoitą odpowiedź.
- Czy można w pełni zabezpieczyć agenta przed prompt injection?
- Nie ma jednego filtra, który eliminuje ten atak. Ryzyko ogranicza się warstwami: rozdzielenie treści od instrukcji, najmniejsze uprawnienia, kontrola akcji, eskalacja do człowieka i ślad audytowy.
- Jak Syntalith ogranicza prompt injection?
- Granicami i izolacją: agent dostaje najmniejsze potrzebne uprawnienia, działa w izolowanym środowisku, nieodwracalne akcje wymagają zgody człowieka, a każde wywołanie narzędzia jest logowane.
Bezpłatny skan procesów
Zacznij od bezpłatnego skanu procesów.
- 30 minut z inżynierem, który będzie budował, nie z handlowcem.
- Przegląd procesów, które kosztują Cię najwięcej czasu i pieniędzy.
- Pisemne podsumowanie: co zautomatyzować, w jakiej kolejności, z widełkami kosztów.
Bez prezentacji sprzedażowej i bez zobowiązań. Jeśli automatyzacja nie ma sensu, też to napiszemy.
0 zł
30 minut · pisemne podsumowanie w 2 dni robocze
Terminy zobaczysz w swojej strefie czasowej.
Wolisz napisać? Formularz bez zobowiązań