Перейти к основному содержанию
MCP-агент — это агент с досягаемостью. Каждый сервер Model Context Protocol, к которому он подключается, — это свежий набор инструментов, учётных данных и сетевых назначений, которые никто не проверял, — и агент может подтянуть новый прямо посреди прогона. Этот рецепт показывает четыре приёма, которые превращают разросшуюся MCP-конфигурацию в управляемую на хостинговом шлюзе: единый аудируемый MCP-шлюз, карантин навыков, запрет egress и зашифрованная аутентификация серверов. Всё это вы настраиваете из консоли (или REST API) против вашего рабочего пространства. Ваш агент продолжает говорить на MCP ровно как раньше.

​
1. Зачем защищать MCP-агента

Направьте агента на пять MCP-серверов напрямую — и у вас пять границ доверия, пять хранилищ учётных данных и ноль общего журнала аудита. tools/call, который читает запись клиента, и тот, что запускает shell-команду, выглядят для модели идентично, а community-сервер может тихо запросить shell.exec и внешнюю сетевую область при первой же загрузке. Решение — сделать OrcaRouter единственной узловой точкой, которую пересекает каждый вызов. Чтобы защитить трафик MCP-агента от начала до конца, вы маршрутизируете весь MCP-диспетч через MCP-шлюз Firewall, так что каждый tools/call вычисляется политикой до того, как достигнет реального сервера, — с оценкой навыков по риску, управлением egress и зашифрованными в покое учётными данными.
Это рецепт — он сшивает существующие функции в один конкретный проход защиты. Для полного справочника следуйте по ссылкам в Firewall, MCP-серверы и Навыки.

​
2. Начните с базиса Secure Agents

Прежде чем писать что-либо своё, задайте позицию. В консоли откройте Firewall → Posture и примените уровень автономии balanced (уровень автономии, роль Developer). В одной транзакции это аудирует вызовы инструментов и флагирует PII, запрещая при этом самые деструктивные действия — вы наблюдаете, прежде чем широко применять, с отменой в один клик. Когда ленты Events и Runs выглядят правильно, переходите к tight: default-deny, запрет деструктивного shell, запрет SSRF-образного egress, плюс применяются guardrails PII Shield и Secrets Blocker. Этот единственный переключатель — пол, на котором строится этот рецепт.
Предпочитаете наращивать, не переключая всё рабочее пространство? Впишите правила ниже в одну именованную политику и включите её shadow-режим — она вычисляет и логирует, но понижает каждый применяющий вердикт до audit (причина с префиксом [shadow] would …), пока вы не уверены. См. режимы применения.

​
3. Маршрутизируйте каждый tools/call через один MCP-шлюз

Зарегистрируйте каждый MCP-сервер один раз; шлюз агрегирует их инструменты под единым соединением (неймспейс <server>.<tool>) и проводит каждый tools/call через движок firewall. Зарегистрируйте сервер из консоли (или REST API, Developer+): 
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-session-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
  }'
Затем направьте ваш MCP-клиент на шлюз — а не на вышестоящие серверы — используя выделенный ключ с областью firewall-gateway: 
https://api.orcarouter.ai/api/v1/firewall/mcp
Теперь github.create_issue и shell.exec появляются бок о бок под одним соединением, и каждый диспетч вычисляется до запуска. Заблокированный вызов возвращается модели как ошибка инструмента (firewall deny: …), а не падение транспорта, так что агент может адаптироваться.
Обычный ключ ретрансляции получает 403 на маршруте шлюза /api/v1/firewall/mcp. Выпустите выделенный токен шлюза (is_firewall_gateway) для MCP-соединения; чтение plaintext этого ключа шлюза требует Admin+.
Прежде чем писать правила против инструментов сервера, прозондируйте (probe) его, чтобы обнаружить их имена и схемы: 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-token>"

​
4. Карантинируйте навыки, которые подтягивает агент

MCP-шлюз управляет вызовами; управление навыками управляет возможностями, которые загружает агент. Каждый устанавливаемый навык, свой MCP-сервер или плагин сканируется в полосу риска и режим применения, который накладывается поверх каждого вердикта правила:
РежимЭффект во время выполнения
allowРешают вердикты правил; навык не добавляет ничего.
quarantineВсё, что меньше deny, удерживается на pending_approval.
blockИнструменты навыка принудительно запрещаются.
Суть для MCP-агента: возможность, которую никто не одобрил, не получает свободного пропуска. Когда агент самоустанавливает что-то и его инструменты впервые пересекают шлюз, Firewall автообнаруживает это и карантинирует, пока человек не проверит — даже если сканирование чистое. Предодобрите серверы, которым доверяете; пусть остальные приземляются в очередь проверки.
Держите balanced/observe включёнными, пока изучаете, что ваш агент реально устанавливает, затем продвиньте доверенные навыки до allow и оставьте длинный хвост карантинированным. См. Навыки.

