Более 20% проверенных MCP-политик доступа оказались сломанными или вообще отсутствовали — плохая новость для всех, кто уже подключает AI-агентов к Slack, календарям, тикетам и внутренним API. Безопасность MCP быстро превращается из архитектурной детали в практический вопрос: кто именно дал агенту токен, что он может трогать и когда этот доступ последний раз пересматривали.
О проблеме сообщает The New Stack со ссылкой на наблюдения Ясмин Раджаби, COO CloudBolt Software. Команда, по ее словам, несколько месяцев настраивала MCP-интеграции в клиентских и потенциальных клиентских окружениях и обнаружила: больше чем в одном случае из пяти политики доступа для MCP были либо некорректными, либо отсутствовали. Чаще всего сервер MCP работал не через сервисную учетную запись, а через чей-то личный токен. Ротации токенов не было. Журналов того, к каким данным обращался сервер, тоже.
Для тех, кто еще не успел устать от аббревиатуры: Model Context Protocol — это способ дать AI-ассистенту доступ к внешним инструментам и данным. Идея здравая: агент не просто болтает, а может открыть задачу, прочитать календарь, дернуть внутренний API, собрать контекст из GitHub или CRM. Проблема начинается там, где такая интеграция появляется быстрее, чем security-команда успевает сказать слово «scope».
The New Stack описывает типичный сценарий через условного Боба из финансов: человек за выходные собрал помощника для планирования, подключил его к Slack и нескольким внутренним API, а к понедельнику инструментом уже пользуются три отдела. Это не карикатура, а вполне узнаваемый портрет эпохи вайб-кодинга: AI снижает порог входа настолько, что внутренние инструменты начинают появляться не по квартальному плану платформенной команды, а между кофе и ужином. Вопрос не в том, хорошо это или плохо. Вопрос в том, на каком токене оно работает.
28 июля 2026 года мейнтейнеры MCP выпустили обновление спецификации, почти полностью посвященное авторизации: проверке issuer, client credentials, привязанным к issuer, и Client ID Metadata Documents как предпочтительному механизму регистрации клиентов. Если переводить с языка протоколов на язык продакшен-инцидентов, создатели MCP признали: исходная модель доверия не выдержала реальной эксплуатации. А значит, самодельные интеграции, собранные «на попробовать», тем более не должны получать индульгенцию.
Один из главных рисков — prompt injection через данные, которые агент воспринимает как инструкции. В мае 2025 года исследователи Invariant Labs показали, что MCP-сервер GitHub можно было атаковать через отравленный публичный issue: текст в описании задачи читался агентом как команда, после чего тот использовал токен жертвы для доступа к приватным репозиториям. Код сервера при этом не обязательно должен быть вредоносным. Достаточно поля с текстом, которое никто не считал частью атакуемой поверхности.
Позже бенчмарк MCPTox проверил похожие сценарии на 45 действующих MCP-серверах и 20 моделях. Средний показатель успешных атак составил 36,5%, а у худшей модели — 72,8%. Для разработчиков это неприятное напоминание: если агент читает сообщения в Slack, тикеты или комментарии в issue tracker и на их основе что-то делает, он должен уметь отличать рабочий запрос от строки, специально написанной для обхода его правил. По умолчанию он этого не умеет.
Вторая проблема скучнее, но опаснее: права часто выдают «с запасом». Серверу нужен read-only-доступ к календарю, а он получает read, write и admin, потому что так было в туториале или потому что узкий scope надо отдельно согласовывать. По данным, приведенным в материале, 88% MCP-серверов требуют учетные данные для работы, но только 8,5% реально используют OAuth. Остальные часто живут на статических API-ключах и персональных access token.
Третья дыра — отсутствие нормальной ротации и наблюдаемости. The New Stack приводит пример Splunk MCP Server app: приложение логировало session- и auth-токены в открытом виде до исправления в версии 1.0.3, уязвимость отслеживалась как CVE-2026-20205. И это продукт вендора с собственной security-командой, а не скрипт из личного репозитория аналитика. По оценкам из материала, больше половины MCP-серверов в реальной эксплуатации используют статические ключи или персональные токены, которые редко меняют, а почти половина enterprise AI-активности идет через личные аккаунты, а не сервисные учетные записи.
Для бизнеса неприятность не в самом MCP и не в том, что сотрудники автоматизируют рутину. Неприятность в слепой зоне. Компания может не знать, какие MCP-серверы уже запущены, какие токены они держат, к каким системам имеют доступ и кто отвечает за их отключение. Классический change advisory board тут помогает плохо: если согласование занимает недели, сотрудники просто продолжат обходить процесс. Безопасность MCP требует не бюрократии ради бюрократии, а инвентаря, минимальных прав, сервисных аккаунтов, ротации секретов и логов доступа.
Для русскоязычных команд вывод довольно практичный: если в компании уже разрешены AI-ассистенты и внутренние агенты, MCP-интеграции надо считать частью инфраструктуры, а не «личными макросами продвинутых сотрудников». Следующий заметный инцидент, скорее всего, случится не из-за сложной zero-day-атаки, а из-за инструмента, который честно выполнял задачу — просто с чужим персональным токеном и правами шире, чем кто-либо помнил.