Что означают безсостоянийная основа MCP и управляемая авторизация для команд по интеграции
Управление Linux Foundation, транспорт HTTP без состояния и авторизация, управляемая поставщиками идентичности, делают MCP пригодным для интеграции в корпоративных средах. Вот что изменилось.
Стандарт Model Context Protocol стандартизирует способ, которым ИИ-агенты взаимодействуют с окружающими их системами, примерно так же, как ранее API стандартизировали взаимодействие между приложениями. Для специалистов по интеграции и IT-операциям это явление уже два года наблюдалось издалека: оно казалось многообещающим, быстро развивалось, но больше походило на инструменты для разработчиков, чем на что-то, что мог бы одобрить совет по архитектуре. Однако это расстояние сократилось. За восемь месяцев MCP преодолел три этапа развития, которые в совокупности напоминают ранние годы управления API примерно в 2010 году, что повторяется сейчас для ИИ-агентов.
Три изменения за восемь месяцев
Нейтральное управление. В декабре 2025 года Anthropic передала MCP в Ассоциацию Agentic AI Foundation. Это специализированный фонд в рамках Linux Foundation, созданный Anthropic, Block и OpenAI при поддержке Google, Microsoft, AWS, Cloudflare и Bloomberg. Благодаря этому MCP больше не следовала планам одного поставщика и оказалась под нейтральным управлением, какое было характерно для Kubernetes и Node.js.
Централизованное авторизование. 18 июня 2026 года расширение Enterprise-Managed Authorization (EMA) достигло стабильной версии. Оно заменяет экраны согласия для каждого сервера на систему, управляемую поставщиком идентификации, причем Anthropic, Microsoft и Okta были среди первых пользователей этой технологии.
Безсостоянийный ядро. Выпуск от 28 июля 2026 года стал самым значительным изменением спецификации с момента появления протокола; в нем была заменена концепция с состоянием, связанная с сессиями, на безсостоянийную модель, основанную на обычном HTTP.
Это не косметические изменения. Каждое из них устраняет одну конкретную причину, по которой MCP не находил применения в серьезных производственных системах, и они особенно важны для тех, кто зарабатывает на жизнь подключением систем, а не созданием демонстраций ИИ.
Краткое определение
MCP — это открытый стандарт, определяющий способ, с помощью которого приложение ИИ, например агент на основе LLM, находит и вызывает внешние инструменты, читает данные из внешних источников и обменивается контекстом с системами, находящимися вне самой модели. Один унифицированный интерфейс заменяет необходимость создания индивидуальных решений для каждого источника данных.
Примерное сравнение: MCP выполняет функцию связи ИИ с системами там, где раньше REST и OpenAPI использовались для взаимодействия между приложениями. Интегрированные системы остаются прежними. Стандартизуется лишь контракт между клиентом ИИ и тем, что обслуживает сервер MCP — это может быть инструмент для работы с тикетами, CMDB, платформа мониторинга или внутренняя база данных.
Изменение 1: отказ от сессий
В течение первых двух лет MCP через HTTP функционировал как многие протоколы реального времени. Клиент подключался, выполнял процедуру инициализации и получал идентификатор сессии, который должен был указываться во всех последующих запросах. Сессия связывала клиента с конкретной инстанцией сервера, которая её создала. Те, кто использовал WebSocket-сервисы за балансировщиком нагрузки, знают связанные с этим проблемы. Для масштабирования требовалось использование стратегии «sticky routing», общего хранилища сессий или шлюза, который анализировал трафик для поиска инстанции, обрабатывающей соединение.
Спецификация от 28.07.2026 устраняет всё это. Не существует процедур инициализации и подтверждения состояния после инициализации, а также заголовка Mcp-Session-Id. Вместо этого каждый запрос содержит собственную версию протокола, идентификатор клиента и информацию о его возможностях. В результате любая инстанция сервера может обработать любой запрос, поэтому концепции «липких сессий» и общих хранилищ сессий больше не являются требованиями протокола. Безсерверные кластеры с несколькими инстанциями и роутинг на периферии работают так же, как и обычные HTTP-API, поскольку структурно MCP именно таким и стал.
Без сессий протокола приложения не становятся безсостоянийными. Когда серверу действительно необходимо что-то запомнить между вызовами, например процесс экспорта или длительная задача по устранению недостатков, он следует старой практике REST: создаёт явный идентификатор, который клиент передаёт обратно в качестве обычного аргумента при следующем вызове. Инженеры, знакомые с механизмами пагинации и точками входа для отслеживания статуса задач, сразу узнают этот подход — это осознанный выбор, подходящий для балансировщиков нагрузки, а не временное решение.
В этом обновлении была усилена безопасность новой структуры. Клиенты должны проверять подлинность источника в ответах на запросы авторизации, что предотвращает украдение сессий посредством перенаправлений в многосерверных сетях. Кроме того, они обязаны указывать, для какого сервера предназначен токен, тем самым устраняя пробел в механизмах делегирования, который команды по безопасности считали серьезной угрозой в системах с несколькими арендаторами. Теперь у MCP впервые существует официальная политика по постепенному отказу от функций, благодаря чему изменения проходят по определенному циклу жизни, а не осуществляются спонтанно.
Изменение 2: доступ, управляемый поставщиком идентификации
Второе изменение касается не столько транспортировки, сколько ежедневных сложностей с развертыванием агентов во всей компании. При подходе первого поколения к авторизации каждый сотрудник должен был самостоятельно выполнять шаг согласия OAuth для каждого сервера MCP, который использовал его клиент ИИ. При численности сотрудников в сто человек и наличии шести-семи внутренних инструментов процесс адаптации новых сотрудников перестает быть масштабируемым. Команды по безопасности также теряют централизованный обзор того, кто подключен к чему, и отсутствует простой способ ограничить доступ при увольнении или смене сотрудника.
EMA передает решение о авторизации поставщику идентификации компании. Администратор один раз в поставщике идентификации определяет, какие серверы MCP могут использовать сотрудники определенной группы. Позже доступ автоматически активируется при первом входе пользователя через поддерживаемый клиент, без запросов на согласие и дополнительной настройки.
Okta стала первым из поставщиков сервисов идентификации, поддержавших это решение, используя в качестве основы свой продукт Cross App Access. Расширение построено на стандарте Identity Assertion JWT Authorization Grant, который является открытой спецификацией IETF и не принадлежит исключительно компании Anthropic. Anthropic интегрировала его в Claude, Claude Code и Cowork с помощью общего слоя MCP, тогда как Microsoft встроила поддержку непосредственно в Visual Studio Code. Серверы, уже поддерживающие это решение, включают Asana, Atlassian, Canva, Figma, Granola, Linear и Supabase, причем список продолжает расти.
Провайдер идентификации выполняет свою задачу после выдачи разрешения. Он не участвует непосредственно в вызове инструмента, и это имеет значение при анализе безопасности: провайдер не проксирует каждый поток данных от ИИ к системе, а лишь определяет, кто получит учетные данные. Поскольку доступ централизован, так же происходит и аннулирование прав. Отключение учетной записи уходящего сотрудника мгновенно отключает все его серверы, подключенные к EMA, так что не требуется вручную отзывать и аннуливать права в семи отдельных интеграциях.
Механизм единого входа для стека SaaS компании работает аналогичным образом, что создает ощущение знакомости, и это сделано намеренно. Командам по безопасности не нужно создавать новую модель управления для агентов — они просто используют уже существующую.
Что это значит для команд с пользовательскими решениями
Многие команды, занимающиеся интеграцией и разработкой платформ, не стали ждать, пока MCP созреет. Когда их просили разрешить внутреннему ИИ-ассистенту читать данные из Jira, публиковать сообщения в Slack или запрашивать информацию из инструментов мониторинга, они писали собственный код-посредник: отдельный обертывающий код для каждого API, собственный механизм аутентификации и ручная обработка сессий, поскольку стандартных решений не существовало. Такие решения работали. Но каждый новый инструмент превращался в отдельное решение, алгоритмы аутентификации приходилось переписывать для каждой системы, и такой подход терпел неудачу, как только другая команда требовала аналогичных возможностей.
Новое уровень зрелости решает эти проблемы тремя способами:
- Меньше ручной настройки для каждой интеграции. Стабильный, безсостоянийный транспорт на основе обычного HTTP позволяет командам прекратить написание собственных механизмов управления соединениями и обращаться с сервером MCP так же, как с любым REST API, расположенным за API-шлюзом.
Сама работа по интеграции не исчезает. Перевод данных между схемами тикетинга и мониторинга, а также преобразование на уровне полей, удаление дубликатов и реализация бизнес-логики, охватывающей несколько систем, по-прежнему требуют значительных инженерных усилий, независимо от протокола передачи запросов. Сокращается лишь объем вспомогательных компонентов: транспортировка данных, обработка сессий и процессы аутентификации. Это снижает объем общих усилий, но не полностью устраняет необходимость в работе.
Старая проблема с новой меткой
Если отбросить аспекты искусственного интеллекта, ситуация кажется знакомой. Уже около двух десятилетий компании создают и приобретают платформы интеграции для решения проблем, связанных с соединением API: стандартизированная аутентификация, централизованное картирование и преобразование данных, рост объема транзакций без необходимости написания специального кода для каждой новой пары систем, а также возможность для команд безопасности контролировать подключенные компоненты.
MCP, по-видимому, проходит через ту же процедуру формирования стандартов для подключения ИИ-агентов, только быстрее. Безсостоянийный ядро на базе обычного HTTP позволяет серверу MCP функционировать и масштабироваться как любой бэкенд-сервис. Авторизация, основанная на IdP, превращает предоставление доступа к ИИ-инструментам и его аудит в обычную задачу управления доступом в предприятии. Нейтральное управление со стороны Linux Foundation делает принятие этого протокола похожим на выбор Kubernetes, а не на следование плану какой-то одной компании.
Для команд по интеграции главный вывод заключается не в том, что агентам требуется совершенно новый набор инструкций. Методы, уже используемые для надежного, безопасного и масштабируемого подключения систем, теперь применимы и к агентам. Слой протокола вписывается в инфраструктуру, которую люди уже понимают, а то, что отличает команды друг от друга, перемещается на более высокий уровень — в маппинг данных, обеспечение соблюдения правил и управление изменениями во всех системах, что всегда было самой сложной частью.