Безопасность MCP-протокола для AI-агентов: новые угрозы 2026 года

Model Context Protocol (MCP) — открытый протокол, представленный компанией Anthropic в ноябре 2024 года. Он стандартизирует способ, которым AI-агенты подключаются к внешним источникам данных, инструментам и системам. К середине 2026 года MCP стал фактическим стандартом для построения агентных AI-систем: его поддерживают все основные IDE, AI-платформы и более 500 интеграций с популярными сервисами.

Однако распространение протокола привлекло внимание не только разработчиков, но и злоумышленников. Спецификация MCP изначально была ориентирована на функциональность, а не на безопасность — и в 2026 году исследователи обнаружили сразу несколько критических векторов атак, использующих архитектурные особенности протокола. В этом материале разбираем, как устроена безопасность MCP, какие угрозы актуальны прямо сейчас и как защитить свою инфраструктуру AI-агентов.

🔍 Что такое MCP: архитектура и модель угроз

MCP работает по клиент-серверной модели. Клиент (MCP Host) — это AI-агент, среда разработки или приложение, которое взаимодействует с пользователем. Сервер (MCP Server) предоставляет ресурсы, инструменты и шаблоны промптов. Протокол использует JSON-RPC 2.0 в качестве транспортного слоя и поддерживает два режима передачи: stdin/stdout (для локальных процессов) и SSE (Server-Sent Events) для удалённых подключений.

Архитектурно MCP вводит три основных типа объектов: ресурсы (данные, которые клиент может читать — файлы, записи БД, API-ответы), инструменты (функции, которые клиент может вызывать — отправка email, выполнение запросов, операции с файлами) и шаблоны промптов (готовые инструкции для LLM). Именно это разделение порождает новую модель угроз: если традиционные API защищаются на уровне эндпоинтов, то MCP требует защиты на уровне того, какие действия AI-агент может совершать через инструменты и к каким данным получать доступ через ресурсы.

🚨 Основные угрозы MCP-протокола в 2026 году

1. Атаки на инструменты (Tool Poisoning)

MCP-серверы могут предоставлять десятки инструментов. Злоумышленник, получивший доступ к серверу (или создавший вредоносный MCP-сервер), может подменить описание инструмента так, что AI-агент выполнит нежелательное действие. Например, инструмент с описанием «отправить письмо» может быть модифицирован для отправки писем с вредоносными вложениями или на произвольные адреса. В июне 2026 года команда Invariant Labs продемонстрировала атаку, при которой вредоносный MCP-сервер убеждал AI-агента вызвать инструмент delete_all_files, замаскированный под инструмент «очистка кэша».

2. Server-Side Request Forgery (SSRF) через MCP

Поскольку MCP-сервер может выполнять HTTP-запросы от имени клиента, атакующий может использовать MCP как прокси для SSRF-атак. Если MCP-сервер настроен с избыточными правами и подключён к внутренней сети, AI-агент (или злоумышленник, контролирующий его промпты) может инициировать запросы к внутренним сервисам: базам данных, API-шлюзам, облачным метаданным. В апреле 2026 года исследователи из Praetorian обнаружили SSRF-уязвимость в популярной реализации MCP-сервера для PostgreSQL, позволявшую читать произвольные таблицы через инструмент query_database.

3. Prompt-инъекции через описание ресурсов MCP

Это, пожалуй, самый опасный класс атак 2026 года. MCP-сервер передаёт клиенту не только данные, но и метаданные — имена ресурсов, описания инструментов, подсказки. Если злоумышленник может контролировать любой из этих элементов (например, через заражённый Git-репозиторий, подключённый как MCP-ресурс), он может внедрить вредоносные инструкции непосредственно в контекст AI-агента. В июле 2026 года команда PromptArmor продемонстрировала атаку, при которой README-файл в публичном репозитории GitHub содержал невидимые промпты, которые через MCP-интеграцию заставляли AI-агента выполнять команды злоумышленника.

4. Перехват и модификация MCP-трафика

По умолчанию MCP не требует шифрования. В режиме SSE данные передаются по незащищённому HTTP-каналу. Если MCP-сервер развёрнут в облаке без TLS, атакующий на сетевом уровне может перехватывать запросы клиента к серверу и ответы сервера — включая содержимое промптов пользователя, результаты вызовов инструментов и аутентификационные токены. Исследование Cado Security (февраль 2026) показало, что 12% публично доступных MCP-серверов не используют HTTPS.

5. Spoofing MCP-серверов

Экосистема MCP включает каталоги публичных серверов (mcpserver.io, smithery.ai, официальный реестр Anthropic). В мае 2026 года исследователи обнаружили подменные MCP-серверы в этих каталогах, которые имитировали легитимные интеграции (для Slack, Jira, GitHub), но на самом деле копировали данные и токены. AI-агент, подключившийся к такому серверу, передавал злоумышленнику полный доступ к своим инструментам.

🔐 Проблема модели привилегий MCP

