Bezpieczeństwo agentów AI: granice, human-gate i logi

Różnica między chatbotem a agentem to sprawczość: agent nie kończy na odpowiedzi, lecz na zmianie stanu — wysłanym mailu, zaktualizowanym rekordzie, obsłużonym leadzie. To ogromna wartość, ale i odpowiedzialność. Sprawczość bez granic jest ryzykiem, więc granice projektujemy razem ze sprawczością.

Trzy filary bezpieczeństwa agenta#

• Allow-lista narzędzi — agent ma katalog dozwolonych narzędzi (np. nawigacja, wyszukiwanie, rezerwacja), a nie dowolny dostęp do systemu. Czego nie ma na liście, tego nie zrobi.
• Human-gate — akcje nieodwracalne (wysyłka, płatność, zmiana danych) wymagają serwerowego tokenu potwierdzenia, podpisanego HMAC. Sama deklaracja modelu nie wystarczy — potrzebne jest „tak” człowieka tam, gdzie nie da się cofnąć.
• Pełny log — każdy krok (myśl → narzędzie → wynik) jest logowany, więc po fakcie da się odtworzyć, co i dlaczego agent zrobił. Bez śladu nie ma odpowiedzialności.

Jak działa allow-lista w praktyce#

Zakres narzędzi opisujemy jawnie, z rozróżnieniem na operacje tylko-do-odczytu i operacje, które zmieniają stan (te idą przez human-gate). Przykładowa lista dla agenta obsługi klienta:

• nawigacja — tylko odczyt (poruszanie się po stronie, bez zapisu),
• wyszukiwanie-oferty — tylko odczyt (sprawdzenie dostępności i cen),
• rezerwacja-terminu — zapis za bramką (proponuje, wykonuje po potwierdzeniu),
• wyslij-mail — zapis za bramką (treść do akceptacji człowieka).

Czego na liście nie ma: dostępu do bazy z danymi innych klientów, usuwania rekordów, zwrotów płatności, eksportu danych. Brak wpisu to twarda odmowa po stronie serwera, a nie sugestia w prompcie — model może „chcieć” wywołać narzędzie spoza listy, ale warstwa wykonawcza je odrzuci.

Human-gate krok po kroku#

Bramka potwierdzeń to mechanizm serwerowy, nie obietnica modelu. Przebieg dla akcji nieodwracalnej:

1. agent proponuje akcję (np. „wyślij potwierdzenie rezerwacji na adres klienta”),
2. serwer wystawia krótko żyjący token podpisany HMAC, związany z konkretnym narzędziem i argumentami (zmiana adresu czy treści unieważnia token),
3. człowiek widzi proponowaną akcję i potwierdza lub odrzuca,
4. serwer weryfikuje token (podpis, ważność, zgodność argumentów) i dopiero wtedy wykonuje narzędzie,
5. wynik trafia do logu razem z tym, kto i kiedy potwierdził.

Token żyje krótko (rzędu minut, nie godzin) i jest jednorazowy — to ogranicza okno, w którym przejęte potwierdzenie dałoby się wykorzystać.

Co zawiera dobry log#

„Pełny log” staje się użyteczny dopiero, gdy z jednej linii da się odtworzyć decyzję. Minimalny zestaw pól dla pojedynczego kroku:

• znacznik czasu i identyfikator żądania (request-id, do powiązania kroków w jednym przebiegu),
• ślad rozumowania w formie myśl → narzędzie → wynik,
• nazwa wywołanego narzędzia i skrót argumentów (hash), z zamaskowanymi danymi osobowymi,
• decyzja human-gate (potwierdzono / odrzucono, przez kogo),
• status wyniku (sukces, błąd, blokada przez allow-listę).

Dane osobowe nie trafiają do logu w jawnej postaci — logujemy skrót i zamaskowane wartości, żeby ślad audytowy sam nie stał się źródłem wycieku.

