Новая спецификация MCP превращает внедренный промпт в украденные учетные данные

Крупнейшее обновление протокола Model Context Protocol (MCP) с момента его первоначального запуска было выпущено 28 июля. К концу первого дня все четыре SDK первого уровня уже поддерживали новую версию, а SDK агентов от Cloudflare обзавелся поддержкой с нулевого дня. Такие клиенты, как Sentry и Linear, внедрили изменения незамедлительно, что означает, что описанные в этой статье возможности уже работают в продакшене. Новая 12-месячная политика прекращения поддержки сохраняет эти изменения в силе как минимум до середины 2027 года. Большинство обзоров было сосредоточено на усовершенствованиях: безграссновое (stateless) ядро, масштабируемое на обычном HTTP, нативная авторизация OAuth и рендерируемые на сервере пользовательские интерфейсы с помощью приложений MCP.

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

До сих пор вопросы безопасности MCP концентрировались на излишне разрешительных серверах, отсутствии аутентификации и отравлении инструментов (tool poisoning), причем масштабы этого явления огромны. Каждый месяц SDK первого уровня для MCP регистрируют около полумиллиарда загрузок, а общее число скачиваний SDK для TypeScript и Python превысило миллиард для каждого из них. Сканирование Censys в конце апреля выявило 12 520 сервисов MCP, выставленных в общедоступный интернет на протоколе, который по умолчанию не требует аутентификации. Компания OX Security сообщила, что один единственный изъян в дизайне транспорта STDIO поставил под угрозу до 200 000 серверов.

В мае Центр безопасности искусственного интеллекта АНБ (NSA) опубликовал собственные рекомендации по MCP, предупредив, что темпы внедрения опережают модель безопасности протокола. Это принципиально иная проблема. Спецификация от 28 июля меняет причину, по которой эти риски усугубляются: сеанс больше не является единицей контроля. Каждый запрос рассматривается как независимая единица, состояние переносится в переносимые дескрипторы (handles), а приложения MCP перекладывают рендеринг пользовательского интерфейса на ИИ-клиент. Семейство уязвимостей то же, но лежащая в их основе плоскость управления изменилась.

Для команд платформ это упражнение на масштабирование, а также поворот в сфере безопасности. Вот что изменилось и что вам нужно с этим делать.

Что на самом деле изменилось (и почему команды безопасности должны обратить на это внимание)

Теперь MCP является безграссковым (stateless) на уровне протокола. Заголовок Mcp-Session-Id и рукопожатия initialize/initialized, связывающие клиенты с конкретными экземплярами серверов, были удалены. Версия протокола, информация о клиенте и возможности клиента передаются прямо внутри каждого запроса, что позволяет любому экземпляру сервера обрабатывать любой запрос.

Хотя это демонстрирует надежное инженерное решение, оно также влечет за собой сдвиг в вопросах безопасности. Вот что изменилось и что это значит для вашей защиты.

Три новые поверхности атак

Компаниям Backslash и Akamai удалось составить карту того, где новая спецификация открывает поверхность для атак, а исследование Microsoft по отравлению инструментов показывает, почему этот сдвиг становится опасным, как только агенты переходят от чтения к действию. Появляются три новых вектора атак, и все они сосредоточены на эндпоинте.

1. Сохраненный XSS в приложениях MCP: Приложения MCP позволяют серверу отправлять интерактивный HTML-код, который хост рендерит в изолированном iframe. Это переносит классическую веб-уязвимость в экосистему ИИ. Злоумышленник сохраняет вредоносный HTML или JavaScript с помощью инструмента MCP; когда агент или другой пользователь просматривает его, скрипт запускается внутри интерфейса приложения. Песочница ограничивает полный захват системы, но клиент находится поверх исходного кода, терминалов, файловых систем и каждого другого подключенного MCP-сервера.

2. Перехват дескрипторов (Handle hijacking): Вместо сеансов используются переносимые дескрипторы, но дескриптор — это всего лишь строка в рамках разговора, и любой, кто может вставить или прочитать эту строку, может воспользоваться ею. Пейлоад с инъекцией промпта в тикете Jira или в ответе инструмента может передать злоумышленнику действительный дескриптор, даже не касаясь сервера. Новая спецификация делает возможным перехват дескрипторов, а инъекция промпта выступает методом атаки. Вам необходима проверка дескрипторов для каждого запроса, а не гигиена на уровне диалога.

