Bezpieczeństwo i kontrola agentów AI — guardrails w praktyce

Dlaczego agent to inna klasa ryzyka niż czat

Czat może najwyżej powiedzieć coś błędnego. Agent AI może to błędne zrobić: wysłać maila, zmienić rekord w CRM, kupić, skasować. Do klasycznych ryzyk modeli (halucynacje) dochodzą ryzyka działania: złe narzędzie, złe dane wejściowe, za szerokie uprawnienia. Że temat jest poważny, widać po samych dostawcach — po czerwcowym zawieszeniu i przywróceniu Fable 5 Anthropic wraz z partnerami zaproponował wspólne, branżowe ramy oceny wagi jailbreaków (opisujemy to w newsach).

Dobra wiadomość: sprawdzone zasady istnieją i są zaskakująco podobne do tych, którymi kontroluje się… nowych pracowników.

Pięć filarów kontroli agenta

1. Minimalne uprawnienia narzędzi

Agent dostaje tylko narzędzia potrzebne do zadania, a każde narzędzie — najwęższy możliwy zakres: odczyt zamiast zapisu, jeden katalog zamiast całego dysku, sandbox zamiast produkcji, konto techniczne z limitem zamiast karty firmowej. Uprawnienia rozszerzasz dopiero wtedy, gdy metryki pokazują, że agent na to „zapracował”.

2. Niezaufane wejście: obrona przed prompt injection

Prompt injection to dziś najważniejszy praktyczny atak na agentów. Zasady minimum: oddzielaj w promptach instrukcje systemowe od danych z zewnątrz i wprost oznaczaj te drugie jako treść, nie polecenia; filtruj/streszczaj treści z sieci zanim trafią do agenta z uprawnieniami; nigdy nie pozwalaj, by tekst przeczytany na stronie czy w mailu mógł bezpośrednio wywołać działanie nieodwracalne bez zatwierdzenia.

3. Human-in-the-loop na działaniach nieodwracalnych

Podziel działania agenta na trzy koszyki: wolne (odczyt, analiza, szkice — pełna autonomia), zatwierdzane (wysyłki, zmiany danych, płatności — człowiek klika „tak”) i zakazane (twardo zablokowane, nawet gdyby model „chciał”). Ten podział to serce guardrails — reszta jest implementacją.

4. Limity i wyłącznik awaryjny

Agent w pętli potrafi „odjechać”: limituj liczbę kroków, czas, budżet tokenów i liczbę wywołań każdego narzędzia; ustaw twardy stop po N nieudanych próbach tej samej akcji. Wyłącznik awaryjny (zatrzymaj wszystko) musi być dostępny człowiekowi w każdej chwili — i przetestowany.

5. Obserwowalność i audyt

Loguj każdy krok: co agent „myślał”, jakie narzędzie wywołał, z jakimi argumentami, co dostał. Bez tego nie odtworzysz incydentu ani nie poprawisz systemu. Regularnie próbkuj przebiegi ręcznie — metryki nie wyłapią wszystkiego.

Kontekst prawny (UE)

Jeśli agent wchodzi w interakcję z ludźmi, pamiętaj o obowiązkach przejrzystości AI Act — wchodzą 2 sierpnia 2026 (użytkownik ma wiedzieć, że rozmawia z AI), podczas gdy wymogi dla systemów wysokiego ryzyka przesunięto na 2.12.2027/2.08.2028 — szczegóły w naszym omówieniu harmonogramu. Obszary typu rekrutacja czy scoring pozostają kategorią wysokiego ryzyka — projektuj je ostrożnie już dziś.

Checklista przed uruchomieniem

• Lista narzędzi agenta z uzasadnieniem i minimalnym zakresem każdego.
• Podział działań: wolne / zatwierdzane / zakazane — wdrożony technicznie, nie tylko w prompcie.
• Treści zewnętrzne oznaczane jako dane; test na 5–10 znanych wzorcach prompt injection.
• Limity kroków/czasu/budżetu + wyłącznik awaryjny (przetestowany).
• Logi przebiegów + osoba odpowiedzialna za ich przegląd.
• Informacja dla użytkownika, że ma do czynienia z AI (przejrzystość).
• Plan stopniowego rozszerzania autonomii w oparciu o metryki, nie wrażenia.

Jak te zasady osadzić w kodzie pokazuje nasz tutorial budowy agenta; wzorce izolowania uprawnień w zespołach agentów opisujemy w tekście o systemach multi-agent.