Найбільш масштабне оновлення протоколу контексту моделі (Model Context Protocol, MCP), відколи він був запущений, відбулося 28 липня. Вже до кінця першого дня всі чотири SDK рівня Tier 1 підтримували нову версію, а SDK Cloudflare Agents отримав підтримку з першого дня. Такі клієнти, як Sentry та Linear, одразу ж почали її використовувати, що означає, що поверхня, описана в цій статті, вже працює в продакшені. Нова 12-місячна політика відкликання зберігає зміни в силі щонайменше до середини 2027 року. Більшість матеріалів зосереджується на покращеннях: безстатусне ядро, що масштабується на стандартному HTTP, авторизація на основі OAuth та інтерфейси користувача, що рендеряться сервером, через MCP Apps.
Останні два роки я розробляю агентні системи, які підключаються до корпоративних інструментів через MCP. Очевидне трактування нової специфікації – це оновлення для масштабування. Однак, важливіша історія полягає в суттєвій зміні відповідальності за безпеку. Нова специфікація перекладає примусове виконання з протоколу на ваші кінцеві точки та розробників. Якщо ваша архітектура безпеки не еволюціонує разом із цією зміною, ви успадкуєте поверхні для атак, які не бачать ваші інструменти мережевого рівня.
До цього часу покриття безпеки MCP зосереджувалося на дозвільних серверах, відсутній автентифікації та отруєнні інструментів, а масштаби цього не малі. Кожного місяця SDK рівня Tier 1 MCP обробляють майже пів мільярда завантажень, а SDK TypeScript і Python вже подолали позначку в мільярд завантажень кожен. Сканування Censys наприкінці квітня виявило 12 520 сервісів MCP, доступних через публічний інтернет, на протоколі, який за замовчуванням не вимагає автентифікації. OX Security повідомила, що одна конструктивна помилка в транспорті STDIO поставила під загрозу до 200 000 серверів.
У травні Центр безпеки штучного інтелекту АНБ опублікував власні рекомендації щодо MCP, попереджаючи, що впровадження випереджає модель безпеки протоколу. Це інша проблема. Специфікація від 28 липня змінює причину накопичення цих ризиків: сесія більше не є одиницею контролю. Кожен запит розглядається як незалежна одиниця, стан переміщується до портативних дескрипторів, а MCP Apps перекладають рендеринг UI на AI-клієнта. Це той самий клас збоїв, але під ними інший контрольний простір.
Для команд платформи це вправа в масштабуванні. Це також зміна у сфері безпеки. Ось що змінилося і що вам потрібно з цим робити.
Що насправді змінилося (і чому команди з безпеки мають це хвилювати)
MCP тепер є безстатусним на рівні протоколу. Заголовок Mcp-Session-Id та рукостискання initialize/initialized, що пов’язували клієнтів з конкретними екземплярами сервера, були видалені. Версія протоколу, інформація про клієнта та його можливості передаються в межах кожного запиту, дозволяючи будь-якому екземпляру сервера обробляти будь-який запит.
Хоча це демонструє солідний інженерний дизайн, це також тягне за собою зміну в безпековому контексті. Ось що змінилося і що це означає для вашої оборони.
|
Зміна специфікації |
Що це дозволяє |
Де тепер безпека |
|
Безстатусне ядро (видалено сесії) |
Round-robin балансування навантаження, автоматичне масштабування |
Примусове виконання на рівні запиту в шлюзі, кожен виклик має бути перевірений, а не тільки початок сесії |
|
Портативні дескриптори стану |
Стан передається явно між викликами інструментів |
Валідація дескрипторів на кінцевій точці, дескриптор, вставлений або прочитаний через ін’єкцію підказок, є дійсним обліковим даними |
|
MCP Apps (HTML, що рендериться сервером) |
Інтерактивні інтерфейси користувача в AI-клієнті |
Кінцева точка/IDE, збережений XSS тепер знаходиться в HTML, відрендереному AI, у пісочниці iframe |
|
Авторизація на основі OAuth |
Стандартні потоки ідентифікації |
Валідація токенів, прив’язаних до аудиторії; токени, видані для одного сервера, не повинні повторно використовуватися проти іншого |
|
Розширення завдань |
Тривала асинхронна робота |
Примусове виконання області дії; без сесій, володіння завданням повинно бути прив’язане до ідентичності, а не до з’єднання |
Три нові поверхні для атак
Компанії Backslash та Akamai розробили карти, де нова специфікація відкриває поверхню для атак, а дослідження Microsoft щодо отруєння інструментів показує, чому цей зсув стає проблематичним, коли агенти переходять від читання до дій. Виникають три нові вектори атак, усі вони знаходяться на кінцевій точці.
1. Збережений XSS у MCP Apps: MCP Apps дозволяє серверу надсилати інтерактивний HTML, який хост відображає у пісочниці iframe. Це приносить класичну веб-вразливість в екосистему ШІ. Зловмисник зберігає шкідливий HTML або JavaScript через MCP-інструмент; коли агент або інший користувач переглядає його, скрипт виконується в інтерфейсі програми. Пісочниця обмежує повний контроль, але клієнт накладений поверх вихідного коду, терміналів, файлових систем та всіх інших підключених MCP-серверів.
2. Перехоплення дескрипторів: Замість сесій використовуються портативні дескриптори, але дескриптор – це просто рядок у розмові, і будь-хто, хто може вставити або прочитати цей рядок, може його експлуатувати. Вантаж ін’єкції підказок у квитку Jira або відповіді інструменту може надати зловмиснику дійсний дескриптор, ніколи не торкаючись сервера. Нова специфікація дозволяє перехоплювати дескриптори; ін’єкція підказок є методом. Вам потрібна валідація дескрипторів для кожного запиту, а не гігієна на рівні розмови.
3. Прогалини в мережевому примусовому виконанні залишаються невидимими: Стан перемістився з транспорту в додаток, тому безпекова робота, яка раніше відбувалася на рівні сесії, тепер повинна виконуватися навмисно, на кінцевій точці. Ці загрози починаються з іншого боку межі, де закінчується видимість мережі.
Що робити, у пріоритетному порядку
Міграція платформи та перехід безпеки – це одна й та сама робота, просто під різними кутами. Нижче наведено мій хід думок. Я впорядкував усе за ризиком, а не за датами.
Почнемо з експозиції MCP Apps: Визначте, які MCP-сервери використовують ваші команди, що можуть відображати HTML UI для клієнта або IDE. Встановіть політику щодо перегляду HTML, який відображається, так само, як ви б переглядали сторонній скрипт, що надсилається на продакшен-сайт. Якщо ви не знаєте, які сервери можуть рендерити UI, ви не зможете цим керувати.
Перенесіть примусове виконання на рівень запитів: Якщо рішення, засновані на стані сесії, приймалися вашим MCP-шлюзом, це зламана конструкція. Її потрібно налаштувати для перевірки та примусового виконання кожного окремого виклику. Прийміть посилену модель авторизації: OAuth 2.1 з PKCE, згода для кожного клієнта, суворе співставлення URI перенаправлення та токени, прив’язані до аудиторії (тобто токен, виданий для одного сервера, не може бути використаний на іншому). Розмістіть шлюз, обізнаний з ідентичністю, перед кожним сервером і відхиляйте будь-який виклик без дійсного, прив’язаного до аудиторії токена.
Дескриптори вважаються неперевіреними вхідними даними: Перевірте, чи ідентичність, що надає дескриптор, є тією, якій він був виданий. Впровадьте гігієну на рівні розмови, яка видаляє або позначає вміст, схожий на інструкції, у вихідних даних інструментів та отриманих документах, оскільки саме там з’являються вставлені дескриптори.
Інструментуйте кінцеву точку: Шлюз, обізнаний з ідентичністю, примусово виконує запит, але йому бракує знань про рендеринг MCP Apps, локальні серверні операції або виконання в IDE. Для цього потрібен інший інструмент. Створіть видимість кінцевої точки для хост-процесу, локальних MCP-серверів та рендерингу клієнта. Якщо ваш стек повністю мережевий, це прогалина, яку відкриває нова специфікація.
Модульні тести не виявлять, що тут зламається: Зміна специфікації виглядає добре в модульних тестах і зламається в реальному циклі роботи агента. Запустіть свої мігровані сервери проти реальних моделей, що керують реальними робочими процесами. Шукайте стан, який витікає між екземплярами сервера, дескриптори, що повторно використовуються в різних сферах дії, та несподіваний вміст UI.
Плануйте відкликання: Коріння, вибірка та логування відкликаються в цій специфікації, як і застарілий транспорт HTTP+SSE, що для більшості команд платформи вимагає роботи з міграції. 12-місячний відлік розпочався 28 липня, і, як наслідок, видалення відбудеться не раніше середини 2027 року. Почніть планувати цю міграцію зараз. Вікна відкликання завжди здаються довгими, а потім здаються досить короткими.
Стратегічний момент
Спеціалісти MCP зробили свідомий вибір: протокол не забезпечує безпеку для вас. Це можна обґрунтувати. Для агентів корпоративного масштабу безстатусний протокол на стандартній інфраструктурі є правильним вибором. Але «протокол не забезпечує безпеку» означає «ви забезпечуєте її» на кінцевій точці, при кожному запиті, кожному дескрипторі, кожному відрендереному UI.
Компанії, які розглядають це як міграцію, впровадять нову специфікацію з тим самим рівнем безпеки, який вони мали для статусного протоколу, і цей рівень не відповідає поточній поверхні загроз. З іншого боку, компанії, які розглядають це як перехід безпеки, переносячи примусове виконання на рівень запитів, запроваджуючи контроль на кінцевій точці та керуючи MCP Apps до їх розповсюдження, будуть тими, чиї розгортання агентів переживуть контакт зі справжнім зловмисником.
Специфікація еволюціонувала. Тож справжнє питання: чи встигне ваша архітектура безпеки?
Нік Кейл – провідний інженер, який спеціалізується на корпоративних AI-платформах та безпеці.
Джерело новини: venturebeat.com