Bezpieczeństwo agentów AI - uprawnienia, sandboxing i dziennik działań, zanim agent coś zepsuje

W lipcu 2025 roku agent AI w Replit usunął produkcyjną bazę danych firmy Jasona Lemkina, inwestora z branży SaaS. Zrobił to w trakcie zamrożenia zmian, mimo wyraźnego polecenia, żeby bez zgody niczego nie ruszać. Zniknęły dane ponad 1 200 menedżerów i prawie 1 200 firm. W badaniu Cloud Security Alliance opublikowanym w kwietniu 2026 roku 53% organizacji przyznało, że ich agenci AI przekroczyli zakładane uprawnienia, a 47% miało w ostatnim roku incydent bezpieczeństwa z udziałem agenta. Dziś nie da się niezawodnie zablokować każdej złośliwej instrukcji, którą agent przeczyta, dlatego bezpieczeństwo agenta polega przede wszystkim na ograniczeniu tego, co może zrobić, gdy coś pójdzie nie tak.

53% firm przyznaje, że ich agenci AI przekroczyli zakładane uprawnienia. Czego uczą incydenty z Replit, GitHub MCP i EchoLeak, czym jest zabójcze trio i zasada dwóch oraz pięć warstw ochrony: uprawnienia, sandbox, limity, akceptacja człowieka i dziennik działań.

W tym wpisie pokazuję, dlaczego agent to nowe ryzyko w porównaniu z chatbotem, czego uczą prawdziwe incydenty, czym jest zabójcze trio i zasada dwóch, a potem pięć warstw ochrony: najmniejsze uprawnienia, sandboxing, bezpieczniki, nadzór człowieka i dziennik działań. Na końcu znajdziesz listę kontrolną przed wdrożeniem.

Dlaczego agent to nowe ryzyko

Chatbot odpowiada tekstem, a człowiek decyduje, co z nim zrobić. Agent sam wykonuje działania: wysyła maile, zmienia statusy w CRM, wystawia dokumenty w ERP, uruchamia kod albo zleca płatności. Błąd chatbota kończy się złą odpowiedzią. Błąd agenta może skończyć się wysłanym przelewem albo skasowaną bazą.

OWASP opisuje to ryzyko w swojej liście zagrożeń dla aplikacji LLM jako nadmierną sprawczość (Excessive Agency, LLM06:2025) i wskazuje trzy przyczyny:

• Za dużo funkcji. Agent ma narzędzia, których do swojego zadania nie potrzebuje.
• Za duże uprawnienia. Narzędzia działają na koncie z szerszym dostępem, niż wymaga zadanie.
• Za dużo samodzielności. Agent wykonuje ważne lub nieodwracalne działania bez akceptacji człowieka.

W grudniu 2025 roku OWASP opublikował osobną listę dziesięciu zagrożeń dla aplikacji agentowych. Na pierwszych miejscach są przejęcie celu agenta, nadużycie narzędzi i nadużycie tożsamości oraz uprawnień agenta.

Skalę problemu widać też w danych SailPoint z 2025 roku. W ankiecie wśród 353 specjalistów IT 80% firm zgłosiło, że ich agenci AI wykonali niezamierzone działania. 39% widziało dostęp agenta do systemów, do których nie miał uprawnień, a 23% przypadki, w których agenta nakłoniono do ujawnienia danych logowania.

Czego uczą prawdziwe incydenty

Większość głośnych przypadków z ostatnich miesięcy ma ten sam schemat: agent przeczytał treść z zewnątrz, miał dostęp do ważnych danych albo systemów i mógł coś zrobić bez kontroli. Część z nich to prawdziwe incydenty, część to badania, w których naukowcy pokazali, jak łatwo przeprowadzić atak.

Po incydencie w Replit prezes firmy Amjad Masad zapowiedział automatyczne oddzielenie baz testowych od produkcyjnych i tryb, w którym agent tylko planuje, ale niczego nie zmienia. To dobry przykład, że skuteczne zabezpieczenia są w architekturze systemu, a nie w treści promptu.

Zabójcze trio i zasada dwóch

Simon Willison, programista i autor jednego z najczęściej czytanych blogów o LLM, w czerwcu 2025 roku opisał zabójcze trio (lethal trifecta). To połączenie trzech cech, które razem pozwalają wykraść dane:

1. 1.Dostęp do prywatnych danych, na przykład do skrzynki, CRM albo dokumentów.
2. 2.Kontakt z niezaufaną treścią, czyli mailami, stronami internetowymi, zgłoszeniami albo plikami od obcych osób.
3. 3.Możliwość komunikacji na zewnątrz, na przykład wysłanie maila, zapytanie do zewnętrznego adresu albo publiczny komentarz.

