MCP-сервер може дати ШІ-помічнику доступ до пошти, файлів, CRM, бази даних, коду чи production-середовища. Тому його підключення — це не встановлення невинного плагіна, а допуск нової інтеграції до систем компанії.
Перевіряйте MCP-сервер до того, як видати йому справжній токен. З’ясуйте, хто його створив, які інструменти він реально відкриває, куди передає дані, від чийого імені діє, що бачить у системі та як його миттєво вимкнути. OAuth-вікно або популярний репозиторій самі по собі нічого цього не доводять.
Чому MCP потребує окремого аудиту безпеки
Model Context Protocol уніфікує підключення ШІ-застосунків до інструментів і даних. Це пришвидшує інтеграцію, але не переносить відповідальність на сам протокол. У офіційній моделі довіри MCP прямо зазначено: клієнт довіряє серверу, локальний сервер отримує доступи свого процесу, а вибір і налаштування сервера залишаються відповідальністю користувача або адміністратора.
У 2026 році ця тема стала значно практичнішою. Специфікація від 28 липня посилила авторизацію; OWASP випустив окремий посібник із захисту MCP-серверів; хмарні платформи документують ризики ланцюжків інструментів і prompt injection. Водночас опитування McKinsey про довіру до ШІ у 2026 році називає безпеку й ризики головною перешкодою для масштабування агентних систем.
Отже, перевіряти треба не слово MCP, а весь маршрут: пакет або віддалений сервіс, конфігурацію, облікові дані, описи інструментів, модель, клієнт, цільові API, журнали та процес реагування.
Спочатку намалюйте межу довіри
Сформулюйте бізнес-потребу одним реченням: хто користуватиметься з’єднанням, який результат потрібен і чому не вистачить прямого API, read-only експорту або вузької автоматизації. Далі позначте шлях від запиту людини до моделі, MCP-клієнта, сервера, бізнес-системи й зовнішнього адресата.
| Ділянка | Що з’ясувати | Який доказ зберегти |
|---|---|---|
| Постачання | Якому коду або сервісу довіряємо? | Видавець, версія, digest, залежності |
| Можливості | Що сервер читає, змінює, надсилає чи запускає? | Реєстр інструментів і тест поведінки |
| Ідентичність | Чиї повноваження доходять до цільової системи? | Audience, scopes, ролі, строк токена |
| Середовище | До чого має доступ процес? | Файли, мережа, змінні, дочірні процеси |
| Реагування | Чи можна пояснити й зупинити одну дію? | Кореляція журналів і план відкликання |
Призначте бізнес-власника і технічного власника. Зафіксуйте клас даних, найбільший можливий збиток, дату наступного перегляду та спосіб екстреного відключення. Якщо після запуску з’єднання не матиме власника, не варто переходити до production.
Перевірте автора, артефакт і шлях оновлення
Локальний MCP-сервер — це виконуване ПЗ. Команда встановлення може завантажувати пакети, виконувати lifecycle scripts, читати змінні середовища й успадковувати доступ до диска та мережі. Віддалений сервер зменшує частину локального ризику, але додає залежність від постачальника, ізоляції клієнтів, зберігання та видалення даних.
- Знайдіть канонічного видавця через офіційний сайт або верифіковану організацію. Схожа назва пакета — не підтвердження.
- Перегляньте вихідний код, ліцензію, security policy, активність розробників, історію релізів, зміну власників і відкриті інциденти.
- Зафіксуйте точну версію, lockfile і, де можливо, digest артефакту. Не встановлюйте неперевірене оновлення автоматично.
- Прочитайте install- та post-install-скрипти. Шукайте запуск shell, обхід каталогів, читання секретів, телеметрію й мережеві звернення.
- Запишіть усі домени, потрібні для встановлення, старту, авторизації, виклику інструментів, оновлень і діагностики. Незрозумілий трафік блокуйте.
Для SaaS-варіанта запросіть перелік subprocessors, регіон даних, строк зберігання, умови використання даних для навчання, ізоляцію tenant-ів, порядок повідомлення про інцидент, експорт і видалення. Відомий бренд не робить кожен новий MCP-інструмент доречним для ваших даних.
Зніміть фактичний реєстр інструментів
У чистому тестовому середовищі збережіть результат discovery. Для кожного tool запишіть опис, схему аргументів, цільовий API, читання, запис, зовнішній адресат, потрібну роль, оборотність, ліміти та правило погодження. Потім порівняйте обіцяне з реальною поведінкою.
Опис інструмента — частина поверхні атаки: модель читає його, коли обирає дію. Перевіряйте приховані, оманливі, надто загальні або сторонні інструкції. Після оновлення повторюйте discovery та сповіщайте про зміну назви, опису, схеми, ресурсу, prompt чи UI-шаблону.
Сервер: crm-mcp-prod
Версія: 2.4.1 + digest
Інструмент: create_follow_up
Читає: id ліда, власника, статус
Змінює: одне завдання; не редагує контакт
Адресат: лише корпоративна CRM
Ідентичність: окрема роль агента
Ліміт: 50 завдань/годину; одне на лід
Доказ: ініціатор, аргументи, policy, result id
Вимкнення: відкликати роль + прибрати з allowlistВіддавайте перевагу вузьким операціям на кшталт create_follow_up замість загального SQL, shell, браузера чи файлової системи. Якщо універсальний інструмент справді потрібний, вважайте його привілейованим. Матриця прав ШІ-агента допоможе визначити межі дій; цей аудит перевіряє, чи здатний конектор їх виконати.
Видайте окрему ідентичність і мінімальні права
Не кладіть довготривалі ключі у prompt, git-репозиторій, аргументи процесу або URL. Використовуйте сховище секретів і короткоживучі облікові дані, якщо система це підтримує. Окрема ідентичність сервера або агента дозволяє побачити його дії та відкликати доступ без блокування працівника.
Для віддаленого сервера перевірте реалізацію, а не лише наявність кнопки OAuth. Чинна специфікація авторизації MCP спирається на OAuth і metadata захищеного ресурсу. Настанови з безпеки 2026 року прямо забороняють token passthrough: сервер не має приймати токен, виданий для іншого ресурсу, й сліпо передавати його далі.
- На кожному запиті перевіряйте issuer, підпис, audience, строк дії, client, scopes і контекст користувача або workload.
- Розділіть токен доступу до MCP і credential для downstream API.
- Розведіть читання та запис. Звужуйте права до tenant, проєкту, репозиторію, каталогу, таблиці, типу запису, поля й операції.
- Використовуйте різні ідентичності для dev, test і production. Ніколи не тестуйте кандидата з production-admin.
- Перевірте expiry, revocation, звільнення працівника, зміну ролі, відкликання consent і спробу доступу до чужого tenant.
У концепції NIST 2026 року ідентифікація, авторизація, аудит, non-repudiation і протидія prompt injection розглядаються разом. У журналі мають залишитися і людина або процес, що започаткували дію, і агент, який її виконав.
Обмежте середовище виконання
Локального кандидата спершу запускайте без прав адміністратора в одноразовому середовищі. Монтуйте лише потрібні каталоги, бажано read-only. Передавайте тільки названі змінні середовища. Забороніть дочірні процеси, якщо вони не потрібні. Дозвольте вихідну мережу лише до відомих доменів; закрийте cloud metadata, локальні control sockets, сторонні внутрішні сервіси й довільний інтернет.
Офіційна модель MCP пояснює: stdio-клієнт навмисно запускає налаштований процес, і це не помилка протоколу. Безпека залежить від того, що може цей процес. Контейнер допоможе лише тоді, коли в нього не змонтовано чутливі каталоги або привілейований socket, він не працює як root і не має необмеженої мережі.
Для віддаленого сервера застосуйте власний API/egress gateway, якщо архітектура дозволяє. Встановіть ліміти на запити, паралельність, обсяг даних, витрати й кількість змін. Записи робіть ідемпотентними: timeout після успішної операції не повинен породжувати дубль.
Перевірте зловмисний контент і погані стани
Документація Google щодо безпеки MCP розділяє роботу з людським підтвердженням і автономний режим, але застерігає: людина теж може схвалити шкідливу дію через надмірну довіру. Погодження має показувати точний tool, адресата, аргументи, записи, джерело й наслідки.
До запуску програйте щонайменше такі сценарії:
- Лист, документ, ticket, сайт або рядок БД наказує агенту ігнорувати policy, розкрити секрет чи викликати інший tool.
- Сервер змінює опис або схему інструмента після первинного погодження.
- Два безпечні окремо tools утворюють небезпечний ланцюг: прочитати приватні дані й надіслати назовні.
- Аргумент містить path traversal, shell-символи, internal URL, завеликий payload або id іншого tenant.
- Запис виконався, але відповідь загубилася, і клієнт повторює запит.
- Токен прострочений, відкликаний, виданий не для цього audience або має зайві scopes.
- Сервер намагається непомітно звернутися до DNS, мережі, файлу, env чи subprocess.
Спершу працюйте в observe-only або draft mode, із синтетичними даними й canary-записами. Заборонена дія має закінчитися відмовою, відповідальна людина — отримати alert, а бізнес-процес — мати ручний резервний шлях.
Журнал має пояснювати не лише HTTP 200
Зберігайте ініціатора, версію агента і сервера, доступний набір tools, обраний tool, очищені аргументи, рішення policy, погодження, downstream-ідентичність, результат, фактичну зміну й correlation id. Захистіть журнал від агента, якого він описує, і не записуйте зайві персональні дані або секрети.
У матеріалі про безпечну експлуатацію coding agents OpenAI описує поєднання системних сигналів з agent-native telemetry: prompts, рішення про погодження, результати tools, використання MCP і рішення мережевої політики. Це корисний принцип незалежно від конкретної платформи.
Сповіщайте про перше звернення до чутливого джерела, новий tool, зміну scopes, незвичний обсяг, новий адресат, серію відмов, схожий на секрет output або спробу вимкнути журналювання. Для машинної швидкості квартального звіту замало.
Зафіксуйте: дозволити, обмежити або відхилити
| Рішення | Коли доречне | Що далі |
|---|---|---|
| Дозволити | Відоме джерело, вузькі tools, окрема роль, ізоляція й пройдені тести | Зафіксувати версію, стежити за drift, призначити review |
| Обмежити | Користь є, доказів або контролів бракує | Read-only, тестові дані, жодних зовнішніх дій |
| Відхилити | Невідомий видавець, зайвий доступ, admin token, слабкі логи, немає revocation | Прямий API, експорт або інший сервер |
Разом із рішенням збережіть manifest можливостей, результати тестів, відомі обмеження, власників, строк дії дозволу, правила оновлення і kill procedure. Зміна сервера, клієнта, моделі, scopes, API або власника автоматично запускає повторний перегляд.
Це не сертифікація й не обіцянка нульового ризику. Мета — зменшити повноваження, зробити зміни видимими, спіймати передбачувані відмови й підготувати швидке стримування інциденту.
Поширені запитання
Чи небезпечний сам протокол MCP?
Ні. MCP має явну модель довіри й актуальні рекомендації з безпеки. Ризик визначають конкретні сервер, клієнт, конфігурація, права, модель, downstream-системи та експлуатація.
Локальний MCP-сервер безпечніший за віддалений?
Не обов’язково. Локальний процес може бачити файли, env і мережу вашого комп’ютера. Віддалений сервіс додає ризики постачальника, tenant-ізоляції та retention. Порівнюйте реальні межі.
Чи достатньо OAuth?
OAuth допомагає делегувати доступ лише за правильної перевірки issuer, audience, scopes, redirect і токенів. Він не доводить безпечність коду, tools, runtime, prompt injection або журналів.
Чи погоджувати кожен виклик tool з людиною?
Ні. Людина потрібна для істотних або нетипових наслідків. Вузькі оборотні дії можна дозволити в детермінованих межах, а заборонене слід блокувати кодом.
Яка найшвидша корисна перевірка?
До введення токена підтвердьте видавця, зніміть список tools, позначте читання й записи, перевірте інсталяцію та мережу, запустіть із синтетичними даними й мінімальними правами, подайте ворожий input, перегляньте логи та відкличте доступ одним кроком.
Джерела й дата перевірки
Перевірено 16 вересня 2026 року за моделлю довіри MCP, настановами з безпеки 2026 й оглядом специфікації від 28 липня; посібником OWASP; рекомендаціями Google; концепцією NIST щодо ідентичності агентів; і практикою agent-native telemetry OpenAI.
Rendframe може інвентаризувати MCP-з’єднання, перевірити сервер, спроєктувати обмежений gateway, підготувати негативні тести й під’єднати журнали до реагування. Спершу визначте повноваження через матрицю прав ШІ-агента, потім перегляньте послугу автоматизації з ШІ або надішліть нам сервер, сценарій і запропоновані права.