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

1. Чек-лист для проверки подключений mcp-сервера

Работайте сверху вниз. Первые три шага обязательны для любого сервера, которым вы не управляете сами; остальное усиливает защиту.

1. Зондируйте, прежде чем доверять

Обнаружьте реальный список инструментов и достижимость до написания единого правила.

2. Default-deny, затем список разрешённых

Разрешите только инструменты, которые вы проверили; всё остальное запрещено.

3. Шифруйте учётные данные

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

4. Заблокируйте egress

Ограничьте, куда инструменты сервера могут обращаться в сети.

5. Карантин самоустановленных навыков

Удерживайте всё, что агент устанавливает самостоятельно, пока человек не проверит.

6. Сначала shadow, затем наблюдайте

Выкатите в audit-only, затем читайте события и аномалии перед применением.

2. Зондируйте, прежде чем доверять

Вы не можете проверить инструменты, которые никогда не видели, а рекламируемый список инструментов сервера — это то, что вероятнее всего изменится под вами. Зарегистрируйте сервер, затем зондируйте (probe) его — шлюз выполняет MCP initialize + tools/list против эндпоинта и возвращает реальные инструменты с их входными схемами, плюс status достижимости ok, degraded или down.
# Консольный маршрут, вызываемый вашей сессией/access-токеном (UserAuth). Developer+.
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
Прочитайте каждое имя инструмента и что принимают его аргументы. Сервер, рекламирующий shell.exec или http_fetch, которого вы не ожидали, — это находка, а не деталь — в этом весь смысл зондировать сначала.
Перезондируйте всякий раз, когда сервер меняет владельца или вы подозреваете дрейф. Новый инструмент, появляющийся в списке — «rug pull» — это именно то, за чем вы наблюдаете. См. Защиту от rug pull.
Полный справочник по регистрации и зондированию живёт в Firewall: MCP servers; сквозное прохождение — Подключить MCP-сервер.

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

Список разрешённых — это разница между «сервер может делать шесть вещей» и «сервер может делать всё, что его оператор решит завтра». Установите default_verdict политики в deny, затем добавьте правило на каждый инструмент, который вы проверили и которому доверяете. Поскольку шлюз именует каждый инструмент в пространстве имён <server>.<tool>, вы можете ограничить правила одним сервером, не трогая остальные.
// Политика на поверхности mcp: deny по умолчанию, разрешить только проверенное.
// tool_name_glob поддерживает полносегментный подстановочный знак: "github.*" (префикс),
// "*.exec" (суффикс) или "*.shell.*" (инфикс). Среднесегментные глобы вроде
// "github.get_*" откатываются к точному совпадению и не раскрываются.
{
  "default_verdict": "deny",
  "rules": [
    { "tool_name_glob": "github.create_issue", "verdict": "allow" },
    { "tool_name_glob": "github.get_issue",    "verdict": "allow" }
  ]
}
Теперь github.create_issue запускается, github.get_issue запускается, а свежевведённый github.delete_repo запрещён, пока вы его не проверите и не разрешите. Запрещённый tools/call возвращается модели как ошибка инструмента (firewall deny: …) — агент адаптируется вместо падения. См. Список разрешённых MCP-инструментов для полного рецепта и Правила Firewall для сопоставляющего DSL.

4. Шифруйте учётные данные — никогда не пишите аутентификацию вручную

Стороннему серверу почти всегда нужны учётные данные, а учётные данные — это то, что вы меньше всего хотите видеть в открытом виде или достигающим модели. Зарегистрируйте аутентификацию сервера через OrcaRouter, чтобы она была зашифрована в покое, замаскирована при чтении и внедрялась только во время диспетча. auth_mode — это один из none, bearer, oauth или basic:
# Консольный маршрут, UserAuth, Developer+.
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\"}"
  }'
Учётные данные шифруются и маскируются в момент сохранения — они никогда не достигают модели или клиента, а при чтении вы всегда видите только маску. При обновлении верните маску обратно, чтобы сохранить хранимое значение; отправляйте свежий auth_json только когда ротируете. См. Аутентификацию и Ротацию учётных данных.

5. Заблокируйте egress: куда могут обращаться его инструменты?

