Перейти к основному содержанию
Политика firewall — это упорядоченный список правил. Эта страница — полный справочник по тому, что может выразить правило: язык сопоставления, вердикты и как движок их вычисляет. Правила пишутся в консольном редакторе правил, который записывает структурированные JSON-объекты сопоставления. Всё ниже описывает этот словарь, чтобы вы могли читать, рассуждать и точно верифицировать правило — независимо от того, строите ли вы его в UI или постите через API.

​
1. Анатомия правила

ПолеТипЗначение
priorityintМеньший выполняется первым. Ничьи разрешаются по id правила.
labelstringЧеловекочитаемое имя, показываемое в событиях и аудите.
stageenumПоверхность — inbound / response / mcp / egress. Пусто = все поверхности.
tool_name_globstringГлоб по имени инструмента.
skill_name_globstringОпциональный глоб по навыку-владельцу. AND-ится с глобом инструмента; пусто = любой навык.
verdictenumДействие — см. §7.
args_matchobjectОпциональный предикат аргумента.
sanitizeobjectКонфигурация редактирования, используется при verdict = sanitize. См. §5.
egressobjectСписок allow/deny по host/CIDR, используется при stage = egress. См. §6.
cap_cost_centsintПотолок стоимости прогона, используется при verdict = cap_cost.
sequenceobjectУпорядоченное многошаговое сопоставление, применяется реактивно. См. §8.
notesstringОбоснование автора; игнорируется движком.
Правило совпадает с вызовом инструмента, когда все его объявленные условия выполняются: стадия совпадает (или пуста), глоб инструмента совпадает, глоб навыка совпадает (или пуст), клаузы аргументов совпадают (или отсутствуют), и область egress совпадает (только для egress-правил). Движок проходит правила в порядке приоритета, и побеждает первое совпадение.

​
2. Глоб имени инструмента

Намеренно маленькая, чувствительная к регистру грамматика — никаких сюрпризов regex, линейное время, безопасно на горячем пути ретрансляции:
ПаттернСовпадает с
"" или *Каждым инструментом.
foo.*Префикс — foo.bar, foo.exec (не голым foo).
*.execСуффикс — shell.exec, db.exec (не голым exec).
*.shell.*Инфикс — local.shell.exec (нужен ≥1 символ с каждой стороны).
что-либо ещёТочное совпадение строки (включая foo.*.bar).
Инструменты по соглашению именуются в пространствах server.tool или category.action, так что shell.* ловит целое семейство, а *.delete ловит глагол через серверы.

​
3. Глоб имени навыка

Та же грамматика глоба, сопоставляемая с навыком-владельцем вызова инструмента (например, community.*, builtin.send). Она AND-ится с tool_name_glob, так что: 
tool_name_glob:  http.fetch
skill_name_glob: community.*
совпадает с http.fetch только когда он принадлежит навыку community.* — доверяйте тому же инструменту от встроенного навыка, шлюзуйте его от community-навыка. Пустой глоб навыка совпадает с любым владельцем. Как вызов инструмента атрибутируется навыку, описано в Навыках.

​
4. Клаузы аргументов

Сопоставление имени инструмента отвечает на какой инструмент; клаузы аргументов отвечают на с какими аргументами — разница между «заблокировать shell.exec» и «заблокировать shell.exec только когда команда — rm -rf». args_match — это набор клауз, все 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 вакуумно истинен — правило совпадает по одному глобу.

​
Операторы

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

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

Малое подмножество JSONPath над объектом аргументов инструмента:
  • $.foo, $.foo.bar — доступ к полю
  • $.foo[0], $.arr[1].k — индексация массива
  • $ — весь объект аргументов
Без подстановочных знаков, фильтров, срезов и рекурсивного спуска.
Клаузы аргументов fail closed — правило, а не запрос. Если путь не разрешается, аргументы искажены или regex/CIDR некорректен, клауза вычисляется в false, и правило просто не срабатывает — вызов проваливается к следующему правилу или default-вердикту. Сломанная клауза никогда не авто-отклоняет и никогда не роняет ретрансляцию. Пишите ваше правило «поймать всё опасное» как явный deny с собственным глобом, а не полагаясь на то, что клауза провалится определённым образом.
Консоль валидирует клаузы строго при сохранении (неизвестные операторы, плохие пути, не-массивные значения in, некомпилируемые regex и некорректные CIDR — всё отклоняется), так что искажённая клауза вообще не может быть сохранена.

​
5. Очистители

Вердикт sanitize редактирует совпавшие подстроки из аргументов инструмента и пересылает очищенный вызов — полезно для удаления секретов или PII, которые агент поместил в аргумент инструмента, без блокировки всего действия. 
{ "presets": ["email", "ssn_us"], "custom": ["foo-\\d+"] }
Совпадения пресетов заменяются на [redacted:<preset>]; совпадения пользовательского regex — на [redacted:custom]. Встроенная библиотека пресетов: aws_access_key, aws_secret_key, openai_key, anthropic_key, bearer_token, email, ssn_us, credit_card (с проверкой Луна). Правило sanitize должно объявлять хотя бы один пресет или пользовательский паттерн — пустой очиститель отклоняется при сохранении. На поверхности inbound нет аргументов времени вызова для редактирования, так что вердикт sanitize там эскалирует до блокировки.

​
6. Списки назначений egress

