Bezpieczna inżynieria agentowa: security by design dla agentów AI

Krótka odpowiedź: czym jest bezpieczna inżynieria agentowa

Bezpieczna inżynieria agentowa to podejście, w którym decyzje bezpieczeństwa zapadają razem z decyzjami architektonicznymi agenta AI — na etapie projektowania, nie po wdrożeniu. Pytanie „jakie narzędzia dostanie agent“ i pytanie „co najgorszego zrobi, jeśli zostanie oszukany“ rozstrzyga się w tej samej rozmowie, przez ten sam zespół, w tym samym momencie procesu. To nie jest lista kontrolna doklejona do gotowego produktu, tylko właściwość samej architektury: zakres narzędzi, środowisko wykonania, granice zaufania wobec danych i punkty zgody człowieka są częścią projektu agenta w takim samym stopniu jak jego prompt systemowy czy dobór modelu.

Różnica wobec „audytu po fakcie“ jest praktyczna, nie ideologiczna. Audyt sprawdza gotowy system i wyłapuje to, co już zbudowano źle — a poprawianie architektury po jej zbudowaniu jest drogie, bo dotyka fundamentów, które trudno ruszyć bez przebudowy całości. Bezpieczna inżynieria agentowa podejmuje te same decyzje wcześniej, gdy zmiana kosztuje tyle, co wybór innego wzorca projektowego na kartce, a nie refaktoryzację działającego systemu produkcyjnego. To ta sama logika, którą branża oprogramowania przeszła już raz przy „shift left“ w testowaniu i przy privacy by design w ochronie danych — bezpieczeństwo agenta AI przechodzi teraz tę samą drogę.

Ten artykuł nie opisuje pojedynczej techniki obronnej. Jest ramą, która pokazuje, gdzie w procesie budowy agenta zapadają decyzje odpowiadające za konkretne ryzyka z listy OWASP Top 10 dla aplikacji agentowych — i linkuje do materiałów, które każdą z tych technik rozkładają na czynniki pierwsze. Jeśli szukasz szczegółów o konkretnym mechanizmie obronnym, w tekście znajdziesz odnośniki do właściwego miejsca. Jeśli szukasz odpowiedzi na pytanie „kiedy w ogóle o tym pomyśleć“ — jesteś we właściwym miejscu.

Dlaczego audyt po fakcie zawsze przychodzi za późno

Typowy scenariusz wygląda tak: zespół buduje agenta skupiony na funkcji — ma streszczać dokumenty, obsługiwać zgłoszenia, wykonywać zapytania do wewnętrznych systemów. Bezpieczeństwo pojawia się na końcu, jako punkt na liście przed wdrożeniem: „zróbmy przegląd bezpieczeństwa“. W tym momencie agent ma już nadane szerokie uprawnienia, bo nikt nie zawężał ich świadomie — po prostu dodawano narzędzia w miarę potrzeb funkcjonalnych. Ma już dostęp do danych wrażliwych, bo to było wygodne przy budowie. Wykonuje kod na tej samej maszynie co reszta usługi, bo tak było szybciej na etapie prototypu.

Przegląd bezpieczeństwa w takim momencie znajduje dziesiątki problemów — i każdy z nich wymaga przebudowy czegoś, co już działa. Zawężenie uprawnień narzędzia oznacza przepisanie integracji. Przeniesienie wykonania kodu do izolowanego środowiska oznacza zmianę infrastruktury. Wprowadzenie zgody człowieka dla działań nieodwracalnych oznacza przeprojektowanie przepływu, z którym użytkownicy już się oswoili w wersji testowej. Nic z tego nie jest niewykonalne — ale wszystko jest droższe, niż gdyby te decyzje zapadły trzy tygodnie wcześniej, zanim ktokolwiek napisał choć jedną integrację.

Gorszy wariant tego scenariusza nie ma w ogóle przeglądu bezpieczeństwa przed wdrożeniem — ma incydent. Analizy realnych naruszeń bezpieczeństwa agentów AI pokazują ten sam wzorzec z zaskakującą regularnością: agent z szerszymi uprawnieniami, niż wymagało zadanie, przetworzył treść, której nie powinien był traktować jak polecenia, i wykonał akcję, której nie dało się cofnąć. Żaden z tych incydentów nie wynikał z tego, że ktoś świadomie zaakceptował ryzyko. Wynikał z tego, że nikt w porę nie zadał pytania, które bezpieczna inżynieria agentowa stawia na starcie: co najgorszego zrobi ten agent, jeśli zostanie oszukany przez treść, którą czyta?

