Безопасность в технологиях искусственного интеллекта становится всё более насущной проблемой на фоне стремительного распространения и применения систем с поддержкой вызова внешних инструментов. Проект Model Context Protocol (MCP), получивший широкое признание и пользующийся популярностью среди разработчиков, в последние годы оказался в центре внимания не из-за инноваций в функциональности, а из-за масштабных проблем, связанных с информационной безопасностью. Журналисты и эксперты с иронией отмечают, что «S» в аббревиатуре MCP символизирует именно безопасность, но не в позитивном смысле. Важно понять, почему подобные уязвимости до сих пор остаются нерешёнными и какой путь нужно пройти индустрии, чтобы повысить уровень защиты систем, использующих вызов инструментов. Истоки нынешнего кризиса берут начало ещё до появления MCP и напрямую связаны с основополагающими архитектурными особенностями современных языковых моделей и принципами их взаимодействия с внешними ресурсами.
ООП в процессе вызова инструментов: от первых уязвимостей к новой реальности Проблема безопасности в системах, поддерживающих вызов инструментов, возникла задолго до появления MCP. В 2023 году OpenAI запустила функцию function calling, которая позволяла языковым моделям взаимодействовать с внешними приложениями и сервисами. Однако вскоре было обнаружено, что эти механизмы содержат серьёзные лакуны в безопасности. Случаи обхода аутентификации, манипуляций с OAuth-переадресациями и компрометации плагинов — все они продемонстрировали, насколько система остро нуждается в доработке. Исследования, например, показывающие уязвимость к подтасовке данных с помощью встроенных в маркдаун изображения, выявили высокий риск получения доступа к конфиденциальной информации через на первый взгляд безобидные средства.
Все эти проблемы базируются на одной и той же фундаментальной проблеме — языковая модель не способна чётко отделять доверенные данные от неtrusted входа пользователя. С появлением MCP, который был разработан с целью стандартизации и упрощения взаимодействия LLM с инструментами, проблема уязвимостей лишь вышла на новый уровень. Стандартный протокол предполагал повышенную совместимость и масштабируемость, но вместе с тем увеличил поверхность атаки, предоставляя злоумышленникам больше возможностей для эксплуатации известных дыр. В ходе нескольких серьезных инцидентов, например, выявлены уязвимости, позволяющие внедрять вредоносные инструкции через описания инструментов, которые затем влияют на поведение AI. Такие случаи именуются tool poisoning или отравлением инструментов.
Это не новый вектор атаки, но MCP сделал возможным его более широкий и быстрый распространение, поднимая проблему для сообщества на новый уровень важности. Существующие типы атак и почему MCP усугубляет проблему Угрозы, с которыми столкнулся MCP, в большой степени являются переработанными или укрупненными версиями давно известных видов атак. Команда исследователей фиксирует случаи так называемой инъекции команд, которая использует уязвимости классического программного обеспечения, такие как небезопасное использование функций типа os.system(). MCP лишь предоставил новый канал для их активации через посредство языковой модели.
Аналогичным образом supply chain атаки, где доверенные инструменты внезапно меняют свой функционал в худшую сторону, теперь становятся масштабируемыми и более разрушительными благодаря широкой интеграции MCP во всевозможные системы и сервисы. Особое место занимают механизмы, при которых один сервер MCP может запутать другого, заставляя последнего выполнять ненадёжные действия. Это классический пример confused deputy, где AI-агент становится «невольным сообщником» злоумышленников. Такой уровень взаимодействия, где различные узлы протокола могут влиять друг на друга опосредованно, делает безопасность всей экосистемы крайне уязвимой. Архитектурные причины уязвимостей: невозможно отделить доверенные данные от пользовательского ввода Корень всех описанных проблем заключается в фундаментальной архитектурной особенности современных LLM.
Все данные — инструкции разработчиков, ввод пользователя, описания инструментов, результаты их работы — объединяются в единый поток токенов, который обрабатывается без чётких границ безопасности. В отличие от традиционных систем с предсказуемой, детерминированной обработкой, языковые модели не обладают механизмом разграничения контекстов доверия. Это означает, что любые попытки механически защитить систему через фильтрацию, подготовленные инструкции или статический анализ оказываются малоэффективными. Простая инъекция текста в поток ввода изменяет интерпретацию и заставляет AI выполнять команды, которые он в иных обстоятельствах бы проигнорировал. Это касается и сложных живых сценариев, где такие атаки похожи не столько на технический взлом, сколько на психологическую манипуляцию, социальную инженерию, реализованную на основе естественного языка.
Многие исследования, включая публикации OWASP, демонстрируют, что уязвимость под названием prompt injection уже давно признана одной из главных угроз в мире LLM-приложений. Она активно эксплуатируется, и добиться стопроцентной защиты в современных архитектурах крайне сложно. Психологический и технический вызовы перед разработчиками Для специалистов по безопасности и разработчикам сложность MCP в том, что привычные инструменты тестирования и обнаружения уязвимостей оказываются бесполезными или ненадёжными. Уязвимости не всегда воспроизводимы однозначно, поскольку результат зависит от множества факторов, включая состояние модели, историю взаимодействия и даже случайные вариации в генерации. Это не просто техническая проблема, а вызов целой парадигме безопасного программирования, основанного на детерминированной логике.
Теперь разработчики вынуждены работать в среде, где поведение системы зависит от интерпретации естественного языка и контекстной информации, что вводит элемент неопределённости и делает анализ угроз более похожим на борьбу с социальными манипуляциями, чем на борьбу с традиционными уязвимостями. Распространение MCP и масштабирование угроз MCP, с одной стороны, ускорил развитие инструментов и сервисов, а с другой — значительно увеличил масштабы потенциальных атак. Уязвимость в одном популярном сервере MCP могла повлиять на тысячи downstream систем, что подтверждается, например, инцидентом с базой данных SQLite у Anthropic. Публикация и распространение известной уязвимости привели к цепной реакции компрометации множества приложений, демонстрируя опасность масштабного распространения угроз через единую экосистему. Не менее серьезной является проблема remote code execution, где злоумышленники способны выполнить произвольный код на машине разработчика или конечного пользователя, используя уязвимости, совмещённые с недостаточной аутентификацией и уязвимостями типа CSRF.
MCP создал архитектуру, в которой подобные атаки становятся более вероятными и потенциально наносят огромный ущерб. Ответ индустрии и перспективы развития архитектуры безопасности В ответ на открывающиеся уязвимости появляются инструменты сканирования и мониторинга, призванные предупреждать и выявлять атаки. Однако подавляющее большинство из них — это попытки лечить симптомы и сокращать количество инцидентов, а не устранить корень проблемы. Современные исследования указывают на то, что необходима фундаментальная архитектурная переосмысление, способное разделять доверенные сигналы и ненадёжные данные ещё на этапе подачи информации в модель. Одним из перспективных направлений является использование нескольких языковых моделей, где одна отвечает за обработку доверенных инструкций, а другая — за работу с пользовательским входом.
Известный пример — Google CaMeL framework, который демонстрирует улучшенное отделение контекста безопасности, пусть и с ощутимыми затратами ресурсов и снижением функциональности. Выводы и данный момент: честный взгляд на проблему Безопасность вызова инструментов в AI-системах — это не проблема одного протокола или продукта. Уязвимости, делающие MCP заметным в новостях, являются скорее символом масштабной, фундаментальной архитектурной дилеммы. Пока разработчики не смогут создавать LLM, понимающие и разграничивающие доверенные и недоверенные источники данных на уровне самой модели, мы будем наблюдать повторение одних и тех же сценариев взлома в разных обёртках. Защита в таких условиях предполагает не только технические меры, но и новые модели мышления, где безопасность воспринимается как спектр вероятностей и контекстных факторов, а не статичный набор правил.
Разработчикам придётся адаптироваться к работе в условиях неопределённости, сочетая традиционные подходы и инновационные техники контроля и аудита. Понимание этих ограничений — первый шаг к тому, чтобы не рассматривать MCP как источник проблем, а как катализатор необходимых преобразований в индустрии искусственного интеллекта, который вынуждает обратить внимание на глубокие и сложные вопросы безопасности. Только честный взгляд и технологическое новаторство помогут создать действительно надёжные AI-системы будущего, где проблемы безопасности будут решаться на корневом уровне, а не частично маскироваться поверхностными средствами.
