Перейти к основному содержанию
Когда агент вызывает http_fetch, web_search или любой инструмент, открывающий исходящее подключение, назначение — это часть, которой вам нужнее всего управлять. Запутанный или захваченный агент, способный достичь 169.254.169.254, читает ваши облачные учётные данные; способный POST’ить на хост злоумышленника — эксфильтрирует ваши данные. Контроль egress агентов управляет этим назначением — вы создаёте правило allow/deny по host/CIDR на поверхности egress firewall, привязываете его к ключу, и шлюз проверяет каждое исходящее назначение, которое сообщает инструмент агента, до того как вызов выйдет. Это сфокусированная страница use-case. О полной грамматике правил и семантике вердиктов см. Схему правил и Вердикты; о том, как egress сидит среди других точек применения, см. Стадии.

​
1. Контроль egress агентов на поверхности egress

Из четырёх поверхностей firewall egress — та, что видит исходящее сетевое назначение, которое сообщает инструмент, — host, IP-литерал или CIDR. Правило, привязанное к stage: egress, совпадает с этим назначением, а не с именем инструмента или его аргументами, что делает его контролем SSRF и эксфильтрации данных: оно отвечает, куда может достичь этот агент, независимо от того, какой инструмент достигал.
Egress — это ограничение назначения, не блокировка инструмента. Чтобы инструмент вообще не существовал, отклоните его по имени на поверхности inbound (Блокировка инструментов). Контроль egress предполагает, что инструмент может законно извлекать — он просто ограничивает, куда.

​
2. Один пример: отклонить SSRF-назначения

Каноническое egress-правило отклоняет endpoint cloud metadata и приватные диапазоны RFC-1918 — назначения, которых инструмент в форме извлечения никогда не должен достигать. В консоли рабочего пространства откройте политику и добавьте правило с stage egress, вердиктом deny и egress-списком: 
{
  "label": "deny SSRF destinations",
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\",\"172.16.0.0/12\",\"192.168.0.0/16\"],\"allow\":[\"api.openai.com\"]}"
}
egress_json — это JSON-кодированная строка, несущая списки host/CIDR — декодированная, это {"deny": [...], "allow": [...]}. Каждая запись совпадает как CIDR, IP-литерал или нечувствительное к регистру имя хоста. Для вердикта deny список deny — это набор в области (назначения, которые правило блокирует), а список allow вырезает из него исключения — так что правило выше блокирует четыре диапазона, но пропускает api.openai.com, даже если он когда-либо разрешился бы в один из них. Когда назначение — имя хоста, а не литеральный IP, и ваш список несёт записи IP/CIDR, имя разрешается по принципу best-effort и его адреса перепроверяются, так что metadata.internal всё равно совпадает с deny 169.254.0.0/16, даже если оно не указано по имени.
Для позиции allow-list вместо этого — разрешить только названный набор назначений и заблокировать остальное — напишите правило с вердиктом allow и поместите ваши назначения в список allow. Полярность переворачивается: allow становится набором в области, а deny вырезает исключения. Сочетайте его с default_verdict политики deny, так чтобы всё, что allow-правило не покрывает, блокировалось.

​
3. Вы создаёте CIDR-правила — ни один пресет их не поставляет

Нет пресетного CIDR-списка. OrcaRouter не поставляет встроенное правило, отклоняющее 169.254.169.254, RFC-1918 или любой другой диапазон. CIDR allow/deny правило — ваше для создания — это пример в §2, написанный вами против вашей собственной сети. Скопируйте его, затем подстройте диапазоны и allow-list исключения под ваше окружение.
То, что уровень автономии tight и его пресет block_ssrf_egress действительно поставляют, — это набор deny на именах инструментов в форме извлечения — http_fetch, web_search, fetch_url, request, плюс их MCP-варианты <server>.<tool>. Это тупая позиция: она отказывает в инструментах в форме egress напрямую, а не ограничивает, куда они могут достичь. Тянитесь за ней, когда агенту вообще нечего делать с сетевыми вызовами; тянитесь за правилом назначения (§2), когда он действительно извлекает, но только из одобренного набора хостов.
ПодходЧто он ограничиваетАвтор
SSRF-пресет tightИмена инструментов в форме извлечения (отклоняет их)Встроенный
Egress CIDR/host правилоНазначение, которого может достичь извлечениеВы

