MCP, або Model Context Protocol, це відкритий стандарт, через який ШІ-агент підключається до робочих систем компанії: пошти, документів, CRM, бази даних. Система відкривається агентові через MCP-сервер, а застосунок з ШІ виступає клієнтом, який цим доступом користується. Конектор економить години ручної роботи, але агент отримує рівно ті права, які йому видали, і користується ними щоразу, коли цього вимагає завдання. Тому перед підключенням керівник перевіряє кілька речей: хто зробив і підтримує конектор, які дії він дозволяє, від чийого облікового запису працює агент, чи ведеться журнал дій, чи потрібне підтвердження людини для ризикових кроків і як швидко можна відкликати доступ.
Коротко
- MCP є відкритим стандартом підключення ШІ-агентів до робочих систем, який компанія Anthropic оприлюднила 25 листопада 2024 року.
- З 9 грудня 2025 року стандарт перебуває у фонді Agentic AI Foundation під Linux Foundation і розвивається спільнотою.
- Агент через конектор отримує ті права, які йому видали, тому рівень ризику визначають набір дозволених дій і обліковий запис, від імені якого агент працює.
- Чинна специфікація описує авторизацію на основі OAuth 2.1, але формально не вимагає її, тому наявність авторизації треба перевіряти в кожного конектора окремо.
- 3 листопада 2026 року CrowdStrike оголосила угоду про придбання Fiddler AI, компанії, що стежить за діями ШІ-агентів, і нагляд за агентами став окремою задачею безпеки.
Що таке MCP і навіщо ШІ-агентові конектори до робочих систем?
ШІ-агентом називають програму на основі мовної моделі, яка самостійно виконує завдання: читає листи, шукає документи, оновлює записи в базі клієнтів. Без доступу до робочих систем така програма бачить лише те, що людина вставила у вікно чату, і кожну відповідь доводиться переносити в робочу систему вручну. Конектор закриває цей розрив. Він є підключенням, через яке агент дістає дані з потрібної системи і виконує в ній дії. Раніше кожен розробник будував таке підключення по-своєму, і для кожної пари застосунку та системи доводилось писати окремий код. MCP, Model Context Protocol, задає спільні правила такого зʼєднання, тож один конектор до системи можуть використовувати різні застосунки з ШІ.
Стандарт відкрила компанія Anthropic 25 листопада 2024 року як відкритий спосіб підключати ШІ-асистентів до систем, де зберігаються дані. 9 грудня 2025 року Anthropic передала MCP фонду Agentic AI Foundation, що працює під Linux Foundation, і відтоді стандарт розвиває спільнота. Для керівника з цього випливає практичний наслідок. Конектори до пошти, документів, CRM чи бази даних пишуть багато різних команд, від великих постачальників до окремих розробників, і якість їхньої роботи різна. Відкритий стандарт полегшує підключення, а відповідальність за вибір конкретного конектора лишається на компанії, яка його встановлює.
Як працює підключення через MCP-сервер і MCP-клієнт без технічних подробиць?
У кожному підключенні є дві сторони. MCP-сервер стоїть біля робочої системи і відкриває назовні певний набір даних і дій, наприклад пошук листів, читання договору або створення угоди в CRM. MCP-клієнт працює всередині застосунку з ШІ, запитує в сервера, які дії доступні, і викликає їх, коли агентові це потрібно для завдання. Агент може виконувати лише ті дії, які сервер відкрив. Усі відкриті дії він виконує без додаткових запитань, якщо в налаштуваннях окремо не передбачено підтвердження людиною.
Друге важливе питання стосується того, чиїми правами користується сервер. Коли конектор підключають, сервер отримує доступ до системи через певний обліковий запис: працівника, керівника або окремий службовий запис. Для мережевих підключень чинна специфікація описує авторизацію на основі OAuth 2.1, тобто стандартного механізму, за яким користувач дозволяє застосунку діяти від свого імені в межах погоджених прав і не передає йому свій пароль. Ця частина специфікації формально необовʼязкова. Тому конектор може бути зроблений без неї, і наявність та налаштування авторизації треба перевіряти щоразу, коли компанія підключає новий конектор.
Які ризики виникають, коли агент отримує доступ до пошти, документів чи CRM?
Перший ризик повʼязаний із зайвими правами. Конектор, створений для читання пошти, може за замовчуванням дозволяти також надсилання, пересилання і видалення листів. Якщо агент працює від облікового запису керівника, він бачить усе листування керівника, зокрема фінансові умови, кадрові питання і листи від юристів. Помилка у формулюванні завдання або в розумінні запиту тоді обертається листом, відправленим не тому адресатові, або видаленим документом.
Другий ризик полягає в чужих інструкціях. Агент читає вміст листів, документів і вебсторінок, а в цьому вмісті може бути прихований текст, складений так, щоб агент сприйняв його як команду. Таку атаку називають впровадженням інструкцій. Вона найнебезпечніша тоді, коли агент має право писати, надсилати чи змінювати записи, бо прочитана чужа вказівка може перетворитися на реальну дію в системі.
Третій ризик стосується постачальника. Сервер конектора може працювати на інфраструктурі сторонньої команди, і тоді дані компанії проходять через чужі сервери. Якщо конектор ніхто не оновлює, вразливості в ньому лишаються відкритими. Четвертий ризик найменш помітний, і це відсутність сліду. Коли дії агента ніде не записані, після інциденту неможливо встановити, що саме він прочитав, що змінив і на чий запит. Підключення агента до систем з персональними даними клієнтів і працівників варто погодити з юристом компанії: цей текст є загальною навчальною інформацією.
Які права доступу варто дати агентові на старті?
Базове правило називають принципом найменших привілеїв: агент отримує мінімальний набір прав, достатній для конкретного завдання, і нічого понад це. На старті найбезпечніше обмежитися читанням. Агент, який лише читає пошту, документи і записи CRM, вже здатен готувати зведення, шукати потрібні договори і складати чернетки відповідей, які людина перевірить і надішле сама. Право запису додають пізніше, окремим рішенням і лише для тих дій, де видно користь і зрозуміло, як перевірити результат. Право видалення агентові на старті майже ніколи не потрібне.
Друге рішення стосується облікового запису. Агентові не варто працювати від імені власника чи фінансового директора з повним доступом до всього. Краще створити окремий службовий запис під агента з доступом лише до потрібних папок, скриньок і розділів CRM. Так межі прав видно в налаштуваннях системи, а дії агента відрізняються від дій людей у журналах. Третє рішення стосується обсягу даних: якщо агентові для задачі потрібна одна спільна скринька відділу продажів, підключайте саме її і залишайте особисті скриньки працівників поза доступом. Четверте рішення стосується строку: доступ варто видавати на визначений період і переглядати при кожній зміні задачі агента.
Чому журнал дій і підтвердження людиною потрібні до запуску агента?
Журнал дій фіксує кожен виклик інструмента: коли агент звернувся до системи, яку дію виконав, з якими даними і за чиїм запитом. Без такого журналу компанія не може розслідувати інцидент, пояснити клієнтові чи перевіряльникові, що сталося з даними, і відрізнити помилку агента від помилки людини. Налаштовувати журнал після першого інциденту запізно, бо саме той інцидент у ньому вже не відобразиться. Тому перевірка журналу входить у підготовку до запуску поряд із перевіркою прав.
Підтвердження людиною означає, що агент готує дію, а виконує її лише після згоди відповідальної людини. Його ставлять на кроки, які важко або неможливо відкотити: надсилання листа зовнішньому адресатові, зміну суми чи статусу угоди в CRM, видалення файлів, оплату, надання доступу третім особам. Решту дій, наприклад пошук і читання, агент виконує сам. Так підтвердження лишається рідкісною і помітною подією, і людина читає зміст дії перед згодою, замість того щоб натискати кнопку за звичкою.
Ринок безпеки вже відповідає на цю задачу окремими продуктами. 3 листопада 2026 року CrowdStrike оголосила остаточну угоду про придбання Fiddler AI, компанії, яка перевіряє агента до запуску, відстежує його рішення і виклики інструментів, виявляє відхилення в поведінці та веде журнал дій для аудиту. Ціну угоди не розкрито. Для керівника цей факт означає, що нагляд за агентами вже став окремою задачею безпеки, яку планують і фінансують так само, як захист пошти чи облікових записів.
Що спитати постачальника конектора перед закупівлею?
Перше питання стосується походження: хто розробив конектор, хто відповідає за його підтримку, як часто виходять оновлення і як постачальник повідомляє про знайдені вразливості. Конектор від невідомого автора без історії оновлень несе більший ризик, навіть якщо він безкоштовний і швидко встановлюється. Друге питання стосується переліку дій: попросіть повний список того, що конектор вміє робити в системі, і зʼясуйте, чи можна вимкнути запис і видалення, залишивши лише читання.
Третє питання стосується авторизації. Уточніть, чи використовує конектор OAuth 2.1 для мережевих підключень, від чийого облікового запису працюватиме агент і чи можна обмежити його права службовим записом. Четверте питання стосується даних: де фізично працює сервер, чи проходять дані компанії через інфраструктуру постачальника, чи зберігаються вони там і як довго. Пʼяте питання стосується контролю: чи веде конектор журнал дій, чи можна вивантажити цей журнал у власну систему аудиту і чи підтримує конектор підтвердження людиною для ризикових дій.
Шосте питання стосується виходу. Зʼясуйте, як швидко можна відкликати доступ агента, чи діє відкликання одразу для всіх відкритих сеансів і що відбувається з даними компанії після завершення договору. Відповіді на ці питання постачальник має дати письмово до підписання, бо після підключення змінити умови доступу значно складніше. Якщо на частину питань відповіді немає, починайте з пробного запуску на тестових даних і розширюйте доступ лише після того, як отримаєте відповіді.
Що робити далі
- Складіть перелік усіх конекторів і ШІ-агентів, які вже підключені в компанії, разом із системами, до яких вони мають доступ.
- Створіть для кожного агента окремий службовий обліковий запис і залиште на старті лише право читання.
- Визначте дії, які агент не виконує без підтвердження людини, і налаштуйте це підтвердження до запуску.
- Перевірте, що журнал дій кожного конектора ввімкнений, зберігається в компанії і доступний людині, яка відповідає за безпеку.
- Опишіть порядок відкликання доступу і відпрацюйте його на пробному запуску, щоб у разі інциденту вимкнути агента за лічені хвилини.