Cały ten cykl był o tym, jak składać kontekst dobrze.
Ten wpis jest o tym, że ktoś inny może go składać za Ciebie.
Sześć poprzednich wpisów traktowało okno kontekstu jak coś, co Ty projektujesz: co wpuścić, ile, w jakiej formie, kiedy pobrać. Założenie było ciche, ale fundamentalne — że wszystko, co trafia do okna, pochodzi od Ciebie i jest po Twojej stronie.
Przy agencie to założenie pęka. Agent autonomicznie pobiera dokumenty, czyta strony, przyjmuje wyniki narzędzi, przetwarza dane od użytkownika. Spora część tego, co ląduje w jego oknie, nie pochodzi od Ciebie — i nie zawsze jest przyjazna. To jest druga strona context engineeringu: okno kontekstu to nie tylko zasób do gospodarowania. To także powierzchnia ataku.
Ten wpis tylko otwiera temat od strony składania kontekstu. Pełne ujęcie prompt injection prowadzimy w cyberflux, a bezpieczeństwo agentów dla budujących — w osobnym artykule serii.
Dlaczego to w ogóle jest możliwe
Sedno problemu jest proste i niewygodne: model nie odróżnia z natury danych do przetworzenia od instrukcji do wykonania. W oknie wszystko jest tym samym — ciągiem tokenów. Twoja instrukcja systemowa, pytanie użytkownika, pobrany dokument, wynik narzędzia — to dla modelu jeden strumień tekstu, a nie zbiór warstw o różnym poziomie zaufania.
To znaczy, że jeśli w treści, którą agent pobiera albo przyjmuje, znajdzie się coś sformułowane jak polecenie — model może potraktować to jak polecenie. Nie dlatego, że został „zhakowany” w klasycznym sensie. Dlatego, że zrobił dokładnie to, do czego służy: przeczytał kontekst i się nim kierował. Tyle że ten kontekst dołożył ktoś inny.
To jest prompt injection. A w świecie agentów ma postać szczególnie kłopotliwą.
Każda warstwa, którą zbudowaliśmy, jest też wektorem
Mechanizmy, które przez sześć wpisów czyniły agenta użytecznym, są jednocześnie drogą wejścia dla zatrutego kontekstu.
Retrieval (C3) pobiera treści z zewnątrz — dokumenty, strony, bazy wiedzy. Jeśli choć jedno z tych źródeł zawiera spreparowaną instrukcję, agent wciąga ją do okna jako „wiedzę” i może za nią pójść. Just-in-time nie chroni przed tym sam z siebie — przeciwnie, automatyzuje pobieranie treści, których nikt ręcznie nie przejrzał.
Wyniki narzędzi (C6) wracają do okna jako podstawa następnego kroku. Jeśli narzędzie sięga po dane, które ktoś kontroluje — treść maila, zawartość strony, rekord wprowadzony przez użytkownika — to, co wraca, może nieść więcej niż dane.
Dane od użytkownika to najstarszy wektor: ktoś wprost wpisuje agentowi instrukcję, która ma nadpisać Twoją.
Rozróżnienie, które warto mieć w głowie, jest takie: atak bezpośredni to złośliwa instrukcja wpisana wprost przez użytkownika. Atak pośredni — groźniejszy dla agentów — to instrukcja ukryta w treści, którą agent pobiera albo czyta sam, bez udziału atakującego w danym momencie. Agent, który autonomicznie czyta internet, autonomicznie wciąga też to, co ktoś tam dla niego zostawił.
Dlaczego agent podnosi stawkę
Przy zwykłym chatbocie najgorsze, co prompt injection może zrobić, to skłonić model, żeby coś powiedział — ujawnił instrukcję systemową, zmienił ton, napisał coś niepożądanego. Nieprzyjemne, ale ograniczone do słów.
Agent nie tylko mówi. Agent działa — wywołuje narzędzia, wysyła dane, wykonuje operacje. Więc zatruty kontekst nie zatrzymuje się na „powiedz coś”. Przesuwa się w stronę „zrób coś”: wywołaj narzędzie, którego nie powinieneś, wyślij dane tam, gdzie nie trzeba, wykonaj akcję, której nikt nie autoryzował. To dokładnie ten moment, w którym pętla agenta— która czyni go potężnym — czyni go też niebezpiecznym, gdy steruje nim cudzy kontekst.
Postawa obronna — bez złudzeń
Nie ma jednego przełącznika, który „wyłącza” prompt injection — to obszar, w którym nie istnieje pełne rozwiązanie, tylko warstwy ograniczania ryzyka. Z perspektywy składania kontekstu liczą się przede wszystkim cztery.
Traktuj każdą wciąganą treść z zewnątrz jako dane, nie jako instrukcje. To zmiana nastawienia, nie ustawienie: wszystko, co przyszło z retrievalu, z narzędzia, od użytkownika, jest materiałem do przetworzenia, a nigdy poleceniem. Agent ma działać według Twojej instrukcji, a pobraną treść analizować — nie wykonywać.
Oddzielaj i oznaczaj warstwy zaufania w oknie. Wyraźne odgraniczenie „to jest niezaufana treść do analizy” od Twoich instrukcji pomaga modelowi nie pomylić jednego z drugim. Pomaga — nie gwarantuje. To utrudnienie, nie mur.
Ogranicz, co agent może zrobić (least privilege). Skoro stawką jest działanie, najmocniejsza obrona jest po stronie uprawnień, nie promptu. Agent powinien mieć dostęp tylko do tych narzędzi, których realnie potrzebuje, a akcje wrażliwe — wysłanie danych, operacje nieodwracalne — powinny wymagać potwierdzenia człowieka. Human-in-the-loop w czułych miejscach jest tu nie wygodą, lecz zabezpieczeniem.
Nie ufaj strukturze jako ochronie. Structured output porządkuje wynik i ułatwia jego walidację, ale samo w sobie nie powstrzymuje wstrzyknięcia — zatruta instrukcja może równie dobrze wyprodukować poprawny strukturalnie wynik. Walidacja kształtu to nie walidacja intencji.
Jak to wygląda w n8n
Najłatwiej zobaczyć to na przepływie, który czyta treść z zewnątrz — agent przetwarzający przychodzące maile, podsumowujący strony, reagujący na zgłoszenia od użytkowników. W każdym z tych przypadków treść wpadająca do modelu jest niezaufanym wejściem, choć w przepływie wygląda jak zwykłe dane między węzłami.
Praktyczna konsekwencja: zanim taka treść trafi do węzła z modelem, traktuj ją jak input z zewnątrz świata, nie jak własny kontekst. A narzędziom, które agent może wywołać w dalszych krokach — zwłaszcza tym, które coś wysyłają albo zmieniają — odbieraj swobodę tam, gdzie nie jest konieczna. Im mniej agent może, tym mniej może zrobić cudzy kontekst jego rękami.
Co z tego wynika — i co zamyka kategorię
Context engineering ma dwie twarze. Pierwsza, której poświęciliśmy sześć wpisów, to składanie okna pod jakość i koszt — co wpuścić, ile, w jakiej formie. Druga to świadomość, że nie wszystko, co wpada do okna, jest po Twojej stronie — i że te same mechanizmy, które robią agenta użytecznym, otwierają go na zatruty kontekst.
Obie twarze sprowadzają się do jednego pytania, które jest sednem całej tej kategorii: co dokładnie jest w oknie, skąd to pochodzi i czemu mu ufam. Kto umie odpowiedzieć na to przy każdym kroku, składa agenta i dobrze, i bezpiecznie.
Tym domykamy context engineering. Dalej temat rozgałęzia się w dwie strony, które mają u nas własne domy: głębia samego promptowania żyje na promptujemy.pl, a bezpieczeństwo — prompt injection i obrona agentów — w cyberflux i w serii o anatomii agenta.
Pojęcia ze słownika: Prompt injection · Grounding · Okno kontekstu · Just-in-time retrieval · Structured output · Human-in-the-loop
