Перейти к основному содержанию
Политика firewall — это упорядоченный список правил, а правило — это просто маленький набор полей: какие вызовы инструментов оно совпадает, на какой поверхности и что с ними делать. Когда вам нужно прочитать правило, которое написал кто-то другой — или точно рассуждать о том, которое вы строите — вы хотите список полей в одном месте. Это эта страница. Вы создаёте правила в консольном редакторе правил (записи требуют Developer+); редактор пишет структурированные поля ниже. Эта страница — карта на уровне полей; глубокий движок сопоставления живёт в Правилах Firewall.

​
1. Схема правил firewall с одного взгляда

Каждое правило несёт те же поля. Только verdict всегда обязателен — всё остальное сужает то, что правило совпадает, или настраивает выбранный вердикт, и отсутствующий сопоставитель вакуумно истинен.
ПолеНазначение
priorityПорядок вычисления — меньшее выполняется первым.
verdictДействие, когда правило совпадает (обязательно).
stageПоверхность, к которой ограничить; пусто = все.
tool_name_globГлоб на имени инструмента.
args_match_jsonJSONPath предикат аргумента, как JSON-кодированная строка.
egress_jsonСписок host / CIDR allow-deny (egress-правила), как JSON-кодированная строка.
sanitize_jsonКонфиг редактирования (когда verdict = sanitize), как JSON-кодированная строка.
cap_cost_centsПотолок стоимости прогона в центах USD (когда verdict = cap_cost).
sequence_jsonПредикат упорядоченной многошаговой цепочки (правила последовательностей), как JSON-кодированная строка.
label / notesЧеловеческое имя и обоснование — показываются в событиях, игнорируются движком.
Правило срабатывает, когда все его объявленные сопоставители держатся сразу — стадия совпадает (или пуста), глоб инструмента совпадает, клаузы аргументов совпадают (или отсутствуют), и область egress совпадает (только egress-правила). Движок проходит правила в порядке приоритета, и побеждает первое совпадение; если ничего не совпало, применяется default_verdict политики.

​
2. priority — порядок вычисления

Целочисленный ординал. Меньшее выполняется первым; два правила с одним приоритетом разрешают ничью по id правила (порядок вставки). Ставьте свои конкретные вырезки выше широких catch-all — allow для одного доверенного инструмента на приоритете 10 бьёт deny * на приоритете 100.
Оставляйте промежутки (10, 20, 30), так чтобы вы могли вставить новое правило между двумя существующими позже без перенумерации всей политики. См. Приоритет правил о стратегии упорядочивания.

​
3. verdict — действие

Единственное обязательное поле. Когда правило совпадает, его вердикт решает, что происходит с вызовом:
ВердиктЭффект
allowПропустить вызов, с логированием.
auditРазрешить и записать для разбора — обычный default_verdict.
denyЗаблокировать вызов.
sanitizeОтредактировать совпавшие подстроки из аргументов инструмента, затем переслать.
pending_approvalУдержать вызов для человека-ревьюера.
cap_costОтклонить, как только накопленные траты прогона агента пересекут потолок.
deny возвращает HTTP 400 firewall_blocked на поверхности inbound или ошибку инструмента на поверхности mcp. Удержанный вызов возвращает HTTP 400 firewall_approval_pending с id, который опрашивает агент. В shadow-режиме каждый применяющий вердикт понижается до audit, а причина получает префикс [shadow] would …. См. Вердикты о полной таблице и формах блокировки.

​
4. stage — поверхность применения

Привязывает правило к одной из поверхностей firewall. Оставьте пустым, и правило применяется ко всем поверхностям:
Инструменты, которые агент рекламирует модели в запросе. Заблокируйте опасный инструмент до того, как модель сможет его выбрать.
tool_calls, которые модель выдаёт в своём ответе.
tools/call, маршрутизированный через MCP-шлюз Firewall.
Исходящий host / IP / CIDR, которого достигает инструмент — поверхность SSRF и эксфильтрации данных.
Некоторые сочетания вердикт + стадия отклоняются при сохранении, потому что вердикт не может там сработать: cap_cost — это pre-dispatch потолок стоимости прогона, инертный на response и egress; pending_approval всегда удерживает только на inbound, так что явная привязка response/egress отклоняется. Редактор скрывает эти комбинации; API их отклоняет. См. Стадии.

​
5. tool_name_glob — какой инструмент

Маленький, чувствительный к регистру глоб на имени инструмента — shell.* для целого семейства, *.delete для глагола по серверам, http_fetch для одного точного инструмента. Пустой или * совпадает с каждым инструментом. Опциональный глоб имени навыка (та же грамматика) объединяет по AND второе условие на владеющем навыке, так что вы можете доверять инструменту из встроенного навыка и ограничить его от community-навыка. Полная грамматика — префикс, суффикс, инфикс, точный и края, на которых люди спотыкаются — это собственный справочник: Синтаксис глоб-шаблонов.

​
6. args_match_json — с какими аргументами