To pytanie jest tanie do zadania na etapie projektu i kosztowne do zadania po fakcie. Cała reszta tego artykułu jest rozwinięciem jednej myśli: zadaj je wcześnie, przy każdej decyzji architektonicznej, a nie raz, na końcu, w formie audytu.

Czym jest inżynieria agentowa i gdzie w niej mieści się bezpieczeństwo

Inżynieria agentowa to dyscyplina projektowania, budowania i utrzymywania agentów AI działających niezawodnie w produkcji — nie pojedynczy prompt czy jedna integracja z modelem, tylko cały cykl życia systemu, który realizuje cel autonomicznie, wywołując narzędzia, przetwarzając kontekst i podejmując kolejne kroki bez człowieka zatwierdzającego każdy z osobna. Obejmuje warstwy, które w praktyce projektowej przenikają się nawzajem: dobór i konstrukcję narzędzi, zarządzanie kontekstem i pamięcią, warstwę wykonawczą (harness) odpowiedzialną za uruchamianie akcji, ewaluację i obserwowalność.

W tym układzie bezpieczeństwo nie jest osobną warstwą doklejoną obok pozostałych. Jest kryterium obecnym w każdej z nich. Decyzja o tym, jakie narzędzia dostanie agent, jest jednocześnie decyzją funkcjonalną (co agent potrafi zrobić) i decyzją bezpieczeństwa (co najgorszego zrobi, jeśli zostanie oszukany). Decyzja o architekturze pamięci jest jednocześnie decyzją o tym, jak dobrze agent pamięta kontekst zadania, i decyzją o tym, czy da się tę pamięć zatruć złośliwym wpisem, który wpłynie na przyszłe działania. Rozdzielanie tych dwóch pytań na „zespół produktowy decyduje o funkcji“ i „zespół bezpieczeństwa robi przegląd na końcu“ jest źródłem problemu opisanego wyżej — traktuje jako dwie osobne decyzje coś, co od początku jest jedną.

Warto tu jedno rozróżnienie: bezpieczna inżynieria agentowa nie zastępuje testów bezpieczeństwa ani przeglądów przed wdrożeniem. Red-teaming i systematyczna ewaluacja pozostają niezbędnym elementem procesu — ale ich rola się zmienia. Zamiast szukać problemów, które trzeba teraz kosztownie naprawiać, weryfikują, czy decyzje podjęte wcześniej faktycznie działają tak, jak zakładano. To różnica między testem, który znajduje wadę projektu, a testem, który potwierdza, że projekt trzyma.

Sześć punktów w procesie, w których decydują się losy ataku

Poniżej rozkładam proces budowy agenta na sześć punktów decyzyjnych, w których architektura albo zawęża pole rażenia przyszłego ataku, albo je poszerza — nieświadomie, bo nikt w danym momencie o tym nie pomyślał. Każdy punkt odpowiada konkretnej klasie ryzyka z listy OWASP Top 10 dla aplikacji agentowych (ASI01–ASI10) i łączy się z materiałem, który opisuje właściwą technikę obronną szczegółowo.

Punkt w procesie	Pytanie, które trzeba zadać	Powiązane ryzyko ASI	Gdzie to rozwijamy
Definicja celu i zakresu	Co dokładnie agent ma robić — i czego wyraźnie nie ma robić?	ASI01 (przejęcie celu agenta)	niżej w tym artykule
Dobór i zakres narzędzi	Jakich narzędzi agent naprawdę potrzebuje do tego zadania, a nie „na wszelki wypadek“?	ASI02, ASI03	minimalne uprawnienia narzędzi
Pochodzenie narzędzi i danych	Skąd pochodzi każdy komponent, z którego agent korzysta — i czy ktoś to zweryfikował?	ASI04 (łańcuch dostaw)	granice zaufania wobec serwerów MCP
Środowisko wykonania	Gdzie fizycznie uruchamia się to, co agent generuje lub pobiera?	ASI05 (niezamierzone wykonanie kodu)	sandboxing i izolacja narzędzi agenta
Granica wejścia i wyjścia	Co filtruje się, zanim dotrze do modelu, i co filtruje się, zanim model to wykona?	ASI01, ASI06	guardrails: filtrowanie wejścia i wyjścia
Punkty zgody i nadzoru	Które działania są nieodwracalne — i kto je zatwierdza, zanim się wykonają?	ASI08, ASI09, ASI10	defense in depth: cały model obrony

