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

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

Всё, что сервер вернул, модель может передать дальше. Точки утечки — там, где возвращается лишнее.

Путь данных#

Данные проходят четыре шага, и на каждом есть точка, где можно отдать лишнее. Сервер отвечает за второй шаг — ответ. Клиент и модель — за третий и четвёртый, но повлиять на них автор сервера может только тем, что не отдаст лишнего на втором.

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

Точка	Что утекает	Пример
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, и такой сервер в рабочий профиль не идёт.
Не держать в одном сеансе сервер с личными данными и сервер, который отправляет что-то наружу (почта, мессенджер, публикация): всё, что прочитал первый, модель может передать второму.
Для серверов с памятью (заметки, история) — знать, как удалить записи, и не диктовать модели пароли и номера документов.