Перейти к основному содержанию
ИИ-агент не просто генерирует текст — он действует. Он вызывает shell.exec, запрашивает базу данных, извлекает URL, диспетчеризует инструмент через MCP-сервер. Каждое из этих действий имеет последствия в реальном мире, которых guardrails уровня промпта не видят. Agent firewall — это плоскость уровня действий, которая ими управляет: именованная политика в рамках рабочего пространства, которую шлюз вычисляет на каждом вызове инструмента, до того, как он достигнет инструмента. Эта страница — хаб раздела Firewall: модель политик, вердикты, поверхности и то, как политика привязывается к ключу. Каждая отдельная страница раскрывает тему глубже, а полный справочник движка находится в Firewall и Правилах Firewall.

​
1. Что делает agent firewall

Вы создаёте политику один раз в консоли рабочего пространства, привязываете к ней API-ключ (или назначаете её default’ом рабочего пространства), и с этого момента каждый вызов инструмента, который выпускает этот ключ, проверяется по политике в шлюзе. Никакого передеплоя, никаких изменений кода агента — ваш агент продолжает выпускать вызовы инструментов ровно так же, как раньше, а редактирование политики вступает в силу на следующем вызове для каждого привязанного к ней ключа. Политика — это упорядоченный список правил. Каждое правило решает, к каким вызовам инструментов оно применяется и что с ними делать. Движок проходит правила в порядке приоритета, побеждает первое совпадение, и откатывается к default-вердикту политики, если ничего не совпало.
Детектирование происходит в шлюзе, при первом использовании, — а не во время установки. Инструмент, MCP-сервер или навык, который агент устанавливает сам, ловится в тот момент, когда его вызов впервые пересекает шлюз. Это единственная узловая точка, которая видит каждого провайдера, каждого агента и каждый вызов инструмента независимо от того, как возможность туда попала.

​
2. Конкретный пример

Допустим, вы хотите блокировать деструктивные shell-команды, но пропускать всё остальное под аудитом. В консоли вы создаёте политику с default_verdict = audit и одним правилом: 
{
  "label": "block rm -rf",
  "tool_name_glob": "*.exec",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|drop table\"}]}",
  "verdict": "deny"
}
args_match_json — это JSON-кодированная строка (шлюз валидирует её по схеме клауз при сохранении): path — это JSONPath в аргументы вызова, op — один из eq, contains, regex, in, cidr_match, gt, lt. Привяжите ключ к политике (установите firewall_policy_id на ключе). Теперь, когда агент выпускает shell.exec с command: "rm -rf /", шлюз возвращает HTTP 400 с кодом ошибки firewall_blocked и причиной, называющей инструмент, — и вызов никогда не достигает shell. Каждый другой вызов инструмента разрешается и записывается для разбора.
Разверните новую политику сначала под shadow-режимом: она вычисляется и логируется ровно так, как делала бы в production, но каждый применяющий вердикт понижается до audit, а причина получает префикс [shadow] would …. Наблюдайте ленту событий, затем выключите shadow, чтобы начать применять.

​
3. Политика, правила и разрешение

Политика ограничена рабочим пространством и именована, с enabled, is_default, default_verdict (allow / audit / deny, по умолчанию audit) и флагом shadow_mode. Правило — это одна проверка внутри неё — см. Создание политики и Схему правил. Для любого вызова инструмента шлюз разрешает активную политику в этом порядке:
  1. Привязка ключа — firewall_policy_id вызывающего ключа, когда эта политика существует и включена.
  2. Default рабочего пространства — иначе включённая политика с is_default.
Отключённая привязанная политика firewall откатывается к default’у рабочего пространства — это отличается от guardrails, где отключённая привязка разрешается в none. Выключатель firewall на ключе означает «использовать default», а не «нет применения». См. Управление политиками.
Когда ни одна политика не разрешается вообще, поведение зависит от настройки рабочего пространства firewall_observe_mode: при включённом observe-режиме вызов разрешается, но логируется как пробел в покрытии (он появляется в Discovered Tools); при выключенном вызов разрешается молча.

​
4. Вердикты

Правило — или default — производит один из:
ВердиктЧто делает
allowПропустить, логируется.
auditРазрешить + записать для разбора. Обычный default.
denyЗаблокировать. HTTP 400 firewall_blocked на inbound; ошибка инструмента на MCP.
sanitizeОтредактировать совпавшие подстроки из аргументов инструмента и переслать.
pending_approvalУдержать для человека; HTTP 400 firewall_approval_pending.
cap_costОтклонить, как только траты прогона превысят пороговый лимит правила.
Вердикт sanitize редактирует только аргументы вызова — никогда содержимое, которое возвращает инструмент. На поверхности inbound, где аргументов времени вызова ещё нет, sanitize эскалирует до блокировки. См. Вердикты и Очистка ответов.

​
5. Четыре поверхности применения

