Перейти к основному содержанию
Правило firewall срабатывает в конкретной точке жизненного цикла вызова инструмента. Эта точка — его стадия, одна из четырёх поверхностей применения, каждая из которых видит свой срез вызова. Привяжите правило не к той стадии — и оно увидит не те данные: egress-allowlist на поверхности inbound не имеет назначения для проверки; клауза аргумента на inbound пока не имеет аргументов времени вызова. Эта страница — сфокусированное руководство по четырём стадиям agent firewall: что наблюдает каждая поверхность, когда правило должно её нацеливать и один конкретный способ, которым одно и то же намерение выражается на разных стадиях. Полный словарь правил см. в Правилах Firewall; модель политик вокруг них — в Firewall.

​
1. Четыре стадии с первого взгляда

Каждое вычисление штампуется ровно одной стадией. Правило без стадии ("") применяется ко всем из них; правило, привязанное к одной стадии, срабатывает только там.
СтадияЧто видит поверхность
inboundИнструменты, которые агент рекламирует в запросе
responsetool_calls, которые модель выдаёт в своём ответе
mcptools/call, диспетчеризованный через MCP-шлюз
egressИсходящий host / IP / CIDR, к которому обращается инструмент
Имена стадий — это стабильные enum-значения: вы устанавливаете их дословно в поле стадии редактора правил или как свойство stage при написании через API.
Стадия управляет тем, какие данные в области видимости, а не тем, насколько строг вердикт. deny — это deny на любой стадии; меняется лишь то, есть ли у правила аргументы, имя инструмента или назначение, которые ему нужно сопоставить.

​
2. inbound — инструменты, которые агент рекламирует

Самая ранняя поверхность. Прежде чем модель вообще запустится, ваш агент отправляет список определений инструментов, которые он готов позволить модели вызвать. Стадия inbound видит этот рекламируемый набор инструментов и может заблокировать опасный инструмент до того, как модель сможет его выбрать. На этой стадии нет аргументов времени вызова — модель ещё не решила, как что-либо вызывать, — поэтому правила inbound сопоставляют по имени инструмента (и опционально его владеющему навыку), а не по args_match_json.
Вердикту sanitize на inbound нечего редактировать (аргументов ещё нет), поэтому он эскалирует до блокировки. Пишите inbound-правила как явные allow / deny, а sanitize приберегите для стадий исполнения.
Отклонённый вызов здесь возвращает HTTP 400 с кодом firewall_blocked, названный по инструменту и причине, и помеченный skip-retry.

​
3. response — вызовы инструментов, которые выдаёт модель

Как только модель отвечает, она может выдать один или несколько tool_calls — конкретные вызовы с реальными аргументами. Стадия response видит их, поэтому именно здесь место правилам уровня аргументов: не «блокировать shell.exec», а «блокировать shell.exec, только когда команда — rm -rf». 
{
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
Поскольку выбранные моделью аргументы присутствуют, sanitize здесь работает — он редактирует совпавшие подстроки из аргументов вызова и пересылает очищенный вызов. (Sanitize редактирует только аргументы вызова инструмента; он никогда не касается содержимого, которое инструмент возвращает.)

​
4. mcp — вызовы, диспетчеризованные через шлюз

Когда агент достигает инструмента через MCP-шлюз OrcaRouter, каждый tools/call вычисляется на стадии mcp до того, как он будет диспетчеризован зарегистрированному серверу. Это поверхность, которая управляет трафиком Model Context Protocol — тот же словарь глоб / аргумент / вердикт, что и у response, применённый к MCP-диспетчу. Блокировка здесь проявляется как ошибка инструмента (firewall deny: <reason>), а не сбой транспорта, так что модель видит отказ и может среагировать — выбрать другой инструмент, спросить пользователя или остановиться.
Стадия mcp сочетается с управлением по каждому серверу: каждый зарегистрированный MCP-сервер имеет собственную проверку здоровья и зашифрованные учётные данные, а навыки, загруженные через него, несут полосу риска и режим применения. См. Firewall MCP и Навыки Firewall.

​
5. egress — исходящее назначение, к которому обращается инструмент

Последняя поверхность. Когда инструмент сообщает исходящее сетевое назначение, стадия egress сопоставляет по нему — поверхность SSRF и эксфильтрации данных. Egress-правила не сопоставляют по одному лишь паттерну имени инструмента; они сопоставляют по списку host / IP / CIDR: 
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\"],\"allow\":[\"api.openai.com\"]}"
}
Записи сопоставляются как CIDR, IP-литерал или регистронезависимое имя хоста. Вы сами пишете правила deny для host и CIDR — эндпоинт cloud-metadata (169.254.169.254) и диапазоны RFC-1918 — это канонические вещи, которые стоит запретить. См. Правила Firewall §6 про полярность allow/deny.
Ни один пресет не поставляет CIDR-правила. SSRF-позиция уровня автономии tight блокирует имена инструментов в форме fetch (например, http_fetch, web_search, fetch_url); egress-deny на основе назначения — это то, что вы пишете для хостов и диапазонов, которых ваши агенты никогда не должны достигать.

​
6. Выбор правильной стадии

У одной и той же цели безопасности часто есть лучшая стадия. Сопоставьте намерение с поверхностью, которая реально несёт нужные вам данные:
Если модель никогда не должна даже видеть инструмент, заблокируйте его на inbound. Блокировка приземляется до вызова модели, поэтому она не стоит токенов модели.
Клаузам аргументов нужны выбранные моделью аргументы, которые существуют только на response и mcp. Блокируйте по опасному аргументу или sanitize, чтобы убрать секрет или значение PII, которое агент поместил в аргумент.
Вызовы, маршрутизированные через MCP-шлюз, вычисляются на mcp до диспетча — узловая точка для инструментов каждого зарегистрированного сервера.
Правила на основе назначения — заблокировать IP cloud-metadata, запретить CIDR, добавить ваши одобренные хосты в список разрешённых — имеют смысл только на egress.
Правило без стадии работает на всех четырёх. Используйте его для общего правила в стиле default_verdict или инструмента, который вы блокируете везде, где он появляется.

​
7. Стадии и shadow-режим

Флаг shadow_mode политики независим от стадии. Включите его, и каждый применяющий вердикт — на любой стадии — понижается до audit, а причина получает префикс [shadow] would …, так что вы можете подтвердить, что правило срабатывает на правильной поверхности, прежде чем оно изменит живой трафик. См. Shadow-режим и Режимы применения.

​
8. Где стадии вписываются в большую картину

Четыре стадии — это где применения; остальная часть модели — это что и кто.

Вердикты

Что каждая стадия может сделать после совпадения — allow, audit, deny, sanitize, удержать для подтверждения, ограничить стоимость.

Списки разрешённых инструментов

Используйте inbound, чтобы ограничить набор инструментов, который рекламирует агент.

Проверка аргументов

Пишите клаузы аргументов response / mcp, которые гейтят инструмент по тому, как он вызван.

Контроль egress

Блокируйте исходящие назначения на поверхности egress — граница эксфильтрации.
О том, как эти поверхности расположены на пути инспекции, см. Как OrcaRouter инспектирует и заметки о латентности пути применения. Угрозы, которые адресует каждая стадия, см. в Опасных вызовах инструментов, Эксфильтрации данных и Отравлении MCP-инструментов.