Перейти к основному содержанию
MCP-сервер, который вы подключаете, поставляет инструменты, обращающиеся к сети — fetch, web_search, отправщик webhook. Имя инструмента может быть в вашем списке разрешённых, аргументы могут выглядеть чисто, а вызов всё равно заканчивается отправкой ваших данных на хост, контролируемый злоумышленником, или вытягиванием учётных данных с эндпоинта метаданных 169.254.169.254. Назначение — это та часть вызова, которую ваши правила по имени инструмента никогда не видят. mcp egress control закрывает этот пробел. Egress-правило ограничивает вердикт firewall тем, куда обращается инструмент — хостом, IP или диапазоном CIDR — так что тот же http_fetch, которому разрешено api.openai.com, запрещён ко всему остальному. Оно работает на поверхности egress firewall, поверх оценки на каждый вызов, через которую уже проходит каждый tools/call.
Это консольная задача. Правила firewall живут на маршрутах /api/workspace/firewall/*, которые аутентифицируются вашей сессией / access-токеном — не relay-ключом sk-orca-…. Написание правила требует роли Developer+.

​
1. Что контролирует egress-правило

Обычное правило совпадает по имени инструмента и его аргументам. Egress-правило добавляет третье измерение: назначение, в которое разрешается вызов. Вы устанавливаете stage правила в egress и прикрепляете список разрешений / запретов egress_json. Движок извлекает хост назначения из вызова и срабатывает правилом только когда этот хост в области. Записи сопоставляются тремя способами:

Имя хоста

Точное совпадение без учёта регистра, например api.openai.com. Завершающая точка обрезается с обеих сторон.

IP-литерал

Точное совпадение с разрешённым IP набора, например 169.254.169.254.

Диапазон CIDR

IP назначения — литеральный или разрешённый через DNS — должен попадать внутрь блока, например 10.0.0.0/8.
Когда назначение — это имя хоста, но ваш список несёт записи IP/CIDR, имя разрешается, и его IP перепроверяются — так что metadata.internal совпадает с deny 169.254.0.0/16, даже если оно не указано по имени. Это защита в глубину по принципу best-effort против имени, разрешающегося в запрещённый диапазон; авторитетная SSRF-защита по-прежнему работает на уровне набора шлюза.

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

Запретите каждому инструменту в форме fetch обращаться к эндпоинту облачных метаданных и диапазонам RFC-1918. Это канонический разрез ноги эксфильтрации SSRF: вердикт deny на стадии egress, ограниченный списком запретов egress_json. 
curl https://api.orcarouter.ai/api/workspace/firewall/rules \
  -H "Authorization: Bearer <your-session-or-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "policy_id": 12,
    "priority": 10,
    "label": "Deny SSRF / metadata egress",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny",
    "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\",\"172.16.0.0/12\",\"192.168.0.0/16\"]}"
  }'
tools/call, чьё назначение разрешается в любой из этих диапазонов, возвращается модели как ошибка инструмента; вызов к публичному хосту, который не покрыт списком запретов, проходит насквозь.
Списки allow/deny меняют значение в зависимости от вердикта. На deny-правиле (или другом принуждающем) список deny — это набор в области, а allow вырезает исключения — «запретить эти, кроме тех». На allow-правиле роли инвертируются: список allow — это набор в области, а deny вырезает исключения — «разрешить только эти». Непустой egress_json должен объявлять хотя бы одну запись allow или deny, иначе запись отклоняется.

​
3. Разрешить списком только одно назначение

Обратное предыдущему примеру: прикрепите fetch-инструмент к одному санкционированному хосту и дайте default_verdict политики (или последующему catch-all) разобраться с остальным. Поскольку это вердикт allow, список allow — это набор в области. 
// egress_json на правиле с вердиктом allow, stage=egress
{ "allow": ["api.openai.com", "api.anthropic.com"] }
Правило теперь срабатывает (разрешает) только когда назначение — один из этих двух хостов. Всё остальное проваливается к следующему правилу — сочетайте это с политикой default-deny, чтобы неуказанное назначение отвергалось, а не пропускалось.
Протестируйте, прежде чем доверять. Вкладка Test консоли и эндпоинт POST /api/workspace/firewall/test (Developer+) воспроизводят образец вызова против вашей черновой политики, так что вы можете подтвердить вердикт на известном назначении, не отправляя живой трафик.

​
4. Как это компонуется с остальным firewall

Egress-правило — это одно правило среди многих в политике firewall рабочего пространства. Движок проходит правила в порядке приоритета (наименьший первым), и выигрывает первое совпадение, так что ставьте узкий egress deny выше любого широкого allow.
Вердикт на egress-правилеЭффект
denyБлокирует вызов к назначениям в области — записывается на поверхности egress и возвращается инструменту как ошибка.
auditЛогирует совпавший вызов как событие firewall; всё равно диспетчит.
allowРазрешает назначения в области; сочетается с полом default-deny.
pending_approval и cap_cost не применяются на поверхности egress — egress — это проверка назначения, а не удержание или лимит расходов. Используйте эти вердикты на поверхностях mcp или inbound. См. справочник вердиктов.
Два связанных контроля стоит подключить рядом с egress-правилом:
Независимо от любого написанного вами правила, MCP-шлюз валидирует каждый эндпоинт сервера и его разрешённый IP набора против SSRF-политики — интранет-диапазоны и адрес облачных метаданных отвергаются, а IP перепроверяется на каждом хопе, чтобы победить DNS rebinding. Ваше egress-правило наслаивает специфичную для рабочего пространства политику назначений поверх этой базовой линии.
Единичный egress deny останавливает обращение инструмента к хосту. Правило последовательности останавливает цепочку — например, «прочитать файл, затем egress в пределах окна» — помечая ногу egress только когда она следует за чувствительным чтением. Это разрыватель смертельной трифекты; ограничение egress — это контроль на каждый вызов.

​
5. Сначала shadow, затем применяйте

Выкатка egress deny напрямую в применение на загруженном рабочем пространстве рискует сломать легитимную интеграцию, о которой вы забыли. Две страховочные сети:
  • Shadow-режим. Политика в shadow-режиме понижает каждый принуждающий вердикт до audit — ваш egress deny логирует [shadow] would deny … вместо блокировки, так что вы видите радиус поражения, прежде чем он начнёт кусаться.
  • Режим observe. Настройка рабочего пространства firewall_observe_mode логирует непокрытые вызовы как Обнаруженные инструменты, показывая реальные назначения, к которым ваши агенты уже обращаются, чтобы вы могли написать точный список разрешённых на основе данных, а не догадок.
Сопоставление назначений egress ключуется по хосту, в который вызов разрешается во время оценки. Враждебный сервер всё ещё может перепривязать DNS между проверкой политики и фактическим набором (TOCTOU) — именно поэтому IP-защита на уровне сокета шлюза является авторитетным контролем, а это правило — защита в глубину, а не единственная линия.

​
6. Роли и маршруты

Все консольные маршруты ограничены рабочим пространством и аутентифицируются вашей сессией / access-токеном. Чтение открыто любому Member; написание или редактирование правила требует Developer+.
Метод и путьРольНазначение
GET /api/workspace/firewall/policies/:idMemberПрочитать политику и её правила.
POST /api/workspace/firewall/rulesDeveloper+Добавить правило (установить stage: egress).
PUT /api/workspace/firewall/rulesDeveloper+Обновить правило (id в теле).
DELETE /api/workspace/firewall/rules/:idDeveloper+Удалить правило.
POST /api/workspace/firewall/testDeveloper+Воспроизвести образец вызова против черновой политики.

​
Связанное

Справочник правил Firewall

Полный DSL правил — глобы инструментов, сопоставление аргументов, списки egress, последовательности.

Подключить MCP-сервер

Зарегистрируйте сервер, чтобы вызовы его инструментов выполнялись за firewall.

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

Default-deny для инструментов, которые вы явно не одобрили.

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

Угроза, для остановки которой построен контроль egress.