Перейти к основному содержанию
Самый быстрый способ остановить агента от чего-то опасного — назвать инструмент и отклонить его. Вердикт deny на глобе имени инструмента — это deny-list примитив agent firewall: одно правило, один глоб, вердикт deny, привязанный к ключу — и с этого момента шлюз отказывает в этом инструменте на каждом вызове, без изменений в коде вашего агента. Эта страница покрывает use-case deny-list и одно решение, которое он навязывает: на какой поверхности вы блокируете — на инструментах, которые вы рекламируете (inbound), или на вызовах инструментов, которые выдаёт модель (response). О полном словаре сопоставления и семантике вердиктов см. Схему правил и Вердикты.

​
1. Заблокировать вызов инструмента, который делает ИИ-агент

Правило deny-list — это простейшее, что может выразить политика firewall: сопоставить инструмент по имени, вернуть deny. Используйте его, когда инструмент никогда не должен срабатывать для данного ключа — shell.exec, *.delete, community-плагин, которому вы не доверяете, — независимо от аргументов. В консоли рабочего пространства откройте политику (или создайте её) и добавьте правило: 
{
  "label": "block destructive shell",
  "tool_name_glob": "*.exec",
  "verdict": "deny"
}
tool_name_glob — это маленький, чувствительный к регистру глоб — shell.* ловит целое семейство, *.delete ловит глагол по серверам, * ловит всё. Клауза аргумента не нужна: голый глоб + deny блокирует инструмент безусловно. Добавляйте клаузу аргумента только когда хотите разрешить инструмент в целом, но отклонить одну форму вызова.
Движок проходит правила политики в порядке приоритета, и побеждает первое совпадение. Ставьте узкие allow-исключения с меньшим числом priority (они выполняются первыми), а ваш широкий deny — ниже них — например, разрешить shell.exec из доверенного навыка builtin.*, отклонить его везде ещё. См. Приоритет правил.

​
2. Inbound против response: выберите поверхность

Deny может приземлиться на две разные точки в жизненном цикле запроса, и разница важна. Привяжите правило полем stage или оставьте его пустым, чтобы покрыть обе.

inbound

Инструменты, которые ваш агент рекламирует модели в запросе (определения инструментов). Deny здесь убирает инструмент до того, как модель сможет его выбрать — модель никогда не видит его как опцию.

response

tool_calls, которые модель выдаёт в своём ответе. Deny здесь ловит вызов, который модель уже решила сделать, до того как он достигнет инструмента.
Предпочитайте inbound, когда хотите, чтобы инструмент был невидим — модель не может вызвать то, что ей никогда не предлагали, так что вы избегаете потраченных впустую ходов, где она выбирает инструмент только чтобы получить отказ. Используйте response (или оставьте stage пустым), когда инструмент законно появляется в некоторых запросах и вы хотите поймать фактический выданный вызов, или когда вы контролируете только цикл агента, а не набор рекламируемых инструментов.
Правило без stage применяется ко всем поверхностям — тот же deny покрывает инструмент, рекламируется ли он, выдаётся или диспетчеризуется через MCP. Это дефолт «пояс-и-подтяжки»; привязывайте поверхность только когда deny должен быть ограничен одной. См. Стадии.

​
3. Привяжите политику и понаблюдайте, как она срабатывает

Политика ничего не делает, пока к ней не разрешится ключ. Привяжите в консоли, установив firewall_policy_id на ключе, или сделайте политику default рабочего пространства. Разрешение такое: привязанная политика ключа (когда она существует и включена), иначе default рабочего пространства. (Отключённая привязанная политика откатывается к default — см. Управление политиками.) Будучи привязанным, отклонённый вызов на поверхности inbound возвращает HTTP 400 с кодом ошибки firewall_blocked и причиной, называющей инструмент — например, tool "shell.exec" blocked by firewall. Ошибка помечается skip-retry (повторный прогон идентичного вызова просто снова заблокируется) и не стоит токенов модели, поскольку inbound-блокировка срабатывает до вышестоящего вызова. Deny, диспетчеризованный через MCP-шлюз, вместо этого проявляется как ошибка инструмента, так что модель видит отказ и может среагировать.
Deny на поверхности inbound убирает инструмент из того, что предлагается модели. Если ваш фреймворк агента требует, чтобы инструмент, который он рекламировал, был вызываемым, блокировка его inbound может запутать цикл — в этом случае блокируйте на response вместо этого, так что инструмент остаётся рекламируемым, но фактический вызов получает отказ. Протестируйте разницу до развёртывания (см. §5).

​
4. Deny — один из нескольких вердиктов

Deny — самый тупой инструмент в deny-list. Когда жёсткая блокировка — это слишком, тот же глоб может нести более мягкий вердикт:
ВердиктКогда тянуться к нему вместо deny
auditВы хотите увидеть, как инструмент срабатывает, но пока не блокировать.
sanitizeИнструмент в порядке, но его аргументы могут нести секреты/PII — редактирует аргументы, никогда результаты инструмента.
pending_approvalЧеловек должен одобрить каждый вызов вне основного канала.
cap_costРазрешать, пока траты прогона агента не пересекут лимит в центах.
Все они задокументированы на Вердиктах. Deny-list — это просто подмножество, где вердикт — deny. Для позиции allow-list (отклонить всё, разрешить названный набор) переключите default_verdict политики на deny и добавьте узкие allow-правила — см. Allow-листинг инструментов.

​
5. Разверните его безопасно

Вкладка Test в консоли прогоняет политику вхолостую против образца вызова инструмента и возвращает вердикт, совпавшее правило и причину — ничего не диспетчеризуется, ничего не сохраняется. Подтвердите, что ваш глоб совпадает с инструментом, который вы имели в виду (и только с этим инструментом), до привязки ключа. См. Тестирование правил.
Включите shadow-режим на политике, и каждый применяющий вердикт — включая ваш deny — понижается до audit, причина с префиксом [shadow] would …. Вы измеряете ровно то, что deny заблокировал бы против реального трафика, затем выключаете shadow, чтобы применять.
Не уверены в точном имени инструмента для глоба? Представление Discovered Tools перечисляет каждый инструмент, который видело рабочее пространство, помеченный covered или gap. Создавайте свой deny прямо по именам, которые реально появились. См. Аналитику.
Каждое вычисление пишет событие firewall с вердиктом, поверхностью, инструментом и совпавшим правилом. После применения отфильтруйте журнал событий по вердикту deny, чтобы увидеть, как правило срабатывает на вызовах, которые вы ожидали.

​
6. Кто что может

Вся конфигурация deny-list выполняется в консоли под вашей сессией (/api/workspace/firewall/*):
ДействиеРоль
Чтение политик, пресетов, обнаруженных инструментов, SimulateMember
Прогон политики вхолостую (Test)Developer+
Создание / редактирование / удаление правил и политикDeveloper+
Чтение журнала событий и свёрток прогоновDeveloper+
Создание или изменение правила deny — запись Developer+, и таков же консольный прогон Test вхолостую. Чтение политики и read-only представление Simulate («что если») открыты каждому участнику.

​
Связанное

Синтаксис глобов

Ровно как shell.*, *.exec и *.shell.* совпадают.

Allow-листинг инструментов

Обратная позиция: default-deny, разрешить названный набор.

Проверять аргументы

Отклонять только одну форму вызова, не весь инструмент.

Опасные вызовы инструментов

Угроза, которую решает deny-list.

Вердикты

Что deny и его более мягкие собратья делают на проводе.

Справочник Firewall

Полный справочник правил + сопоставления.