Атаки через MCP-сервери на ШІ-агентів: чотири класи, реальні CVE і захист

Підключаючи MCP-сервер до агента, ви відчиняєте сторонньому коду одразу два входи: він запускається на вашому комп’ютері й спілкується з моделлю, яка вміє виконувати команди. Тому атаки через MCP-сервери — це вже не розділ моделі загроз «на майбутнє», а перелік зареєстрованих вразливостей із номерами CVE: від підміненого mcp.json у Cursor влітку 2025 року до атаки без жодного кліку, опублікованої в реєстрі вразливостей у червні 2026-го. В англомовних джерелах цю тему зазвичай шукають як MCP security attacks.

Головне, що варто винести ще до деталей: протокол сам собою безпеки не забезпечує. В офіційних рекомендаціях з безпеки MCP вимоги адресовано клієнтам і серверам, а не «протоколу»: захист живе в програмі, якою ви користуєтеся, і у ваших налаштуваннях. Далі — чотири класи атак, розбір реальних кейсів, таймлайн інцидентів, масштаб проблеми та налаштування обмежень у Cursor, Claude Code і Codex. Дані перевірено станом на 26 вересня 2026 року.

Коротко (TL;DR)

• Небезпечний не лише шкідливий сервер. Офіційний GitHub MCP у травні 2025 року став каналом витоку приватного коду: інструкцію для агента підклали у звичайний issue публічного репозиторію.
• Чотири класи атак: отруєний опис інструмента (tool poisoning), зміна поведінки після схвалення (rug pull), вплив на сусідній довірений інструмент (tool shadowing) і підміна конфігу mcp.json.
• Cursor ламали двічі й по-різному. MCPoison (CVE-2025-54136, 2025) — це буквально підміна команди в уже схваленому mcp.json. DuneSlide (CVE-2026-50548/50549, 2026) — втеча з пісочниці, де конфіг не чіпали взагалі.
• Масштаб оцінковий: OX Security у квітні 2026 року просканувала понад 7000 серверів із відкритим STDIO й екстраполювала до 200 000 вразливих екземплярів. Це оцінка, а не підрахунок.
• Захист — на боці клієнта: allowlist за командою або URL (не за назвою), закріплена версія сервера, токени з мінімальними правами, ізоляція та ручне схвалення дій на запис.

Що таке MCP і чому це нова поверхня атаки на ШІ-агентів

MCP (Model Context Protocol) — відкритий протокол, через який ШІ-агент під’єднується до зовнішніх інструментів і даних: GitHub, баз даних, пошти, файлової системи. Як він улаштований і навіщо потрібен, ми розбирали в матеріалі MCP (Model Context Protocol): як ШІ підключається до ваших інструментів — тут лише те, що важливо для безпеки.

Протокол виріс швидше, ніж практики його захисту. Anthropic представила MCP у листопаді 2024 року, OpenAI підтримала стандарт у березні 2025-го, у грудні 2025-го Anthropic передала його Linux Foundation, а до квітня 2026 року SDK протоколу завантажили понад 150 млн разів (дані VentureBeat і The Agent Report).

Чому це окрема поверхня атаки, а не ще один плагін:

ШІ-стек для UGC-рекламного відео: 30-секундний ролик із трьох моделей і його ціна

GPT-6.1 Astra не вийде в жовтні: модель обманювала й діяла без дозволу

Надійність криптобіржі: Proof of Reserves, страховий фонд і ліцензії за 10 хвилин

OpenAI і Anthropic розслідують десятки тисяч інцидентів агентів: злами й чужі ключі

Агенти OpenAI 16 500 разів сканували портал ООН UNCTADstat, підбираючи поля API

