MCP 2026-07-28: настоящая аутентификация агентов

28 июля 2026 года выходит крупное обновление спецификации MCP (Model Context Protocol) под той же датой: 2026-07-28. Кандидат в релиз появился 21 мая, а финальная спецификация — 28 июля. Его главное изменение — перестройка аутентификации и авторизации для ИИ-агентов: от «принеси свой токен» к единой модели безопасности на уровне протокола.

Проблема, выросшая вместе с агентами

В начале авторизация в MCP была практически не определена: каждый сервер решал сам. С одним сервером это работает, но сегодня один агент общается сразу со многими MCP-серверами. В таком мире слабая семантика авторизации — это разница между полезным агентом и инцидентом безопасности: токен, выданный серверу A, можно злоупотребить для доступа к серверу B или воспроизвести между серверами. Это не мелкая деталь реализации — это основа доверия.

Что действительно изменилось

Обновление делает MCP-серверы полноценными серверами-ресурсами OAuth 2.1 с чёткими правилами:

Метаданные защищённого ресурса (RFC 9728): каждый сервер отдаёт эндпоинт .well-known/oauth-protected-resource или добавляет resource_metadata в заголовок WWW-Authenticate, чтобы клиент знал, где запрашивать доступ.
Привязка к аудитории (RFC 8707): клиент явно указывает, какому серверу предназначен токен, поэтому вредоносный сервер не получит токен, выданный другому.
Проверка издателя: клиент проверяет личность сервера авторизации и привязывает к нему учётные данные, закрывая межсерверное воспроизведение.
CIMD вместо динамической регистрации: Client ID Metadata Documents теперь предпочтительнее DCR (RFC 7591), который остаётся для обратной совместимости.

И дело не только в аутентификации: протокол переходит на stateless-дизайн, добавляет полную поддержку JSON Schema 2020-12 для схем инструментов и вводит фреймворк расширений с идентификаторами в обратной DNS-нотации.

Практический пример

Поток начинается с ответа 401, который направляет клиента дальше:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

Клиент читает метаданные защищённого ресурса:

{
"resource": "https://mcp.example.com",
"authorization_servers": ["https://auth.example.com"],
"scopes_supported": ["tools.read", "tools.call"],
"bearer_methods_supported": ["header"]
}

Затем запрашивает токен, привязанный к этому серверу, через индикатор ресурса:

POST /token HTTP/1.1
grant_type=authorization_code&code=...&resource=https://mcp.example.com

Оговорки из реальной практики

Спецификация остаётся кандидатом в релиз до 28 июля; у сопровождающих SDK есть окно около 10 недель на проверку и внедрение.
DCR всё ещё работает, но предпочтителен CIMD; десктопным и CLI-клиентам нужна регистрация, соответствующая реальному развёртыванию (например, localhost-редиректы).
На существующих серверах — работа по миграции: отдача метаданных, проверка аудитории и издателя, определение областей (scopes).

Вывод

Перенос безопасности на уровень протокола превращает аутентификацию из того, что каждый сервер изобретает заново, в общий, готовый к enterprise фундамент. Более безопасные агенты могут больше, а надёжные инструменты умножают возможности разработчика, а не заменяют его, — как и новый HTTP-метод QUERY, который мы недавно разбирали: слой стандартов взрослеет шаг за шагом. Подготовьте серверы сегодня — и встретите 28 июля готовыми.

Первоисточник: официальный репозиторий спецификации MCP.