У корпоративному світі багатокомпонентні агенти й інструменти на базі великих мовних моделей дедалі частіше будуються навколо MCP (Model Context Protocol) — відкритого стандарту, створеного в Anthropic. Проте, попри тисячі доступних MCP‑серверів у офіційному реєстрі, більшість підприємств фактично не здатні використовувати більше ніж кілька з них.
Про те, чому так відбувається, розповідає Карана Сампат, forward deployed engineer в Anthropic і перший інженер у цій ролі поза США. Він працює безпосередньо з великими компаніями над впровадженням MCP та внутрішніми кейсами Anthropic. Його досвід показує: проблема не в самому стандарті MCP, а в тому, як підприємства намагаються його «операціоналізувати» — тобто зробити частиною масштабованої, безпечної інфраструктури.
MCP як стандарт не гальмує — гальмує те, як його вбудовують у корпоративну реальність
MCP сьогодні виглядає як історія успіху. Це відкритий протокол, який дозволяє агентам безпечно й структуровано взаємодіяти з зовнішніми інструментами та даними. Він створений в Anthropic, має офіційний реєстр із тисячами серверів, і цей реєстр швидко зростає: окремі команди й компанії постійно додають нові MCP‑сервери, намагаючись стандартизувати доступ до своїх сервісів.
На папері це ідеальна картина для підприємств: є зрозумілий стандарт, є багата екосистема, є можливість швидко будувати нові інструменти. Але на практиці більшість організацій «упирається» в дуже низьку стелю — одиниці або, в кращому разі, невелику кількість MCP‑серверів у продуктивному використанні.
Ключовий момент: сам протокол MCP не є вузьким місцем. Він навпаки спроєктований так, щоб бути максимально корисним для enterprise‑сценаріїв. Проблема в тому, що все, що знаходиться навколо нього — безпека, спостережуваність, контроль доступу, управління обліковими даними — у більшості компаній залишається фрагментованим, ручним і несистемним.
У результаті MCP виявляється не спільною інфраструктурою, а набором поодиноких інтеграцій, кожна з яких вимагає окремих погоджень, окремих перевірок безпеки й окремого «обслуговування». На масштабі це просто не працює.
Чому реєстрів недостатньо: де закінчується зручність і починається хаос
Офіційний реєстр MCP‑серверів — важливий елемент екосистеми. Він дає огляд доступних серверів, спрощує пошук і повторне використання вже створених інструментів. Anthropic цілком відверто пишається тим, що допомогла його створити.
Але для підприємств реєстр — лише стартова точка, а не повноцінне рішення. На рівні великої організації виявляється, що реєстр не відповідає на базові запитання, які вважаються «гігієнічним мінімумом» для будь-якої критичної інфраструктури.
По-перше, автентифікація. Реєстр не є системою керування ідентичностями. Він не знає, хто саме в межах конкретної компанії звертається до сервера, як цей користувач автентифікований, які в нього права, як це пов’язано з корпоративним IdP. Для enterprise‑середовища це фундаментальна прогалина.
По-друге, контроль доступу. Реєстр не реалізує тонке, рольове керування правами. Він не може, наприклад, забезпечити сценарій, коли весь департамент бачить діагностику певного MCP‑сервера, але лише вузька група має право змінювати конфігурацію чи оновлювати дашборди. Для складних організаційних структур це критично.
По-третє, спостережуваність. Реєстр не відповідає на питання: хто, коли і як використовує конкретний MCP‑сервер у межах організації. Він не дає цілісної картини навантаження, помилок, «гарячих» інструментів, які реально несуть бізнес‑цінність. Для команд безпеки, SRE й продукту це означає роботу в темряві.
По-четверте, керування обліковими даними. Реєстр не є централізованим сховищем секретів і не визначає політики того, як саме MCP‑сервери мають працювати з токенами, ключами, службовими акаунтами. Кожен сервер змушений вирішувати це по-своєму.
У підсумку, спиратися лише на публічний або простий внутрішній реєстр MCP‑серверів — означає залишити поза увагою всі питання, які для enterprise‑команди є визначальними: хто має доступ, як це логувати, як це контролювати, як це масштабувати без вибуху складності.
Коли кожен MCP живе за своїми правилами: фрагментація безпеки й інфраструктури
Якщо немає єдиного контрольного шару, кожен MCP‑сервер у компанії починає жити власним життям. Кожна команда, яка створює сервер, змушена самостійно вирішувати, як саме реалізувати безпеку, логування, підключення до внутрішніх систем, політики доступу.
Це призводить до кількох системних наслідків.
По-перше, з’являються несумісні політики. Один сервер може вимагати жорсткої автентифікації й детального логування, інший — покладатися на спрощені механізми або взагалі мінімальну перевірку. Для служби безпеки це означає мозаїку з різних підходів, які важко перевіряти й аудіювати.
По-друге, дублюється зусилля. Кожна команда знову й знову вирішує одні й ті самі інфраструктурні задачі: як підняти сервер, як його захистити, як підключити до внутрішньої мережі, як зібрати логи. Це не лише неефективно, а й створює різнорівневу якість реалізацій.
По-третє, зростають ризики. Чим більше «саморобних» схем безпеки, тим вищий шанс, що десь буде пропущена критична деталь: відсутній аудит, некоректно налаштований доступ, слабке шифрування, надто широкі права для сервісних облікових записів. На масштабі десятків MCP‑серверів це перетворюється на серйозну поверхню атаки.
По-четверте, страждає швидкість впровадження. Навіть якщо бізнес‑команда, наприклад юридичний відділ, готова самостійно описати бізнес‑логіку MCP‑сервера для аналізу контрактів, вона впирається в необхідність залучати інженерів безпеки, інфраструктурні команди, проходити повний цикл рев’ю. Кожен новий сервер стає маленьким проєктом із високим порогом входу.
Усе це створює парадокс: MCP як стандарт дозволяє швидко будувати нові інструменти, але відсутність єдиного контрольного шару змушує підприємства поводитися з ними так, ніби це окремі, важкі інтеграції. У результаті більшість організацій так і залишаються на рівні «одиничних» MCP‑серверів, не переходячи до десятків і тим паче сотень.
Спостережуваність, доступ, безпека: «триголовий гідра», яка блокує масштаб
У корпоративних розмовах про MCP найчастіше фігурують три теми, які Карана Сампат описує як «триголового гідру»: спостережуваність, контроль доступу й безпека. Кожна з них окремо складна, але разом вони створюють саме той бар’єр, через який більшість компаній не можуть переступити.
Спостережуваність — це не лише технічні метрики на кшталт latency чи error rate. Для підприємства важливо розуміти, хто саме використовує конкретний MCP‑сервер, які інструменти реально задіяні, де виникають збої, які частини протоколу працюють не так, як очікується. Без цього важко як розвивати самі сервери, так і будувати довіру до них з боку бізнесу й безпеки.
Контроль доступу — це не просто «є доступ / немає доступу». У реальних сценаріях потрібні складні моделі: наприклад, усі співробітники можуть переглядати аналітичні дашборди, але лише окремі ролі мають право змінювати конфігурацію або запускати дії, що впливають на продакшн‑системи. MCP‑сервери сьогодні рідко мають вбудовані, уніфіковані механізми для таких сценаріїв.
Безпека — найширший пласт. Вона включає як перевірку самих MCP‑серверів (чи безпечні їхні інструменти, чи не допускають вони витоку даних, чи не можуть бути використані для шкідливих дій щодо внутрішньої інфраструктури), так і питання віддалених клієнтів. У сучасних архітектурах агенти й клієнти можуть бути частково або повністю недовіреними, але при цьому їм потрібно надавати доступ до приватних корпоративних даних через MCP. У світі API для цього вже є напрацьовані патерни, але для MCP вони ще не стали стандартом.
Коли всі три проблеми не вирішені системно, вони підсилюють одна одну. Без спостережуваності важко оцінити реальні ризики безпеки. Без чіткого контролю доступу важко будувати довірені моделі взаємодії з MCP‑серверами. Без єдиної моделі безпеки кожен сервер стає окремою точкою потенційної вразливості.
Саме тому Anthropic спостерігає, що більшість підприємств «застрягають» на невеликій кількості MCP‑серверів: далі цього рівня триголовий гідра стає просто некерованою.
MCP як спільна інфраструктура, а не колекція інтеграцій
Стратегічна рамка, яку пропонує Anthropic, полягає в тому, що MCP у великих організаціях мають розглядатися не як набір окремих інтеграцій, а як спільна інфраструктура. Це зміна мислення, яка безпосередньо впливає на те, чи зможе компанія вийти за межі «одиничних» MCP‑серверів.
Якщо MCP сприймається як разова інтеграція, кожен новий сервер проходить повний цикл: окремий дизайн безпеки, окреме погодження, окремі інфраструктурні рішення. Це неминуче обмежує масштаб — навіть якщо технічно створити новий сервер нескладно, організаційно це стає надто дорогим.
Якщо ж MCP розглядається як спільна інфраструктура, завдання формулюється інакше: створити єдиний шар, який бере на себе всі повторювані аспекти — автентифікацію, авторизацію, спостережуваність, безпечне з’єднання, хостинг і деплоймент. Тоді кожна нова команда, яка будує MCP‑сервер, фокусується виключно на бізнес‑логіці.
Це особливо важливо в умовах, коли завдяки інструментам на кшталт Claude Core дедалі більше команд можуть самостійно створювати MCP‑сервери, не залучаючи спеціалізованих інженерів. Юридичний відділ може описати логіку перевірки контрактів, операційна команда — логіку оновлення дашбордів, фінансовий департамент — логіку аналізу витрат. Але без спільної інфраструктури кожен із цих серверів перетворюється на окремий «проєкт із безпеки».
Anthropic прямо формулює: якщо підприємства не почнуть ставитися до MCP як до спільної інфраструктури, а не до колекції одноразових інтеграцій, протокол так і залишиться обмеженим кількома серверами на організацію. Це, у свою чергу, стримуватиме й потенціал агентів: кожен якісний MCP‑сервер теоретично може підсилювати всі агенти в компанії, але лише за умови, що його реально можна безпечно й масштабовано використовувати.
Єдина «благословенна» платформа як кореневий центр довіри
У відповідь на цей виклик Anthropic пропонує чітку інтуїцію: підприємствам потрібна одна «благословенна» платформа — єдиний кореневий центр довіри для всього, що стосується MCP. Саме її мають «освятити» команди безпеки, саме через неї мають проходити всі взаємодії між агентами й MCP‑серверами.
Ідея проста: у світі, де майже кожна команда потенційно може створювати MCP‑сервери, безпека не може масштабуватися через ручний контроль кожного окремого сервера. Натомість безпекові й інфраструктурні команди мають інвестувати в один платформенний шар, який стає єдиною довіреною точкою входу.
Ця платформа виконує кілька ролей одночасно. Вона централізує автентифікацію й авторизацію, підключаючись до корпоративного IdP і реалізуючи рольову модель доступу. Вона забезпечує спостережуваність: логування, метрики, аналітику використання MCP‑серверів. Вона відповідає за безпечне з’єднання між, можливо, недовіреними клієнтами й внутрішніми MCP‑серверами, які працюють із чутливими даними. Вона спрощує хостинг і деплоймент нових серверів.
У такій моделі команди безпеки перестають бути «вузьким горлечком», яке блокує кожен новий MCP‑сервер. Вони один раз визначають стандарти й політики на рівні платформи, а далі окремі команди можуть вільніше експериментувати, знаючи, що всі їхні сервери автоматично потрапляють під єдині правила.
Anthropic підкреслює: ті підприємства, які змогли побудувати таку платформу — як усередині самої компанії, так і серед клієнтів Anthropic, — значно швидше й глибше досліджують можливості MCP і, відповідно, агентів. Кожен новий сервер у такій архітектурі не створює додаткового хаосу, а навпаки, підсилює загальну екосистему.
MCP‑шлюз як практична форма цього контрольного шару
Практичним втіленням цієї «благословенної» платформи Anthropic бачить MCP‑шлюз — проміжний шар між MCP‑клієнтами (агентами, інтерфейсами на кшталт Claude.ai чи внутрішніми інструментами) та численними MCP‑серверами.
Концептуально MCP‑шлюз — це «чорна скринька», через яку проходить увесь трафік між клієнтами й серверами. Для клієнтів він виглядає як єдина точка доступу, для серверів — як єдиний довірений контрагент. Усередині ж він реалізує саме ті функції, яких бракує реєстрам і окремим MCP‑серверам.
По-перше, це автентифікація й авторизація. Шлюз інтегрується з корпоративною системою керування ідентичностями, дозволяє визначати ролі, політики доступу, делеговані ідентичності для користувачів і агентів. Anthropic очікує, що саме делегована ідентичність агентів стане одним із ключових питань найближчими роками, і розглядає шлюз як місце, де ці ідентичності визначаються й обмежуються.
По-друге, це маршрутизація й проксіювання. MCP‑клієнти бачать лише шлюз, а той уже розподіляє запити між внутрішніми MCP‑серверами, які довіряють лише йому. Це дозволяє централізовано контролювати, які клієнти можуть звертатися до яких серверів, і водночас приховувати внутрішню топологію.
По-третє, це безпечні тунелі. Шлюз забезпечує зашифровані, довірені з’єднання між, можливо, зовнішніми або частково недовіреними клієнтами й внутрішніми MCP‑серверами, які працюють із конфіденційними даними. Це критично для сценаріїв, де агенти розгорнуті поза периметром корпоративної мережі.
По-четверте, це внутрішній підреєстр MCP‑серверів. Шлюз може містити власний реєстр, який відображає саме ті сервери, що доступні в межах конкретної організації, з урахуванням їхніх політик доступу, версій, статусу.
По-п’яте, це допоміжні інструменти, зокрема CLI для роботи зі шлюзом. Наявність зручного інструментарію означає, що будь-яка команда в компанії може швидко створити й зареєструвати новий MCP‑сервер, не розбираючись у всіх деталях безпеки й інфраструктури: за них відповідає шлюз.
Ключова перевага такої архітектури в тому, що команди, які будують MCP‑сервери, можуть зосередитися на бізнес‑логіці. Юридичний відділ, який створює сервер для рев’ю контрактів, описує лише те, як саме має відбуватися аналіз, які правила застосовувати, як ескалювати складні випадки. Питання «хто має доступ», «як це логувати», «як це масштабувати», «як підключити нових агентів» — автоматично вирішуються на рівні шлюзу.
Це не просто зручність. У світі, де агенти й генеративні моделі стають повсякденним інструментом для все більшої кількості команд, саме така декомпозиція — коли бізнес‑логіка відділена від безпеки й інфраструктури — стає необхідною умовою масштабування.
Ідентичність агентів і майбутнє MCP в enterprise‑середовищі
Окремий аспект, на який звертає увагу Anthropic, — це ідентичність користувачів і агентів. Сьогодні більшість систем ідентичності орієнтовані на людей: співробітників, адміністраторів, сервісні акаунти. Але в міру того, як агенти стають автономнішими й отримують доступ до ширшого кола інструментів, постає питання: як саме визначати, обмежувати й аудіювати їхню ідентичність?
Anthropic очікує, що делегована ідентичність — коли агент діє від імені користувача або групи користувачів із чітко визначеними правами — стане одним із ключових викликів найближчих років. І MCP‑шлюз у цій картині виступає тим місцем, де ці ідентичності формалізуються: де визначається, які дії агент може виконувати, до яких MCP‑серверів звертатися, які дані читати чи змінювати.
Це ще один аргумент на користь того, що MCP‑інфраструктура в enterprise‑середовищі має бути централізованою на рівні контрольного шару, а не розпорошеною між окремими серверами. Без такого шару неможливо послідовно впроваджувати й еволюціонувати політики ідентичності для агентів.
Висновок: без спільної інфраструктури MCP не розкриє свій потенціал у корпораціях
Сьогодні MCP виглядає як один із найперспективніших стандартів для побудови агентних систем у підприємствах. Відкритий протокол, тисячі серверів у реєстрі, можливість швидко створювати нові інструменти — усе це створює враження готової до масштабування екосистеми.
Але практичний досвід великих компаній, із якими працює Карана Сампат як forward deployed engineer Anthropic, показує інше: більшість організацій не здатні вийти за межі кількох MCP‑серверів. І причина не в протоколі, а в тому, як саме вони намагаються його впроваджувати.
Поки MCP сприймається як набір окремих інтеграцій, а не як спільна інфраструктура, безпека, спостережуваність і контроль доступу залишатимуться фрагментованими. Кожен новий сервер вимагатиме непропорційних зусиль, а служби безпеки й далі виступатимуть вузьким горлечком, яке блокує масштаб.
Стратегічна відповідь Anthropic — заклик до підприємств будувати єдину «благословенну» платформу, кореневий центр довіри для MCP. У практичному вимірі це означає створення MCP‑шлюзу як проміжного шару, який централізує автентифікацію, авторизацію, спостережуваність, безпечне з’єднання й хостинг серверів.
Лише в такій архітектурі MCP може стати справжньою спільною інфраструктурою, де кожен новий сервер підсилює всю екосистему агентів у компанії, а не додає ще одну точку хаосу. І саме від того, наскільки швидко підприємства зможуть зробити цей крок, залежить, чи перетвориться MCP на базовий шар корпоративної AI‑інфраструктури, чи залишиться нішевим інструментом для поодиноких експериментів.