Poniżej rozwijam każdy z tych punktów — nie jako osobną technikę do wdrożenia na końcu, tylko jako pytanie, które powinno paść w konkretnym momencie procesu, zanim padnie kolejna linia kodu.

Definicja celu i zakresu: gdzie zaczyna się ASI01

Pierwsza decyzja, jaką podejmuje każdy zespół budujący agenta, brzmi: co ma robić? Rzadko pada drugie pytanie, równie ważne: czego wyraźnie nie ma robić, nawet jeśli technicznie mógłby? To pytanie wygląda na oczywiste, ale w praktyce projektowej ginie, bo zespoły definiują agenta przez to, co potrafi, a nie przez granice tego, co wolno mu zrobić.

Ta luka ma nazwę w taksonomii ryzyk: ASI01, przejęcie celu agenta. Agent, którego zakres zadania nie został jasno ograniczony na starcie, jest podatny na sytuację, w której treść z zewnątrz — dokument, e-mail, wynik wyszukiwania — podsuwa mu nowy „cel“, a on nie ma wbudowanego kryterium, by odróżnić go od zadania oryginalnego. Jeśli zakres nigdy nie został spisany precyzyjnie, nie ma też względem czego sprawdzić, że coś odbiega od niego.

Praktyczna konsekwencja projektowa: zanim zapadnie jakakolwiek decyzja o narzędziach czy architekturze, spisz zakres zadania agenta w formie, która da się egzekwować w kodzie, a nie tylko opisać w dokumentacji. „Agent podsumowuje przychodzące dokumenty i nie inicjuje żadnej komunikacji na zewnątrz“ jest zakresem, który da się przełożyć na brak narzędzia do wysyłki wiadomości. „Agent pomaga w obsłudze klienta“ nie jest — bo nie mówi, czego agentowi nie wolno.

Dobór i zakres narzędzi: gdzie ASI02 i ASI03 albo dostają szansę, albo nie

To najważniejsza pojedyncza decyzja w całym procesie, bo determinuje, ile w ogóle jest do stracenia, jeśli poprzednia warstwa zawiedzie. Zasada jest prosta do wypowiedzenia i trudna do konsekwentnego stosowania: agent dostaje wyłącznie te narzędzia, których wymaga bieżące zadanie, i żadnego „na wszelki wypadek“. Każde narzędzie ponad ten zakres jest powierzchnią ataku oddaną za darmo — bo jeśli agent kiedykolwiek da się oszukać (a prędzej czy później się da), to właśnie zestaw narzędzi decyduje, jak poważne będą tego skutki.

To nie jest lista kontrolna do przejrzenia na koniec. To jest pytanie zadawane przy każdym nowym narzędziu w trakcie projektowania: co najgorszego zrobi ten agent, jeśli użyje tego narzędzia pod wpływem wstrzykniętej instrukcji? Jeśli odpowiedź brzmi „nic poważnego“ — narzędzie zostaje. Jeśli odpowiedź brzmi „wyśle pieniądze“ albo „usunie dane produkcyjne“ — narzędzie wymaga dodatkowej bramki, zanim w ogóle trafi do zestawu.

Pełny zestaw technik — capability scoping, bramkowanie uprawnień poza modelem, dynamiczne zawężanie narzędzi do etapu zadania i punkty zgody człowieka dla działań nieodwracalnych — rozkładam osobno w materiale o narzędziach agenta o minimalnych uprawnieniach. To bezpośrednia ochrona przed ASI02 (nadużycie narzędzi) i ASI03 (nadużycie tożsamości i uprawnień) — a jednocześnie decyzja, którą architektonicznie taniej podjąć na starcie niż odkręcać po fakcie, bo zawężenie zestawu narzędzi w działającym systemie oznacza przepisanie integracji, na których już ktoś polega.

