Agent jest tak bezpieczny, jak narzędzia, które mu daliście

Zapytajcie, jak zabezpiecza się agenta, a odpowiedź zwykle będzie dotyczyć promptu systemowego. Powiedziano mu, żeby pewnych rzeczy nie robił, pewnych żądań odmawiał i uważał na dane klientów. Ta instrukcja jest realna i jest najsłabszą warstwą w systemie.

Prawie całe bezpieczeństwo agenta bierze się z tego, do czego może fizycznie sięgnąć. To jest warstwa narzędzi i jest decyzją inżynierską, a nie redakcyjną.

Dlaczego reguły na poziomie promptu nie są modelem bezpieczeństwa

Instrukcje i dane przychodzą tym samym kanałem. Agent czytający maila czyta tekst, który napisał ktoś inny. Jeśli ten tekst mówi, żeby zignorować wcześniejsze instrukcje, model nie ma strukturalnego sposobu rozpoznania, który z dwóch tekstów ma władzę. Staranne prompty obniżają skuteczność ataku; nie zmieniają kształtu problemu.

Pokrycia nie da się poznać. Reguła zakazuje tego, o czym pomyśleliście. Nie ma sposobu, żeby wyliczyć to, o czym nie pomyśleliście, ani testu dowodzącego, że lista jest kompletna.

Promień rażenia się nie zmienia. Nawet idealnie posłuszny agent z szerokim dostępem do bazy jest o jeden błąd od zrobienia czegoś dużego. Instrukcje ograniczają zamiar, a nie możliwości.

Co zamiast tego robi warstwa narzędzi

Zasada jest zwykłym bezpieczeństwem oprogramowania, zastosowanym w nowym miejscu: agent dostaje wąskie, jawne możliwości zamiast ogólnego dostępu, a granicy pilnuje kod, który nie czyta promptów.

Otypowane operacje, nie ogólny dostęp. Nie połączenie do bazy, tylko pobierz_zamowienie(id) i przygotuj_odpowiedz(id, tresc). Czego nie wystawiono, tego nie da się zrobić, niezależnie od tego, do czego jakiś tekst przekona model.

Uprawnienia przy narzędziu, sprawdzane po stronie serwera. Narzędzie weryfikuje, że ten agent, dla tego użytkownika, może dotknąć tego rekordu. Sprawdzane tam, gdzie są dane, a nie tam, gdzie odbywa się rozumowanie.

Limity wartości i tempa w kodzie. Narzędzie do zwrotów odmawiające powyżej progu nie potrzebuje, żeby agent był ostrożny. Limit trzyma niezależnie od tego, co modelowi powiedziano.

Działania nieodwracalne za bramką zatwierdzania. Wszystko, co wydaje pieniądze, kontaktuje się z klientem albo zaciąga zobowiązanie, zwraca szkic dla człowieka, zamiast wykonać działanie.

Minimalizacja danych z konstrukcji. Jeśli agent nigdy nie potrzebuje pól z wynagrodzeniami, narzędzie nigdy ich nie zwraca. Dane poza zasięgiem nie wyciekną, a to usuwa całą klasę incydentów, zamiast ją łagodzić.

Walidacja wyjścia. Ustrukturyzowane wyniki parsowane i sprawdzane, zanim cokolwiek na nich zadziała — żeby odpowiedź zniekształcona albo zmanipulowana kończyła się odmową, a nie propagacją.

Pytanie projektowe, które ma znaczenie

Dla każdej możliwości zapytajcie, jaki jest najgorszy wynik, jeśli model zostanie w pełni zmanipulowany do użycia jej najgorzej, jak się da.

Jeśli odpowiedzią jest błędny szkic, narzędzie może być otwarte. Jeśli odpowiedzią jest płatność, usunięcie albo klient dostający coś nieprawdziwego, narzędzie potrzebuje limitu, zatwierdzania albo obu. To jedno pytanie generuje większość projektu i potrafią na nie odpowiedzieć ludzie, którzy nie są specjalistami od bezpieczeństwa.

Nieefektowna konsekwencja

Budowanie agentów w ten sposób to więcej pracy niż napisanie dobrego promptu, a większość wysiłku idzie w integracje, a nie w cokolwiek wyglądającego jak AI. To także różnica między czymś, co można postawić przed prawdziwym procesem, a czymś, co zostaje pokazem, bo nikt nie podpisze się pod ryzykiem.

Ta warstwa narzędzi pochłania większość naszego czasu przy inżynierii agentów AI i jest tą częścią, o którą zapytalibyśmy każdego innego dostawcę w pierwszej kolejności.