# Утечки через ответы сервера

Какие данные уходят из результатов, журналов и вопросов пользователю — и как это закрыть на сервере

> Страница сайта MCP Docs (https://mcpdocs.ru/security/utechki/). Сверено 19.10.2026, ревизия 2026-07-28.

Ловушка заставляет модель сделать лишнее; утечка происходит и без ловушки — когда сервер возвращает больше, чем нужно для задачи. Всё, что попало в контекст модели, она может пересказать, передать другому инструменту или сохранить в память. Поэтому правило для сервера простое: возвращать ровно то, что нужно, и не хранить то, что вернул.

## Путь данных

Данные проходят четыре шага, и на каждом есть точка, где можно отдать лишнее. Сервер отвечает за второй шаг — ответ. Клиент и модель — за третий и четвёртый, но повлиять на них автор сервера может только тем, что не отдаст лишнего на втором.
**На заметку**В ревизии 2026-07-28 нет сессий: сервер не хранит состояние между запросами, а то, что ему нужно для продолжения, кладёт в `requestState` и получает обратно от клиента. Это поле проходит через клиента и его журнал — секреты в нём хранить нельзя (см. «Память и состояние»).

## Пять точек утечки

| Точка | Что утекает | Пример |
| **1 · Лишние поля в результате** | Записи целиком вместо нужных полей: внутренние идентификаторы, адреса, телефоны, заметки | Инструмент «найти клиента по имени» возвращает строку таблицы со всеми 40 колонками |
| **2 · Документ целиком** | Ресурс или файл отдаётся полностью, хотя нужен фрагмент; в нём — чужие данные и, возможно, ловушки | Инструмент «прочитать письмо» возвращает всю цепочку переписки с вложениями |
| **3 · Журнал и телеметрия сервера** | Параметры вызовов и результаты в логах, `requestState`, отчёты об ошибках | Сервер пишет в журнал тело каждого `tools/call`, включая номер карты из параметра |
| **4 · Вопросы пользователю** | Через `input_required` сервер собирает данные, которые не нужны задаче; они проходят через клиента и остаются в разговоре | Форма «уточните адрес и телефон» у инструмента, которому нужен только город |
| **5 · Токен не того сервера** | Сервер принимает токен, выпущенный для другого ресурса, — и чужой сервер получает доступ к вашим данным по чужому токену | Сервер проверяет только подпись токена, но не `aud` |

Пятая точка — единственная, по которой спецификация даёт прямое требование: MCP-сервер ДОЛЖЕН проверять, что токен выпущен для него (`aud` или проверка ресурса при интроспекции), и НЕ ДОЛЖЕН передавать полученный токен дальше. В руководстве «Авторизация MCP-сервера» это параметр `validate_token_resource=True`.

## Что делать автору сервера

- **Поля — по списку.** Результат инструмента описывается `outputSchema`, и в него входят только нужные поля. Ненужное не «фильтруется потом», а не выбирается из источника.

- **Фрагмент, а не документ.** Инструменты чтения принимают диапазон, запрос или идентификатор части и возвращают часть. Для «всего документа» — отдельный инструмент с явным названием.

- **Права по токену, а не по параметру.** Для удалённого сервера данные пользователя отделяются по субъекту токена (`sub`), а не по значению, которое прислал клиент: клиент может прислать чужой идентификатор.

- **Журнал без тел.** В журнал — метод, имя инструмента, время, статус. Параметры и результаты — только в режиме отладки, и не на боевом сервере. Отчёты об ошибках — без фрагментов данных.

- **`requestState` непрозрачен, но не секретен.** Кладите в него идентификатор продолжения, а не данные; при необходимости — подписывайте и шифруйте, как показано в «Памяти и состоянии».

- **Формы — по делу.** `input_required` запрашивает только то, без чего инструмент не может работать, с понятным `message`; пароли и ключи через формы не собираются.

- **Токен только свой.** Проверять аудиторию токена; не пересылать токен клиента в сторонние API — у сервера должны быть свои учётные данные к ним.

## Что делать пользователю

- Давать серверу ключ с правами на чтение только нужных данных: сервер не вернёт то, к чему у него нет доступа.

- Смотреть результаты первых вызовов в журнале клиента: если инструмент «найти клиента» возвращает полные карточки — это точка 1, и такой сервер в рабочий профиль не идёт.

- Не держать в одном сеансе сервер с личными данными и сервер, который отправляет что-то наружу (почта, мессенджер, публикация): всё, что прочитал первый, модель может передать второму.

- Для серверов с памятью (заметки, история) — знать, как удалить записи, и не диктовать модели пароли и номера документов.

**На заметку**Готовые серверы с датой проверки и источником — в [каталоге MCP-серверов](https://mcpprotocol.ru/katalog/) справочника. Запись в каталоге означает, что источник и лицензия сверены на указанную дату; работу сервера каталог не гарантирует.