Pochodzenie narzędzi i danych: gdzie mieszka ASI04

Agent rzadko jest zbudowany wyłącznie z własnego kodu. Korzysta z bibliotek, wtyczek, rejestrów narzędzi i serwerów MCP (Model Context Protocol) dostarczających mu zewnętrzne możliwości. Każdy z tych elementów to komponent, którego integralności zespół budujący agenta nie kontroluje bezpośrednio — a decyzja, żeby go w ogóle podłączyć, zapada zwykle w pięć minut, bo „ten serwer robi dokładnie to, czego potrzebujemy“.

To jest dokładnie ten moment, w którym rozstrzyga się ASI04 — podatności łańcucha dostaw. Serwer MCP, który zostaje podłączony bez weryfikacji pochodzenia, działa z uprawnieniami agenta i dyktuje zachowanie jego narzędzi; podstawiony lub przejęty komponent wpływa na agenta z tą samą siłą, jakby ktoś zmienił jego kod źródłowy — tyle że nikt tego kodu nie przejrzał. Materiał o granicach zaufania wobec serwerów MCP opisuje dokładnie, jak podstawione serwery wchodzą do systemu i jak je weryfikować, przypinać do konkretnych wersji i izolować.

Decyzja projektowa, którą warto podjąć na starcie, a nie po incydencie: lista dozwolonych źródeł narzędzi i komponentów, z których agent może korzystać, plus zasada, że nic spoza tej listy nie trafia do zestawu bez świadomej weryfikacji. To dokładnie ten sam mechanizm, który OWASP przywołuje przy udokumentowanym nadużyciu integracji z GitHub przez MCP — zaufanie do gotowego łącznika okazało się słabym ogniwem, bo nikt nie zapytał wcześniej, jakie uprawnienia ten łącznik faktycznie dostaje.

Środowisko wykonania: gdzie decyduje się ASI05

Jeśli agent generuje lub pobiera kod i go uruchamia, pytanie „gdzie to się dzieje fizycznie“ jest jedną z najważniejszych decyzji architektonicznych — i jedną z najczęściej odkładanych na później, bo na etapie prototypu „działa na tej samej maszynie“ jest po prostu szybsze. Problem w tym, że przeniesienie wykonania kodu do izolowanego środowiska po zbudowaniu systemu wymaga zmiany infrastruktury, którą dużo taniej zaprojektować od razu.

To jest miejsce, w którym rozstrzyga się ASI05 — niezamierzone wykonanie kodu. Wykonanie dowolnego, złośliwego lub po prostu błędnego kodu omija wszystkie wyższe warstwy logiki bezpieczeństwa: napastnik nie musi już przekonywać modelu do niczego, skoro raz uruchomiony kod robi, co chce. Przewodnik po sandboxingu i izolacji narzędzi agenta rozkłada dostępne prymitywy izolacji — od kontenerów o współdzielonym jądrze po microVM — i pokazuje, kiedy który z nich jest właściwym wyborem. Kluczowa decyzja projektowa brzmi: niezaufany kod generowany przez agenta nigdy nie trafia na tę samą maszynę co reszta systemu, niezależnie od tego, jak bardzo to przyspieszyłoby pierwszą wersję.

Granica wejścia i wyjścia: gdzie ASI01 i ASI06 spotykają filtrowanie

Każdy fragment treści, który agent pobiera z zewnątrz — strona, dokument, wynik wywołania narzędzia — i każda odpowiedź, którą generuje przed jej wykonaniem, przechodzi (albo nie) przez punkt kontroli. Decyzja, czy taki punkt w ogóle istnieje, zapada na etapie projektowania przepływu danych przez agenta, a nie przy przeglądzie bezpieczeństwa.

Filtrowanie wejścia i wyjścia to pierwsza warstwa obrony przed ASI01 (przejęcie celu) na poziomie treści oraz przed ASI06 (zatrucie pamięci i kontekstu) — jeśli treść trafiająca do pamięci długoterminowej agenta przechodzi przez tę samą kontrolę co treść trafiająca do bieżącego kontekstu. Materiał o guardrails opisuje mechanikę: etykietowanie treści niezaufanej, skan wejścia pod kątem znanych wzorców i kontrolę odpowiedzi modelu zanim zostanie wykonana. Ważne zastrzeżenie architektoniczne: to warstwa pierwszego sita, nie ostatniej linii obrony — a projektowanie systemu tak, jakby guardrails wystarczały samodzielnie, jest błędem, do którego wracam w kolejnej sekcji.

