Пояснення безпеки MCP #
Протокол контексту моделі не з'явився з попередженням про безпеку. Він з'явився як прорив у продуктивності, standard що дозволяє помічникам зі штучним інтелектом виходити за межі вікна чату та безпосередньо взаємодіяти з інструментами, файлами, API та pipelines. На той час, коли команди безпеки почали запитувати, що таке MCP, він уже працював у середовищах розробників у великих масштабах.
Цей розрив між впровадженням та управлінням є саме тим, куди потрапляють атаки на ланцюги поставок. Розуміння того, що таке протокол контексту моделі, як працюють сервери MCP та які ризики вони створюють, тепер є важливим. основна вимога для будь-якої команди DevSecOps, що працює в середовищі, нативному для штучного інтелекту.
Що таке протокол контексту моделі? Визначення #
Протокол контексту моделі (MCP) – це відкритий standard що визначає, як великі мовні моделі взаємодіють із зовнішніми інструментами, джерелами даних та сервісами. Там, де традиційний помічник на базі штучного інтелекту відповідає лише текстом, помічник із підтримкою MCP може виконувати дії (читати файли, запитувати API, виконувати команди, встановлювати залежності та взаємодіяти з CI/CD pipelines) через структурований інтерфейс, який з'єднує модель із середовищем розробника.
Протокол MCP був представлений Anthropic у листопаді 2024 року і з того часу був прийнятий в основних інструментах кодування штучного інтелекту, включаючи Claude, Cursor, Windsurf та GitHub Copilot. Він забезпечує спільну мову для зв'язку між штучним інтелектом та інструментами, подібно до того, як HTTP забезпечує спільний протокол для веб-спілкування.
Якщо помічником ШІ є мозок, то сервер MCP — це нервова система, яка з'єднує його з корпусом інструментів розробника.
Як це працює? #
MCP працює за принципом клієнт-серверної архітектури з трьома компонентами:
- Ведучий MCP це програма, в якій працює розробник, IDE, як-от VS Code, Cursor або Windsurf, або помічник штучного інтелекту, як-от Claude. Хост керує підключеннями до серверів MCP та контролює, до чого модель може отримати доступ.
- Клієнт MCP знаходиться всередині хоста та підтримує взаємне з'єднання з кожним MCP-сервером. Він перетворює запити моделі на структуровані виклики інструментів та повертає результати моделі.
- Сервер MCP є містом до зовнішніх можливостей. Він надає інструменти, ресурси та підказки, які може викликати модель. Сервер MCP може підключатися до файлової системи, репозиторію GitHub, бази даних, CI/CD платформа або сканер безпеки. Кожен виклик інструменту, який здійснює модель, проходить через MCP-сервер, який виконує його та повертає результат.
Коли розробник просить помічника штучного інтелекту просканувати проект, виправити вразливість або встановити залежність, модель не виконує ці дії безпосередньо. Вона надсилає структурований запит на відповідний MCP-сервер, який виконує дію за допомогою авторизованих локальних інструментів і повертає результат.
MCP проти традиційних помічників зі штучним інтелектом: що змінилося? #
До появи MCP помічники з кодування на основі штучного інтелекту були принципово пасивними. Вони могли читати код, який ви вставляли в чат, і пропонувати зміни, але не могли безпосередньо впливати на ваше середовище. MCP повністю змінює цю модель.
Ця різниця важлива для безпеки, оскільки вона змінює можливості помічника зі штучним інтелектом. Традиційний помічник, який дає погані поради, коштує вам циклу перевірки коду. Помічник із підтримкою MCP, який виконує неправильну дію (встановлення шкідливої залежності, виконання скомпрометованого скрипта збірки або пересилання облікових даних на зовнішню кінцеву точку), коштує вам інциденту.
MCP перетворює помічників зі штучним інтелектом з радників на операторів. Цей перехід вимагає тих самих заходів безпеки, які ви застосовуєте до будь-якого оператора з доступом до вашої інфраструктури.
Що таке MCP-сервер? #
МКП сервер — це легкий процес, який надає можливості до MCP-сумісних клієнтів штучного інтелекту. Він визначає набір інструментів (дискретних дій, які може викликати модель), а також ресурсів, які модель може зчитувати, та шаблонів запитів, які вона може використовувати.
Сервери MCP існують для широкого спектру інтеграцій: доступ до файлової системи, GitHub, Slack, бази даних, сканери безпеки та CI/CD платформи. Розробники можуть запускати MCP-сервери локально, в межах інфраструктури своєї організації, або підключатися до MCP-серверів сторонніх розробників, що надаються зовнішніми постачальниками.
Саме в останній категорії ризик безпеки стає конкретним. Сторонній MCP-сервер – це зовнішній процес із доступом до середовища розробника. Дослідження показують, що 5.5% публічних MCP-серверів мають вразливості, що призводять до отруєння інструментів, а 43% – до вразливостей, що призводять до впровадження команд, а це означає, що значну частину публічно доступних MCP-серверів можна використовувати як зброю для маніпулювання поведінкою ШІ, викрадання даних або виконання несанкціонованих команд.
Ризики безпеки MCP: що потрібно знати командам DevSecOps #
MCP представляє нову поверхню для атаки, яку традиційні інструменти AppSec не могли покрити. Ключові ризики:
Тіньові MCP-сервери. Розробники налаштовують MCP-сервери локально без офіційного схвалення чи управління, створюючи прогалину в інвентарі. Служби безпеки не можуть захистити те, що вони не бачать.
Отруєння інструментами. Шкідливий MCP-сервер розкриває інструменти, які здаються легітимними, але виконують шкідливі дії, коли їх викликає модель. Оскільки модель довіряє отриманим визначенням інструментів, вона може викликати заражений інструмент без будь-яких видимих ознак того, що щось не так.
Негайне введення через MCP. Шкідливий контент у файлах, документах або відповідях API може впроваджувати інструкції в контекст моделі, маніпулюючи її поведінкою. Сервер MCP, який зчитує зовнішній контент і передає його моделі без очищення, є вектором прямого впровадження запиту.
Зміна залежностей. Сервери MCP, які керують встановленням пакетів або вирішенням залежностей, можуть бути скомпрометовані для встановлення шкідливих пакетів. Коли агент штучного інтелекту встановлює залежність автономно через сервер MCP, між шкідливим пакетом та його компонентом немає людини-переглядача. pipeline.
Розкриття довіреності. Сервери MCP часто обробляють токени автентифікації, ключі API та змінні середовища. Незахищена конфігурація MCP може розкрити ці облікові дані через контекст моделі або через журнали.
Несанкціоноване виконання інструменту. Без суворих списків дозволених дій помічник із підтримкою MCP може викликати інструменти, що виходять за межі його цільової області застосування, змінювати виробничу інфраструктуру, отримувати доступ до конфіденційних репозиторіїв або здійснювати виклики API до зовнішніх служб.
Найкращі методи безпеки #
Для забезпечення безпеки MCP кожен MCP-сервер потрібно розглядати як привілейовану інтеграцію, а не як зручність для розробників.
- Блокуйте шкідливі залежності на кінцевій точці. Коли агент із підтримкою MCP встановлює залежність, цю інсталяцію слід перехопити та просканувати перед виконанням. Виявлення на основі сигнатур недостатньо; шкідливі пакети, спрямовані на інструменти штучного інтелекту, публікуються швидше, ніж сигнатури можуть їх відстежувати.
- Інвентаризуйте кожен MCP-сервер. Дізнайтеся, які MCP-сервери налаштовані у ваших середовищах розробника, локально, у вашому CI/CD pipelines, а також у ваших конфігураціях IDE. Тіньовий MCP — це та ж проблема, що й тіньова ІТ, з прямим доступом до ваших інструментів.
- Застосувати білий список MCP. Дозволено роботу лише схвалених MCP-серверів. Будь-який несхвалений сервер, який намагається підключитися, слід блокувати на кінцевій точці, перш ніж він зможе взаємодіяти з моделлю.
- Застосувати найменші привілеї до визначень інструментів MCP. Кожен MCP-сервер повинен надавати лише ті інструменти, які необхідні для його конкретної функції. Сервер читання файлів не має права надавати можливості встановлення пакетів.
- Перевіряти та очищувати контент, що проходить через MCP. Будь-який зовнішній контент (файли, відповіді API, результати бази даних), який проходить через MCP-сервер і потрапляє в контекст моделі, є потенційним вектором впровадження запиту. Розглядайте його як ненадійний вхід.
- Моніторинг взаємодій MCP під час виконання. Реєструйте кожен виклик інструменту, який модель здійснює через сервери MCP. Аномальні закономірності (неочікувані виклики інструментів, вихідні з'єднання із середовищ збірки, виклики інструментів поза звичайним робочим часом) є ранніми ознаками компрометації.
Реальні інциденти безпеки #
Безпека MCP не є теоретичною. На початку 2026 року дослідження, проведене в Університеті Квінз, задокументувало, що стеки MCP мають 92% ймовірність експлойту коли поєднується кілька плагінів. Кампанія PromptMink (яку приписують північнокорейській державній групі Famous Chollima) спеціально розробила шкідливі npm-пакети, щоб обманом змусити агентів кодування ШІ, які працюють через інтерфейси, подібні до MCP, встановити шкідливе програмне забезпечення для крадіжки облікових даних. Пакети були розроблені таким чином, щоб агенти ШІ виглядали справжніми, навіть якщо людина-рецензент позначила б їх.
У червні 2026, Xygeni підтвердив кластери ollama-helpers та openai-agents-helpers (понад 35 об'єднаних версій, опублікованих у скоординованих хвилях), безпосередньо спрямованих на пакети, що використовуються в робочих процесах агентної розробки, де поширені MCP-з'єднання. Коли агент штучного інтелекту встановлює залежність автономно через MCP-сервер, між шкідливим пакетом та його виконанням немає людини-переглядача.
Що таке MCP у контексті безпеки ланцюга поставок штучного інтелекту? #
MCP знаходиться на перетині безпеки штучного інтелекту та software supply chain securityЦе рівень, який з'єднує моделі штучного інтелекту з інструментами, репозиторіями та інфраструктурою, що визначають сучасний... SDLC, що робить його одночасно найпотужнішою точкою інтеграції та найбільш вразливою поверхнею для атак у розробці на основі штучного інтелекту.
Традиційна AppSec зупиняється на рівні репозиторію. EDR стежить за операційною системою. Жоден з них не був створений для розуміння MCP-серверів, викликів інструментів або встановлення залежностей за допомогою штучного інтелекту. Розрив між ними — це саме те місце, де потрапляють атаки на основі MCP.
Для забезпечення безпеки MCP потрібне розуміння того, які сервери MCP працюють, які інструменти вони надають, що викликає модель та чи були перевірені залежності та файли, що обробляються. Це означає об'єднання інвентаризації за допомогою штучного інтелекту, моніторингу поведінки та безпеки ланцюга поставок в одну проблему.
Забезпечення безпеки MCP за допомогою Xygeni
#
Безпека MCP вимагає більше, ніж просто документів політики та контрольних списків найкращих практик. Вона вимагає постійного контролю над тим, що працює на серверах MCP у ваших середовищах розробника, поведінкового моніторингу кожного виклику інструменту, який виконує модель, та можливості блокувати шкідливі залежності на кінцевій точці до їх виконання, до появи сигнатури. Розуміння того, що таке протокол контексту моделі, є ключовим.
Платформа безпеки на основі штучного інтелекту від Xygeni охоплює повну поверхню атаки MCP: інвентаризація кожного сервера MCP за допомогою AI-SPM, виявлення отруєння інструментів, оперативного впровадження та незахищених конфігурацій MCP за допомогою сканування безпеки AI відповідно до OWASP MCP Top 10 та забезпечення дотримання політики на кінцевій точці розробника через Shield, блокуючи несанкціоновані MCP-сервери та шкідливі залежності, перш ніж вони досягнуть pipeline.
Якщо ваші команди використовують помічників кодування на основі штучного інтелекту, рівень MCP вже є частиною вашої поверхні атаки. Питання в тому, чи бачите ви його.

FAQ #
MCP (Model Context Protocol) – це відкритий standard що дозволяє помічникам ШІ взаємодіяти із зовнішніми інструментами, джерелами даних та сервісами. Це дає змогу моделям ШІ виконувати дії (читати файли, запитувати API, встановлювати пакети, виконувати команди) через структурований інтерфейс, а не відповідати лише текстом.
Дослідження показують, що MCP створює значні ризики для безпеки, якщо його не регулювати належним чином. 5.5% публічних MCP-серверів мають вразливості, що отруюють інструменти, а 43% — вразливості, що дозволяють впроваджувати команди.Для забезпечення безпеки MCP потрібне інвентаризація кожного сервера MCP, забезпечення дотримання списків дозволених ресурсів, застосування мінімальних привілеїв та моніторинг викликів інструментів під час виконання.
Традиційний API викликається кодом, який пише та контролює розробник. Виклики інструментів MCP викликаються моделлю штучного інтелекту на основі її інтерпретації завдання. Модель вирішує, які інструменти викликати, в якому порядку та з якими параметрами, що ускладнює прогнозування та аудит взаємодій MCP, ніж традиційних викликів API.
Отруєння інструментів – це атака, під час якої шкідливий MCP-сервер розкриває визначення інструментів, які здаються легітимними, але виконують шкідливі дії під час виклику моделлю. Оскільки модель довіряє визначенням інструментів, які вона отримує від підключених MCP-серверів, вона може викликати отруєний інструмент без будь-якого видимого попередження.
Запит на впровадження через MCP відбувається, коли шкідливий контент у файлах, документах або відповідях API (переданих через сервер MCP у контекст моделі) маніпулює поведінкою моделі. Це еквівалент SQL-впровадження через MCP: ненадійний вхід, що впливає на поведінку довіреної системи.
