# Безопасность MCP: модель доверия и границы ответственности

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

Страница: https://mcpdoc.ru/security/best-practices/
Указатель сайта: https://mcpdoc.ru/llms.txt

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

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

## Четыре вида утверждений

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

| Вид | Что это | Откуда |
|---|---|---|
| требование протокола | слова «обязан», «должен», «следует» из спецификации | [спецификация](https://modelcontextprotocol.io/specification/2026-07-28) |
| официальная рекомендация | документ Security Best Practices из официальной документации | [Security Best Practices](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices) |
| известный класс атак | описан исследователями, в спецификации может не упоминаться | публикации исследователей |
| совет по реализации | практика эксплуатации, не правило MCP | общая практика безопасности |

Уязвимость в конкретной программе - это свойство этой программы и её версии, а не протокола. Такие случаи собраны на странице [«Уязвимости и инциденты»](https://mcpdoc.ru/security/incidents/).

## Кто за что отвечает

```mermaid
flowchart LR
    U[Пользователь] --> H

    subgraph H["Хост: решает и спрашивает согласие"]
        direction TB
        M[Языковая модель]
        C1[Клиент 1]
        C2[Клиент 2]
    end

    C1 <--> S1[Сервер 1]
    C2 <--> S2[Сервер 2]
```

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

Принцип проектирования из [раздела об архитектуре](https://modelcontextprotocol.io/specification/2026-07-28/architecture): сервер не должен иметь возможности прочитать весь разговор и «заглянуть» в другие серверы. Полная история остаётся у хоста.

## Три принципа спецификации

Сформулированы в разделе Security and Trust & Safety [обзора спецификации](https://modelcontextprotocol.io/specification/2026-07-28).

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

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

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

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

## Что протокол действительно определяет

| Что | Где описано |
|---|---|
| авторизацию для HTTP на основе OAuth 2.1: токен выдаётся для конкретного сервера, чужие токены не принимаются | [Модель авторизации](https://mcpdoc.ru/auth/) |
| проверку заголовка `Origin` и совпадения заголовков с телом запроса | [Транспорты](https://mcpdoc.ru/protocol/transports/) |
| запрет запрашивать секреты формой | [Elicitation](https://mcpdoc.ru/protocol/elicitation/) |
| требование считать `requestState` входом от возможного злоумышленника | [Многошаговые запросы](https://mcpdoc.ru/protocol/mrtr/) |
| обязанности сервера при работе с инструментами и ресурсами | [Tools](https://mcpdoc.ru/protocol/tools/), [Resources](https://mcpdoc.ru/protocol/resources/) |

## Чему нельзя доверять без проверки

| Данные | Почему | Источник |
|---|---|---|
| имя и версия сервера или клиента | стороны сообщают их сами, протокол не проверяет; по ним не следует принимать решения о безопасности | базовый протокол |
| аннотации инструмента | считаются ненадёжными, если сервер не доверенный | Tools |
| описание и результат инструмента, текст шаблона, содержимое ресурса | приходят от сервера и попадают к модели | Tools, Prompts |
| значки | адрес и содержимое значка - ненадёжный вход | базовый протокол |
| сведения о личности пользователя, переданные клиентом | их можно подделать; сервер проверяет личность сам | Elicitation |
| идентификатор состояния в аргументах | владение идентификатором - не подтверждение личности | Security Best Practices |

## Локальный и удалённый сервер

| | Локальный сервер (stdio) | Удалённый сервер (HTTP) |
|---|---|---|
| где работает | на машине пользователя, запускается клиентом | отдельный сервис |
| учётные данные | из окружения процесса | токен доступа по правилам авторизации |
| главный риск | программа выполняется с правами пользователя | доступ к данным многих пользователей через сеть |
| что читать | [Защита сервера](https://mcpdoc.ru/security/server/) | [Модель авторизации](https://mcpdoc.ru/auth/), [Защита сервера](https://mcpdoc.ru/security/server/) |

## Карта раздела

| Вопрос | Страница |
|---|---|
| как содержимое сервера может управлять моделью | [Отравление инструментов и внедрение инструкций](https://mcpdoc.ru/security/threats/) |
| что обязан делать сервер | [Защита сервера](https://mcpdoc.ru/security/server/) |
| какие уязвимости уже находили и в чём | [Уязвимости и инциденты](https://mcpdoc.ru/security/incidents/) |