MCP опублікував стабільну специфікацію «Enterprise-Managed Authorization»; інші чернетки ідентифікації machine-to-machine — включаючи чернетку OAuth client-credentials та дві відкриті пропозиції — залишаються незавершеними. Для тих, хто намагається запускати автономних агентів за допомогою Model Context Protocol, це означає, що сьогоднішній протокол може перевірити користувача-людину, але не пропонує готового способу довести, що автономний процес є саме тим, за кого себе видає.

Чому дорожня карта має значення

Дорожня карта Model Context Protocol (MCP) ставить ідентифікацію та безпеку агентів серед своїх головних пріоритетів. Було заплановано чотири пункти: браузерний потік, орієнтований на людину (human-centric browser flow), потік OAuth client-credentials для сервісів, прив'язку токенів на основі DPoP та механізм федерації ідентифікації робочих навантажень (workload-identity federation). Лише перший пункт — Enterprise-Managed Authorization — досяг стабільного статусу.

Що насправді робить стабільна специфікація

Enterprise-Managed Authorization дозволяє IT-адміністраторам надавати доступ до сервера з єдиної консолі замість того, щоб кожен співробітник мав підтверджувати кожне з'єднання. Цей потік використовує перенаправлення в браузері та вхід користувача, тому людина за ноутбуком може пройти автентифікацію, після чого сервер довірятиме сесії цього користувача.

Обмеження очевидне: процесу потрібна людина за клавіатурою. У агента, який працює вночі, обробляє дані або реагує на сповіщення, немає нікого, хто міг би натиснути кнопку входу. Як наслідок, будь-яке розгортання, що залежить від автономних агентів, не може використовувати єдину специфікацію, яку MCP гарантує на сьогодні.

Варіанти чернеток та їхні недоліки

Два розширення у формі чернеток мають на меті надати агентам власну ідентифікацію:

  • SEP-1932 (DPoP) – прив'язує токени до пари публічного та приватного ключів, що робить викрадені токени марними.
  • SEP-1933 (Workload Identity Federation) – дозволяє агентам успадковувати ідентифікацію, яка вже надана на хмарних платформах.

Обидва варіанти існують як відкриті pull requests; жоден із них ще не було об'єднано з офіційною специфікацією. Тим часом єдиним іншим задокументованим варіантом є потік OAuth client-credentials, який потребує попередньо зареєстрованих секретів. Зберігання цих секретів у місці, де агент може їх прочитати, створює класичну поверхню атаки: якщо секрет буде викрадено, будь-який зловмисник зможе видати себе за агента.

Практичні кроки для використання у продакшені вже сьогодні

Оскільки протокол ще не надає нативної ідентифікації агентів, команди все одно можуть захистити агентів, винісши управління ідентифікацією за межі MCP:

  1. Видавайте верифіковані ідентифікатори на рівні робочого навантаження (workload layer). Такі системи, як SPIRE, генерують короткострокові сертифікати, прив'язані до кореня довіри хоста, що усуває потребу в статичних секретах.
  2. Завершуйте обробку облікових даних на шлюзі (gateway). Фронтенд-сервіс утримує API-ключ або токен і пересилає запити від імені агента, не допускаючи потрапляння секрету в середовище виконання (runtime environment).
  3. Авторизуйте на основі верифікованої ідентифікації, а не вмісту токена. Розділяйте автентифікацію (хто викликає) та авторизацію (що вони можуть робити), щоб політику можна було застосовувати навіть у разі зміни методу автентифікації.

За чим стежити далі

Два відкриті pull requests — прив'язка DPoP та федерація ідентифікації робочих навантажень — є єдиними шляхами до справжнього стандарту ідентифікації machine-to-machine у межах MCP. Якщо спільнота об'єднає їх, агенти зможуть доводити володіння приватним ключем або успадковувати ідентифікацію, видану хмарою, не розкриваючи секретів. До того часу будь-яке розгортання у продакшені має покладатися на зовнішні фреймворки ідентифікації або приймати ризик використання статичних облікових даних.

Висновок зрозумілий: наразі MCP може автентифікувати людину, яка стоїть за запитом, але він ще не автентифікує програмне забезпечення, що робить цей запит. Командам, яким потрібні безпечні автономні агенти, не варто чекати на фіналізацію специфікації; вони повинні будувати систему ідентифікації на рівні робочого навантаження вже сьогодні та стежити за очікуваними пропозиціями щодо DPoP та федерації.