Каждый шаг настройки здесь делается из консоли (или REST API вашей
сессией/access-токеном) и ограничен по роли. Только маршруты шлюза
firewall и relay-вызовы
/v1/* несут ключ в стиле sk-orca-....1. Чек-лист для проверки подключений mcp-сервера
Работайте сверху вниз. Первые три шага обязательны для любого сервера, которым вы не управляете сами; остальное усиливает защиту.1. Зондируйте, прежде чем доверять
Обнаружьте реальный список инструментов и достижимость до написания
единого правила.
2. Default-deny, затем список разрешённых
Разрешите только инструменты, которые вы проверили; всё остальное
запрещено.
3. Шифруйте учётные данные
Храните аутентификацию так, чтобы она была зашифрована в покое,
замаскирована при чтении, никогда не видна модели.
4. Заблокируйте egress
Ограничьте, куда инструменты сервера могут обращаться в сети.
5. Карантин самоустановленных навыков
Удерживайте всё, что агент устанавливает самостоятельно, пока человек не
проверит.
6. Сначала shadow, затем наблюдайте
Выкатите в audit-only, затем читайте события и аномалии перед
применением.
2. Зондируйте, прежде чем доверять
Вы не можете проверить инструменты, которые никогда не видели, а рекламируемый список инструментов сервера — это то, что вероятнее всего изменится под вами. Зарегистрируйте сервер, затем зондируйте (probe) его — шлюз выполняет MCPinitialize + tools/list против эндпоинта и
возвращает реальные инструменты с их входными схемами, плюс status
достижимости ok, degraded или down.
shell.exec или http_fetch, которого вы не ожидали, — это
находка, а не деталь — в этом весь смысл зондировать сначала.
Полный справочник по регистрации и зондированию живёт в
Firewall: MCP servers; сквозное прохождение —
Подключить MCP-сервер.
3. Default-deny, затем список разрешённых для проверенных инструментов
Список разрешённых — это разница между «сервер может делать шесть вещей» и «сервер может делать всё, что его оператор решит завтра». Установитеdefault_verdict политики в deny, затем добавьте правило на каждый
инструмент, который вы проверили и которому доверяете. Поскольку шлюз
именует каждый инструмент в пространстве имён <server>.<tool>, вы можете
ограничить правила одним сервером, не трогая остальные.
github.create_issue запускается, github.get_issue запускается, а
свежевведённый github.delete_repo запрещён, пока вы его не проверите и не
разрешите. Запрещённый tools/call возвращается модели как ошибка
инструмента (firewall deny: …) — агент адаптируется вместо падения.
См. Список разрешённых MCP-инструментов
для полного рецепта и Правила Firewall для
сопоставляющего DSL.
4. Шифруйте учётные данные — никогда не пишите аутентификацию вручную
Стороннему серверу почти всегда нужны учётные данные, а учётные данные — это то, что вы меньше всего хотите видеть в открытом виде или достигающим модели. Зарегистрируйте аутентификацию сервера через OrcaRouter, чтобы она была зашифрована в покое, замаскирована при чтении и внедрялась только во время диспетча.auth_mode — это один из none, bearer, oauth или basic:
5. Заблокируйте egress: куда могут обращаться его инструменты?
Вердикты на каждый вызов решают, какой инструмент запускается; egress решает, куда он может обращаться. Инструмент, который «возвращает данные», и инструмент, который «эксфильтрует ваши секреты на хост злоумышленника», могут быть одним и тем же инструментом с разным аргументом — контроль egress — это то, что их различает. Шлюз уже валидирует каждый удалённый эндпоинт и его разрешённый IP набора против SSRF-политики на каждом хопе, отвергая интранет-диапазоны и адрес облачных метаданных и перепроверяя IP, чтобы победить DNS rebinding. Поверх этого напишите своё собственное egress deny-правило для хостов и CIDR, которых этот сервер никогда не должен касаться:Нет пресета, который поставляет CIDR-правила за вас — вы пишете список
запретов по хосту/CIDR сами, ограниченный тем, что этому серверу легитимно
нужно. См. Лимиты egress и
Эксфильтрацию данных.
6. Карантин для того, что агент устанавливает самостоятельно
Сервер, который вы зарегистрировали, — это один риск; навыки, BYO MCP-серверы и плагины, которые агент самостоятельно устанавливает потом, — другой. OrcaRouter сканирует каждую устанавливаемую возможность, присваивает ей банд риска и выводит режим применения —allow, quarantine или block
— который накладывается поверх каждого вердикта правила.
Всё автообнаруженное при первом использовании помещается в карантин, пока
человек не проверит: возможность, которую никто не одобрял, не получает
свободного пропуска просто потому, что просканировалась безобидно.
Возможность quarantine эскалирует всё, что короче запрета, до
pending_approval, так что её инструменты запускаются только после того, как
вы посмотрели.
7. Сначала shadow, затем наблюдайте за следом
Не переключайте новый сервер сразу на применение. Поместите политику в shadow-режим — принуждающие вердикты понижаются до audit и логируются как[shadow] would … — так что вы можете увидеть, что было бы
заблокировано, прежде чем это действительно произойдёт. Когда след аудита
выглядит правильно, снимите shadow-режим и применяйте.
После того как это активно, контроли продолжают наблюдать:
События firewall
События firewall
Каждый управляемый вызов записывает свой вердикт, поверхность и совпавшее
правило. Читайте их, чтобы подтвердить, что список разрешённых и
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.
