MCP доводить агента до API, але не вирішує доступ на рівні полів сам

2026 року, 29 вересня, на The New Stack опубліковано статтю засновника Apollo GraphQL Метта Дебергаліса: сьогодні під'єднати систему через MCP легко, але те, що агент може побачити після з'єднання, MCP сам не вирішує.

Доступність сьогодні легка, а видимість — ні

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

Зробити внутрішній API доступним для агента можна, побудувавши MCP-сервер, але складне питання — на що він має право дивитися після підключення.

Чому очевидні рішення не розв'язують проблему

API керування замовленнями може повертати значно більше, ніж статус замовлення: персональні дані, фінансові деталі та дані про шахрайство, а також операційну інформацію, яка не повинна виходити за межі довіреної мережі. У звичайному застосунку це вирішує сервер: перевіряє права й повертає лише відповідне подання.

Агент ламає цю схему: інструмент, який передає все із зовнішньої системи, є ризиком безпеки. А фільтрування відповіді створює другу проблему: фінансовому відділу потрібне інше подання замовлень, підтримці — частина внутрішніх нотаток, інша команда під'єднує систему запасів, і накопичуються десятки дублювальних інструментів.

Контракт на рівні полів

Рішення, на думку автора, — контракт на рівні полів, який точно визначає, що може бачити й що робити кожен агент. MCP визначає виявлення та виклик інструментів, а контракт — межі доступу; потрібні обидва шари.

Як практичний шлях автор пропонує GraphQL: запит містить лише потрібні поля, наприклад status і shipBy, і у відповіді повертаються тільки вони. Якщо агент запитує чутливе поле, як-от internalFraudScore або customerSSN, сервер може відхилити запит або зробити ці поля недоступними. Правило належить самому полю.

Запис працює так само: лише право на читання не дозволить виконати роботу, а необмежений доступ дасть агенту змогу змінити запас, скасувати замовлення або повернути кошти. Окрема бізнес-дія, наприклад requestInventoryTransfer, постає як окрема операція: права перевіряють під час запуску, а наявність запасу й потрібні погодження перевіряє базовий сервіс. Змінювати бізнес-API не потрібно: шар ставиться поверх наявних REST, gRPC або SOAP сервісів.

Що це означає на практиці

Рекомендація не нейтральна: автор керує компанією-виробником GraphQL. Сам аргумент працює незалежно від конкретного інструмента: доступ агента потребує окремої, чітко визначеної межі між API та інструментом, на рівні кожного поля й кожної дії. За словами автора, такий контракт понад десять років працює в реальних системах і обслуговує мільярди транзакцій у компаніях, як-от Shopify, Netflix, Airbnb, Expedia Group і Walmart.