Правило egress (стадия egress) совпадает по исходящему назначению — поверхности SSRF и эксфильтрации: 
{
  "deny":  ["169.254.169.254", "10.0.0.0/8"],
  "allow": ["api.openai.com"]
}
Записи совпадают как CIDR, IP-литерал или нечувствительное к регистру имя хоста; имена хостов разрешаются best-effort и перепроверяются по записям IP/CIDR. Полярность следует за вердиктом: при вердикте allow список allow определяет, что в области, а deny вырезает из него исключения; при применяющем вердикте (deny) список deny определяет, что заблокировано, а allow вырезает исключения. 169.254.169.254 (эндпоинт облачных метаданных) и диапазоны RFC-1918 — канонические вещи для блокировки; пресет block_ssrf_egress и уровень автономии tight поставляют ровно это.

​
7. Вердикты

ВердиктЭффектПримечания
allowПропустить, логируется.
auditРазрешить + записать для разбора.Обычный default_verdict.
denyЗаблокировать вызов.HTTP 400 на inbound; ошибка инструмента на mcp.
sanitizeОтредактировать аргументы, переслать.Нужен очиститель; эскалирует до deny на inbound.
pending_approvalУдержать для человека.Требует настроенного хранилища подтверждений; отклоняется на response/egress.
cap_costОтклонить после лимита трат.Нужен неотрицательный cap_cost_cents; инертен на response/egress.
В shadow-режиме каждый применяющий вердикт понижается до audit, а причина получает префикс [shadow] would ….

​
8. Последовательности

Некоторые риски видны только через несколько вызовов — прочитать 50 записей CRM, затем экспортировать, затем обратиться к внешнему хосту. Правило sequence совпадает с упорядоченной цепочкой, а не с одиночным вызовом: 
{
  "window_seconds": 600,
  "steps": [
    { "match": "crm.*",   "min_count": 3 },
    { "match": "*.export" },
    { "match": "*",       "egress": true }
  ]
}
Каждый шаг — это глоб инструмента с опциональным min_count (по умолчанию
  1. и опциональным egress: true (шаг должен быть egress-вызовом). Шаги должны происходить по порядку — чередование с другими вызовами допустимо — и вся цепочка должна завершиться в пределах window_seconds (0 = без ограничения).
Последовательности применяются реактивно асинхронным сопоставителем, а не inline на каждом вызове — иначе последовательность с шагом * совпадала бы с каждым вызовом инструмента. Они загораются в ленте событий и могут запускать последующее действие, но они не блокируют отдельный вызов, завершающий цепочку, в реальном времени.

​
9. Встроенные пресеты

Начните с пресета вместо пустого правила. Они написаны на стороне сервера, так что консоль и эта документация описывают идентичное поведение:
ПресетЧто делает
block_destructive_shellОтклоняет деструктивные shell-команды (rm -rf, mkfs, dd, fork-бомбы, …) через набор правил deny-by-glob.
block_ssrf_egressАудирует egress к эндпоинту метаданных и диапазонам RFC-1918.
block_secrets_in_argsОриентирован на детектирование — флагирует учётные данные, появляющиеся в аргументах инструментов.
block_pii_in_tool_resultsОриентирован на детектирование — выявляет PII в результатах инструментов.
Примените пресет как семя, затем редактируйте свободно — пресет это отправная точка, а не замок.

​
10. Вычисление, лимиты и безопасность

  • Побеждает первое совпадение. Правила выполняются в порядке priority ASC, id ASC; первое правило, чьи условия все выполняются, решает вердикт. Ни одно правило не совпало → default_verdict политики.
  • Детерминированно и без зависимостей. Сопоставление глобов и клауз — чистые операции над строками/JSON без сетевого вызова, безопасные для выполнения на каждом вызове инструмента. Regex — это RE2: линейное время, без катастрофического возврата.
  • Fail-closed клаузы. Клауза, которую нельзя вычислить, делает своё правило несрабатывающим, а не авто-отклоняет (§4).
  • Строгая валидация при сохранении. Сочетания вердикт/стадия, непустота очистителя, наличие cap_cost_cents, форма клауз и разрешение ссылок — всё проверяется при сохранении; некорректные правила не могут быть сохранены.
  • Аудируется. Каждое создание/обновление/удаление правила пишет строку аудита после коммита изменения; блобы правил и секреты никогда не пишутся в лог аудита.

​
API-справочник

Правила живут под политикой и ограничены рабочим пространством; записи требуют Developer+.
Метод и путьРольНазначение
POST /api/workspace/firewall/rulesDeveloper+Создать правило.
PUT /api/workspace/firewall/rulesDeveloper+Обновить правило (id в теле).
DELETE /api/workspace/firewall/rules/:idDeveloper+Удалить правило.
GET /api/workspace/firewall/presetsMemberСписок встроенных пресетов.
POST /api/workspace/firewall/testDeveloper+Dry-run политики (правила включены) по образцу вызова инструмента.
Чтобы предпросмотреть правило, прежде чем на него полагаться, используйте Test — он возвращает вердикт, совпавшее правило и причину, ничего не диспетчеризуя.

​
Смотрите также

Хотите глубже разобраться в безопасности агентов? Руководства «Защитите агентов — Zero Trust» встраивают эту функцию в рабочий процесс нулевого доверия.

Создайте политику firewall

Напишите политику нулевого доверия шаг за шагом, затем обкатайте её в shadow-режиме перед применением.

Справочник по схеме правил

Каждое поле правила — globs, предикаты аргументов, исходящий трафик и лимиты стоимости.