Перейти к основному содержанию
Вы хотите, чтобы ваши агенты использовали сервер Model Context Protocol (MCP) — ваш собственный удалённый сервер или встроенный — но хотите, чтобы каждый вызов инструмента, который он выставляет, выполнялся за единой аудируемой узловой точкой. Первый шаг — зарегистрировать сервер в вашем рабочем пространстве: имя, эндпоинт, режим аутентификации и его учётные данные. Как только он зарегистрирован, MCP-шлюз рекламирует его инструменты под одним подключением и вычисляет каждый tools/call через вашу политику firewall, прежде чем он достигнет реального сервера. Эта страница покрывает одну эту задачу — подключение и настройку записи сервера. О рантайм-поведении шлюза и вердиктах на каждый вызов см. Справочник MCP; о более широкой картине начните с Обзора безопасности MCP.
Регистрация — это действие консоли (маршруты /api/workspace/firewall/* аутентифицируются вашим session/access-токеном, а не relay-ключом sk-orca-…). Записи требуют роли Developer+; любой участник может перечислять серверы.

​
1. Как подключить MCP-сервер

Откройте Firewall → MCP Servers в консоли и добавьте сервер, либо вызовите workspace API напрямую. Регистрация несёт четыре значимые вещи:

name

Уникально в рамках рабочего пространства. Становится префиксом пространства имён <server>.<tool>, так что дублирующееся имя в том же рабочем пространстве отклоняется с HTTP 409.

endpoint

URL вашего удалённого MCP-сервера. Оставьте пустым, чтобы зарегистрировать встроенный внутрипроцессный сервер — так он станет видимым и управляемым.

auth_mode

Как шлюз аутентифицируется на вашем сервере: none, bearer, oauth или basic.

credentials

Специфичный для режима секрет. Хранится зашифрованным в покое и маскируется при чтении — никогда не достигает модели или клиента.
Сервер стартует enabled и полностью выбрасывается из шлюза в тот момент, когда вы его отключаете — это выключатель, и учётные данные отключённого сервера никогда не расшифровываются.

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

Зарегистрируйте удалённый GitHub MCP-сервер с bearer-токеном. Это console-эквивалентный REST-вызов; имена полей — ровно то, что пишет форма. 
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-session-or-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'
Форма учётных данных зависит от auth_mode:
{"token":"…"} — отправляется как bearer-токен на ваш сервер.
{"access_token":"…"} — статический access-токен, который шлюз отправляет как bearer-заголовок. Автоматический обмен client-credentials пока не поддерживается; без хранимого access_token зонд в режиме oauth завершается ошибкой, а не подключается неаутентифицированным.
{"username":"…","password":"…"}.
Пустая строка. Учётные данные не прикрепляются.
При чтении и учётные данные, и эндпоинт маскируются — API возвращает sentinel-плейсхолдеры, а не сырые значения. Когда вы обновляете сервер, верните эти плейсхолдеры неизменными, чтобы сохранить хранимые значения; отправляйте свежий auth_json только когда вы действительно ротируете секрет. См. ротацию учётных данных.

​
3. Зондирование его здоровья

Прежде чем вы сможете писать правила firewall против инструментов сервера, вам нужно знать, что они достижимы и как называются. Зондируйте (probe) сервер — шлюз прогоняет рукопожатие MCP initialize + tools/list, используя расшифрованные учётные данные, записывает достижимость и возвращает рекламируемые инструменты: 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-or-access-token>"

{
  "status": "ok",
  "last_checked_at": 1700000000,
  "tools": [
    { "name": "create_issue", "description": "…", "input_schema": {} }
  ]
}
status оседает в записи сервера и управляет индикатором здоровья:
statusЗначение
okДостижим; инструменты обслуживаются шлюзом.
degradedДостижим, но рукопожатие было частичным.
downНедостижим при последнем зонде; сервер пропускается.
Сервер down остаётся в стороне, когда шлюз строит свой набор инструментов, так что переходный сбой деградирует мягко вместо того, чтобы ломать диспетч. Зонд возвращает свой результат независимо от исхода — неудавшийся зонд возвращается как 200 с status: down и вычищенной причиной, а не как ошибка транспорта.
Встроенный внутрипроцессный сервер (пустой endpoint) диспетчит локально и не зондируется — зондирование его отклоняется ошибкой, объясняющей, что у регистрации нет эндпоинта. Вы зондируете только BYO-серверы, у которых есть URL.
Каждое изменение регистрации немедленно инвалидирует per-workspace кэш инструментов шлюза, так что вновь подключённый, отключённый или переснованный сервер вступает в силу на следующем подключении, а не после окна кэша.

​
4. После подключения

Как только сервер зарегистрирован и зондируется ok, его инструменты управляются:
  • Каждый вызов вычисляется. Каждый tools/call прогоняется через вашу политику firewall на поверхности mcp, прежде чем достигнет вашего сервера. Стройте охват правил по tool_name_glob: github.* теперь, когда вы знаете имена инструментов.
  • Заблокируйте поверхность. По умолчанию запрещайте инструменты, которые вы явно не разрешили — см. список разрешённых MCP-инструментов.
  • Управляйте тем, куда он достаёт. Напишите egress-правило, чтобы инструмент не мог обращаться к произвольным хостам.
  • Следите за изменениями. Сервер, которому вы доверяли, может изменить свои определения инструментов задним числом; защита от rug-pull отмечает этот дрейф.

​
5. API-справочник

Все маршруты консоли ограничены рабочим пространством и аутентифицируются вашим session/access-токеном. Чтения списков открыты любому Member (секреты замаскированы); каждая запись требует Developer+.
Метод и путьРольНазначение
GET /api/workspace/firewall/mcp_serversMemberСписок серверов (секреты + эндпоинт замаскированы).
GET /api/workspace/firewall/mcp_servers/:idMemberОдин сервер, замаскирован.
POST /api/workspace/firewall/mcp_serversDeveloper+Зарегистрировать сервер (409 при дублирующемся имени).
PUT /api/workspace/firewall/mcp_serversDeveloper+Обновить сервер (id в теле).
DELETE /api/workspace/firewall/mcp_servers/:idDeveloper+Soft-delete; освобождает имя.
POST /api/workspace/firewall/mcp_servers/:id/probeDeveloper+Зондировать достижимость + обнаружить инструменты.
SDK-прокси агента читает рантайм-реестр через токен области gateway по адресу GET /api/v1/firewall/mcp_servers (только включённые серверы). О том, как аутентифицировать эту сторону, см. аутентификацию MCP-шлюза.
Зачем вообще подключаться через OrcaRouter? Чтобы было одно место, которое видит каждый вызов инструмента — одно подключение, одна политика, один аудируемый лог и учётные данные, внедряемые при диспетче, а не разбросанные по конфигам агентов. Прочитайте защиту ИИ-агентов и угрозу отравления MCP-инструментов о мотивации.

​
Связанное

Обзор безопасности MCP

Полная модель управления MCP, от начала до конца.

Firewall: MCP-серверы

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

Аутентификация шлюза

Выпустите и ограничьте токен, с которым подключается ваш агент.

Чек-лист доверия

Всё, что нужно проверить, прежде чем доверять новому серверу.