Czym różni się ryzyko agenta od chatbota#

Dlatego agentów nie wdraża się „na żywioł”. Granicę między rozmową a wykonaniem opisujemy też we wpisie agent vs chatbot.

Stopniowe luzowanie nadzoru#

Nie zaczynamy od pełnej autonomii. Agent startuje z ciasnym human-gate (potwierdzasz prawie wszystko), a w miarę jak dowody zaufania rosną — log jest czysty, decyzje trafne — luzujemy bramki na sprawdzonych ścieżkach. To samo podejście, co przy prompt injection: bezpieczeństwo wbudowane, nie doklejone.

Te trzy filary odpowiadają wprost na ryzyka, które katalog OWASP Top 10 dla aplikacji LLM opisuje na poziomie agentów: nadmierną sprawczość (gdy agent może zrobić więcej, niż powinien) i niebezpieczne użycie narzędzi (gdy wywołanie narzędzia obchodzi kontrole). Allow-lista ogranicza zakres sprawczości, human-gate odbiera modelowi możliwość samodzielnego wykonania akcji nieodwracalnej, a log daje ślad do wykrycia nadużycia. Granicę zaufania luzujemy stopniowo właśnie dlatego, że to te dwie klasy ryzyka rosną najszybciej wraz z autonomią.

Wypróbuj na żywo#

Agenta uruchamiamy w bezpiecznej piaskownicy z przejrzystym śladem (playground: PII maskowane, zero retencji). Poproś model o rozpisanie kroków zadania:

FAQ#

Czy agent AI jest bezpieczny, skoro działa sam?#

Jest bezpieczny, gdy ma jasne granice: allow-listę narzędzi, human-gate na akcjach nieodwracalnych i log każdego kroku. Sprawczość bez tych barier to ryzyko, dlatego projektujemy je od początku. Agent działa autonomicznie w wąskim, dobrze opisanym zakresie, a nie „w ogóle”.

Co to jest human-gate?#

To punkt, w którym akcja nieodwracalna (wysyłka, płatność, zmiana rekordu) wymaga potwierdzenia człowieka — technicznie serwerowego tokenu podpisanego HMAC, nie samej decyzji modelu. Dzięki temu nawet jeśli agent „uzna”, że trzeba coś zrobić, nie zrobi tego bez zielonego światła.

Od czego zacząć z agentami?#

Od jednego wąskiego, powtarzalnego procesu z ciasnym nadzorem — potwierdzasz prawie wszystko, log jest pełny. Gdy dowody zaufania rosną, luzujesz bramki na sprawdzonych ścieżkach. Tak bezpiecznie oddaje się AI sprawczość, krok po kroku.

Jak przetestować allow-listę przed wdrożeniem?#

Testem negatywnym: zanim agent trafi na produkcję, sprawdzamy, że wywołanie narzędzia spoza listy kończy się odmową po stronie serwera, a nie próbą wykonania. Warto też przeprowadzić krótki red-team — celowo skłonić model (również przez treści w danych wejściowych) do sięgnięcia po zabronione narzędzie i potwierdzić, że warstwa wykonawcza je blokuje oraz że blokada trafia do logu. Test przechodzi, gdy każde niedozwolone narzędzie jest odrzucane, a dozwolone działają zgodnie z zakresem.

Czym human-gate różni się od zwykłego potwierdzenia w interfejsie?#

Zwykłe potwierdzenie w UI to sygnał po stronie klienta — można je obejść, a model i tak może spróbować wykonać akcję. Human-gate jest egzekwowany na serwerze: akcja nieodwracalna nie wykona się bez ważnego, krótko żyjącego tokenu podpisanego HMAC i związanego z konkretnym narzędziem oraz argumentami. Różnica jest praktyczna — przy zwykłym potwierdzeniu zaufanie opiera się na deklaracji, przy human-gate na weryfikowalnym tokenie, którego sam model nie potrafi podrobić.