3. Пробелы в сетевом контроле остаются невидимыми: Состояние переместилось из транспорта в приложение, поэтому работа по безопасности, которая раньше выполнялась на уровне сеанса, теперь должна выполняться целенаправленно на эндпоинте. Эти угрозы начинаются по ту сторону границы, где заканчивается сетевая видимость.

Что делать в порядке приоритета

Миграция платформы и переход в сфере безопасности — это по сути одна и та же задача, просто рассматриваемая под разными углами. Ниже приводится ход моих мыслей. Я упорядочил все по степени риска, а не по датам.

Мы начнем с подверженности рискам приложений MCP: Выясните, какие серверы MCP используют ваши команды, способные отображать пользовательский интерфейс HTML для клиента или IDE. Установите политику в отношении проверки отображаемого HTML-кода точно так же, как вы проверяли бы сторонний скрипт, отправляемый на производственный веб-сайт. Если вы не знаете, какие серверы могут рендерить интерфейс, вы не можете этим управлять.

Перенесите обеспечение безопасности на уровень запросов: Если решения, основанные на состоянии сеанса, принимались вашим шлюзом MCP, это ошибочная архитектура. Шлюз должен быть настроен на проверку и принудительное применение политик при каждом вызове. Примите усиленную модель авторизации: OAuth 2.1 с PKCE, согласие для каждого клиента, строгая сверка redirect-URI и токены, привязанные к аудитории (это означает, что токен, выданный для одного сервера, не может быть использован на другом). Установите шлюз с поддержкой идентификации перед каждым сервером и отклоняйте любые вызовы без действительного токена, привязанного к аудитории.

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

Инструментируйте эндпоинт: Шлюз с поддержкой идентификации контролирует запрос, но он не обладает информацией о рендеринге приложений MCP, операциях локального сервера или выполнении в IDE. Для этого требуется другой инструмент. Обеспечьте видимость эндпоинтов для хост-процесса, локальных MCP-серверов и клиентского рендеринга. Если ваш стек полностью сетевой, это как раз та брешь, которую открывает новая спецификация.

Юнит-тесты не покажут, что именно здесь сломается: Изменение спецификации выглядит отлично в модульных тестах, но даст сбой в цикле работы реального агента. Запустите ваши мигрированные серверы против реальных моделей, управляющих реальными рабочими процессами. Следите за утечками состояния между экземплярами серверов, повторно используемыми в разных областях видимости дескрипторами и неожиданным контентом пользовательского интерфейса.

Планируйте прекращение поддержки (deprecations): С этой спецификацией устаревают корни (roots), семплинг (sampling) и логирование, а также устарел устаревший транспорт HTTP+SSE, что для большинства платформ заставляет проводить работы по миграции. 12-месячный отсчет начался 28 июля, в результате чего удаление произойдет не раньше середины 2027 года. Начинайте планировать этот переход прямо сейчас. Окна прекращения поддержки всегда кажутся длинными, а затем пролетают очень быстро.

Стратегический вывод

Разработчики MCP приняли осознанное решение: протокол не обеспечивает безопасность за вас. Это можно оправдать. Для агентов корпоративного масштаба безграссковый протокол на товарной инфраструктуре — правильный выбор. Но фраза «протокол не обеспечивает безопасность» означает «это делаете вы» — на эндпоинте, для каждого запроса, каждого дескриптора, каждого отображаемого интерфейса.

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

Спецификация эволюционировала. Так что главный вопрос звучит так: успеет ли ваша архитектура безопасности поспеть за ней?

Ник Кале (Nik Kale) — главный инженер, специализирующийся на корпоративных ИИ-платформах и безопасности.

Добро пожаловать в сообщество VentureBeat!

Наша программа гостевых публикаций — это площадка, где технические эксперты делятся идеями и проводят непредвзятый, независимый глубокий анализ ИИ, инфраструктуры данных, кибербезопасности и других передовых технологий, формирующих будущее бизнеса.

Читайте далее в рамках нашей программы гостевых постов и ознакомьтесь с нашими рекомендациями, если вы хотите сами написать статью!