Безопасность MCP стала проблемой не из-за одного критического бага в протоколе, а из-за старой боли корпоративной ИБ: слишком широких прав, вечных токенов и разрешений, которые никто не пересматривает. Anthropic вывела Model Context Protocol в продакшен в конце 2024 года, после чего вокруг него быстро выросли тысячи серверов, а сам MCP подхватили Microsoft, Google и OpenAI, сообщает The New Stack.
MCP нужен как прослойка между AI-агентом и внешними инструментами: репозиториями, таск-трекерами, CRM, базами данных, облачными сервисами. Для разработчиков это удобный стандарт подключения контекста к модели. Для безопасников — новый класс интеграций, который часто получает доступ к данным быстрее, чем команда успевает понять, кто именно этот доступ выдал, на какой срок и зачем.
Ключевой тезис материала: атаки на MCP чаще выглядят не как взлом криптографии или эксплуатация низкоуровневой уязвимости, а как использование уже выданных полномочий. Учетные данные, которые казались разумными в день подключения, через несколько месяцев превращаются в тихий риск. Проект сменил задачу, агент стал жить дольше, область данных расширилась, а токен остался прежним — широкий, постоянный и почти невидимый для регулярного аудита.
Цифры хорошо объясняют масштаб. В опросе SANS 2026 Identity Threats Survey участвовали более 500 специалистов по безопасности. 76% организаций сообщили о росте числа нечеловеческих идентичностей, а 74% используют AI-системы, которым для автономной работы нужны постоянные учетные данные. При этом ни один из защитных механизмов — approval-процессы, sandboxing или логирование — не применяется более чем у 40% компаний. Иными словами, агенты уже получили ключи от рабочих систем, но охрана на входе все еще живет в эпохе обычных SaaS-интеграций.
В качестве примеров приводятся инциденты 2025 года. В мае злоумышленник использовал prompt injection против GitHub MCP server и смог получить данные приватных репозиториев. Проблема была не только в самой атаке на инструкции модели: за сервером стоял personal access token с областью доступа шире, чем требовала задача. Через несколько дней в MCP-интеграции Asana нашли логическую ошибку, которая допускала cross-tenant access, потому что граница между клиентами не была жестко зафиксирована на уровне разрешений.
Исследователи описывают такие риски через два уже знакомых паттерна. Первый — tool poisoning, когда описание инструмента или сервера содержит скрытые инструкции для агента. Второй — confused deputy problem: агент действует как доверенный посредник и получает больше полномочий, чем нужно для конкретного действия. Для бизнеса это неприятная комбинация: формально доступ выдан легитимно, но фактически агент может стать каналом утечки или несанкционированного изменения данных.
Практический вывод довольно приземленный: безопасность MCP требует не еще одного сканера, а переделки модели разрешений. Интеграции стоит дробить по задачам, пользователям, сайтам, репозиториям или workspace, а не выдавать доступ на всю организацию. GitHub в своих рекомендациях по secure remote MCP servers предлагает изолировать секреты для каждого экземпляра, ограничивать запросы пользователем, который выполняет действие, и проверять авторизацию для каждого действия отдельно. Постоянные токены лучше заменять временными динамическими учетными данными, которые создаются под конкретную операцию.
Отдельная проблема — идентичность AI-агента. Сейчас многие агенты фактически работают как человеческий OAuth-токен в чужом пальто: своей устойчивой identity у них нет, срок жизни задачи в модели доступа почти не учитывается, а права наследуются от человека или от заранее созданного технического пользователя. Это терпимо, когда агент живет минуты. Но если агент начинает работать неделями или месяцами, ему нужна собственная идентичность, отдельные логи, ограниченный радиус поражения и пересмотр прав при изменении задачи.
OAuth здесь тоже выглядит не идеально. Его модель согласия рассчитана на человека, который видит список scopes и нажимает кнопку разрешения. На практике люди редко читают эти списки внимательно, а у автономного процесса и вовсе нет нормального момента осознанного согласия. В отрасли уже обсуждаются черновики IETF, где срок жизни токена привязывается к жизненному циклу задачи, а агенты получают стабильные идентификаторы, отличные от пользователя-инициатора. Но это пока ранние предложения, а не стандарт, который можно просто включить в настройках.
Для русскоязычных команд вывод неприятный, но полезный: подключая MCP к GitHub, Jira, Asana, Notion, внутренним базам или продакшен-инфраструктуре, надо думать не только о том, «умеет ли агент вызвать инструмент». Вопрос жестче: что именно он может прочитать, что может изменить, кто это увидит в логах и кто отзовет доступ, когда эксперимент станет постоянной частью рабочего процесса. Следующий этап зрелости AI-инфраструктуры, похоже, будет измеряться не количеством подключенных MCP-серверов, а тем, насколько быстро компания научится забирать у агентов лишние ключи.