Jeśli agent ma wszystkie trzy, wystarczy jedna złośliwa instrukcja ukryta w treści, żeby wysłał dane atakującemu. Willison zwraca uwagę, że narzędzia filtrujące ataki obiecują zwykle wykrycie około 95% prób, a w bezpieczeństwie to wynik niewystarczający.

Meta w październiku 2025 roku zaproponowała podobną, praktyczną zasadę dwóch (Agents Rule of Two). W jednej sesji agent może mieć najwyżej dwie z trzech cech: przetwarzać niezaufane treści, mieć dostęp do wrażliwych systemów lub danych oraz zmieniać stan systemów albo komunikować się na zewnątrz. Jeśli zadanie wymaga wszystkich trzech, trzeci krok zatwierdza człowiek.

W praktyce wygląda to tak. Agent, który czyta maile od klientów i ma dostęp do CRM, przygotowuje odpowiedź, ale jej nie wysyła - szkic czeka na akceptację handlowca. Agent, który przegląda strony internetowe, nie dostaje dostępu do danych klientów. Więcej o projektowaniu akceptacji piszę we wpisie o human-in-the-loop, a o samych atakach przez ukryte instrukcje we wpisie o prompt injection.

Najmniejsze uprawnienia dla agenta

Zasada najmniejszych uprawnień jest stara, ale przy agentach trzeba ją stosować bardziej rygorystycznie niż przy ludziach. Pracownik rzadko wykona polecenie z maila od nieznajomego. Agent może to zrobić, jeśli polecenie trafi do jego kontekstu.

• Osobna tożsamość agenta. Agent działa na własnym koncie technicznym, a nie na koncie pracownika ani na wspólnym kluczu API. Tylko wtedy wiadomo, co zrobił agent, a co człowiek.
• Tokeny z ograniczonym zakresem. Tylko odczyt tam, gdzie wystarczy, dostęp do jednego folderu, jednej skrzynki albo jednego repozytorium zamiast do wszystkiego.
• Lista dozwolonych narzędzi. Agent dostaje tylko narzędzia potrzebne do zadania. Zamiast ogólnego narzędzia „wykonaj zapytanie SQL" lepiej dać mu wąskie „pobierz zamówienie po numerze".
• Krótko ważne poświadczenia. Tokeny wygasają po godzinach, a nie po latach, i nie trafiają do promptu, z którego model mógłby je przepisać.
• Sprawdzone serwery narzędzi. Serwery MCP i rozszerzenia tylko z zaufanych źródeł, w przypiętych wersjach. Jak działa MCP, opisuję w osobnym wpisie.

Jak projektować wąskie i przewidywalne narzędzia dla agenta, pokazuję we wpisie o tool calling w produkcji.

Sandboxing - gdzie agent wykonuje działania

Agent, który uruchamia kod, komendy albo przegląda internet, powinien robić to w odizolowanym środowisku: w kontenerze albo maszynie wirtualnej bez dostępu do produkcji i danych firmy. Jeśli coś pójdzie źle, szkoda zostaje w tym środowisku.

Dobrym przykładem jest sandboxing, który Anthropic wprowadził w Claude Code w październiku 2025 roku. Opiera się na dwóch rodzajach izolacji. Izolacja plików ogranicza agenta do wskazanych katalogów, więc nie zmieni plików systemowych. Izolacja sieci pozwala łączyć się tylko z zatwierdzonymi adresami, więc agent nie wyśle danych w nieznane miejsce. Według Anthropic taki układ zmniejszył liczbę próśb o zgodę o 84%. Sandbox zwiększa więc bezpieczeństwo, a przy okazji pozwala agentowi pracować samodzielniej. Anthropic podkreśla, że obie izolacje muszą działać razem. Bez izolacji sieci agent może wynieść dane, a bez izolacji plików może zmienić system i obejść resztę zabezpieczeń.

Trzy zasady, które warto stosować niezależnie od narzędzia:

• Oddzielne środowiska. Agent pracuje na środowisku testowym, a zmiany na produkcji przechodzą przez ten sam proces co zmiany ludzi.
• Lista dozwolonych adresów. Ruch wychodzący tylko do zatwierdzonych domen. To najprostszy sposób, żeby usunąć trzeci element zabójczego trio.
• Środowisko jednorazowe. Po zakończeniu zadania sandbox jest usuwany, więc nic w nim nie zostaje na kolejne sesje.

