Що означають безстановий ядро та керована авторизація 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 виконує для з’єднань AI з системою ту саму функцію, що REST та OpenAPI виконували між додатками. Інтегровані системи залишаються незмінними. Стандартизується лише контракт між клієнтом AI та тим, що обслуговує сервер MCP – це може бути інструмент для обробки замовлень, CMDB, платформа моніторингу чи внутрішня база даних.
Зміна 1: більше немає сеансів
Протягом перших двох років MCP через HTTP функціонував як багато протоколів реального часу. Клієнт під’єднувався, виконував процедуру ініціалізації та отримував ідентифікатор сеансу, який мусив бути включений у кожен наступний запит. Сеанс прив’язував клієнта до конкретної інстанції сервера, яка його створила. Кожен, хто використовує сервіс WebSocket за балансувальником навантаження, знає про проблеми, пов’язані з цим. Для масштабування потрібні були механізми «sticky routing», спільний сховище сеансів чи шлюз, який аналізував трафік для знаходження інстанції, що підтримує з’єднання.
Специфікація від 28.07.2026 усуває все це. Немає процедур ініціалізації та підтвердження ініціалізації, а також заголовка Mcp-Session-Id. Натомість кожен запит містить власну версію протоколу, ідентифікатор клієнта та його можливості. У результаті будь-яка інстанція сервера може відповісти на будь-який запит, тож «липкі сесії» та спільні сховища сесій більше не є обов’язковими згідно з протоколом. Кластери без серверів, багатоінстанційні структури та маршрутизація на периферії працюють так само, як і з звичайними HTTP-API, адже структурно MCP і є саме цим.
Без сеансів протоколу додатки не стають безстановими. Коли сервер справді мусить щось пам’ятати між викликами, наприклад процес експорту чи тривалу задачу виправлення, він дотримується старої практики REST: він створює явний ідентифікатор, а клієнт передає його назад як звичайний аргумент наступного разу. Інженери, знайомі з механізмами сторінкування та ендпоїнтами статусу завдань, його впізнають; це обґрунтований вибір, який підходить для балансувальників навантаження, а не просто патч.
У цьому оновленні була посилена безпека навколо нової структури. Клієнти повинні перевіряти автентичність видачі токенів у відповідях на запити на авторизацію, що запобігає викраденню сеансів через перенаправлення у мультисерверних системах. Вони також мають вказувати, для якого саме сервера призначений токен, що усуває проблему делегування, яку команди з безпеки вважали справжнім ризиком у системах з кількома користувачами. Крім того, MCP тепер вперше має формальну політику виходу з експлуатації, тож зміни мають чіткий життєвий цикл та не вносяться спонтанно.
Зміна 2: доступ, який керується постачальником ідентичності
Друга зміна стосується не стільки транспортування даних, скільки щоденних труднощів із розгортанням агентів у всій компанії. За підходом авторизації першого покоління кожен співробітник мусив особисто пройти крок згоди OAuth для кожного сервера MCP, який використовував його клієнт штучного інтелекту. При кількості сотні працівників та шести-семи внутрішніх інструментах процес інтеграції більше не може масштабуватися. Команди з безпеки також втрачають централізований огляд того, хто підключений до чого, і не існує простого способу обмежити доступ, коли хтось переходить на іншу посаду чи залишає компанію.
EMA передає рішення щодо авторизації постачальнику ідентичностей компанії. Адміністратор один раз у IdP визначає, які сервери 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 досягне зрілості. Коли їх просили дозволити внутрішньому AI-асистенту читати дані з Jira, публікувати повідомлення в Slack чи запитувати інформацію з інструментів моніторингу, вони писали власний код для з’єднання: індивідуальний обгорток для кожного API, власну схему автентифікації та ручне керування сеансами, оскільки стандартних рішень не існувало. Такі рішення працювали. Але кожен новий інструмент перетворювався на окреме рішення, автентифікація перепроектовувалася для кожної системи, і такий підхід припиняв працювати, як тільки ще одна команда потребувала такої ж функціональності.
Новоотримана зрілість призводить до проблем у трьох аспектах:
- Менше власного коду для кожної інтеграції. Стабільний, безстановий транспорт через звичайний HTTP дозволяє командам припинити писати власні механізми керування з’єднаннями та працювати з сервером MCP так само, як із будь-яким REST API, розташованим за API-гейтвеєм.
Сама робота з інтеграцією не зникає. Переклад даних між схемою тикетів та схемою моніторингу, а також трансформація на рівні полів, усунення дублікатів та бізнес-логіка, яка поєднує різні системи, все ще вимагають справжніх інженерних зусиль, незалежно від протоколу, який передає запит. Зменшується кількість супутніх елементів: транспортування даних, обробка сеансів та процес автентифікації. Це значно скорочує кількість неспецифічних зусиль, хоча й не всю роботу.
Стара історія з новою назвою
Якщо відкинути аспекти штучного інтелекту, це звучить знайомо. Протягом приблизно двох десятиліть компанії створювали та купували платформи інтеграції для вирішення проблем, пов’язаних із з’єднанням API: стандартизована автентифікація, централізоване картування та трансформація даних, зростання обсягу транзакцій без необхідності писати окремий код для кожної нової пари систем, а також можливість для команд безпеки бачити та контролювати те, що підключено.
MCP, схоже, проходить через ту саму процедуру регулювання для підключень AI-агентів, тільки швидше. Безстановий ядро на звичайному HTTP дозволяє серверу MCP функціонувати та масштабуватися як будь-який бекенд-сервіс. Авторизація, заснована на IdP, робить надання та контроль доступу до AI-інструментів звичайною частиною корпоративного керування доступом. А нейтральне управління в межах Linux Foundation робить впровадження цього протоколу схожим на вибір Kubernetes, а не на слідування конкретному плану однієї компанії.
Для команд з інтеграції урок полягає не в тому, що агентам потрібні зовсім нові методики. Методи, які вже використовуються для надійного, безпечного та масштабованого підключення систем, тепер можна застосовувати й до агентів. Протокольний шар вписується в інфраструктуру, яку люди вже розуміють, а те, що відрізняє команди, зміщується вище — у мапування даних, забезпечення дотримання правил та управління змінами в системах з обох кінців, що завжди було найскладнішою частиною.