Punkty zgody i nadzoru: gdzie mieszkają ASI08, ASI09 i ASI10

Ostatni punkt decyzyjny dotyczy tego, co dzieje się, gdy wszystkie wcześniejsze warstwy zawiodą naraz. Które działania agenta są na tyle poważne, że wymagają wyraźnej zgody człowieka, zanim się wykonają? Które sygnały powinny zatrzymać cały potok, zanim błąd rozleje się dalej? Kto — i w jaki sposób — może wyłączyć agenta, jeśli zacznie działać poza oczekiwanym wzorcem?

Te pytania odpowiadają na trzy powiązane ryzyka z listy ASI: kaskadowe awarie (ASI08), nadużycie zaufania między człowiekiem a agentem (ASI09) oraz agenty wymknięte spod kontroli (ASI10). Wspólny mianownik: żadna pojedyncza warstwa obrony nie wytrzyma zawsze, więc architektura potrzebuje punktu, w którym człowiek albo mechanizm nadzoru przejmuje kontrolę, zanim skutek stanie się nieodwracalny. To dokładnie temat, który defense in depth dla autonomicznych agentów AI rozwija jako spójny model — pięć warstw obrony ułożonych tak, by luka w jednej nie kładła całego systemu.

Co potwierdzają realne incydenty: awaria jednego konkretnego punktu, nie całej architektury

Powyższe sześć punktów nie jest teoretycznym podziałem — każdy z udokumentowanych incydentów agentów AI daje się przypisać do konkretnego punktu procesu, w którym decyzja zapadła źle albo nie zapadła wcale.

EchoLeak (CVE-2025-32711, ujawniony publicznie w czerwcu 2025 r. przez badaczy z Aim Security, naprawiony przez Microsoft server-side jeszcze w maju 2025 r., przed publicznym ujawnieniem) jest awarią dokładnie punktu piątego: granicy wejścia i wyjścia. Treść e-maila napisanego przez atakującego trafiła do tego samego kontekstu, w którym Copilot przetwarzał dane wrażliwe użytkownika, a mechanizm wyjścia pozwolił na automatyczne pobranie obrazka z adresem zawierającym wykradzione dane. Żadna z warstw kontrolujących ten łańcuch nie została pominięta przez przypadek — po prostu w architekturze nie było punktu, który jednoznacznie oddzielał treść niezaufaną od uprzywilejowanego kontekstu i kontrolował, dokąd może popłynąć odpowiedź modelu. Pełną sekcję zwłok tego i dwóch innych naruszeń rozkładamy osobno w materiale o anatomii naruszenia przez prompt injection.

Udokumentowane nadużycie integracji z GitHub przez MCP, przywoływane przez OWASP przy ASI04, jest z kolei awarią punktu trzeciego: weryfikacji pochodzenia i zakresu komponentów. Token dostępu podłączony do agenta obejmował znacznie szerszy zasięg repozytoriów, niż wymagało zadanie — a to, czy taki zakres w ogóle był potrzebny, to pytanie, które powinno paść przy podłączaniu integracji, nie po tym, jak ktoś już wykazał, że da się je nadużyć.

Kampania TeamPCP / LiteLLM z marca 2026 roku, która skompromitowała szeroko używane proxy bramy AI i zebrała poświadczenia w wielu systemach naraz, pokazuje ten sam wzorzec o poziom wyżej: w miarę jak infrastruktura łącząca agentów — bramy, rejestry narzędzi, serwery MCP — konsoliduje się, jedna kompromitacja opłaca się atakującemu wobec wielu ofiar naraz. To dokładnie ryzyko, przed którym chroni lista dozwolonych źródeł komponentów opisana w punkcie trzecim — z tą różnicą, że tutaj skala awarii dotyczy nie jednego agenta, lecz całej tkanki łączącej wielu agentów w organizacji.

Wspólny mianownik tych trzech przypadków: żaden nie wymagał „złego modelu“ ani wyrafinowanego exploita. Każdy wymagał jednej pominiętej decyzji na wczesnym etapie procesu — decyzji, która w momencie projektowania kosztowałaby jedno pytanie zadane na spotkaniu architektonicznym, a po incydencie kosztowała już znacznie więcej.

