Перейти к основному содержанию
Allow-листинг инструмента отвечает на вопрос, какой инструмент агент может вызвать. Он не может ответить, с какими аргументами. shell.exec в порядке для ls; это катастрофа для rm -rf /. db.query в порядке против реплики; против prod это обуза. Разница живёт в аргументах, и правило имени инструмента её не видит. Клаузы аргументов Firewall (args_match_json) закрывают этот пробел. Они инспектируют конкретные аргументы, которые модель выбрала для вызова инструмента, и решают вердикт по их значениям — так что вы можете разрешить инструмент широко, отклоняя одну опасную форму, которую он может принять. Эта страница — сфокусированное руководство по созданию таких клауз; о полном словаре правил см. Правила Firewall, а о модели политик вокруг них — Firewall.
Значения аргументов существуют только когда модель выбрала, как вызвать инструмент, так что клаузы аргументов принадлежат стадиям response и mcp. На inbound — где агент только рекламирует определения инструментов — нет аргументов времени вызова, которые можно проверить.

​
1. Когда проверять аргументы вызова инструмента

Тянитесь за клаузой аргумента всякий раз, когда инструмент безопасен в целом, но опасен в конкретной форме:

Деструктивные команды

Разрешить shell.exec, но отклонить, когда команда совпадает с rm -rf, mkfs или dd if=.

Production-радиус поражения

Разрешить db.query, но отклонить (или удержать для подтверждения), когда цель подключения — prod.

Внутренние назначения

Разрешить инструмент извлечения, но отклонить, когда его аргумент url/ip попадает в диапазон RFC-1918 или IP cloud-metadata.

Чрезмерные операции

Разрешить bulk-инструмент, но отклонить, когда аргумент limit или count превышает числовой потолок.
Правило всё равно сначала совпадает по имени инструмента; клаузы сужают его от какого инструмента до какого вызова.

​
2. Форма набора клауз

args_match_json — это JSON-кодированная строка, чьё декодированное значение — объект, содержащий список clauses. Каждая клауза — это тройка { path, op, value }, и все клаузы объединяются по AND — правило срабатывает только когда каждая клауза истинна. Декодированное значение выглядит так: 
{
  "clauses": [
    { "path": "$.command",    "op": "regex",      "value": "rm -rf|drop table" },
    { "path": "$.connection", "op": "in",         "value": ["prod", "replica"] },
    { "path": "$.ip",         "op": "cidr_match", "value": "10.0.0.0/8" }
  ]
}
В теле правила поле несёт этот JSON как одну экранированную строку — например, "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf\"}]}". Пустой или отсутствующий args_match_json вакуумно истинен — правило совпадает по своему глобу имени инструмента в одиночку, ровно как делает правило только-по-имени.

​
3. Операторы

Семь операторов составляют закрытый словарь. Консоль валидирует оператор и форму его значения при сохранении, так что некорректная клауза никогда не сохраняется.
ОператорСовпадает, когда
eqСкалярное равенство (числа сравниваются численно; несовпадение типов — не совпадение).
containsПодстрока — оба операнда должны быть строками.
regexШаблон Go RE2 совпадает со строковым значением (линейное время, без обратных ссылок).
inЗначение — элемент данного JSON-массива.
cidr_matchСтроковый IP попадает внутрь данного CIDR.
gt / ltЧисленно больше / меньше (строки не приводятся).

​
4. Синтаксис пути

path клаузы — это маленькое подмножество JSONPath над объектом аргументов инструмента:
Прочитать поле объекта верхнего уровня или вложенное по имени.
Индексировать в массив, опционально продолжая в поля элемента.
Совпасть со всем блобом аргументов (полезно с contains или regex для грубого сканирования).
Нет wildcard’ов, фильтров, срезов или рекурсивного спуска — грамматика намеренно мала, так что сопоставление остаётся линейного времени и предсказуемым на горячем пути.

​
5. Проработанный пример

Вы позволяете своим агентам свободно запускать shell.exec, но рекурсивное принудительное удаление никогда не должно достигать shell. Создайте одно правило стадии response, которое отклоняет shell.exec только когда аргумент команды выглядит деструктивным.
1

