Уязвимости MCP-протокола: как атаки через LLM-агенты работают и как защититься

Друзья, у нас проблема: MCP — это не протокол, а дуршлаг

Model Context Protocol задумывался как элегантный мост между LLM и внешними инструментами. Единый интерфейс, прозрачная передача контекста, лёгкая интеграция. Красиво, да? На практике этот мост превратился в трамплин для атак. Исследователи Palo Alto Networks в апреле 2026 года выпустили отчёт, от которого у меня дёргается глаз: 78% протестированных MCP-эндпоинтов содержат критические уязвимости, позволяющие удалённо выполнить код или украсть токены. Но главная беда даже не в этом.

Проблема глубже: MCP не защищает от атак на уровне доверия между агентом и сервером. LLM доверяет тому, что написано в описании инструмента. А описание может подсунуть злоумышленник. Мы уже обсуждали реальную кибератаку через Claude и MCP, где промпт-инъекция через цепочку задач привела к утечке .env файлов. Теперь всё стало хуже.

Корень зла: MCP не проверяет, кто тыкает в его инструменты

Протокол определяет, как агент подключается к ресурсам (файлы, API, базы данных) и какие инструменты ему доступны. Но аутентификация и авторизация оставлены на совести разработчика. А разработчики, как показывает статистика, — люди занятые. Вспомните проверку 2181 MCP-эндпоинта: 37% не требуют никакой аутентификации. Вы серьёзно? Это как оставить ключи от банка в прихожей с табличкой «берите, кто хочет».

Второй корень — отсутствие границ доверия (trust boundaries). В классической архитектуре каждый сервис знает, кому верить. В мире агентов всё размыто: агент A общается с агентом B через A2A, а тот через MCP выдёргивает данные из базы. Цепочка доверия строится на «честном слове» агентов. А слово LLM — штука ломкая. Через структурные инъекции фреймворка Phantom можно заставить агента забыть, что он вообще агент, и начать выполнять произвольные команды.

Разбор практической атаки: MCP как дверь для supply-chain атак

Представьте сценарий: вы ставите MCP-сервер из публичного реестра (Hugging Face MCP Hub, npm, pip). Сервер обещает «интеграцию с Google Calendar». Разработчик скачал, запустил, агент начал работать. А внутри — троян, который при каждом вызове инструмента get_events ещё и копирует credentials в скрытый файл. Это supply-chain атака на MCP. Мы уже разбирали почему невозможно запатчить такие атаки: потому что уязвимость не в коде, а в модели доверия.

Palo Alto Networks в своём отчёте (апрель 2026) описали атаку «MCP Proxy»: злоумышленник ставит промежуточный MCP-сервер, который прозрачно проксирует запросы к реальному сервису, но по пути модифицирует контекст. Агент считает, что общается с легитимным сервисом, а на самом деле выполняет подменённые инструкции. Особенно опасна такая атака в связке MCP + A2A, когда агент A через MCP обращается к агенту B, а тот уже в продакшене. AWS и Cisco пытаются закрыть это воротами и экранами, но пока что это гонка вооружений.

Как НЕ надо защищать MCP (спойлер: семантические фильтры не работают)

Многие тянутся к «очевидному» решению: добавить промпт-фильтр, который проверяет входящие инструкции на вредоносность. Проблема в том, что атаки на MCP — не про «скажи наркотики», а про структурные искажения. Семантические фильтры бесполезны, потому что атакующий не использует запрещённые слова — он искажает логику принятия решений агентом. Например, передаёт в описании инструмента поле allowed_paths: ['/tmp'], а агент почему-то решает, что может читать из /etc. Почему? Потому что LLM интерпретирует контекст не так, как мы ожидаем. Архитектурные пределы безопасности LLM-агентов — это не баг, а фича вероятностной модели.

Другая ошибка — верить в sandboxing на уровне ОС. Да, можно запустить MCP-сервер в изолированном контейнере. Но атака обычно происходит не на системном уровне, а на уровне логики агента. Злоумышленник не пишет в /etc/shadow — он заставляет агента самому отправить секреты на его сервер. И sandbox этого не остановит.

Пошаговый план защиты MCP-среды (работает на 06.07.2026)

class SecureMCPServer:
    def __init__(self):
        self.allowed_tools = {
            'read_file': {'path': '/data/docs/', 'glob': '*.md'},
            'send_email': {'to': ['admin@corp.com']}
        }

    def validate_call(self, tool_name, arguments):
        if tool_name not in self.allowed_tools:
            raise PermissionError("Tool not allowed")
        # проверка аргументов, а не доверие LLM
        for key, expected in self.allowed_tools[tool_name].items():
            actual = arguments.get(key)
            if not self.match_pattern(actual, expected):
                raise PermissionError(f"Parameter {key} out of allowed range")
        return True

Нюансы и типовые ошибки при внедрении защиты

Что дальше? Прогноз на конец 2026

Сейчас мы в точке, где MCP стал стандартом, но безопасность догоняет его с отставанием в год. Думаю, к концу 2026 года появятся встроенные механизмы на уровне протокола: обязательная подпись каждого сообщения, контракты на инструменты (как OpenAPI для агентов). Но до тех пор — каждый сам за себя. И если ваш AI-агент имеет доступ к продакшену через MCP, а вы до сих пор не внедрили валидацию вызовов — считайте, вы просите хакера удалить вашу БД.

Один неочевидный совет, который я даю всем командам: напишите тест, который проверяет, что ваш MCP-сервер сопротивляется структурной инъекции. Возьмите описание инструмента с вредоносным переопределением параметров и убедитесь, что сервер его отвергает. Если ваш агент проваливает такой тест — он уязвим, и никакой firewall не спасёт.

А пока — не верьте своим агентам. Они слишком доверчивы.

Подписаться на канал