Границы авторизации email MCP: чек-лист безопасности

Подключение email MCP может открыть несколько операций — чтение, создание черновиков, отправку и удаление писем. Но работающая интеграция сама по себе не доказывает, что каждая операция разрешена. Проверять нужно границу между клиентом, MCP-сервером и почтовым провайдером.[3]

Этот чек-лист посвящён именно протокольной границе доступа. Это не очередное сравнение почтовых провайдеров: о выборе ящика читайте в статье email API и inbox API, а об общей модели коннекторов — в руководстве по безопасному доступу ИИ-агентов к инструментам.

1. Определите владельца каждого секрета

До подключения реального ящика зафиксируйте MCP-клиент, сервер и транспорт, издателя токена, почтовый аккаунт, запрошенные права и ответственного за отзыв доступа. Отдельно укажите учётные данные, с которыми клиент обращается к MCP-серверу, и те, с которыми сервер обращается к почтовому провайдеру.[2]

Не считайте статус «подключено» универсальным разрешением. Важно знать, какую идентичность представляет каждый секрет и какая система проверяет соответствующие права.[2]

2. Проверьте фактический способ аутентификации

Авторизация MCP необязательна.[1] Для HTTP-реализаций, которые её поддерживают, спецификация описывает поток авторизации MCP.[1] Реализациям на STDIO не следует переиспользовать этот HTTP-поток: учётные данные нужно получать из переменных окружения.[1]

Проверяйте транспорт и настройки запущенной интеграции, а не только инструкцию по установке или успешный список инструментов.[1] Для локального процесса проверьте исполняемый файл, версию пакета, пользователя процесса, переменные окружения и процедуру обновления.[2] Для удалённого HTTP — домен сервера и фактически выбранные издателя токена и аккаунт.[1]

3. Проверьте, для какого сервера выпущен HTTP-токен

В HTTP-потоке авторизации MCP клиент должен указать целевой MCP-сервер как ресурс, а сервер — проверить, что предъявленный токен выпущен именно для него.[1] Токены доступа нельзя помещать в query string URL.[1]

Проверьте границу токеном, выданным для другого ресурса: MCP-сервер должен его отклонить.[1] Также убедитесь, что токены не попадают в URL, журналы приложения и диагностический вывод.[2]

4. Не пересылайте токен клиента в почтовый API

Если MCP-сервер проксирует запросы к почтовому провайдеру, не передавайте дальше без изменений bearer-токен клиента. Руководство MCP по безопасности называет передачу токена антишаблоном, а спецификация требует, чтобы сервер не принимал и не пересылал токены, выпущенные не для него.[1][2]

Отдельно проследите путь учётных данных провайдера.[2] Проверьте, какой аккаунт они представляют, какие права включают и отклоняет ли сам провайдер неразрешённую операцию.[2] Отдельно протестируйте отсутствие или недействительность права у провайдера — не предполагайте, что вход клиента в MCP автоматически авторизует downstream-вызов.[2]

5. Считайте обнаружение инструментов инвентарём, а не авторизацией

Интерфейс инструментов MCP возвращает их имена, описания и схемы ввода; сервер также может сообщить об изменении списка.[3] Сохраните снимок tools/list при ревью развёртывания и сравнивайте его перед включением изменившегося или нового инструмента.[3]

Наличие инструмента в списке означает, что его можно обнаружить, но не что он автоматически разрешён.[3]

Проверяйте политику на стороне сервера или провайдера: скрыть инструмент в одном клиенте или попросить модель не вызывать его недостаточно.[3][4]

OWASP относит избыточную функциональность, права и автономность к факторам чрезмерной агентности.[4]

6. Проведите негативные тесты до подключения почты

На тестовом аккаунте проверьте, что:

1. MCP-сервер отклоняет токен, предназначенный для другого ресурса.[1]

2. Запрещённое почтовое действие отклоняется, даже если клиент вызывает инструмент напрямую.[3][4]

3. Недействительный или слишком широкий токен клиента не передаётся провайдеру как подтверждение права.[2]

4. Проверьте документированное поведение отзыва и момент, когда доступ действительно прекращается.

5. Bearer-токен не появляется в URL, журнале или экспортируемой диагностике.[1][2]

Запишите версию сервера, транспорт, идентичность аккаунта, снимок списка инструментов, решение политики, результаты тестов и ответ провайдера.[1][2][3] Маскируйте секреты и не сохраняйте тексты писем без определённой деловой необходимости.

До запуска ответственный должен уметь ответить: *какую идентичность представляет каждый секрет, какой сервер его проверяет, какие операции разрешены, как отозвать доступ и какие негативные тесты прошли?* Если ответа нет, оставьте интеграцию в тестовой среде. Общий цикл работы почтового агента описан в руководстве по созданию email-агентов.

Sources

[1] https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization — MCP Authorization Specification

[2] https://modelcontextprotocol.io/docs/2025-11-25/tutorials/security/security_best_practices — MCP Security Best Practices

[3] https://modelcontextprotocol.io/specification/2025-11-25/server/tools — MCP Tools Specification

[4] https://genai.owasp.org/llmrisk/llm062025-excessive-agency — OWASP LLM06:2025 Excessive Agency

Узнать про Neuro OS →