MCP опубликовал стабильную спецификацию «Enterprise-Managed Authorization»; остальные черновики идентификации для взаимодействия машин (machine-to-machine) — включая черновик OAuth client-credentials и два открытых предложения — остаются незавершенными. Для всех, кто пытается запускать автономных агентов с использованием Model Context Protocol, это означает, что текущий протокол может подтвердить личность человека, но не предлагает готового способа доказать, что автономный процесс является тем, за кого себя выдает.

Почему важна дорожная карта

В дорожной карте Model Context Protocol (MCP) идентификация и безопасность агентов указаны в числе приоритетных задач. Планировалось выпустить четыре элемента: браузерный сценарий (flow), ориентированный на человека; сценарий OAuth client-credentials для сервисов; привязку токенов на основе DPoP; и механизм федерации идентификации рабочих нагрузок (workload-identity federation). Только первый — Enterprise-Managed Authorization — достиг стабильного статуса.

Что на самом деле делает стабильная спецификация

Enterprise-Managed Authorization позволяет ИТ-администраторам предоставлять доступ к серверу из единой консоли, вместо того чтобы заставлять каждого сотрудника подтверждать каждое соединение. Сценарий использует перенаправление в браузере и вход пользователя, поэтому человек за ноутбуком может пройти аутентификацию, после чего сервер начинает доверять сессии этого пользователя.

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

Черновики и их недостатки

Два черновика расширений призваны наделить агентов собственной идентификацией:

  • SEP-1932 (DPoP) — привязывает токены к паре открытого и закрытого ключей, делая украденные токены бесполезными.
  • SEP-1933 (Workload Identity Federation) — позволяет агентам наследовать идентификаторы, уже предоставленные в облачных платформах.

Оба варианта существуют в виде открытых pull requests; ни один из них еще не был объединен с официальной спецификацией. Тем временем единственным другим документированным вариантом является сценарий OAuth client-credentials, требующий предварительно зарегистрированных секретов. Хранение этих секретов в месте, доступном для чтения агенту, создает классическую поверхность атаки: если секрет будет украден, любой злоумышленник сможет выдать себя за агента.

Практические шаги для использования в продакшене сегодня

Поскольку протокол пока не предоставляет нативной идентификации агентов, команды могут обезопасить их, вынеся управление идентификацией за пределы MCP:

  1. Выдавайте проверяемые идентификаторы на уровне рабочих нагрузок. Такие системы, как SPIRE, генерируют краткосрочные сертификаты, привязанные к корню доверия хоста, что исключает использование статических секретов.
  2. Завершайте проверку учетных данных на шлюзе. Фронтенд-сервис хранит API-ключ или токен и пересылает запросы от имени агента, не допуская попадания секрета в среду выполнения.
  3. Выполняйте авторизацию на основе проверенной личности, а не содержимого токена. Разделяйте аутентификацию (кто вызывает) и авторизацию (что разрешено делать), чтобы политики могли применяться даже при изменении метода аутентификации.

За чем следить дальше

Два открытых pull request — привязка DPoP и федерация идентификации рабочих нагрузок — являются единственными путями к настоящему стандарту идентификации machine-to-machine внутри MCP. Если сообщество объединит их, агенты смогут доказывать владение закрытым ключом или наследовать облачные идентификаторы, не раскрывая секретов. До тех пор любое промышленное развертывание должно полагаться на внешние фреймворки идентификации или принимать риск использования статических учетных данных.

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