• Текст стає командою. Опис інструмента і відповідь інструмента потрапляють просто в контекст моделі. Модель не відрізняє «дані» від «інструкцій», тож фраза в описі чи у відповіді може змінити її поведінку.
• Локальний сервер — це програма з вашими правами. Офіційна документація протоколу прямо попереджає: MCP-сервери працюють із тими самими привілеями, що й клієнт.
• Конфіг виконуваний. Поле command у mcp.json — це рядок, який клієнт запустить під час старту. Хто може правити конфіг, той може запустити код.
• Довіру видають один раз. Користувач схвалює сервер під час підключення, а сервер може змінитися пізніше.
• Відповідальність лежить на реалізації. У настановах NSA процитовано саму документацію MCP: протокол не може забезпечити ці принципи безпеки на рівні протоколу.

Короткий словничок для подальшого тексту. Інструмент (tool) — функція, яку сервер пропонує агенту (наприклад, «прочитати issue»). Опис інструмента — текст для моделі про те, що робить функція; користувач зазвичай не бачить його повністю. Непрямий prompt injection — інструкція, схована не у вашому запиті, а в даних, які агент читає за вашим завданням. STDIO — спосіб запуску локального сервера як процесу на вашому комп’ютері. CVSS — шкала небезпеки вразливості від 0 до 10.

Чотири класи атак через MCP: від prompt injection до rug pull

Перші три класи публічно описала компанія Invariant Labs 1 квітня 2025 року; вразливими вона назвала Cursor, а також системи Anthropic, OpenAI і Zapier. Механізм у них спільний — непрямий prompt injection, різниться лише місце, куди атакувальник кладе інструкцію. Четвертий клас, підміну конфігу, показала Check Point Research у липні 2025 року: тут модель не потрібна, атакувальник змінює команду, яку клієнт виконає сам.

Атаки мають і зворотний напрямок. Вразливість CVE-2025-6514 у клієнті mcp-remote (CVSS 9.6, опублікована 9 липня 2025 року) дозволяла шкідливому серверу впровадити команду операційної системи через адресу авторизації, яку сервер сам надсилає клієнту. Модель тут не потрібна взагалі: сервер атакує програму-клієнт безпосередньо. Документація протоколу закриває цей сценарій окремим розділом про перевірку OAuth-адрес.

Суміжний вектор тієї самої природи — шкідливі навички агента. Як відрізнити безпечний скил від небезпечного, розібрано в матеріалі Skills для Claude: де брати і як не встановити шкідливу навичку.

Крадіжка токенів через MCP: чому mcp.json цікавий атакувальникам

Одна з головних цілей атак на основі MCP (MCP based attacks) — не ваш код, а ваші ключі. Конфіг клієнта зберігає токени доступу до всіх під’єднаних сервісів: GitHub, бази даних, пошти. Тож один скомпрометований сервер відкриває доступ до всіх інших.

Саме це показала демонстрація Invariant Labs. Отруєний інструмент «додавання чисел» містив приховану вказівку прочитати ~/.cursor/mcp.json і приватний SSH-ключ ~/.ssh/id_rsa, а вміст передати як додатковий параметр виклику. Користувач бачив математичне пояснення, а ключі йшли на сервер атакувальника.

Документація протоколу закриває дві суміжні діри на рівні вимог:

• Прокидання токена заборонено. Сервер не повинен приймати токен клієнта й передавати його далі чужому API: у специфікації авторизації такий прийом прямо названо забороненим.
• Проблема «збитого з пантелику посередника» (confused deputy). Проксі-сервер зі статичним ідентифікатором клієнта, динамічною реєстрацією клієнтів і збереженою згодою в стороннього сервісу дає змогу зловмиснику отримати код авторизації без згоди користувача.

Недарма перший рядок в OWASP MCP Top 10 — «Token Mismanagement & Secret Exposure». Практичний висновок: у кожного сервера свій токен із мінімальними правами, а не спільний ключ «на все», і авторизація через OAuth там, де сервер її підтримує.

Як шкідливий mcp.json зламав Cursor: розбір MCPoison

Якщо потрібен один кейс, що пояснює всю тему, то це MCPoison. Вразливість CVE-2025-54136 знайшли дослідники Check Point Research у липні 2025 року; вона стосувалася Cursor до версії 1.2.4 включно.