Глоб отвечает, какой инструмент; args_match_json отвечает, с какими аргументами — разница между «заблокировать shell.exec» и «заблокировать shell.exec только когда команда — rm -rf». Его значение — это JSON-кодированная строка, несущая набор JSONPath-клауз, все объединены по 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" }
  ]
}
В теле запроса поле несёт этот объект как экранированную строку, например "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf\"}]}". Операторы — eq, contains, regex, in, cidr_match, gt и lt. Отсутствующий args_match_json вакуумно истинен — правило совпадает по глобу в одиночку. Полный язык предикатов, синтаксис пути и поведение fail-closed сломанной клаузы — в Проверке аргументов и кулинарной книге аргументов.

​
7. egress_json — какие назначения

Используется на поверхности egress: JSON-кодированная строка, содержащая список allow-and-deny по host / CIDR, сопоставляемый с исходящим назначением, которого достигает инструмент. Декодированный объект выглядит так: 
{
  "deny":  ["169.254.169.254", "10.0.0.0/8"],
  "allow": ["api.openai.com"]
}
Записи совпадают как CIDR, IP-литерал или нечувствительное к регистру имя хоста. Полярность следует за вердиктом — с применяющим вердиктом список deny определяет, что блокируется, а allow вырезает из него исключения.
Шаблон firewall Baseline поставляет egress deny-правило с готовым SSRF / cloud-metadata denylist (metadata IP 169.254.169.254, диапазоны RFC-1918, loopback, link-local и metadata.google.internal), так что вам не нужно создавать их вручную. Добавьте свои собственные назначения сверху для всего прочего, что хотите ограничить. См. Контроль egress о полном рецепте и Эксфильтрацию данных о том, почему это важно.

​
8. sanitize_json — отредактировать аргументы

Используется, когда verdict = sanitize: JSON-кодированная строка, называющая, какие пресеты / кастомные regex’ы редактируют совпавшие подстроки из аргументов инструмента до того, как очищенный вызов пересылается — полезно для удаления секрета или значения PII, которое агент уронил в аргумент, без блокировки всего действия. Декодированный объект выглядит так: 
{ "presets": ["email", "ssn_us"], "custom": ["foo-\\d+"] }
Sanitize редактирует только аргументы — никогда содержимое, которое инструмент возвращает. Правило sanitize должно назвать хотя бы один пресет или кастомный шаблон (пустой sanitizer отклоняется). На поверхности inbound нет аргументов времени вызова для редактирования, так что вердикт sanitize там эскалирует до deny.
См. Очистку ответов о библиотеке пресетов и формах редактирования.

​
9. cap_cost_cents — потолок трат

Используется, когда verdict = cap_cost: per-rule потолок стоимости прогона, целое число в центах USD. Когда правило совпадает, вызов отклоняется, как только накопленные траты прогона агента пересекут потолок — предохранитель для убегающего цикла, разрешающийся в allow или deny в событиях. Потолок должен быть явным и неотрицательным, и правило нельзя привязать к response или egress (где вердикт инертен). Полное поведение в Cap cost.

​
10. Одно полное правило

Собираем поля вместе — отклонить shell.exec, но только когда команда выглядит деструктивной, ограничено выданными моделью вызовами инструментов: 
{
  "priority": 10,
  "label": "block destructive shell",
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|:\\\\(\\\\)\\\\{\"}]}",
  "verdict": "deny",
  "notes": "fork bombs and recursive deletes only — plain shell.exec audits"
}
Стадия совпадает с поверхностью response, глоб выбирает shell.exec, единственная клауза сужает до деструктивной команды, а вердикт отклоняет. Любой shell.exec, чья команда не совпадает с regex, проваливается к следующему правилу или default политики. Привяжите ключ к политике (firewall_policy_id на ключе), и она живая на следующем вызове — без передеплоя.
Подтвердите, что правило срабатывает ровно на том, что вы ожидаете, до того как полагаться на него: Тестирование правил прогоняет политику вхолостую против образца вызова инструмента и возвращает вердикт, совпавшее правило и причину, ничего не диспетчеризуя.

​
11. Как поля объединяются

verdict. Всё остальное опционально: пустой stage совпадает со всеми поверхностями, пустой tool_name_glob (или *) совпадает с каждым инструментом, а отсутствующий args_match_json совпадает с любыми аргументами. Голый { "verdict": "audit" } — валидный catch-all.
Они AND. Правило срабатывает, только когда его стадия, глоб инструмента, глоб навыка, клаузы аргументов и область egress все держатся. Чтобы выразить OR, напишите отдельные правила.
sanitize_json читается только для вердикта sanitize; cap_cost_cents только для cap_cost; egress_json только на поверхности egress. Консоль валидирует эти сочетания при сохранении, так что правило, которое отображает одно поведение, но никогда не может его применить, не может быть сохранено.
Побеждает меньший priority (ничьи разрешаются по id правила) — побеждает первое совпадение, и вычисление там останавливается. См. Приоритет правил.

​
Связанное

Создать политику

Создайте свою первую политику и привяжите ключ.

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

Полная грамматика глоба имени инструмента.

Вердикты

Каждый вердикт и как выглядит блокировка.

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

JSONPath-клаузы аргументов в глубину.

Управление политиками

Редактируйте, версионируйте и откатывайте политики.

Правила Firewall

Полный справочник движка сопоставления.
Новичок в плоскости действий? Начните с обзора Firewall или посмотрите, как она сочетается с проверкой текста в Guardrails против Firewall.