Firewall для tool calls

Разрешить агенту инструмент delete_file ещё не значит разрешить удаление любого файла. С execute_sql та же история: название одно, последствия зависят от запроса.

Поэтому между решением модели и выполнением хочется иметь отдельную проверку. Особенно когда агент работает с реальными данными.

В мартовском препринте AEGIS: No Tool Call Left Unchecked авторы описывают такой слой. Он перехватывает вызов до выполнения, извлекает строки из аргументов, проверяет их по шаблонам угроз и заданным политикам.

Дальше три варианта: пропустить, заблокировать или приостановить до решения человека.

В основе проверки здесь правила и паттерны. Например, признаки опасных SQL-запросов, shell injection и обращения к чувствительным файлам.

По результатам авторов:

• заблокированы 48 из 48 атак в подготовленной ими выборке;
• на 500 безопасных вызовах было 6 ложных срабатываний, то есть 1,2%;
• медианная добавленная задержка составила 8,3 мс на 1000 вызовах в локальном развёртывании.

Все шесть ложных срабатываний вызвали легитимные SQL-запросы с OR. Знакомая проблема: конструкция выглядит подозрительно, хотя запрос нормальный.

Но 48 примеров мало для вывода об устойчивости защиты. Авторы признают, что правила могут пропускать новые варианты атак. А вызовы в обход SDK вообще находятся вне модели защиты AEGIS.

Мне здесь интереснее сама точка контроля: модель предложила действие, а право его выполнить проверяется отдельно.

Потому что проверка перед delete_file полезна ровно до момента, когда тот же файл можно удалить через shell.

#AIxSec #AgentSecurity #ToolCalling #MLSecOps