Сценарій виглядав так. У спільному репозиторії лежить .cursor/mcp.json із безневинним записом. Колега відкриває проєкт, Cursor питає, чи запускати сервер, і той його схвалює. Після цього атакувальник із правом запису в репозиторій змінює команду всередині того самого запису. Схвалення було прив’язане до назви запису, а не до його вмісту, тому повторного питання не виникало: нова команда запускалася щоразу, коли проєкт відкривали.

Поруч стоїть сусідня вразливість того самого місяця, CurXecute (CVE-2025-54135), і їх часто плутають.

У CurXecute клік жертви не потрібен: інструкція надходить у даних, які агент читає за завданням користувача, а новий конфіг створюється без питання. Якщо .cursor/mcp.json у проєкті ще не було, агент міг створити його сам — і сервер із цього файлу запускався.

Окремо про розбіжність оцінок MCPoison. Картка NVD дає 8.8, а GitHub як організація, що присвоїла номер, — 7.2. Різниця в одному параметрі вектора: NVD вважає, що атакувальнику потрібні низькі привілеї, GitHub — високі. По суті, сперечаються про те, наскільки складно отримати право запису в чужий репозиторій. Для команди з десятками зовнішніх контриб’юторів ближча оцінка NVD.

Урок MCPoison ширший за Cursor: будь-яка зміна MCP-конфігу — це зміна виконуваного коду, і її треба перевіряти як код у pull request. Виправлення вийшло в Cursor 1.3 (29 липня 2025 року): за даними Check Point Research, відтоді будь-яка правка MCP-конфігу, навіть доданий пробіл, знову вимагає ручного схвалення.

DuneSlide: як Cursor ламали без жодного кліку у 2026 році

DuneSlide — наступний щабель, і за механікою це вже не атака на mcp.json. Дві вразливості, CVE-2026-50548 і CVE-2026-50549, стосуються Cursor Desktop до версії 3.0. У реєстрі вразливостей обидві опубліковано 25 червня 2026 року з оцінкою 9.3 за CVSS 4.0. Публічний технічний розбір Cato AI Labs вторинні джерела відносять до липня 2026-го — розбіжність дат між реєстром і звітом дослідників звична.

Зв’язок із MCP тут у доставці. За розбором The Agent Report, інструкція надходила у відповіді MCP-інструмента або в результаті вебпошуку, який агент читав за завданням користувача. Атакувальник не чіпав ні редактор, ні конфіг. NVD для CVE-2026-50548 додатково дає 9.8 за CVSS 3.1 — це та сама вразливість в іншій версії шкали, а не інша цифра ризику.

Важливий висновок із порівняння двох кейсів: схвалення змін конфігу закриває MCPoison, але проти DuneSlide марне. Проти інструкції у відповіді інструмента допомагають ізоляція, своєчасне оновлення клієнта і ручне схвалення дій на запис.

Довірені MCP-сервери теж зливають дані: кейс GitHub MCP

26 травня 2025 року Invariant Labs показала атаку на офіційний GitHub MCP-сервер. Зловмисник створював issue в публічному репозиторії жертви з інструкцією для агента. Користувач просив агента «переглянути відкриті issue», агент читав шкідливий текст, збирав дані з приватних репозиторіїв і публікував їх у pull request публічного репозиторію.

Три деталі роблять цей кейс хрестоматійним:

• Сервер не був шкідливим. Invariant наголошує, що це не помилка в коді GitHub MCP, а архітектурна проблема агентної системи: GitHub не може закрити її патчем на своєму боці.
• Модель була з-поміж найзахищеніших. В експерименті використовували Claude 4 Opus, і проста ін’єкція все одно спрацювала.
• Підтвердження вимкнули самі користувачі. Claude Desktop за замовчуванням питає дозволу на кожен виклик, але багато хто вмикає режим «Always Allow» і перестає стежити за діями.