Jak warstwy obrony wyglądają, gdy są częścią procesu, nie dodatkiem

Poniższy diagram pokazuje uproszczony przekrój tych warstw w momencie, gdy realny atak próbuje dotrzeć od treści wejściowej do uprzywilejowanego działania. To nie jest lista kontrolna do odhaczenia po wdrożeniu — to układ, który powstaje z decyzji podjętych na wcześniejszych etapach opisanych wyżej: zakres narzędzi (filtr wejścia i uprawnienia), środowisko wykonania (izolacja) i punkty zgody (zatwierdzenie człowieka).

Zwróć uwagę na kolejność, w jakiej te warstwy powstają w procesie inżynierskim — bo nie jest ona przypadkowa. Filtr wejścia i zakres uprawnień zapadają razem, na etapie doboru narzędzi. Izolacja zapada na etapie projektowania środowiska wykonania. Zgoda człowieka zapada na etapie mapowania działań nieodwracalnych. Żadna z tych decyzji nie czeka na to, aż ktoś przeprowadzi test penetracyjny gotowego systemu — bo do tego momentu wszystkie już są częścią architektury.

Dlaczego kolejność decyzji ma znaczenie, nie tylko ich obecność

Zespoły, które próbują wprowadzić bezpieczeństwo do już zbudowanego agenta, często sięgają najpierw po guardrails — bo to najłatwiejsza warstwa do dodania bez ruszania architektury: kilka reguł w prompcie systemowym, może klasyfikator bezpieczeństwa. To zrozumiały odruch, ale odwrócona kolejność względem tego, co faktycznie ogranicza szkody.

Guardrails to warstwa językowa, działająca na tym samym poziomie co treść, którą ma filtrować — reguła w prompcie systemowym jest tekstem w tym samym kontekście, w którym ląduje wstrzyknięcie, a model waży obie po swojemu. Wystarczająco przekonująco sformułowany atak potrafi tę regułę przebić. Zawężenie zestawu narzędzi działa inaczej: narzędzia, którego agent nie posiada, nie da się nadużyć żadnym sformułowaniem, bo decyzja zapadła poza zasięgiem modelu, w kodzie, do którego wstrzyknięta treść nie ma dostępu.

Stąd praktyczna kolejność priorytetów przy projektowaniu (i przy poprawianiu) bezpieczeństwa agenta: najpierw zakres narzędzi i uprawnień, bo to największy efekt przy najmniejszym koszcie i bo ogranicza skutki, zanim jeszcze cokolwiek pójdzie źle. Potem środowisko wykonania, jeśli agent uruchamia kod. Potem punkty zgody dla działań nieodwracalnych. Guardrails i filtrowanie treści dopiero na końcu tej listy priorytetów — nie dlatego, że są zbędne, tylko dlatego, że jako warstwa odsiewająca szum mają sens dopiero wtedy, gdy pod spodem stoi już solidny fundament: wąskie uprawnienia, izolacja i jasno zdefiniowane punkty nadzoru. Ta sama logika kolejności wybrzmiewa w pełnym modelu defense in depth — tu pokazuję tylko, że wynika ona wprost z tego, kiedy w procesie budowy agenta każda z tych decyzji faktycznie zapada.

Weryfikacja jako część procesu, nie jednorazowy test

Bezpieczna inżynieria agentowa nie kończy się na projekcie architektury. Decyzje podjęte na wcześniejszych etapach trzeba sprawdzić — nie raz, przed pierwszym wdrożeniem, tylko cyklicznie, bo zestaw narzędzi agenta rośnie razem z produktem, a każde nowe narzędzie to nowa powierzchnia ataku, którą ktoś musiał świadomie ocenić.