Jak pracować z agentami kodującymi w zespole programistów, opisuję we wpisie o Claude Code i Cursor.

Bezpieczniki - limity i przycisk stop

Nawet dobrze ograniczony agent może się zapętlić, źle zrozumieć zadanie albo zostać zmanipulowany. Bezpieczniki działają niezależnie od modelu i ograniczają skalę szkód.

• Limity kwotowe. Agent może na przykład sam zatwierdzić zwrot do 200 zł, a wyższe kwoty trafiają do człowieka.
• Limity liczby działań. Najwyżej określona liczba maili na godzinę albo zmian w CRM na dzień. Nagły skok to sygnał, że coś jest nie tak.
• Budżet kosztów. Limit tokenów i wydatków na zadanie chroni przed pętlą, która w nocy wygeneruje wysoki rachunek.
• Akceptacja działań nieodwracalnych. Usuwanie danych, przelewy i wysyłka do wielu odbiorców zawsze wymagają zgody człowieka.
• Przycisk stop. Ktoś w firmie musi móc w kilka minut zatrzymać agenta i unieważnić jego tokeny.

Dziennik działań agenta

Jeśli agent coś zepsuje, trzeba szybko ustalić, co zrobił, na jakiej podstawie i kto to zatwierdził. Bez dziennika działań (audit trail) zostaje zgadywanie. W badaniu CSA z 2026 roku tylko 16% firm miało dużą pewność, że wykryje zagrożenia związane z agentami.

Dziennik powinien być poza zasięgiem agenta, żeby agent nie mógł go zmienić ani usunąć. Warto ustawić alerty na nietypowe zachowania, na przykład nagły wzrost liczby działań albo próby użycia narzędzi spoza listy.

Przy systemach wysokiego ryzyka wymaga tego też AI Act. Artykuł 12 nakazuje automatyczne rejestrowanie zdarzeń, a artykuł 26 zobowiązuje firmy, które takie systemy stosują, do przechowywania logów przez co najmniej sześć miesięcy. Większość firmowych agentów nie jest systemem wysokiego ryzyka, ale ta sama praktyka po prostu ułatwia życie, gdy coś pójdzie nie tak. Szerzej o zasadach korzystania z AI piszę we wpisie o polityce AI w firmie.

Lista kontrolna przed wdrożeniem agenta

1. 1.Opisz, co agent robi i czego mu nie wolno, w tym listę działań nieodwracalnych.
2. 2.Sprawdź zabójcze trio: czy agent ma jednocześnie dostęp do danych, kontakt z obcą treścią i możliwość komunikacji na zewnątrz. Jeśli tak, usuń jeden element albo dodaj akceptację człowieka.
3. 3.Załóż agentowi osobne konto z minimalnymi uprawnieniami i krótko ważnymi tokenami.
4. 4.Daj mu tylko potrzebne narzędzia, możliwie wąskie, z jasno opisanymi parametrami.
5. 5.Uruchamiaj kod i przeglądanie internetu w sandboxie z listą dozwolonych adresów.
6. 6.Ustaw limity: kwotowe, liczby działań i kosztów.
7. 7.Wymagaj akceptacji dla usuwania danych, płatności i wysyłki na zewnątrz.
8. 8.Włącz dziennik działań poza zasięgiem agenta i alerty na anomalie.
9. 9.Przygotuj przycisk stop i sprawdź, ile trwa zatrzymanie agenta.
10. 10.Przetestuj agenta atakami, zanim zrobi to ktoś inny, na przykład wysyłając mu maile z ukrytymi instrukcjami.

---

Pomagam firmom wdrażać agentów AI tak, żeby mieli dostęp tylko do tego, czego potrzebują - od mapy uprawnień i analizy zabójczego trio, przez sandbox, limity i akceptację człowieka, po dziennik działań i testy atakami. Robię to w ramach doradztwa AI i budowy aplikacji AI. Napisz do mnie - zaczniemy od przeglądu agentów, które już działają w Twojej firmie.

Warto przeczytać dalej:

• Prompt injection i bezpieczeństwo aplikacji LLM - jak chronić chatboty, RAG i agentów AI
• Human-in-the-loop w praktyce - jak zaprojektować nadzór człowieka nad agentami AI
• MCP (Model Context Protocol) - jeden standard, żeby podłączyć AI do wszystkich narzędzi firmy
• Bezpieczeństwo danych przy wdrożeniu AI - jak nie oddać tajemnic firmy?