Рекомендація Invariant — жорстко обмежувати, з чим агент працює за одну сесію, наприклад один репозиторій на сесію. Ширше це правило сформулював дослідник Саймон Віллісон під назвою «смертельна трійка» (lethal trifecta): небезпечно, коли в одному агенті сходяться доступ до приватних даних, читання недовіреного тексту й канал назовні. Приберіть будь-який із трьох — і ланцюжок рветься.

Шкідливі MCP-сервери в реальних атаках: таймлайн інцидентів

Cursor у новинах частіше за інших, але проблема не про один продукт. У таблиці — датовані випадки, де зловмисником або каналом був сам сервер (в англомовних звітах — MCP server attacks).

Два рядки варто прочитати уважніше. postmark-mcp, за оцінкою Koi Security, — перший шкідливий MCP-сервер, помічений у реальній атаці: npm-пакет видавав себе за інструмент Postmark, хоча компанія не мала до нього стосунку, і 15 версій поспіль поводився чесно. Бекдор з’явився лише в 16-й. Це класична схема атаки на ланцюг постачання: спершу набрати довіру й установлення, потім змінити код.

Другий — WhatsApp MCP. В огляді Checkmarx цей випадок датовано листопадом 2025 року, але оригінальна публікація Invariant Labs вийшла 7 квітня 2025-го; ми беремо дату першоджерела. Механіка першого експерименту та сама, що й у rug pull: сервер спершу поводився безневинно й перемикався після схвалення. Другий експеримент показовіший: шкідливий сервер там узагалі не знадобився, вистачило звичайного повідомлення з інструкцією, яке агент прочитав через довірений WhatsApp MCP.

Масштаб проблеми: скільки MCP-серверів насправді вразливі

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

Розбір OX Security — найсистемніший. Дослідники показали, що STDIO-транспорт в офіційних SDK на Python, TypeScript, Java і Rust запускає передану команду без санітизації. Вразливими виявилися застосунки, які дають змогу користувачу або атакувальнику додати MCP-сервер із довільною командою. Це атаки на MCP як на інфраструктуру (attacks on MCP), а не на конкретну модель.

Позиція Anthropic, за словами дослідників OX у переказі The Register від 16 квітня 2026 року: змінювати архітектуру протоколу компанія відмовилася, назвавши поведінку «очікуваною». Документація протоколу при цьому окремо описує ризик STDIO в проксі-архітектурах.

Серед IDE в тому самому розборі без участі користувача ламався лише Windsurf: CVE-2026-30615 спрацьовувала під час простого відкриття репозиторію зі шкідливим MCP-конфігом. Cursor, Claude Code і Gemini-CLI віднесено до родини, де ін’єкція змінює локальний конфіг, але потрібна хоча б одна дія користувача. Виробники, зокрема Google, Microsoft і Anthropic, назвали це відомою проблемою або не вразливістю, адже правка файлу вимагає явного дозволу. Це важливо розуміти, коли ви натискаєте «Дозволити».

Цифру HackerOne часто подають як «зростання MCP-атак на 540%». У пресрелізі йдеться про валідовані звіти про prompt injection на платформі загалом. MCP у пресрелізі не згадано взагалі, тож частку MCP-атак із цієї цифри не вивести.

Як перевірити MCP-сервер перед підключенням

Перевірка займає 10–15 хвилин і відсікає більшість ризиків із таймлайну вище.

