Перейти к содержимому
Выберите тему

Модель доверия MCP

Кому и что можно доверять в MCP - что гарантирует протокол редакции 2026-07-28, что остаётся на хосте и сервере, принципы согласия пользователя и карта раздела безопасности

Протокол MCP сам почти ничего не защищает. Он задаёт формат обмена и правила авторизации, а согласие пользователя, границы между серверами и проверку данных обеспечивают хост, клиент и сервер. Спецификация говорит об этом прямо: принципы безопасности MCP не может обеспечить на уровне протокола.

Описана редакция 2026-07-28, сверено со спецификацией 4 октября 2026.

В разделе «Безопасность» каждое утверждение относится к одному из четырёх видов. Их нельзя смешивать.

Вид Что это Откуда
требование протокола слова «обязан», «должен», «следует» из спецификации спецификация
официальная рекомендация документ Security Best Practices из официальной документации Security Best Practices
известный класс атак описан исследователями, в спецификации может не упоминаться публикации исследователей
совет по реализации практика эксплуатации, не правило MCP общая практика безопасности

Уязвимость в конкретной программе - это свойство этой программы и её версии, а не протокола. Такие случаи собраны на странице «Уязвимости и инциденты».

Хост: решает и спрашивает согласие

Пользователь

Языковая модель

Клиент 1

Клиент 2

Сервер 1

Сервер 2

Участник Ответственность по спецификации
хост проводит политику безопасности и согласия, решает, каким серверам что разрешено, держит границы между серверами
клиент общается с одним сервером и не смешивает его с другими
сервер обязан соблюдать ограничения безопасности; отвечает за проверку входных данных, доступ и свои секреты

Принцип проектирования из раздела об архитектуре: сервер не должен иметь возможности прочитать весь разговор и «заглянуть» в другие серверы. Полная история остаётся у хоста.

Сформулированы в разделе Security and Trust & Safety обзора спецификации.

Согласие и контроль пользователя. Пользователь явно соглашается на доступ к данным и на действия и понимает, на что соглашается. Он сохраняет контроль над тем, какие данные передаются и какие действия выполняются.

Приватность данных. Хост получает явное согласие пользователя, прежде чем открыть его данные серверу, и не передаёт данные ресурсов куда-либо ещё без согласия.

Безопасность инструментов. Инструмент - это выполнение произвольного кода, и относиться к нему нужно соответственно. Описание поведения инструмента, включая аннотации, считается ненадёжным, если получено не от доверенного сервера. Хост получает явное согласие пользователя перед вызовом любого инструмента.

Сразу за этими принципами спецификация делает оговорку: обеспечить их на уровне протокола MCP не может. Разработчикам следует самим строить согласие и авторизацию, документировать последствия для безопасности, разграничивать доступ и защищать данные.

Что Где описано
авторизацию для HTTP на основе OAuth 2.1: токен выдаётся для конкретного сервера, чужие токены не принимаются Модель авторизации
проверку заголовка Origin и совпадения заголовков с телом запроса Транспорты
запрет запрашивать секреты формой Elicitation
требование считать requestState входом от возможного злоумышленника Многошаговые запросы
обязанности сервера при работе с инструментами и ресурсами Tools, Resources
Данные Почему Источник
имя и версия сервера или клиента стороны сообщают их сами, протокол не проверяет; по ним не следует принимать решения о безопасности базовый протокол
аннотации инструмента считаются ненадёжными, если сервер не доверенный Tools
описание и результат инструмента, текст шаблона, содержимое ресурса приходят от сервера и попадают к модели Tools, Prompts
значки адрес и содержимое значка - ненадёжный вход базовый протокол
сведения о личности пользователя, переданные клиентом их можно подделать; сервер проверяет личность сам Elicitation
идентификатор состояния в аргументах владение идентификатором - не подтверждение личности Security Best Practices
Локальный сервер (stdio) Удалённый сервер (HTTP)
где работает на машине пользователя, запускается клиентом отдельный сервис
учётные данные из окружения процесса токен доступа по правилам авторизации
главный риск программа выполняется с правами пользователя доступ к данным многих пользователей через сеть
что читать Защита сервера Модель авторизации, Защита сервера
Вопрос Страница
как содержимое сервера может управлять моделью Отравление инструментов и внедрение инструкций
что обязан делать сервер Защита сервера
какие уязвимости уже находили и в чём Уязвимости и инциденты