​
4. Как выглядит заблокированный egress

Когда назначение совпадает с применяющим egress-правилом, вызов отклоняется до того, как покинет шлюз, и вычисление записывается как событие firewall с поверхностью egress и вердиктом deny. В shadow-режиме deny понижается до audit с причиной с префиксом [shadow] would …, так что вы можете точно измерить, какие назначения правило заблокировало бы против реального трафика, до того как примените его.
Некорректный или пустой egress-список трактуется консервативно: применяющее правило deny всё равно ограничивает (опечатка не может молча остановить его блокировку), но правило allow со сломанным списком не сработает — иначе неправильно набранный allow-list стал бы allow-all и затенил бы default deny. Новые правила валидируются при сохранении (список должен объявить хотя бы одну запись allow или deny), так что это лишь защищает legacy-строки.

​
5. Создавайте из реального трафика, затем разворачивайте

Журнал событий записывает хост назначения на каждом событии поверхности egress (egress_host/egress_url), так что отфильтруйте его по поверхности egress и создавайте свой deny-список по назначениям, которые реально появились, а не угадывая. Вкладка Discovered Tools — это свёртка по именам инструментов (имена инструментов и поверхности, на которых они срабатывали) — она говорит вам, какие инструменты в форме извлечения выполнялись, а не хосты, которых они достигли. См. Аналитику.
Вкладка Test в консоли прогоняет политику вхолостую против образца tool_name + поверхность (+ опциональные аргументы) и возвращает вердикт, совпавшее правило и причину — ничего не диспетчеризуется. Она подтверждает, к какому правилу разрешается вызов; чтобы подтвердить вашу CIDR/host-математику против реальных назначений, используйте shadow-режим ниже (полезная нагрузка Test не несёт назначение, так что сопоставление egress-списка отрабатывается на живом egress-трафике). См. Тестирование правил.
Включите shadow-режим, и egress-deny логируется так, как сработал бы, без блокировки. Наблюдайте за журналом событий, отфильтрованным по поверхности egress, подтвердите, что он ловит назначения, которые вы ожидаете, затем выключите shadow.
Ограничение назначения на шлюзе — это эшелонированная защита, не последняя линия. IP, в который имя хоста разрешается во время вычисления, может отличаться от того, который инструмент реально набирает (DNS rebinding). Держите контроль IP-deny на вашем собственном слое egress/dialer тоже; правило шлюза — дешёвый pre-flight перехват для очевидных случаев.

​
6. Привяжите политику и кто может её редактировать

Политика ничего не делает, пока к ней не разрешится ключ. Привяжите в консоли, установив firewall_policy_id на ключе, или сделайте политику default рабочего пространства. Разрешение такое: привязанная политика ключа (когда она существует и включена), иначе default рабочего пространства. Вся конфигурация egress-правил выполняется в консоли под вашей сессией (/api/workspace/firewall/*):
ДействиеРоль
Чтение политик, пресетов, обнаруженных инструментов, Simulate автономииMember
Создание / редактирование / удаление egress-правил и политикDeveloper+
Эндпоинт Test вхолостую (POST /test)Developer+
Чтение журнала событий и свёрток прогоновDeveloper+

​
Связанное

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

Угроза, которую решает контроль egress.

Стадии

Четыре поверхности и где сидит egress.

Вердикты

Что deny, audit и allow делают на проводе.

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

Отклонить инструмент извлечения по имени вместо назначения.

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

Более широкий класс риска.

Справочник Firewall

Полный справочник правил + сопоставления, включая egress-списки.