Ваші MCP-інструменти працювали. Slack, GitHub, Jira, база даних — все з'єднане через MCP, універсальний стандарт підключення для AI-інструментів. Ви вставили API-ключі в JSON-конфіг, запустили локально і відчули себе чарівником. Все спілкувалося з усім.

А потім прийшла команда безпеки. Де зберігаються ці креденшали? Як вони ротуються? Хто ще має до них доступ? Відповідь на всі три: ніхто не знає. І та тиха паніка, яку ви відчули? Помножте її на кожну компанію, що намагається перевести AI-агентів з демо у продакшн.

У квітні 2026-го всі три великі AI-платформи випустили свої рішення для автентифікації MCP — і жодна з них не згодна з іншими, як це має працювати.

Один протокол, три сейфи

9 квітня Anthropic запустила Managed Agents з Credential Vault — зашифрованим проксі, який підтягує ваші секрети, щоб код агента ніколи не торкався реальних креденшалів. OAuth з автооновленням, статичні bearer-токени — все як треба. Ліміт — 20 креденшалів на сховище, бо, очевидно, ентерпрайз-безпека продається з абонементом.

15 квітня OpenAI оновила свій Agents SDK. Їхня пропозиція: передай bearer-токен у хедері, оновлення — сам. Потрібен OAuth? Будуй. Але ось де починається комедія: ChatGPT Apps вимагають OAuth 2.1 — bearer-токени навіть на поріг не пускають. Одна компанія випускає SDK, який каже «токени — ок», і продукт, який каже «категорично ні». OpenAI публічно сперечається сама з собою про автентифікацію, а розробники мають обрати сторону.

17 квітня Google випустила ADK 1.0 — пізніше продемонстрований на Cloud Next 22 квітня. П'ять типів креденшалів, включаючи service accounts, Application Default Credentials і OAuth-флоу з паузою та відновленням. Працює чудово — якщо ви вже присягнули на вірність GCP. Для всіх інших це повний переписування auth з гугловським акцентом.

Три розумні підходи. Три несумісні системи. MCP мав бути USB для AI. Виявилося, що кожен порт потребує окремого блока живлення.

Специфікація, яку ніхто не дотримується

Специфікація MCP (версія 2026-03-15) вимагає OAuth 2.1 з resource indicators — правильно обмежені токени, правильна безпека, все як годиться. На папері проблема вирішена.

На практиці екосистема не отримала цього меморандуму. Як ми розбирали в минулотижневому аналізі supply chain, MCP-сервери мають фундаментальну проблему гігієни — більшість серверів спільноти досі покладається на статичні API-ключі в конфіг-файлах. Аудит AgentSeal від 10 квітня з 1 808 серверів виявив, що дві третини нашпиговані вразливостями — від обходу автентифікації до command injection. За два тижні нічого не покращилось.

Але аспект автентифікації важить більше: серед launch-партнерів усіх трьох платформ майже ніхто не імплементує OAuth 2.1 згідно з реальною специфікацією. Credential Vault від Anthropic стартував з Notion, Asana та Sentry — три managed-інтеграції із сотень серверів, якими розробники реально користуються. Документація Google ADK демонструє п'ять патернів автентифікації, але приклади за замовчуванням — API-ключі. SDK від OpenAI просто пасує — «принеси свій auth» означає, що більшість розробників обирає шлях найменшого опору: статичний токен, скопійований з дашборда.

Чому така прірва? OAuth 2.1 вимагає серверної інфраструктури. Самотній розробник, що підтримує open-source MCP-конектор на вихідних, не має token endpoint, redirect-сервера чи refresh flow. Як написав один розчарований мейнтейнер у тредах спільноти: «Мене просто бісить, що клієнти не всі підтримують OAuth або API key, і мені доводиться підтримувати обидва!» Специфікація вимагає того, що робоча сила екосистеми не здатна забезпечити.

Реальна ціна: написав раз — залочився скрізь

Модель автентифікації кожної платформи має внутрішній сенс. Anthropic грає турботливого батька — замикає аптечку, щоб діти не отруїлися. Google використовує свій хмарний identity-стек — ефективно, якщо ви вже переїхали в будинок GCP. OpenAI максимізує свободу розробника — що є дипломатичним способом сказати, що вони не хотіли будувати auth-інфраструктуру і назвали це фічею.

Колективна ціна — lock-in на рівні креденшалів. Інструмент, підключений до Credential Vault від Anthropic, не працює в Google ADK без переписування auth. Інструмент, що покладається на GCP service accounts, марний у SDK від OpenAI. MCP обіцяв «напиши раз, підключи будь-де». Auth перетворив це на «напиши раз, потім переписуй автентифікацію під кожну платформу». Той самий інструмент — три рахунки за інтеграцію.

Звіт Futurum Group з безпеки MCP сформулював чітко: «Питання, яке насправді ставлять ентерпрайзи — не чи працює MCP. А чи можуть вони контролювати, що він робить.»

Ваша команда безпеки досі чекає

Пам'ятаєте їх? Вони й далі стоять у дверях. Тільки тепер замість однієї незручної відповіді ви їм винні три — кожна прив'язує вас до іншої платформової теології щодо того, як мають працювати креденшали.

Якщо ви оцінюєте MCP-інструменти для продакшну, перевірки функціональності недостатньо. Той Slack-конектор, що гуде в Claude Managed Agents? Закладіть бюджет на повне переписування auth для Google ADK. Ваша команда обрала SDK від OpenAI заради «гнучкості»? Насолоджуйтесь будівництвом OAuth з нуля, поки ChatGPT Apps відмовляються використовувати те, що ви збудували.

MCP має один протокол і три релігії креденшалів. Протокол працює. «Універсальність» розсипалась на рівні автентифікації — саме там, де демо стають деплойментами. Хто зробить автентифікацію за стандартами безболісною для людей, які реально будують MCP-сервери, а не лише для тих, хто їх використовує — той захопить ринок продакшну. Наразі — ніхто. Підставляйте більше стільців для вашої команди безпеки — ця нарада буде довгою.