Екосистема MCP вибухнула — безпека не встигла
Модельний контекстний протокол, представлений Anthropic наприкінці 2024 року, став де-факто стандартом для підключення ШІ-помічників до зовнішніх інструментів менш ніж за 18 місяців. До березня 2026 року екосистема MCP включає конектори баз даних, сервери файлових систем, інтеграції GitHub, мости Slack, поштові клієнти та сотні предметно-специфічних серверів інструментів.
Крива впровадження крута. Рівень безпеки — ні.
Станом на березень 2026 року понад 8 000 MCP-серверів публічно доступні в інтернеті. Дослідники безпеки, що сканують на ендпойнти MCP, виявили 492 сервери без жодної автентифікації — без ключа API, без OAuth, без обмеження IP. Будь-який HTTP-клієнт може викликати їхні інструменти. 36,7% перевірених MCP-серверів вразливі до SSRF (Server-Side Request Forgery — підробка запиту на стороні сервера), що означає: зловмисник, який контролює вхід інструменту, може перейти з MCP-сервера до внутрішніх мережевих ресурсів.
За той самий період подано понад 30 CVE проти реалізацій MCP за 60 днів — темп, що відображає як незрілість екосистеми, так і інтенсивність уваги дослідників, яку вона привернула.
Чому MCP створює ризик PII
MCP розроблений, щоб дати ШІ-помічникам можливість виконувати дії та отримувати доступ до даних. Саме це також робить його вектором ризику PII.
Коли розробник використовує Cursor або Claude Desktop з MCP-конектором бази даних, ШІ-помічник генерує SQL-запити на основі запиту користувача на природній мові. Ці запити повертають реальні дані — які можуть включати імена клієнтів, адреси електронної пошти, платіжну інформацію або інший PII. Ці дані течуть:
- Від MCP-сервера бази даних → до вікна контексту ШІ-помічника
- З вікна контексту → потенційно до логової інфраструктури постачальника моделі
- З історії розмови → на локальний комп'ютер розробника
- З сесій відлагодження → до інших ШІ-помічників, коли розробник вставляє контекст
Жоден з цих кроків не є обов'язково порушенням. Це передбачувана поведінка MCP. Але результат полягає в тому, що PII проходить через кілька систем, не розроблених для його обробки, без шифрування під час передачі між MCP-сервером та ШІ-клієнтом у багатьох реалізаціях.
CVE-2026-25253 (CVSS 8,8), розкрита в лютому 2026 року, продемонструвала конкретну атаку: зловмисно налаштований MCP-сервер міг впровадити інструкції у відповіді викликів інструментів, що змушували підключений ШІ-помічник викрадати дані з інших підключених MCP-серверів. Розробник, що підключається до скомпрометованого суспільного MCP-сервера, маючи активний MCP-сервер бази даних, міг розкрити всю свою базу даних зловмиснику.
492 сервери без автентифікації
492 MCP-сервери без жодної автентифікації представляють інший ризик, ніж CVE-2026-25253. Це не скомпрометовані легітимні сервери — вони просто неправильно налаштовані. Багато з них є інструментами розробника, що мали бути лише локальними, але були відкриті через переадресацію портів або хмарне розгортання без контролю доступу.
Що зазвичай відкривають ці сервери:
- Інструменти файлової системи з читацьким доступом до домашніх каталогів
- Конектори баз даних з продакшн-обліковими даними, вбудованими в конфігурацію
- Поштові MCP-сервери з доступом до корпоративних поштових скриньок
- Середовища виконання коду (найнебезпечніші — довільне виконання коду без автентифікації)
Розробники, що побудували ці сервери, майже напевно не мали наміру відкривати їх публічно. Але Cursor і Claude Desktop не розрізняють MCP-сервер на localhost та публічно відкритий — вони підключаються до будь-якої URL-адреси, що надається користувачем у їх конфігурації.
Рішення MCP від anonym.legal
Структурне виправлення ризику PII у конвеєрах MCP — це анонімізація даних перед тим, як вони досягнуть будь-якого виклику інструменту, що відправляє їх до LLM. Саме це надає MCP-сервер anonym.legal.
Сервер надає 7 інструментів:
| Інструмент | Призначення |
|---|---|
analyze_text | Виявляти сутності PII та повертати їх позиції та типи |
anonymize_text | Видаляти або псевдонімізувати виявлений PII |
deanonymize_text | Зворотна псевдонімізація з використанням вашого ключа шифрування |
anonymize_batch | Обробка кількох текстів за один виклик |
get_supported_entities | Перелік усіх 285+ типів сутностей для заданої мови |
get_supported_languages | Перелік усіх 48 підтримуваних мов |
health_check | Перевірка підключення |
Коли ШІ-помічник має налаштований як MCP-сервер anonym.legal, так і MCP-сервер бази даних, розробник може інструктувати: «Перед відображенням будь-яких даних клієнтів із бази даних виклич anonymize_text для результату». ШІ обробляє оркестрування — і PII ніколи не досягає видимого виводу або історії розмови моделі в ідентифікованій формі.
Інтеграція з Cursor IDE
Для додавання MCP-сервера anonym.legal до Cursor:
// .cursor/mcp.json
{
"mcpServers": {
"anonym-legal": {
"url": "https://anonym.legal/mcp",
"transport": "sse",
"headers": {
"Authorization": "Bearer YOUR_API_KEY"
}
}
}
}
Після налаштування ви можете попросити Cursor: «Проаналізуй цей тікет підтримки на наявність PII перед тим, як я вставлю його в трекер задач». Cursor викликає analyze_text, повертає список сутностей, і ви можете вирішити, чи анонімізувати перед вставкою.
Інтеграція з Claude Desktop
// claude_desktop_config.json
{
"mcpServers": {
"anonym-legal": {
"command": "npx",
"args": ["-y", "@anonym-legal/mcp-server"],
"env": {
"ANONYM_API_KEY": "YOUR_API_KEY"
}
}
}
}
З цією конфігурацією Claude Desktop може анонімізувати будь-який текст, яким ви ділитеся, перед включенням його у виклики інструментів, що надсилаються до інших MCP-серверів. Анонімізація відбувається на стороні клієнта у вашій сесії Claude Desktop — PII ніколи не досягає серверів Anthropic в ідентифікованій формі.
Зміцнення вашого налаштування MCP
Окрім використання MCP anonym.legal, застосуйте ці кроки зміцнення до вашої конфігурації MCP:
Перевірте свій список серверів. Перегляньте кожен MCP-сервер у вашій конфігурації Cursor/Claude Desktop. Для кожного переконайтеся, що довіряєте оператору і розумієте, до яких даних він має доступ.
Надавайте перевагу локальним серверам над віддаленими. Локальні MCP-сервери (підключені через stdio, а не HTTP) не створюють мережевого відкриття. Використовуйте віддалені сервери лише тоді, коли немає локальної альтернативи.
Перевірте автентифікацію. Кожен віддалений MCP-сервер, до якого ви підключаєтеся, повинен вимагати ключ API або токен OAuth. Якщо ні — не використовуйте його з контекстами, що містять PII.
Розділяйте розробку та продакшн. Використовуйте окремі конфігурації MCP-серверів для розробки (синтетичні дані, без PII) та будь-яких робочих процесів, що стосуються продакшн-даних.
Моніторте логи викликів інструментів. Якщо ваш MCP-сервер підтримує аудит-логування — увімкніть його. Знайте, які дані пройшли через який виклик інструменту.
Понад 30 CVE за 60 днів сигналізують, що безпека MCP активно досліджується. Нові вразливості будуть розкриті. Структурний захист — анонімізація перед тим, як будь-які дані досягають виклику інструменту, що торкається LLM — залишається ефективним незалежно від того, яка конкретна CVE буде виявлена наступною.
Налаштуйте MCP anonym.legal у Cursor →
Джерела:
- Дані про відкриття MCP-серверів Shodan, березень 2026 — понад 8 000 серверів, 492 без автентифікації
- CVE-2026-25253, CVSS 8,8, вразливість міжсерверної ін'єкції MCP
- Дані про вразливості SSRF: сканування безпекових досліджень публічно доступних ендпойнтів MCP, березень 2026
- Специфікація MCP Anthropic v1.2, розділ про міркування безпеки