Вердикты на каждый вызов решают, какой инструмент запускается; egress решает, куда он может обращаться. Инструмент, который «возвращает данные», и инструмент, который «эксфильтрует ваши секреты на хост злоумышленника», могут быть одним и тем же инструментом с разным аргументом — контроль egress — это то, что их различает. Шлюз уже валидирует каждый удалённый эндпоинт и его разрешённый IP набора против SSRF-политики на каждом хопе, отвергая интранет-диапазоны и адрес облачных метаданных и перепроверяя IP, чтобы победить DNS rebinding. Поверх этого напишите своё собственное egress deny-правило для хостов и CIDR, которых этот сервер никогда не должен касаться:
// Правило стадии egress ограничивает свой вердикт исходящим назначением.
// egress_json несёт списки allow + deny по хосту/CIDR.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\"]}"
}
Нет пресета, который поставляет CIDR-правила за вас — вы пишете список запретов по хосту/CIDR сами, ограниченный тем, что этому серверу легитимно нужно. См. Лимиты egress и Эксфильтрацию данных.

6. Карантин для того, что агент устанавливает самостоятельно

Сервер, который вы зарегистрировали, — это один риск; навыки, BYO MCP-серверы и плагины, которые агент самостоятельно устанавливает потом, — другой. OrcaRouter сканирует каждую устанавливаемую возможность, присваивает ей банд риска и выводит режим применения — allow, quarantine или block — который накладывается поверх каждого вердикта правила. Всё автообнаруженное при первом использовании помещается в карантин, пока человек не проверит: возможность, которую никто не одобрял, не получает свободного пропуска просто потому, что просканировалась безобидно. Возможность quarantine эскалирует всё, что короче запрета, до pending_approval, так что её инструменты запускаются только после того, как вы посмотрели.
Не пытайтесь регистрировать каждый навык вручную. Предодобрите те, которым доверяете, и дайте остальным быть автообнаруженными и помещёнными в карантин — затем проверяйте на основе реальных данных. Режим ужесточается при пересканировании, никогда не ослабевает. См. Firewall: skills и Отравление MCP-инструментов.

7. Сначала shadow, затем наблюдайте за следом

Не переключайте новый сервер сразу на применение. Поместите политику в shadow-режим — принуждающие вердикты понижаются до audit и логируются как [shadow] would … — так что вы можете увидеть, что было бы заблокировано, прежде чем это действительно произойдёт. Когда след аудита выглядит правильно, снимите shadow-режим и применяйте. После того как это активно, контроли продолжают наблюдать:
Каждый управляемый вызов записывает свой вердикт, поверхность и совпавшее правило. Читайте их, чтобы подтвердить, что список разрешённых и egress-правила ведут себя как задумано. См. Аудит событий MCP.
Всплески частоты и стоимости против выученной базовой линии, плюс циклы повторов и новые пути инструментов, показываются как аномалии — читаемые любым Member.
Включите режим observe, чтобы логировать вызовы, которые политика ещё не покрывает, как пробелы, так что вы ужесточаете на основе того, что агент действительно делает, а не из догадок.

8. Быстрый путь: выберите уровень автономии

Если вы предпочитаете не строить вручную шаги 3–5 для сервера, которому не полностью доверяете, примените уровень автономии и редактируйте оттуда. Уровни пишут реальные, редактируемые строки политики и guardrail — это отправная точка, а не чёрный ящик:
УровеньЧто он устанавливает
permissiveРежим observe включён — логирует всё, не применяет ничего.
balancedПолитика default-audit, которая запрещает деструктивный shell, плюс guardrail PII Shield в режиме flag-only.
tightПолитика default-deny, запрещающая деструктивный shell и инструменты в форме fetch (http_fetch/web_search/fetch_url/request — вектор SSRF), плюс guardrails PII Shield и Secrets Blocker применяются. Секреты в аргументах перехватываются guardrail Secrets Blocker на запросе, а не правилом аргумента инструмента.
Для стороннего сервера, который вы ещё проверяете, начните с tight, зондируйте, затем расслабьте конкретные инструменты в список разрешённых. Отмена в один клик восстанавливает снимок до применения.
Чтение настроек, политик, обнаруженных инструментов, аномалий, зарегистрированных MCP-серверов и навыков открыто любому Member; чтение событий, прогонов и агрегатов требует Developer+, и каждая запись требует Developer+. Раскрытие открытого ключа токена также Developer+.

9. Куда идти дальше

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

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

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

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

Защита от rug pull

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

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

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