Перейти к основному содержанию
Зарегистрированный MCP-сервер рекламирует любые инструменты, какие захочет, — а агент с радостью вызовет любой из них. Безопасная позиция обратна: определите короткий список инструментов, которые вам действительно нужны, разрешите ровно их и запретите остальное. Это список разрешённых (allow-list), и на OrcaRouter вы строите его из правил tool_name_glob, оцениваемых на поверхности mcp. Каждый tools/call, пересекающий MCP-шлюз, прогоняется через вашу политику firewall до того, как он достигнет реального сервера. Так что список разрешённых не носит рекомендательный характер — вызов инструмента, который вы не разрешили, никогда не диспетчится.
Редактирование политики — это консольное действие. Маршруты /api/workspace/firewall/* аутентифицируются вашей сессией / access-токеном, а не relay-ключом sk-orca-…. Запись правил требует роли Developer+; любой участник рабочего пространства (вплоть до Viewer) может читать политики и ленту обнаруженных инструментов.

​
1. Зачем нужен список разрешённых default-deny для безопасных mcp-инструментов

Список запрещённых (deny-list) — «блокировать опасные инструменты» — проваливается в момент, когда сервер добавляет новый инструмент, переименовывает один или вы подключаете второй сервер. Набор опасных инструментов открыт; набор, который вы намеревались использовать, мал и известен. Список разрешённых инвертирует значение по умолчанию, так что неизвестное отвергается, а не допускается:
  • Новые инструменты запрещены по умолчанию. Сервер, у которого вырастает инструмент delete_repo после того, как вы его подключили, не может быть вызван, пока вы не добавите его в список разрешённых.
  • Охват — на каждый сервер. Пространство имён <server>.<tool> позволяет вам разрешить github.create_issue, запретив всё остальное под github.*.
  • Одна узловая точка. Та же политика управляет встроенным сервером и каждым BYO-сервером за шлюзом, так что есть одно место для чтения списка разрешённых.
Список разрешённых естественно сочетается с режимом observe: включите его сначала, дайте реальному трафику наполнить ленту Обнаруженных инструментов, затем продвиньте инструменты, которые вы видите, в явные allow-правила и переключите значение по умолчанию на deny.

​
2. Две составляющие

Список разрешённых — это default_verdict плюс упорядоченный набор правил.

default_verdict: deny

Запасной вариант политики для любого tools/call, не совпавшего ни с одним правилом. Установите его в deny, и всё, что вы явно не разрешили, блокируется. (Он также принимает allow и audit — audit по умолчанию.)

allow-правила

Одно правило на инструмент (или на глоб). Каждое несёт tool_name_glob и вердикт allow. tools/call, совпавший с глобом, разрешается в allow и диспетчится; всё остальное падает на deny по умолчанию.
Глоб сопоставляется с именем инструмента в пространстве имён — github.create_issue, shell.exec. * совпадает с любым инструментом (используйте экономно; allow-правило с * сводит на нет весь список разрешённых). Ведущий <server>. ограничивает глоб одним сервером.

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

Вы подключили сервер github и хотите, чтобы агенты только читали и открывали задачи — никогда ничего не удаляли и не администрировали. В консоли откройте Firewall → Policies, установите вердикт политики по умолчанию в deny и добавьте два allow-правила:
Порядокtool_name_globВердикт
1github.create_issueallow
2github.list_issuesallow
Это весь список разрешённых. При значении по умолчанию deny:
  • github.create_issue → совпадает с правилом 1 → allow, диспетчится.
  • github.delete_repo → не совпадает ни с чем → deny по умолчанию.
Запрещённый MCP-вызов возвращается модели как ошибка инструмента (firewall deny: …) — той же формы, что возвращает любой сбойный инструмент — так что агент может адаптироваться, а не упасть. (На поверхности inbound deny — это вместо этого HTTP 400 с кодом ошибки firewall_blocked.)
Правила упорядочены и оцениваются сверху вниз. Не ставьте широкое allow tool_name_glob: github.* выше ваших конкретных deny-правил — выигрывает первое совпадение, и подстановочный знак допустил бы те самые инструменты, которые вы намеревались исключить. В случае сомнений держите список разрешённых узким и опирайтесь на deny по умолчанию, а не на подстановочные знаки.

​
4. Ужесточение аргументами

Имя инструмента в списке разрешённых всё ещё может быть вызвано с плохими аргументами. Сузьте дальше, добавив клаузу args_match (JSONPath + оператор вроде eq, contains, regex, in или cidr_match) в правило или наслоив deny-правило над allow для конкретной формы аргумента — например, разрешите github.create_issue, но deny-те его, когда целевой репозиторий не в одобренном списке. См. справочник правил firewall для полного набора операторов.
sanitize редактирует аргументы вызова инструмента перед пересылкой — оно никогда не касается того, что инструмент возвращает. Для усечения возвращаемого контента это другой контроль; см. очистку вывода инструментов.

​
5. Выкатывайте безопасно

Переключите default-deny на весь сервер в продакшене — и вы рискуете сломать агента, который тихо зависел от инструмента, о котором вы забыли. Две настройки снижают этот риск:
Флаг на каждую политику, понижающий принуждающие вердикты до audit. Ваш deny по умолчанию и deny-правила логируют [shadow] would deny … вместо блокировки, так что вы можете проверить список разрешённых на реальном трафике, прежде чем он начнёт кусаться. Подробнее в режимах применения.
Настройка рабочего пространства, которая логирует каждый непокрытый вызов как пробел в ленте Обнаруженных инструментов. Запустите её перед написанием списка разрешённых, чтобы узнать, какие именно инструменты вызывают ваши агенты, затем продвиньте каждый в явное allow-правило.
Как только shadow-журнал чист — ни один легитимный вызов не был бы запрещён — очистите shadow_mode, и список разрешённых применяется.

​
6. Убедитесь, что это работает

После применения подтвердите, что запрещённые инструменты действительно отклоняются:
  • Dry-run tools/call против политики (Developer+), чтобы увидеть вердикт и какое правило — или значение по умолчанию — его произвело, без отправки реального трафика. Передайте имя инструмента, поверхность и образец аргументов; движок оценивает их и возвращает трассировку вердикта, не записывая событие.
  • Наблюдайте за событиями. Каждый заблокированный вызов записывает событие firewall, которое может прочитать Developer+ в консоли; страница событий аудита покрывает ленту и её поля.
Предпочитаете не писать каждое правило вручную? Пресет автономии tight пишет политику default-deny за вас (плюс deny-правила для деструктивных shell-инструментов и имён инструментов в форме fetch), затем вы добавляете обратно конкретные нужные вам инструменты. См. режимы применения о том, что устанавливает каждый уровень автономии.

​
Связанное

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

Зарегистрируйте сервер, прежде чем вы сможете внести его инструменты в список разрешённых.

Firewall: MCP servers

Рантайм-поведение шлюза и вердикты на каждый вызов.

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

Полный DSL правил — глобы, args_match, egress, sanitize.

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

Угроза, для сдерживания которой построен список разрешённых.

Лимиты egress

Управляйте тем, куда может обращаться разрешённый инструмент.

Guardrails vs. firewall

Когда обращаться к контентной политике, а когда к политике инструментов.