Перейти к основному содержанию
Агент, говорящий на Model Context Protocol (MCP), настолько безопасен, насколько безопасны серверы, к которым он подключается. Каждый MCP-сервер — это свежий набор инструментов, свежие учётные данные и свежий сетевой охват — и в тот момент, когда агент набирает один из них напрямую, никто не наблюдает за вызовом. Именно эту проблему должна решить безопасность mcp: не «безопасен ли вот этот один инструмент», а «кто управляет всеми ими, на каждом вызове, с одним следом аудита». Ответ OrcaRouter — единая аудируемая узловая точка. Вы регистрируете каждый MCP-сервер один раз; агенты подключаются к одному шлюзу; и каждый tools/call прогоняется через движок firewall, прежде чем достигнет реального сервера. Эта страница — карта этой поверхности: шлюз, вердикт на каждый вызов, управление навыками, egress и зашифрованные учётные данные — со ссылками на сфокусированный how-to по каждому.
Каждое управляющее действие здесь настраивается из консоли (или REST API с вашим session/access-токеном) и защищено ролями. Только /v1/* relay-вызовы и gateway-маршруты firewall несут ключ вида sk-orca-....

​
1. Почему безопасности mcp нужен шлюз

Направьте десять агентов на пять community-MCP-серверов напрямую — и вы получите худшее из всех миров: ни общей политики, ни следа аудита, учётные данные скопированы в десять конфигов агентов, а инструмент по имени shell.exec — в одном редиректе от вашего эндпоинта облачных метаданных. Шлюз схлопывает это в одно управляемое подключение.

Одно подключение, каждый сервер

Агенты подключаются к единому эндпоинту. Шлюз агрегирует инструменты каждого включённого, достижимого сервера под пространством имён <server>.<tool>.

Политика на каждом вызове

Каждый tools/call вычисляется вашей политикой firewall перед диспетчем.

Зашифрованные учётные данные

Секреты аутентификации сервера шифруются в покое, маскируются при чтении и внедряются при диспетче — они никогда не достигают модели или клиента.

Egress под контролем

Эндпоинт зарегистрированного сервера валидируется по приватным диапазонам и диапазонам облачных метаданных по умолчанию. Для назначений на каждый инструмент примените базовый SSRF egress-denylist или напишите собственные правила host/CIDR.
Об основах за всем этим см. Защита ИИ-агентов и Почему нулевое доверие.

​
2. Четыре строительных блока

Управление MCP на OrcaRouter — это четыре кооперирующихся части. Выберите ту, что соответствует вопросу, на который вы пытаетесь ответить.
Единый эндпоинт, к которому ваши агенты подключаются вместо того, чтобы набирать серверы напрямую. Он агрегирует инструменты каждого зарегистрированного сервера в пространстве имён <server>.<tool> и переэкспонирует входную схему каждого инструмента дословно. Начните с Подключения MCP-сервера и Аутентификации; полный справочник живёт в Firewall: MCP-серверы.
Шлюз прогоняет каждый tools/call через firewall на поверхности mcp и возвращает вердикт — allow, audit, deny, sanitize или pending_approval — перед диспетчем. См. Список разрешённых MCP-инструментов и Очистка аргументов инструмента.
Возможности, которые агент устанавливает сам — навыки, BYO-MCP-серверы, плагины — сканируются, получают полосу риска и режим применения (allow / quarantine / block), который надстраивается над каждым вердиктом правила. См. Firewall: навыки и Защита от rug-pull.
Секрет аутентификации каждого сервера шифруется в покое и маскируется при чтении. См. Аутентификацию и Ротацию учётных данных.

​
3. Как вычисляется tools/call

Когда агент вызывает инструмент через шлюз, вызов не идёт прямо к серверу. Он сопоставляется с политикой вашего рабочего пространства, поверх применяется режим применения владеющего навыка, и только вердикт allow / audit / sanitize достигает реального сервера.
ВердиктЧто видит агент
allow / auditПереслано. audit также логирует событие.
sanitizeПереслано с аргументами отредактированными (никогда результат).
deny / pending_approvalВозвращено как ошибка инструмента, так что агент может адаптироваться, а не падать.
Заблокированный MCP-вызов возвращается как ошибка инструмента (firewall deny: …), в той же форме, какую возвращает любой сбойный инструмент — агент может попробовать иначе, спросить пользователя или остановиться. Это не сбой транспорта.
Словарь вердиктов, поверхности и сопоставление правил задокументированы полностью в Firewall и Правилах firewall; концептуальная модель — в Режимах применения и Как OrcaRouter проверяет.

​
4. Регистрация сервера (один конкретный пример)

Вы регистрируете каждый сервер один раз. Запись сервера несёт name (уникальный в рамках рабочего пространства, без .), endpoint, auth_mode (none / bearer / oauth / basic) и его зашифрованные учётные данные. Делайте это из консоли — запись требует Developer+. 
# Маршрут консоли, вызывается с вашим session/access-токеном (UserAuth).
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-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
  }'
Затем зондируйте (probe) его, чтобы обнаружить его инструменты и записать достижимость (ok / degraded / down): 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
Теперь вы можете писать правила против github.*, точно зная, что принимает github.create_issue. Сквозное руководство живёт в Подключении MCP-сервера.
Секреты никогда не хранятся в открытом виде. auth_json шифруется в покое и маскируется при чтении; при обновлении верните маску обратно, чтобы сохранить хранимое значение. См. Ротацию учётных данных.

​
5. Подключение агента к шлюзу

Когда серверы зарегистрированы, направьте любой MCP-клиент на шлюз с ключом области firewall-gateway (токен без этой области получает 403): 
https://api.orcarouter.ai/api/v1/firewall/mcp
Шлюз говорит на streamable HTTP и рекламирует инструменты каждого включённого, достижимого сервера под пространством имён <server>.<tool>. SDK, который проксирует вызовы сам, может читать рантайм-реестр из GET /api/v1/firewall/mcp_servers с тем же gateway-токеном.

​
6. Ограничьте, чего могут достичь инструменты

Вердикты на каждый вызов управляют тем, какой инструмент запускается; egress-контроли управляют тем, куда он может достичь. Кооперируют два слоя. Во-первых, когда шлюз подключается к эндпоинту зарегистрированного сервера, этот URL валидируется по приватным (RFC1918), loopback, link-local и cloud-metadata-диапазонам по умолчанию — а хост разрешается по DNS, так что имя, разрешающееся в заблокированный диапазон, тоже отвергается. Так что BYO-сервер, нацеленный на 169.254.169.254 или интранет-адрес, отвергается, если вы явно не внесли его в whitelist. Во-вторых, для назначений на каждый инструмент egress-правило несёт список allow/deny host/CIDR, сопоставляемый с исходящим назначением вызова на поверхности egress. Шаблон базового use-case поставляет готовое egress-deny-правило, чей список уже покрывает приватные, loopback, link-local и cloud-metadata-диапазоны (включая 169.254.169.254 и metadata.google.internal), так что его применение даёт вам защиту от SSRF/метаданных без написания CIDR вручную.
SSRF и egress — это разница между «этот инструмент вернул данные» и «этот инструмент эксфильтровал ваши секреты на хост злоумышленника». Примените базовый egress-denylist и добавьте свои правила host/CIDR — см. Лимиты egress и Эксфильтрацию данных.

​
7. Наблюдайте: события, прогоны и аномалии

Каждый управляемый вызов оставляет след. События firewall записывают вердикт, поверхность и сопоставленное правило; прогоны группируют вызовы сессии; а лента аномалий отмечает всплески частоты и стоимости против выученной базовой линии. Чтения настроек, политик и обнаруженных инструментов открыты любому Member; чтения событий/прогонов/агрегатов требуют Developer+.

​
8. Куда двигаться дальше

Подключение MCP-сервера

Зарегистрируйте, зондируйте и выставьте сервер через шлюз.

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

Default-deny для сервера и разрешите только проверенные инструменты.

Защита от rug-pull

Управляйте серверами и навыками, которые меняются после вашего одобрения.

Firewall: MCP-серверы

Полный справочник по полям и маршрутам.
Впервые с этой моделью? Прочитайте Guardrails vs. firewall, чтобы увидеть, куда вписывается управление MCP, затем Отравление MCP-инструментов и Избыточные полномочия — об угрозах, которые оно закрывает.