Одна из главных архитектурных проблем MCP — отсутствие гранулярного контроля доступа на уровне протокола. MCP-сервер либо предоставляет все свои инструменты и ресурсы, либо ничего. Нет механизма «попросить подтверждение» перед вызовом опасного инструмента (подобно OAuth consent screen). Нет ограничений на количество вызовов одного инструмента за сессию. Нет разграничения прав между разными AI-агентами, подключёнными к одному серверу.

MCP использует концепцию «песочницы» (sandbox) на уровне транспорта: локальный сервер (stdin/stdout) изолирован процессом ОС, удалённый сервер (SSE) изолирован сетью. Однако внутри этой песочницы все инструменты доступны без ограничений. Как отметили исследователи NVIDIA Security в отчёте за июнь 2026 года, «MCP решает проблему подключения, но не проблему авторизации».

В 2026 году Anthropic представила спецификацию MCP Authorization Framework, которая вводит OAuth 2.0-подобный механизм согласий. Однако на июль 2026 года эта спецификация находится в статусе черновика, и ни одна популярная реализация её не поддерживает.

🛡️ Методы защиты MCP-инфраструктуры

На основе анализа атак 2026 года и рекомендаций исследовательских команд можно выделить следующие практики защиты:

Инфраструктурная защита

• Шифрование трафика: все MCP-серверы, доступные по сети, должны использовать TLS 1.3. Сертификаты Let's Encrypt бесплатны и достаточны для базовой защиты.
• Аутентификация клиентов: внедрение API-ключей или mTLS для всех удалённых MCP-подключений. MCP не определяет механизм аутентификации, но его можно реализовать на транспортном уровне.
• Изоляция серверов: MCP-серверы должны запускаться в изолированных контейнерах или виртуальных машинах с минимальными правами. Подключение к внутренней сети должно быть запрещено, если не требуется явно.

Защита на уровне приложений

• Sandboxing инструментов: перед выполнением каждого инструмента MCP-сервер должен проверять параметры вызова. Например, инструмент для работы с файлами не должен принимать пути выше определённой директории.
• Rate limiting: ограничение количества вызовов одного инструмента за единицу времени — защита от автоматизированных атак через AI-агента.
• Валидация метаданных: все описания инструментов и ресурсов должны проверяться на наличие prompt-инъекций перед передачей AI-агенту. Инструменты вроде llm-guard и inspector-mcp могут автоматически сканировать метаданные.

Мониторинг и реагирование

• Логирование всех вызовов: каждый вызов инструмента и чтение ресурса должны записываться с метаданными: какой клиент, когда, с какими параметрами.
• Детекция аномалий: необычные паттерны использования MCP-инструментов (например, массовое чтение ресурсов за короткое время) должны вызывать алерты.
• Аудит цепочки поставки: периодическая проверка используемых MCP-серверов на предмет подмены или компрометации. Особенно важно для серверов из публичных каталогов.

🔮 Будущее безопасности MCP

Экосистема MCP развивается стремительно, и вопросы безопасности начинают получать внимание разработчиков. В дорожной карте протокола на вторую половину 2026 года заявлены следующие улучшения безопасности:

• Встроенная поддержка OAuth 2.0 для авторизации клиентов и согласий на вызов инструментов
• Стандартизированные политики безопасности на уровне протокола (поле securityPolicy в описании сервера)
• Аудит-лог на уровне MCP Host — каждый host будет обязан вести лог всех вызовов
• Шифрование по умолчанию для SSE-транспорта

Однако, как показывает практика, внедрение этих механизмов займёт не менее 12–18 месяцев. В переходный период ответственность за безопасность MCP-инфраструктуры полностью лежит на разработчиках и администраторах. Использование MCP без дополнительных слоёв защиты — это вопрос времени до компрометации, особенно если сервер доступен по сети.

Безопасность MCP-протокола — это не проблема протокола как такового, а проблема его окружения. MCP предоставляет AI-агентам невиданную ранее гибкость в подключении к данным и инструментам, но эта гибкость требует адекватного контроля доступа. Организациям, которые внедряют MCP, необходимо рассматривать его не как простой API-шлюз, а как полноценный компонент инфраструктуры безопасности, требующий такого же уровня защиты, как базы данных и критические сервисы.

📚 Читайте также

• Защита CI/CD пайплайнов: как предотвратить компрометацию поставки кода
• Почему уязвимости ИИ-приложений так часто критичны: анализ и практика защиты
• Безопасность кода, написанного ИИ: риски и практики защиты приложений
• Уязвимости в ИИ-приложениях: каждая третья угроза оказалась критической
• Prompt-инъекции через README: как GitHub-документация атакует ИИ-агентов

📖 Термины

Adversarial ML · Безопасность моделей ИИ · Пентест

🔗 Источники

• MCP Security Specification — GitHub (Anthropic)
• MCP серверы и интеграции — каталог Smithery.ai
• NVIDIA Security: уязвимости в MCP-реализациях — отчёт за июнь 2026
• Инструмент анализа безопасности MCP — Invariant Labs
• Официальная документация Model Context Protocol — Anthropic