Каждый вызов инструмента вычисляется ровно по одной поверхности — привяжите правило к одной полем stage или оставьте его пустым, чтобы применить ко всем.

inbound

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

response

tool_calls, которые модель выдаёт в своём ответе.

mcp

tools/call, диспетчеризованный через MCP-шлюз. См. MCP-серверы.

egress

Исходящий host / IP / CIDR, к которому обращается инструмент, — поверхность SSRF и эксфильтрации данных.

​
6. Сопоставление

Правила выражают, какие вызовы инструментов они ловят, малым детерминированным словарём, безопасным на горячем пути:
Регистрозависимый глоб по имени инструмента (shell.*, *.delete), опционально AND-нутый с глобом по владеющему навыку. См. Синтаксис глобов и Списки разрешённых инструментов.
JSONPath-предикаты над аргументами вызова с операторами eq, contains, regex, in, cidr_match, gt, lt — разница между «блокировать shell.exec» и «блокировать его, только когда команда — rm -rf». Клаузы fail closed (правило, а не запрос). См. Проверка аргументов.
Списки разрешённых и запрещённых host / IP / CIDR на поверхности egress. Вы можете написать собственное правило deny для cloud-metadata или диапазонов RFC-1918. См. Контроль egress.
Правило sequence сопоставляет упорядоченную цепочку вызовов в пределах окна (применяется реактивно); правило cap_cost отклоняет, как только накопленные траты прогона агента превышают потолок в центах. См. Правила последовательностей и Лимит стоимости.

​
7. Подтверждение человеком, автономия и аномалии

  • Human-in-the-loop. Вердикт pending_approval удерживает вызов и возвращает его id подтверждения. Ревьюер разрешает его в консоли (Developer+) или через подписанный HMAC вебхук-колбэк; агент опрашивает и повторно отправляет с одноразовым заголовком X-OrcaRouter-Firewall-Approval. См. Подтверждения и Вебхук подтверждения.
  • Уровни автономии. Один переключатель задаёт всю вашу позицию: tight (default-deny + блокировка деструктивного shell + блокировка инструментов в форме fetch (http_fetch/web_search/fetch_url/request, вектор SSRF) + применение PII Shield + Secrets Blocker), balanced (default audit, блокировка деструктивного shell, PII Shield только в режиме аудита) или permissive (только наблюдение). Каждый записывает реальные, редактируемые строки политики и guardrail, с отменой в один клик из снимка аудита.
  • Детектирование аномалий. Помимо статических правил, firewall оценивает использование инструментов относительно обученного базиса по часу недели (14-дневного) и флагирует всплески частоты/стоимости, retry_loop и novel_path в читаемой Member’ом ленте, которую можно отложить на срок до 7 дней.

​
8. Где firewall вписывается

Firewall — это собрат уровня действий двух соседних плоскостей:
ПлоскостьУправляетКогда к ней обращаться
GuardrailsТекст промпта и ответаPII, секреты, jailbreak, намерение инъекции
Agent firewallДействия инструментовКакие инструменты, MCP-вызовы, хосты и стоимость
ComplianceДоказательства и фреймворкиГотовность к SOC 2 / HIPAA / EU AI Act
И контентная, и action-плоскость могут применяться к одному запросу, а уровень автономии настраивает их вместе. См. Guardrails vs. Firewall и стек управления.

​
9. Привязка и подключение

Политика привязывается к ключу через firewall_policy_id (настраивается в консоли; привязка живёт на ключе в шлюзе). Есть два способа, которыми вызов инструмента достигает движка, оба требуют ключа с областью firewall-gateway (is_firewall_gateway = true) — обычный relay-ключ получает 403 на этих маршрутах:
  • MCP-шлюз — направьте ваш MCP-клиент на единый эндпоинт ANY /api/v1/firewall/mcp; каждый tools/call вычисляется inline. См. MCP-серверы.
  • Хук evaluate — вызывайте POST /api/v1/firewall/evaluate (или /evaluate_plan для многошагового плана) из собственного цикла агента перед диспетчем и действуйте по вердикту.
Вся консольная конфигурация работает в рамках вашей сессии через /api/workspace/firewall/*. Чтения политик, настроек, обнаруженных инструментов, read-only симулятора автономии и ленты аномалий открыты каждому участнику рабочего пространства; dry-run песочница Test, лог Events / Runs и все записи требуют Developer+. См. Ключи шлюза и Тестирование правил.

​
10. Угрозы, которые адресует эта плоскость

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

Блокировка деструктивного shell, DB-drop’ов и рискованных команд по глобу + аргументам.

Эксфильтрация данных

Списки egress и правила последовательностей read-then-export.

Отравление MCP-инструментов

Вычисление каждого вызова на поверхности mcp до диспетча.

Избыточная агентность

Подтверждения, лимиты стоимости и позиция default-deny.

​
Дальнейшие шаги

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

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

Вердикты

Что каждый вердикт делает на проводе.

Лог событий

Прочитайте, что firewall решил и почему.