To miejsce, w którym red-teaming i systematyczna ewaluacja wpisują się w proces inżynierski jako jego stały element, a nie jednorazowa bramka przed wdrożeniem. Narzędzia ofensywne — takie jak Garak, PyRIT czy Promptfoo — automatyzują sprawdzanie, czy decyzje o zakresie uprawnień i izolacji faktycznie trzymają pod presją zorganizowanego ataku, a nie tylko w teorii projektu. Praktyczny wzorzec: każda zmiana w zestawie narzędzi agenta albo w granicach jego uprawnień uruchamia ten sam zestaw testów ofensywnych, którym poddano wersję pierwotną — dokładnie tak, jak zmiana w kodzie uruchamia testy jednostkowe. Bezpieczeństwo przestaje być punktem na osi czasu i staje się bramką w potoku, przez którą przechodzi każda kolejna wersja.

Mapa: gdzie w cyklu życia agenta pojawia się każde ryzyko ASI

Zebrana całość wygląda następująco — nie jako lista technik do wdrożenia w dowolnej kolejności, tylko jako mapa punktów decyzyjnych w procesie budowy agenta, z których każdy odpowiada za konkretną klasę ryzyka.

1. Definicja celu i zakresu — spisany, egzekwowalny w kodzie zakres zadania. Zapobiega ASI01 u źródła, zanim jeszcze pojawi się jakiekolwiek narzędzie.
2. Dobór narzędzi — capability scoping, bramkowanie poza modelem, zgoda człowieka dla działań nieodwracalnych. Bezpośrednia ochrona przed ASI02 i ASI03.
3. Weryfikacja pochodzenia komponentów — lista dozwolonych źródeł narzędzi i serwerów MCP, przypięte wersje. Ochrona przed ASI04.
4. Projekt środowiska wykonania — izolacja kodu generowanego lub pobieranego przez agenta. Ochrona przed ASI05.
5. Granica wejścia i wyjścia — etykietowanie treści niezaufanej, filtrowanie odpowiedzi przed wykonaniem. Ochrona przed ASI01 na poziomie treści i przed ASI06.
6. Punkty zgody i nadzoru — bezpieczniki, ograniczanie tempa, wyłącznik awaryjny, zatwierdzenie człowieka. Ochrona przed ASI08, ASI09 i ASI10.
7. Weryfikacja cykliczna — red-teaming wbudowany w potok wydawniczy, uruchamiany przy każdej zmianie zestawu narzędzi, nie raz na projekt.

Każdy z tych siedmiu punktów odpowiada momentowi w procesie inżynierskim, w którym pada konkretne pytanie projektowe — nie liście kontrolnej, którą ktoś odhacza po fakcie. To jest cała różnica między bezpieczeństwem wbudowanym a audytem.

Od czego zacząć, jeśli budujesz agenta od zera

Jeśli stoisz na początku procesu, kolejność, w jakiej warto zadawać powyższe pytania, jest taka sama jak kolejność, w jakiej faktycznie zapadają decyzje architektoniczne. Zacznij od spisania zakresu zadania w formie, którą da się przełożyć na ograniczenia w kodzie, a nie tylko opisać w dokumentacji projektowej. Przy każdym narzędziu, zanim trafi do zestawu, zadaj pytanie o najgorszy możliwy skutek jego nadużycia. Zdecyduj o środowisku wykonania kodu, zanim napiszesz pierwszą integrację, która ten kod generuje. Zmapuj działania nieodwracalne i postaw przy nich punkt zgody, zanim ktokolwiek zacznie polegać na przepływie bez niego. Dopiero na końcu tej listy dołóż filtrowanie treści i guardrails jako warstwę odsiewającą szum nad już solidnym fundamentem.

Żaden z tych kroków nie wymaga czekania na komplet pozostałych — każdy osobno zmniejsza pole rażenia potencjalnego ataku. Ale kolejność, w jakiej je podejmujesz, decyduje o tym, czy budujesz bezpieczeństwo w architekturę, czy doklejasz je do niej później, drożej i z gorszym skutkiem.

---

Ten artykuł jest częścią obszaru „Obrona i utwardzanie“ w secagentlabs i pełni rolę ramy łączącej — pokazuje, na którym etapie procesu inżynierskiego zapada każda decyzja bezpieczeństwa, i odsyła do materiałów opisujących poszczególne techniki szczegółowo. Klasyfikacje ryzyk pochodzą z OWASP Top 10 for Agentic Applications (ASI01–ASI10), opublikowanej 9 grudnia 2025 roku. Nie stanowi to instrukcji konfiguracji konkretnego produktu — każde wdrożenie wymaga dopasowania do własnego modelu zagrożeń.