1. Перевірте видавця. Чи збігається автор пакета з компанією, чиє ім’я стоїть у назві пакета? postmark-mcp видавав себе за Postmark. Зважайте: каталог конекторів Anthropic перевіряє їх на відповідність критеріям лістингу, але, за документацією Claude Code, аудиту безпеки серверів не проводить.
2. Прочитайте описи інструментів повністю. Не в інтерфейсі клієнта, а у вихідному коді або в повній відповіді сервера зі списком інструментів. Тривожні ознаки: згадки файлів (~/.ssh, mcp.json, .env), вказівки «перед використанням зроби…», службові теги на кшталт <IMPORTANT>.
3. Подивіться точну команду запуску. Для встановлення в один клік документація протоколу вимагає від клієнтів показувати команду повністю, з аргументами. Команда без версії пакета означає, що завтра запуститься інший код.
4. Закріпіть версію. Вкажіть конкретну версію пакета, за можливості — з перевіркою хешу. Invariant Labs називає закріплення версії одним із головних заходів проти rug pull.
5. Видайте мінімальний токен. Окремий токен для кожного сервера, лише на потрібні ресурси, краще тільки на читання. Кейс GitHub MCP спрацював тому, що токен мав доступ до всіх репозиторіїв.
6. Визначте, що сервер читає ззовні. Вебсторінки, issue, листи — це канал ін’єкції. Такий сервер не варто тримати в одній сесії із сервером, що має доступ до приватних даних і вихід назовні.
7. Перевірте історію вразливостей. Пошук за назвою пакета в базі GitHub Advisory і NVD займає хвилину.
8. Запускайте в ізоляції, якщо сумніваєтеся. Контейнер або окремий користувач без доступу до домашнього каталогу — рекомендація і документації протоколу, і NSA.

Налаштування захисту MCP у Cursor, Claude Code і Codex

Механіку підключення тут не повторюємо — лише налаштування, що обмежують атаку. Чим три інструменти різняться за підходом загалом, розібрано в порівнянні Claude Code, Cursor і Codex. В усіх трьох інструментів захист будується у два шари: що користувач схвалює в інтерфейсі і що адміністратор забороняє політикою.

Cursor: версія 3.0 і перевірка mcp.json як коду

Оновлення — перший і головний крок: MCPoison закрито в 1.3, CurXecute — в 1.3.9, DuneSlide — в 3.0. Підключення серверів у Cursor докладно розібрано в гайді MCP у Cursor: як підключити базу даних, Figma і власні інструменти; з погляду безпеки важливе інше:

• перевіряйте зміни в .cursor/mcp.json і ~/.cursor/mcp.json так само ретельно, як зміни коду, — через рев’ю;
• у команді задайте allowlist у панелі адміністратора Cursor (Team Settings → MCP Configuration): локальні сервери дозволяються за шаблоном команди, віддалені — за шаблоном URL, а для схваленого сервера можна обмежити інструменти, які запускаються автоматично;
• не вмикайте режим, у якому агент виконує все без підтвердження. Сам Cursor у документації пише, що allowlist команд — це не гарантія безпеки, обхід можливий.

Claude Code: managed settings і allowlist за командою

Проєктні сервери з .mcp.json Claude Code запускає лише після схвалення в інтерактивній сесії. Склонований репозиторій не може схвалити свої сервери сам: ключі enableAllProjectMcpServers і enabledMcpjsonServers у його .claude/settings.json ігноруються, доки ви не підтвердили довіру до теки (у v2.1.196 це правило поширили і на claude mcp list та claude mcp get). Скинути зроблені вибори можна командою claude mcp reset-project-choices. Як підключати сервери загалом, розібрано в матеріалі MCP у Claude Code: як підключити сервери, не спалити контекст і коли він не потрібен.

Для команди головне — managed settings: вони мають пріоритет над користувацькими і проєктними налаштуваннями. Приклад із документації Anthropic, скорочений:

