Содержание
Сторонние MCP позволяют агентам напрямую работать с GitHub, таск-трекерами и PostgreSQL без дополнительного кода. Это ускоряет интеграцию, но одновременно открывает канал для промпт-инъекций, которые модель не умеет фильтровать по источнику. В итоге агент может выполнить вредоносные команды, полученные из внешних ресурсов, и причинить ущерб данным или инфраструктуре. При оценке решения о внедрении важно учитывать, что быстрая настройка доступа к внешним системам снижает порог входа для атак, а отсутствие встроенных механизмов разграничения источников делает последствия необратимыми. Командам следует заранее определить, насколько критичны данные и операции, к которым получит доступ агент, и сопоставить выгоду от автоматизации с потенциальными потерями от несанкционированных действий.
Почему LLM не различает источники
Модель обрабатывает все токены контекста как равнозначные, независимо от роли — системный промпт, описание инструментов или содержимое README из репозитория. Даже когда разработчик явно прописывает запрет на опасные действия, последующий текст из пользовательского ресурса может перекрыть это правило. Модель просто предсказывает следующий токен и не обладает механизмом проверки достоверности инструкции. Это означает, что любые данные, поступающие через подключённые ресурсы, воспринимаются наравне с внутренними правилами безопасности. Для принятия решения о использовании таких инструментов важно понимать, что даже тщательно прописанные ограничения не гарантируют защиты, поскольку модель не проводит проверку происхождения текста.
Это свойство лежит в основе всех известных атак на LLM. Промпт-инъекция не требует обхода аутентификации: достаточно разместить текст с командой «игнорируй предыдущие правила» среди легитимных данных. Современные модели пытаются учитывать роли сообщений, однако гарантий строгого следования системным ограничениям нет. В контексте выбора технологии это создаёт дополнительный риск: организация не может полагаться только на инструкции в промпте, потому что внешний контент способен их отменить без каких-либо технических уязвимостей в самом протоколе подключения.
Как MCP масштабирует проблему
MCP даёт агенту готовые инструменты для работы с PostgreSQL, Git и таск-трекерами. Когда один из подключённых ресурсов содержит отравленный контекст, агент получает возможность выполнить реальные действия: изменить данные в базе, отправить деньги или удалить файлы. Раньше уязвимость оставалась внутри изолированного чата, теперь она получает прямой доступ к внешним системам. Масштаб проблемы растёт потому, что один и тот же агент может одновременно читать несколько источников и применять их содержимое для формирования команд. При решении о внедрении необходимо оценить, какие именно операции агент сможет выполнять и есть ли возможность ограничить круг доступных действий до минимально необходимого набора.
Особенно опасны сценарии, где вредоносная инструкция собирается по частям из нескольких источников. Каждый фрагмент выглядит нейтрально, но вместе они формируют команду, нарушающую политику безопасности. Проверка отдельных MCP не помогает, потому что модель не проводит критический анализ целостности контекста. Это усложняет мониторинг: даже при регулярной проверке каждого подключения нельзя заранее предсказать, как именно агент интерпретирует комбинацию данных. Командам важно учитывать, что отсутствие единой точки контроля над контекстом делает стандартные меры аудита недостаточными для предотвращения инцидентов.
Практические последствия для команд
В российском контуре, где многие компании используют PostgreSQL и внутренние Git-репозитории, подключение сторонних MCP создаёт прямой путь к утечкам и саботажу. Агент может прочитать чувствительные таблицы или выполнить DDL-команды по инструкции из внешнего файла. Отсутствие изоляции между источниками данных и инструментами делает откат сложным: последствия проявляются уже после выполнения действия. При оценке целесообразности внедрения следует проанализировать, какие именно таблицы и репозитории будут доступны, и предусмотреть дополнительные уровни контроля, такие как ограничение прав агента на уровне базы данных или системы контроля версий.
Организациям стоит оценивать не только удобство интеграции, но и наличие контроля над тем, какие именно ресурсы агент может читать и изменять. Без такого контроля MCP превращается в множитель существующих рисков LLM, а не в безопасный инструмент расширения возможностей. Решение о подключении требует сопоставления скорости разработки с необходимостью дополнительных мер защиты, включая мониторинг действий агента и регулярный пересмотр предоставленных прав доступа.
Источник
Это краткий разбор материала Сбер. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: MCP усиливает уязвимости ИИ-агентов.
Курс по теме — Каталог курсов Школы Больших Данных


