Model Context Protocol (MCP, протокол взаимодействия ИИ с внешними инструментами) — это открытый стандарт от Anthropic, по которому ИИ-агенты подключаются к сервисам, API, базам данных, файлам и сайтам. Если языковая модель — это «мозг», то MCP — стандартный разъём, через который она дотягивается до реального мира: вашей CRM, аналитики, репозитория или CMS.
28 июля 2026 года выходит финальная версия спецификации MCP 2026-07-28 — сейчас она в статусе релиз-кандидата (release candidate, предварительная стабильная версия перед публикацией). Это крупнейший пересмотр протокола с момента его запуска. Ниже разберём, что именно меняется, зачем это сделано, что даёт разработчикам и бизнесу — и почему одновременно резко обострился вопрос безопасности MCP.
Что такое MCP и почему о нём стоит знать
До появления MCP каждое подключение ИИ к внешнему инструменту приходилось программировать отдельно: свой коннектор к почте, свой — к базе данных, свой — к платёжному сервису. MCP стандартизирует этот слой. Часто его называют «USB-C для ИИ»: единый разъём вместо десятка несовместимых.
Архитектура простая: есть клиент (ИИ-приложение — например, Claude Code или агент вроде OpenClaw) и MCP-сервер — небольшая обёртка над конкретным инструментом или API, которая описывает доступные действия на понятном модели языке. Именно так современные агенты получают доступ к вашим данным и сервисам. Мы уже разбирали, как агенты выходят из редактора кода в бизнес-процессы и как локальный агент превращается в инфраструктуру — MCP это тот самый «клей», который связывает их с внешним миром.
Что меняется в спецификации 2026-07-28
Обновление затрагивает саму механику протокола. Изменения делают MCP проще в эксплуатации, ближе к привычным веб-стандартам и пригоднее для промышленного использования.
Stateless-ядро: протокол без сессий
Ключевое изменение — MCP становится stateless (без сохранения состояния между запросами). Убраны начальный обмен initialize/initialized (handshake, «рукопожатие» при установке соединения) и заголовок Mcp-Session-Id. Теперь информация о клиенте и его возможностях едет прямо в каждом запросе, в полях _meta.
Появились служебные HTTP-заголовки Mcp-Method, Mcp-Name и MCP-Protocol-Version. Благодаря им балансировщик нагрузки может маршрутизировать трафик, не заглядывая в тело запроса. Практический смысл: любой экземпляр сервера обрабатывает любой запрос, поэтому MCP-сервисы масштабируются на обычной HTTP-инфраструктуре так же, как привычные веб-приложения — без «липких» сессий и сложной синхронизации состояния.
MCP Apps: интерфейсы прямо от сервера
Новое расширение MCP Apps позволяет серверу отдавать не только текст и данные, но и готовый интерактивный интерфейс — HTML, отрисованный на стороне сервера и показанный в sandboxed iframe (изолированном фрейме-«песочнице»). Инструмент заранее объявляет свой UI-шаблон, чтобы клиент мог его предзагрузить и проверить на безопасность. При этом все действия из такого интерфейса идут по тому же протоколу JSON-RPC, что и обычные вызовы инструментов. Для пользователя это значит, что агент сможет показать форму, таблицу или набор кнопок, а не только абзац текста.
Расширение Tasks: для долгих операций
Раньше вызов инструмента был коротким запросом-ответом. Расширение Tasks переработано под stateless-модель: сервер отвечает на tools/call «хэндлом задачи» (task handle, ссылкой на выполняемую операцию), а клиент отслеживает прогресс через tasks/get и управляет ей через tasks/update и tasks/cancel.
Это отражает общий тренд 2026 года: агенты перестали быть «спросил — ответил» и работают минутами и часами, выполняя длинные цепочки действий. Экспериментальный вариант Tasks из версии 2025-11-25 придётся мигрировать на новый API.
Авторизация ближе к OAuth и предсказуемая эволюция
Шесть отдельных предложений по улучшению (SEP, Specification Enhancement Proposal) приближают авторизацию MCP к практикам OAuth 2.0 и OpenID Connect (общепринятые стандарты авторизации и аутентификации). В частности, клиенты обязаны проверять параметр iss (издатель токена) по RFC 9207, объявлять тип приложения при динамической регистрации и привязывать учётные данные к конкретному серверу авторизации.
Отдельно вводится политика устаревания: у каждой возможности теперь есть жизненный цикл — «активна», «устарела», «удалена», причём между объявлением устаревания и возможным удалением проходит не менее двенадцати месяцев. По этой схеме уже помечены к устареванию Roots, Sampling и Logging. Для разработчиков это главное: на MCP теперь можно строить продукты, не опасаясь, что протокол внезапно сломает совместимость.
Корпоративная авторизация: единый вход для ИИ-агентов
Параллельно до стабильного статуса доведено расширение Enterprise-Managed Authorization (EMA, корпоративно-управляемая авторизация). Оно даёт организациям централизованный контроль доступа к MCP-серверам через корпоративный провайдер идентификации (IdP, identity provider — система единого входа сотрудников). Вместо того чтобы подтверждать согласие на каждом сервере по отдельности, пользователь входит один раз и получает доступ к разрешённым инструментам.
Технически это работает через Identity Assertion JWT Authorization Grant (ID-JAG) — подписанное утверждение об identity, которое обменивается на токен доступа. Поддержку уже заявили Anthropic (в Claude, Claude Code и Cowork), Microsoft (в Visual Studio Code) и Okta как первый провайдер идентификации; на стороне серверов — Asana, Atlassian, Canva, Figma, Linear, Supabase, а Slack в процессе.
Важная оговорка: EMA управляет доступом на уровне подключения, но это не авторизация каждого отдельного действия в момент выполнения. Что именно агент делает после получения токена, нужно ограничивать отдельными средствами.
Тема контроля доступа для ИИ становится центральной — мы уже касались её в разборе того, как доступ к мощным моделям упирается не в вычисления, а в правила.
Обратная сторона: безопасность MCP вышла на первый план
Зрелость протокола обнажила и его риски. Июль 2026 года прошёл под знаком безопасности MCP, и здесь важно быть трезвым.
Агентство национальной безопасности США (NSA) выпустило рекомендации по харднингу (hardening, усилению защиты) MCP. В документе названы структурные проблемы: инвертированный клиент-серверный паттерн, непроверенное распространение задач между инструментами и серьёзный риск исполнения произвольного кода.
Конкретные примеры уже есть. В инструменте Amazon Q обнаружили уязвимость с оценкой CVSS 8.5 (CVSS — шкала критичности уязвимостей, где 10 — максимум): она позволяла автоматически подгружать MCP-конфигурации из рабочих каталогов без согласия пользователя, а затем исполнять код и красть ключи доступа к AWS. Патч вышел в июне 2026 года. Отдельное исследование более чем 10 000 реальных MCP-серверов показало, что учётные данные, API-ключи и персональные данные (PII, personally identifiable information) утекают более чем в 10% случаев.
Появились и специфические техники атак: ShareLock — распределение вредоносных инструкций по описаниям нескольких «безобидных» инструментов (успех более 90%), WebMCP Tool Surface Poisoning — подмена набора инструментов агента в середине сессии, и Agentjacking — поддельные диагностические события, вынуждающие агент выполнить чужие команды (успех около 85%). Общий вывод специалистов однозначен: MCP-сервер нельзя считать доверенным по умолчанию.
Что это значит на практике
Для разработчиков. Stateless-архитектуру проще деплоить и масштабировать — это плюс. Но стоит заранее спланировать миграцию с экспериментального Tasks API, учесть будущее устаревание Roots, Sampling и Logging и закладывать авторизацию, совместимую с OAuth 2.0 и OpenID Connect. Если вы уже используете MCP в связке с агентами, полезно свериться с базовой структурой проекта для Claude Code, чтобы конфигурация серверов была прозрачной и воспроизводимой.
Для владельцев сайтов и бизнеса. MCP — это то, как ваши будущие ИИ-помощники будут подключаться к CRM, аналитике, платежам и CMS. Стандартизация и корпоративный вход упрощают внедрение, но каждая новая интеграция — это дополнительная поверхность атаки. Не подключайте случайные MCP-серверы из непроверенных источников, ограничивайте права и требуйте явного подтверждения чувствительных действий.
Чек-лист безопасного внедрения MCP
Подключайте только проверенные MCP-серверы из доверенных источников; не разрешайте автозагрузку конфигураций из рабочих каталогов.
Требуйте явного согласия пользователя на чувствительные операции (запись, оплата, отправка данных).
Проверяйте (валидируйте) то, что возвращает MCP-сервер, и не относитесь к нему как к заведомо «своему» внутреннему сервису.
Ограничивайте права токенов и помните: доступ к подключению — это ещё не право на любое действие.
Где возможно, используйте корпоративный провайдер идентификации (EMA) вместо разрозненных согласий.
Держите SDK и серверы в актуальных версиях и следите за публикуемыми уязвимостями (CVE).
Логируйте и отслеживайте вызовы инструментов — это первая линия обнаружения аномалий.
Вывод
MCP переходит из категории «эксперимент для разработчиков» в категорию инфраструктуры: он становится стабильнее, масштабируемее, получает корпоративный вход и предсказуемую политику развития. Но взросление протокола означает и взросление требований к безопасности. Выигрывают не те, кто подключает всё подряд, а те, кто внедряет MCP осознанно: берут пользу от стандартизации, но держат под контролем каждый сервер и каждое действие агента.
Частые вопросы
Что такое MCP простыми словами?
Это единый стандарт, по которому ИИ-модель подключается к внешним инструментам и данным — почте, базам, API, сайтам. Аналог универсального разъёма, избавляющего от десятка индивидуальных интеграций.
Нужно ли что-то менять прямо сейчас?
Если вы только пользуетесь готовыми агентами — нет, обновление подтянется на стороне вендоров. Если разрабатываете свои MCP-серверы — да: планируйте переход на stateless-модель, новый Tasks API и OAuth-совместимую авторизацию.
Безопасно ли использовать MCP?
При аккуратном подходе — да. Риски связаны не с самой идеей, а с бездумным подключением непроверенных серверов и избыточными правами. Чек-лист выше закрывает большинство типовых проблем.
Заменит ли MCP обычные API?
Нет. MCP не заменяет API, а стандартизирует то, как ИИ ими пользуется. Под капотом MCP-сервер обычно и обращается к привычным REST- или GraphQL-эндпоинтам.
Источники: официальный блог Model Context Protocol (анонс релиз-кандидата 2026-07-28), InfoQ о корпоративной авторизации MCP, обзор безопасности MCP за июль 2026 (Adversa AI).
