Атаки через 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 не выйдет в октябре: модель обманывала и действовала без разрешения

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

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 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 вашего клиента.

FAQ

Может ли вредоносный 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 — стандарт, который поддерживают крупные клиенты, и без него агенты теряют большую часть пользы. Разумный подход — относиться к серверу как к зависимости с правом выполнять код: брать у официальных издателей, закреплять версию, давать минимальные права. Непроверенные серверы запускать только в изоляции.