Откройте редактор правил

В консоли откройте политику firewall, привязанную к ключу вашего агента (или default рабочего пространства), и добавьте правило. Редактирование политик — действие Developer+ — Members могут читать политики, но не писать их.
2

Сопоставьте инструмент на стадии response

Установите стадию в response, а глоб инструмента в shell.exec. Стадия response несёт выбранные моделью аргументы, которые нужны клаузе.
3

Добавьте клаузу аргумента

Добавьте одну клаузу regex на $.command, затем установите вердикт в deny:
{
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm\\\\s+-rf|mkfs|dd\\\\s+if=\"}]}"
}
args_match_json — это JSON-кодированная строка; её декодированное значение — объект { "clauses": [ … ] }, показанный в §2.
4

Прогоните вхолостую, прежде чем полагаться на него

Используйте вкладку Test, чтобы вычислить правило против образца вызова shell.exec. Она возвращает вердикт, совпавшее правило и причину — ничего не диспетчеризуется и ничего не сохраняется.
Теперь shell.exec с "command": "ls -la" проходит как раньше, тогда как "command": "rm -rf /var" отклоняется. Deny на response позволяет модели увидеть ошибку инструмента и среагировать — выбрать другой инструмент, спросить пользователя или остановиться — вместо падения.
Хотите разрешить вызов, но удалить утёкшее значение вместо блокировки? Поменяйте вердикт на sanitize. Sanitize не редактирует то, что совпала клауза — он запускает отдельный редактор (именованные пресеты вроде openai_key, anthropic_key, ssn_us, плюс ваши собственные кастомные regex’ы) над строками аргументов, заменяет каждое попадание токеном [redacted:…] и пересылает очищенный вызов. Клауза args_match_json всё равно решает, срабатывает ли правило; sanitizer решает, что вычищается. См. Очистку аргументов. Sanitize редактирует аргументы вызова инструмента только — никогда содержимое, которое возвращает инструмент.

​
6. Клаузы fail closed — правило, а не запрос

Если клаузу нельзя вычислить — путь не разрешается, аргументы некорректны или regex / CIDR недействителен — клауза вычисляется в false, и правило просто не срабатывает. Вызов проваливается к следующему правилу или default_verdict политики. Сломанная клауза никогда не авто-отклоняет и никогда не беспокоит ретрансляцию.
Поскольку клауза, которую нельзя вычислить, делает своё правило не совпавшим, никогда не полагайтесь на клаузу, чтобы провалиться определённым образом. Создавайте своё правило «лови всё опасное» как явный deny с собственным глобом инструмента, а клаузы аргументов используйте, чтобы сузить разрешение — не как последнюю линию обороны.

​
7. Сочетание клауз с остальным правилом

Клаузы аргументов складываются со всем остальным, что выражает правило — они одно AND-условие среди нескольких:
Сочетать сЭффект
tool_name_globКлауза выполняется только когда имя инструмента совпало — имя первым, аргументы вторыми.
skill_name_globОграничивайте аргументы того же инструмента по-разному по владеющему навыку (например, строже на community.*).
verdictСочетайте клаузы с deny, sanitize, pending_approval или cap_cost, не только с deny.
Несколько клаузВсе должны держаться — сочетайте проверку команды regex с проверкой окружения in, чтобы ограничить deny узко.
О точной семантике вердиктов, которую производит каждое сочетание, см. Вердикты; о том, как разрешается удержанный вызов, см. Подтверждения.

​
8. Куда это вписывается

Правила Firewall

Полный справочник правил — глобы, клаузы, sanitizer’ы, egress и последовательности.

Кулинарная книга аргументов

Готовые рецепты args_match_json для распространённых опасных форм.

Стадии Firewall

Почему клаузы аргументов живут на response и mcp, а не inbound.

Блокировать инструменты

Отклонить инструмент полностью, когда ни один аргумент не безопасен.
О более широкой картине см. Опасные вызовы инструментов и Как OrcaRouter инспектирует.