{
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.sentry.dev/*" },
    { "serverCommand": ["python", "/usr/local/bin/approved-server.py"] }
  ],
  "deniedMcpServers": [
    { "serverCommand": ["npx", "-y", "unapproved-package"] }
  ]
}

Три нюанси, які легко пропустити:

• Назва сервера — не захист. Документація прямо каже: serverName задає користувач, і будь-який сервер можна назвати github. Дозволяйте за serverCommand (точна команда з аргументами) або serverUrl.
• Порожній список і відсутність списку — різні речі. allowedMcpServers: [] забороняє все, а незаданий ключ дозволяє все.
• Щоб користувач не розширив список сам, потрібен ще allowManagedMcpServersOnly: true. Заборона з deniedMcpServers діє завжди.

І одна пастка для CI: у запусках claude -p, в Agent SDK і в хмарних сесіях Claude Code не може показати запит на схвалення й завантажує проєктні сервери без питання. Чужий репозиторій у такому конвеєрі варто запускати лише з managed-політикою.

Codex: requirements.toml і перелік дозволених інструментів

Адміністратор задає allowlist у requirements.toml (на macOS і Linux — /etc/codex/requirements.toml). Сервер увімкнеться, лише якщо збігаються і назва, і «ідентичність»: для локального сервера — команда, для віддаленого — URL. Приклад із документації OpenAI:

[mcp_servers.docs]
identity = { command = "codex-mcp" }

[mcp_servers.remote]
identity = { url = "https://example.com/mcp" }

На рівні користувача в config.toml у кожного сервера є enabled_tools (які інструменти взагалі бачить модель), disabled_tools (заборона поверх), default_tools_approval_mode і tools.<назва>.approval_mode — режим схвалення для сервера й окремих інструментів. Як працюють транспорти і config.toml, докладно — в матеріалі MCP-сервери в Codex: config.toml, транспорти і чому сервер не відповідає.

Codex уже мав вразливість цього класу: CVE-2025-61260 дозволяла виконати код із MCP-секції проєктного конфігу під час простого запуску в чужому репозиторії — розбір у статті Пісочниця Codex не закриває читання: модель загроз і чек-лист.

Залишкові ризики: чого allowlist і схвалення MCP не закривають

Allowlist і діалоги схвалення закривають питання «який сервер запуститься». Питання «що зробить агент, прочитавши недовірений текст» вони не закривають. Зведення сильних і слабких сторін заходів:

Кейс CVE-2026-22708, знайдений Pillar Security, показовий: вбудовані команди оболонки на кшталт export виконувалися без підтвердження навіть за порожнього allowlist і дозволяли підготувати оточення так, що наступна безневинна команда запускала шкідливий код. Cursor після цього почав запитувати схвалення для всього, що не може класифікувати, але висновок лишається: allowlist — один шар, а не межа.

Звідси практичне правило: дії з незворотними наслідками (запис у репозиторій, надсилання листів, платежі, публікація) агент має виконувати лише після вашого явного підтвердження, навіть якщо це незручно.

OWASP MCP Top 10 і рекомендації NSA для захисту

Будувати модель загроз з нуля не потрібно — є два формальні фреймворки. OWASP MCP Top 10 описує десять категорій ризику і поки перебуває на стадії бета-версії. NSA разом із партнерами Five Eyes випустило настанову «Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation» (PP-26-1834, версія 1.0, травень 2026; опубліковано 2 червня 2026 року). Нижче категорії OWASP прив’язано до кейсів із цієї статті.

Настанова NSA додає те, чого немає в OWASP: організаційний шар. Головні тези:

• Будь-який виклик інструмента через MCP — потенційно дія з високим ризиком. Його варто запускати в пісочниці засобами ОС: AppContainers на Windows, seccomp, AppArmor або SELinux на Linux.
• Найменші привілеї. Якщо серверу не потрібен доступ до файлової системи чи мережі, цей доступ явно забороняють під час виконання.
• Межі довіри. Агент, плагіни, модель і користувач — різні зони довіри з власними перевірками.
• Перевірка коду сервера. Якщо в організації є аудит коду, MCP-сервери проходять його за найсуворішим профілем.
• Журнали — у спільний моніторинг. Логи MCP-викликів варто надсилати в SIEM, а не зберігати лише на комп’ютері розробника.

Чек-лист захисту від атак через MCP за один вечір

1. Інвентаризація. Випишіть усі під’єднані сервери з ~/.cursor/mcp.json, проєктних .cursor/mcp.json і .mcp.json, а також із config.toml Codex. Зайві видаліть.
2. Оновлення клієнтів. Cursor — не нижче 3.0, Claude Code і Codex — до актуальних версій.
3. Закріплення версій. У кожній команді запуску — конкретна версія пакета замість «останньої».
4. Ротація токенів. Для серверів, що стояли без закріпленої версії або з невідомого джерела, випустіть нові токени з мінімальними правами.
5. Allowlist. У команді — allowedMcpServers за serverCommand/serverUrl у Claude Code, requirements.toml у Codex, allowlist за командою і URL у панелі адміністратора Cursor.
6. Інструменти на запис. Залиште ручне схвалення для всього, що пише, надсилає або публікує. Режим «Always Allow» — лише для інструментів на читання.
7. Правило для репозиторіїв. Зміни MCP-конфігів проходять рев’ю в pull request, як код.
8. Розділення сесій. Сервери, що читають веб або чужі issue, не тримайте в одній сесії із серверами, які мають приватні дані й вихід назовні.
9. Ізоляція. Неперевірені сервери запускайте в контейнері або від імені окремого користувача.
10. Журнал. Увімкніть логування викликів інструментів, щоб потім можна було зрозуміти, що робив агент.

Що в захисті від MCP-атак застаріє першим

Найшвидше змінюються номери версій клієнтів, ключі налаштувань і перелік CVE: лише за 2025–2026 роки Cursor пройшов шлях від виправлень у 1.3 до 3.0, а в документації Claude Code поведінка схвалень змінювалася на рівні патч-версій. Повільніше — сама модель загроз: поки модель не вміє відрізняти дані від інструкцій, ін’єкція через опис або відповідь інструмента лишається робочим вектором. Свіжі дані перевіряйте за першоджерелами: документацією протоколу MCP, картками NVD і advisory вашого клієнта.

Часті запитання

Чи може шкідливий MCP-сервер викрасти мої файли, навіть якщо я його явно не схвалював? Так, якщо він діє через інший, уже схвалений канал. У CurXecute інструкція надходила в даних, які агент читав сам, і змушувала Cursor створити новий MCP-конфіг без питання. У DuneSlide інструкція надходила у відповіді інструмента або результаті вебпошуку. Схвалення захищає від запуску конкретного сервера, але не від тексту, який агент читає.

Чим rug pull відрізняється від tool poisoning? Tool poisoning — шкідлива інструкція в описі інструмента від самого початку. Rug pull — зміна поведінки після того, як ви сервер схвалили: спершу безневинний опис чи команда, потім шкідливі. На практиці їх поєднують, як у демонстрації з WhatsApp MCP. Від першого захищає читання описів до підключення, від другого — закріплення версії і повторне схвалення змін.

Чи досить оновити Cursor до останньої версії, щоб закрити всі відомі MCP-атаки? Ні. Оновлення до 3.0 закриває відомі вразливості самого Cursor — CurXecute, MCPoison і DuneSlide. Але атаки на кшталт GitHub MCP використовують не помилку клієнта, а те, що модель виконує інструкції з прочитаних даних. Проти них потрібні мінімальні права токенів, розділення сесій і ручне схвалення дій на запис.

Як зрозуміти, що MCP-сервер, яким я вже користуюся, безпечний? Гарантії немає, але є перевірка: видавець збігається з компанією, версію закріплено, описи інструментів не містять вказівок про файли й «перед використанням», за назвою пакета немає відкритих advisory, токен видано з мінімальними правами. Якщо сервер стояв на «останній версії» з невідомого джерела, варто змінити токени, до яких він мав доступ.

Чи захищає allowlist MCP-серверів від rug pull, якщо сервер не змінюється, а змінюється лише його поведінка? Частково. Allowlist за точною командою із закріпленою версією не дасть запуститися новій версії локального пакета. Але віддалений сервер за дозволеним URL може змінити поведінку на своєму боці, і allowlist цього не побачить. Тут допомагають лише обмеження прав токена, ручне схвалення дій і журнал викликів.

Чи треба боятися MCP загалом або відмовитися від сторонніх серверів? Відмовлятися не обов’язково: MCP — стандарт, який підтримують великі клієнти, і без нього агенти втрачають більшу частину користі. Розумний підхід — ставитися до сервера як до залежності з правом виконувати код: брати в офіційних видавців, закріплювати версію, давати мінімальні права. Неперевірені сервери запускати лише в ізоляції.