​
5. Запретите SSRF-образный egress

Скомпрометированный или сбитый с толку MCP-инструмент, дотягивающийся до облачных метаданных или интранет-хоста, — это классический путь эксфильтрации. Его покрывают два слоя. Во-первых, шлюз валидирует каждый удалённый MCP-endpoint и его разрешённый dial-IP против SSRF-политики при регистрации и на каждом хопе диспетча — интранет-диапазоны и адрес облачных метаданных отклоняются, перепроверяются, чтобы победить DNS rebinding. Это встроено; вы это не настраиваете. Во-вторых, уровень автономии tight поставляет egress-пресет SSRF, который запрещает fetch-образные имена инструментов — http_fetch, web_search, fetch_url, request и их неймспейсные формы <server>.* — так что инструмент, чья вся работа — «иди извлеки этот URL», останавливается до дозвона. Чтобы управлять тем, куда инструменты могут дотягиваться по назначению, создайте собственное правило egress с deny-списком host/CIDR — это поверхность для закрепления исходящей досягаемости: 
// firewall rule, egress stage — deny outbound to an internal range.
// egress_json is a JSON *string*: {"deny":[…],"allow":[…]} of hosts/CIDRs.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\",\"169.254.169.254\"]}"
}
Ни один пресет не поставляет CIDR egress-правил — пресет SSRF сопоставляет имена инструментов, а не назначения. Напишите deny-список host/CIDR сами, когда нужен контроль на уровне назначения. См. egress-списки и остановите эксфильтрацию.

​
6. Держите учётные данные серверов зашифрованными

auth_json каждого MCP-сервера шифруется в покое и маскируется при чтении; шлюз внедряет учётные данные во время диспетча, так что они никогда не достигают модели или клиента. Поддерживаемые значения auth_mode:
{ "token": "…" } — статический bearer-токен, отправляемый как Authorization: Bearer.
{ "client_id": "…", "client_secret": "…", "token_url": "…" } — OAuth client-credentials; шлюз получает и обновляет токен.
{ "username": "…", "password": "…" } — HTTP Basic auth.
"" — неаутентифицированный сервер. По умолчанию.
При чтении секрет маскируется; верните маску обратно при обновлении, чтобы сохранить хранимое значение. status сервера (ok / degraded / down) из последней пробы говорит вам, достижим ли он, прежде чем вы на него положитесь.

​
7. Добавьте контентный guardrail на запросе

Firewall управляет действиями; сочетайте его с Guardrail, чтобы текст, проходящий через вашего MCP-агента, тоже проверялся. Пресет Secrets Blocker ловит учётные данные в запросе до того, как их увидит модель — или любой инструмент, а PII Shield маскирует идентификаторы на входе. Оба включаются с уровнем автономии tight, или привяжите именованный guardrail к ключу ретрансляции агента через guardrail_id.
Вердикт sanitize firewall редактирует аргументы вызовов инструментов, никогда контент, который инструмент возвращает. Удалите секреты из запроса guardrail’ом Secrets Blocker; очищайте аргументы, которые выдаёт агент, правилом firewall. Они покрывают разные половины потока.

​
8. Проверьте и наблюдайте

Убедитесь, что политика делает то, что вы ожидаете, прежде чем доверять ей, затем следите за лентами:

Протестировать вызов инструмента

Прогоните образец tools/call против вашей политики вхолостую и посмотрите вердикт, совпавшее правило и причину — ничего не диспетчеризуется, ничего не логируется.

Discovered tools

Каждый инструмент, который видело рабочее пространство, помеченный covered или gap — пишите правила прямо из реального MCP-трафика.

Events & Runs

Каждый диспетч, его вердикт и поверхность, на которую он попал, свёрнутые по прогону агента.

Лента аномалий

Всплески частоты/стоимости, циклы повторов и новые пути инструментов против обученного базиса.

​
9. Куда дальше

Отравление MCP-инструментов

Модель угроз за карантином и MCP-шлюзом.

Избыточная агентность

Почему default-deny и HITL важны для автономного использования инструментов.

Рецепт автономного агента

Защитите высокоавтономного агента от начала до конца.

Остановите эксфильтрацию

Ограничьте исходящий egress в глубину.