Model Context Protocol (MCP) стремительно занимает лидирующие позиции в сфере интеграции искусственного интеллекта с внешними инструментами и API, соединяя мощные языковые модели вроде Claude и GPT с разнообразными внешними системами. Несмотря на многообещающий потенциал, внедрение MCP сопровождается серьёзными вызовами в области безопасности, которые становятся препятствием для полного раскрытия возможностей этой технологии. В недавних исследованиях специалисты по кибербезопасности заметили частые случаи пробелов и уязвимостей в MCP-серверах, что усиливает необходимость комплексного подхода к обеспечению защиты. Без надежных мер предосторожности MCP может стать уязвимым звеном, открывая злоумышленникам прямой путь к системам компании. Одной из ключевых уязвимостей является доступность MCP-серверов с публичных IP-адресов.
Если такие серверы могут быть найдены через поисковые системы типа Shodan, любой пользователь интернета получает возможность произвольно обращаться к вашим эндпоинтам, создавая потенциальные точки входа для несанкционированных действий. Чтобы минимизировать этот риск, крайне важно ограничить публичный доступ, используя персональные VPN-сети либо API-шлюзы с жёсткой фильтрацией запросов по IP-адресам и диапазонам. Ещё одной распространённой проблемой становится отсутствие слоя аутентификации на MCP-серверах. В стандартных настройках многие решения пропускают незаверенные запросы, что позволяет злоумышленникам выдавать себя за легитимных агентов. Внедрение надёжной системы аутентификации с использованием токенов – OAuth2, подписанных JWT или bearer-токенов с ограниченным доступом – считается обязательным для предотвращения подобных инцидентов.
Помимо аутентификации, важное значение имеет и авторизация. Поскольку MCP-протокол не предусматривает разграничения прав доступа, многие реализации предоставляют агентам избыточные разрешения после верификации. Это создаёт возможность для агентов с широкими полномочиями востребовать, просмотреть или изменить данные, выходя за рамки допустимых функций. Введение модели наименьших привилегий и проверка контекста каждого запроса обеспечивают дополнительный уровень контроля и минимизируют вероятность злоупотреблений. Отсутствие аудита действий агентов также усугубляет проблему безопасности.
Без детальных логов невозможно проследить, какие операции были совершены, и своевременно отреагировать на подозрительную активность. Ведение полного журнала запросов с информацией о происхождении, используемых полномочиях, выполненных действиях и результатах становится незаменимым инструментом для отладки и защиты системы. Опасность также таится в распространённой практике хранения секретных данных прямо в исходных кодах репозиториев. Многие проекты на GitHub содержат в открытом доступе конфиденциальные ключи API, внутренние IP-адреса и базы данных, что делает их лёгкой добычей для хакеров. Решением становится использование переменных окружения и специализированных сервисов для безопасного управления секретами, а также периодический аудит кода с применением автоматизированных сканеров, таких как TruffleHog.
Техническая уязвимость, связанная с инъекциями различных типов, дополняет список опасностей. Один из примеров — SQL-инъекция в эталонном SQLite-сервере Anthropic, который используется в MCP-среде. Вредоносные команды могут внедряться через несанкционированные входные данные, влияя на работу моделей и цепочек инструментов. Стандарты разработки в области веб-безопасности должны применяться и к интерфейсам MCP, включая тщательную фильтрацию и очистку всех входящих данных и даже ответов моделей. Еще один серьёзный вызов — отсутствие защиты от перегрузки запросами и злоупотребления.
Агентов в MCP-среде могут атаковать массовым количеством запросов, что ведёт к отказу в обслуживании (DoS), перерасходу вычислительных ресурсов и злоупотреблению доступными функциям. Для снижения рисков необходимо внедрять ограничение частоты запросов, верификацию источников запросов и мониторинг аномалий в поведении системы. Отдельного внимания заслуживает проблема избыточных полномочий у агентов. Чрезмерная открытость доступа, часто оправдываемая стремлением ускорить разработку, создаёт уязвимости, через которые можно получить доступ ко всей базе данных или критическим системам. Подход, при котором агенты воспринимаются как недоверенные субъекты, позволяет ограничивать их действия строго в рамках конкретных бизнес-задач и предотвращать масштабные утечки.
Идентификация и разграничение субъектов действий в MCP также вызывают сложности. Когда агенты действуют от имени пользователей, важно иметь чёткое понимание кто инициировал каждую операцию. Отсутствие механизмов строгой атрибуции приводит к отсутствию ответственности, невозможности делегирования прав и проблемам с откатом операций. Для решения этой задачи внедряют структуру делегирования, повышая прозрачность посредством токенов, в которых зашифрованы как данные агента, так и пользователя. Взаимодействия между агентами посредством MCP дают новые возможности, но с ними связаны и новые угрозы в виде цепочек доверия.
