MCP-сервер может открыть ИИ-помощнику доступ к почте, документам, CRM, базе данных, исходному коду или production-системе. Такое подключение следует проверять как привилегированную интеграцию, а не устанавливать как безобидное расширение.
Проверяйте MCP-сервер до выдачи настоящих учетных данных. Установите издателя и конкретный артефакт, перечислите инструменты, проследите движение данных, ограничьте идентичность, изолируйте процесс, испытайте вредоносные входы и убедитесь, что действие можно восстановить по журналу и быстро остановить.
Почему безопасность MCP нельзя свести к OAuth
Model Context Protocol унифицирует подключение ИИ-приложений к инструментам и источникам данных. Однако стандартный интерфейс не означает стандартный уровень доверия. В официальной модели безопасности MCP указано: клиент доверяет подключенному серверу, локальный сервер работает с правами доступного ему процесса, а выбор и конфигурация остаются ответственностью пользователя или администратора.
В 2026 году появились более конкретные ориентиры. Спецификация от 28 июля усилила авторизацию, OWASP выпустил практическое руководство по защите MCP-серверов, а поставщики облачных платформ описали риски prompt injection и небезопасных цепочек инструментов. По данным исследования McKinsey AI Trust 2026, безопасность и риски стали главным препятствием для полного масштабирования агентного ИИ, а зрелость агентных контролей все еще отстает.
Поэтому единица анализа — не название протокола. Проверке подлежит вся цепочка: пакет или облачный сервис, конфигурация, токены, описания tools, модель, хост, целевые API, логи и дежурный процесс реагирования.
Составьте короткую карту границ доверия
Опишите задачу: кто использует соединение, какой результат нужен и почему недостаточно прямого API, read-only выгрузки или узкой автоматизации. Нарисуйте путь от запроса пользователя через модель, MCP-клиент и сервер до бизнес-системы и внешнего получателя. Отметьте переходы инструкций, данных, секретов и необратимых действий между владельцами.
| Граница | Контрольный вопрос | Доказательство |
|---|---|---|
| Поставка | Какой код или сервис мы запускаем? | Издатель, версия, digest, зависимости |
| Возможности | Что он читает, меняет, отправляет, исполняет? | Реестр tools и наблюдаемое поведение |
| Идентичность | Чьи полномочия получает целевая система? | Issuer, audience, scopes, роли, срок |
| Среда | Что доступно процессу? | Файлы, сеть, env, subprocess policy |
| Реагирование | Можно ли объяснить и остановить действие? | Связанные логи и инструкция отзыва |
Назначьте бизнес-владельца и технического владельца. Зафиксируйте тип данных, максимальный правдоподобный ущерб, дату пересмотра и аварийное отключение. Соединение без ответственного владельца не должно переходить в production.
Проверьте издателя, артефакт и обновления
Локальный MCP-сервер — исполняемое ПО. Команда установки может скачать пакет, запустить lifecycle scripts, прочитать переменные среды и унаследовать доступ к диску и сети. Удаленный сервер уменьшает часть риска на компьютере, но добавляет вопросы хранения, изоляции клиентов, подрядчиков и жизненного цикла данных.
- Найдите канонического издателя на официальном сайте или в подтвержденной организации. Похожее имя пакета не доказывает происхождение.
- Изучите исходный код, лицензию, security policy, активность сопровождающих, историю релизов, смену владельцев и нерешенные уязвимости.
- Закрепите точную версию и транзитивные зависимости; сохраните digest, если канал поставки его предоставляет.
- Прочитайте install- и post-install-скрипты. Отметьте shell execution, доступ к файлам и секретам, телеметрию, обновление и внешние адреса.
- Составьте allowlist доменов для установки, запуска, авторизации, tool calls и диагностики. Необъяснимый трафик следует заблокировать.
- Определите порядок обновления. Автопереход на непроверенную версию обнуляет выводы предыдущего аудита.
У поставщика remote MCP запросите список subprocessors, регион и срок хранения данных, условия обучения, tenant isolation, порядок disclosure и уведомления об инциденте, экспорт и удаление. Репутация SaaS не заменяет анализ нового интерфейса и его разрешений.
Снимите фактический каталог tools и ресурсов
Запустите discovery в чистой тестовой среде. Для каждого tool сохраните описание, input schema, downstream API, читаемые данные, возможную запись, получателя, нужную роль, обратимость, лимит и правило подтверждения. Затем проверьте, совпадает ли поведение с описанием.
Текст описания влияет на выбор модели и поэтому входит в поверхность атаки. Ищите скрытые, вводящие в заблуждение, чрезмерно широкие и посторонние инструкции. После обновления сравнивайте список tools, descriptions, schemas, resources, prompts и UI templates с утвержденной версией.
Сервер: crm-mcp-prod
Версия: 2.4.1 + digest
Tool: create_follow_up
Читает: id лида, владельца, статус
Пишет: одну задачу; не меняет контакт
Получатель: только корпоративная CRM
Идентичность: отдельная роль агента
Лимит: 50 задач/час; одна на лид
След: инициатор, аргументы, policy, result id
Отключение: отозвать роль + удалить из allowlistПредпочитайте узкие операции вроде create_follow_up общему SQL, shell, браузеру или файловому доступу. Универсальный tool следует считать привилегированным и сильнее ограничивать средой. Матрица прав ИИ-агента помогает решить, какие действия допустимы; аудит MCP проверяет, способен ли коннектор технически удержать эти рамки.
Разведите идентичности и сократите полномочия
Не размещайте постоянные секреты в prompt, git, аргументах процесса и URL. Используйте хранилище секретов и короткоживущие токены, когда они доступны. Отдельная identity сервера или агента позволяет атрибутировать действия и отозвать доступ, не блокируя аккаунт сотрудника.
При remote MCP проверяйте протокол авторизации, а не только наличие входа через OAuth. Действующая спецификация MCP Authorization опирается на OAuth и metadata защищенного ресурса. Рекомендации безопасности 2026 запрещают token passthrough: сервер не должен принимать токен для другого audience и слепо пересылать его downstream-сервису.
- Для каждого запроса проверяйте issuer, подпись, audience, expiry, client, scopes и контекст пользователя или workload.
- Отделяйте токен вызова MCP от credential, которым сервер обращается к целевому API.
- Разделяйте чтение и запись. Ограничивайте tenant, проект, репозиторий, папку, таблицу, тип записи, поле и операцию.
- Создайте разные identities для development, test и production. Не испытывайте кандидата с административным production-токеном.
- Проверьте отзыв, истечение срока, уход сотрудника, изменение роли, отзыв consent и попытку cross-tenant доступа.
Концепция NIST 2026 года связывает идентификацию, авторизацию, аудит, non-repudiation и защиту от prompt injection. В следе действий должны сохраняться инициатор и отдельный исполняющий агент.
Сведите доступ среды к необходимому минимуму
Сначала запускайте локальный сервер без прав администратора в одноразовой среде. Монтируйте только нужные каталоги, по возможности read-only. Передавайте конкретные переменные, а не всю env. Запретите дочерние процессы, если они не входят в задачу. Ограничьте исходящую сеть, облачный metadata endpoint, локальные управляющие sockets, внутренние сервисы и произвольный интернет.
В модели MCP запуск команды через stdio является ожидаемым поведением. Контроль заключается в правах процесса. Контейнер мало помогает, если в него смонтирован домашний каталог или Docker socket, он работает как root и свободно ходит в сеть.
Для удаленного сервера примените собственный API или egress gateway, где это возможно. Ограничьте частоту, параллельность, объем данных, расходы и число изменений. Сделайте записи идемпотентными. Безопасно обрабатывайте timeout: успешная операция с потерянным ответом не должна повториться.
Испытайте вредоносный контент и ошибки
Руководство Google по безопасности MCP различает работу с подтверждением и автономный режим, но отдельно указывает на ошибочные одобрения из-за чрезмерного доверия. Полезное окно подтверждения показывает точный tool, получателя, аргументы, число объектов, источник и последствия.
До production воспроизведите как минимум восемь случаев:
- Письмо, документ, тикет, сайт или строка БД велит игнорировать policy, раскрыть секрет или вызвать другой tool.
- Сервер меняет описание либо schema после первоначального разрешения.
- Два допустимых tools образуют опасную цепочку: чтение закрытых данных и внешняя отправка.
- Аргумент содержит path traversal, командные символы, внутренний URL, слишком большой payload или id другого tenant.
- Запись прошла, ответ потерялся по timeout, клиент повторяет действие.
- Токен просрочен, отозван, предназначен для другого audience или имеет лишние scopes.
- Downstream API возвращает частичный результат, delayed error, rate limit или неожиданный redirect.
- Сервер пытается получить незаявленный доступ к DNS, сети, файлу, env или subprocess.
Начинайте с observe-only или draft mode, синтетических данных и canary records. Запрещенная операция должна надежно отклоняться; оповещение — доходить до владельца; бизнес — иметь ручной маршрут на время остановки интеграции.
Журнал должен отвечать: кто, почему, что и чем закончилось
Обычный API-log показывает endpoint и статус. Для расследования действия агента также нужны инициирующий пользователь или event, версии агента и сервера, доступный набор tools, выбранный tool, очищенные аргументы, решение policy, подтверждение, downstream identity, результат, фактический side effect и correlation id. Защитите логи от изменения агентом и удаляйте из них секреты и лишние персональные данные.
OpenAI в описании безопасной эксплуатации coding agents сочетает стандартные системные события с prompts, approval decisions, tool results, MCP usage и решениями сетевой политики. Ценность здесь в полноте контекста, а не в конкретном продукте.
Настройте сигналы на первое обращение к чувствительному источнику, новый tool, изменение scopes, аномальный объем, нового получателя, серию запретов, похожий на секрет output и попытку выключить журналирование. Отчет раз в квартал не соответствует скорости агента.
Выберите один из трех исходов
| Исход | Основание | Следующий шаг |
|---|---|---|
| Разрешить | Проверенная поставка, узкие tools, отдельная роль, изоляция, пройденные тесты | Закрепить версию, следить за drift, назначить review |
| Ограничить | Польза понятна, но данных или контролей не хватает | Read-only, тестовые данные, без внешних действий |
| Отклонить | Неизвестный автор, необъяснимый доступ, admin token, слабые логи, нет revocation | Прямой API, экспорт или другой сервер |
Приложите к решению capability manifest, результаты тестов, ограничения, владельцев, срок разрешения, update policy и kill procedure. Изменение сервера, клиента, модели, scopes, downstream API или владельца должно запускать повторную проверку. Неожиданный discovery drift переводит соединение обратно в ограниченный режим.
Такой аудит не является сертификатом безопасности. Его задача — уменьшить полномочия, сделать изменения видимыми, поймать типовые отказы и заранее подготовить сдерживание инцидента.
Частые вопросы
Протокол MCP небезопасен?
Нет. MCP определяет интерфейс, модель доверия и развивающиеся рекомендации. Риск создается сочетанием конкретного сервера, клиента, конфигурации, токенов, модели, бизнес-систем и эксплуатации.
Локальный MCP-сервер безопаснее удаленного?
Не автоматически. Локальный сервер получает доступ процесса к файлам, env и сети. Удаленный добавляет поставщика, хранение, tenant isolation и передачу данных. Сравнивать нужно фактические границы.
Защищает ли OAuth?
OAuth обеспечивает делегирование лишь при правильной проверке issuer, audience, scopes, redirect и токенов. Он не проверяет исходный код, поведение tools, изоляцию, prompt injection и полноту логов.
Нужно ли подтверждать каждый tool call?
Нет. Запрашивайте осмысленное подтверждение для существенных и необычных последствий. Узкие обратимые действия допускайте внутри программных лимитов, а запрещенные блокируйте без предложения нажать Approve.
Как быстро проверить MCP-сервер?
До ввода токена подтвердите издателя, снимите список tools, отметьте чтение и запись, проверьте установку и трафик, запустите на синтетических данных с минимумом прав, подайте вредоносный input, проверьте логи и отзовите доступ одним действием.
Источники и дата проверки
Проверено 16 сентября 2026 года по модели доверия MCP, рекомендациям 2026 года и обзору спецификации от 28 июля; руководству OWASP; документации Google; материалу NIST об идентичности агентов; и примеру agent-native telemetry OpenAI.
Rendframe может инвентаризировать MCP-подключения, проверить сервер, спроектировать ограниченный gateway, собрать негативные тесты и связать agent logs с реагированием. Сначала определите полномочия через матрицу прав ИИ-агента, затем изучите услугу автоматизации с ИИ или пришлите сервер, сценарий и предполагаемые права.