MCP security config начинается не с антивируса, а с одного файла на вашем диске. Каждый раз, когда вы подключаете новый MCP-сервер к Claude Desktop, Cursor или Claude Code, вы вписываете токен в JSON, который лежит открытым текстом и запускает чужой код с вашими правами. Ниже разберём, где именно утекают claude mcp credentials, какие атаки на MCP серверы реально происходили в 2026 году и как настроить permissions так, чтобы утечка одного токена не превратилась в утечку всего аккаунта.
Главный риск MCP не в протоколе, а в конфиге: credentials хранятся открытым текстом, а серверы получают права вашего пользователя. Решение — переменные окружения вместо hardcode, read-only токены вместо полного доступа и pinning версий вместо @latest. В статье разберём три реальные атаки 2026 года и рабочий чеклист защиты.
Что такое MCP и почему конфиг агента это точка входа для атаки?
MCP связывает AI-хост, клиент и сервер в одну цепочку доверия. Если сервер скомпрометирован, агент выполняет его инструкции с вашими правами и вашими credentials.
MCP (Model Context Protocol) — открытый протокол Anthropic для подключения LLM к внешним инструментам: файлам, API, базам данных. К середине 2026 года экосистема выросла до 10 000+ опубликованных серверов, большинство из которых пишут независимые разработчики без формального ревью <cite index="15-1">— установка MCP-сервера по факту ближе к установке расширения браузера, чем к загрузке софта из проверенного магазина: вы напрямую доверяете автору</cite>.
В цепочке три звена: хост (Claude Desktop, Cursor), клиент, который управляет соединением, и сервер с набором тулов. Сервер описывает каждый инструмент текстом, и модель обучена доверять этим описаниям. Именно поэтому конфиг с credentials, который подключает сервер к хосту, становится точкой входа. Скомпрометированный сервер получает не абстрактный доступ, а конкретные права токена, который вы прописали в env. Один неудачно выданный ключ с правами на весь аккаунт GitHub — и агент способен натворить столько же, сколько вы сами вручную из терминала.
Какие атаки на MCP серверы реально происходили в 2026 году?
Три работающих сценария: tool poisoning через описание тула, shadowing между несколькими серверами и supply-chain атака через обновление пакета. У каждого есть подтверждённые инциденты с credentials.
Исследование 2 614 реализаций MCP-серверов от Endor Labs показало, что 82% используют операции с файлами, уязвимые к path traversal, 67% работают с API, склонными к code injection, и 34% подвержены command injection <cite index="19-1">— то есть больше трети деплоев MCP несут риск в базовой конфигурации, а не в экзотическом сценарии</cite>. Это не гипотеза, а статистика по уже установленным серверам.
Tool poisoning. Вредоносный сервер прячет инструкцию прямо в описании инструмента. На практике это выглядит как безобидный параметр вроде "side note", в который вшита команда передать SSH-ключи или содержимое .env. Модель читает описание тула как часть контекста и выполняет скрытую часть, даже если пользователь одобрил только видимую.
Shadowing между серверами. Когда хост подключён сразу к нескольким MCP-серверам, вредоносный сервер способен незаметно подменить поведение доверенного инструмента, например перенаправить исходящую почту на чужой адрес. Пользователь одобряет действие "доверенного" тула, а реально выполняется код чужого сервера.
Supply-chain через MCP pull rug. Сервер меняет описание инструмента уже после того, как пользователь его одобрил, и делает это без нового запроса на подтверждение. Разработчики Anthropic сами закрыли три уязвимости в официальном Git MCP-сервере в декабре 2025 года, включая обход валидации путей, который позволял создавать репозитории в произвольном месте файловой системы, и после этого полностью удалили инструмент git_init из релиза <cite index="20-1">— даже создатель протокола выпускал уязвимую реализацию собственного сервера</cite>.
Реальные инциденты с credentials уже задокументированы. В мае 2025 исследователь Invariant Labs показал, что одного публичного GitHub issue с вредоносным текстом хватило, чтобы вытащить содержимое приватных репозиториев через агента с GitHub MCP <cite index="22-1">— разработчику для этого достаточно было попросить ассистента посмотреть открытые issues в репозитории, без единого лишнего действия</cite>. В июле 2025 команда, подключившая Cursor к Supabase с правами service_role, получила тикет поддержки со встроенной AI-инструкцией, которая заставила агента вытащить интеграционные токены прямо в публичный тред <cite index="17-1">— комбинация избыточных прав, недоверенного входа и внешнего канала связи обернулась утечкой данных</cite>. В начале 2026 года на публичном интернете нашли больше 42 000 инстансов агента OpenClaw, из которых свыше тысячи гоняли MCP-эндпоинты вообще без аутентификации и светили API-ключи и Slack-токены наружу <cite index="20-1">— проблема оказалась не в протоколе, а в том, что развёртывания оставляли открытыми настройками по умолчанию</cite>.
| Тип атаки | Что происходит | Реальный кейс |
|---|---|---|
| Tool poisoning | Инструкция скрыта в описании тула | Модификация параметра запроса для передачи SSH-ключей |
| Shadowing | Вредоносный сервер подменяет поведение доверенного | Перехват письма при подключении к нескольким серверам |
| MCP pull rug | Описание тула меняется после одобрения пользователя | Уязвимости в официальном Git MCP-сервере, декабрь 2025 |
| Supply-chain | Компрометация через обновление пакета сервера | Незакреплённая версия @latest в конфиге |
| Prompt injection через контент | Инструкция внутри issue, тикета, страницы | Утечка приватных репозиториев через GitHub issue, 2025 |
Почему нельзя хранить credentials прямо в claude_desktop_config.json?
Файл конфига хранит все ключи открытым текстом на диске. Любой процесс или человек с доступом к файловой системе читает их без пароля и без дополнительного шага.
Путь до файла у Claude Desktop стандартный: на macOS это ~/Library/Application Support/Claude/claude_desktop_config.json, на Windows — %APPDATA%\Claude\claude_desktop_config.json. Внутри блока env каждого сервера токены лежат буквально текстом, без шифрования <cite index="14-1">— файл читается любым инструментом, который умеет открывать JSON, и права доступа к нему стоит настраивать так же строго, как к SSH-ключу</cite>.
Проблема не только в самом факте plaintext. Сервер запускается как подпроцесс вашего пользователя и видит только те переменные, которые вы явно передали в его блок env, а не весь ваш shell целиком <cite index="14-1">— это ограничивает блast radius одного сервера, но не отменяет того, что сам конфиг остаётся общей точкой хранения всех секретов сразу</cite>. Если вы подключили пять серверов с пятью разными токенами в одном файле, компрометация файла (не сервера) отдаёт все пять сразу.
| Способ хранения | Плюс | Минус |
|---|---|---|
| Hardcode в JSON | Просто и быстро | Открытый текст, риск утечки при коммите или бэкапе |
| Переменная окружения в env-блоке | Секрет не размазан по коду сервера | Всё ещё лежит в JSON, нужны права на файл |
| OS keychain / secret manager | Шифрование на уровне ОС | Сложнее настроить, поддерживают не все клиенты |
| Vault / гейтвей с короткоживущими токенами | Минимальное окно компрометации | Нужна инфраструктура, избыточно для соло-разработчика |
Максим: «Мог засесть до пяти утра, чтобы починить одну функцию, которая не работала. В моменте хотелось всё бросить, но я понимал: это можно и нужно решить, иначе дальше не пойдёшь. С безопасностью конфига та же история — доводишь до конца один раз, а не разгребаешь утечку потом.»
Как правильно использовать переменные окружения в MCP конфиге?
Хост сам передаёт переменные из блока env в процесс сервера при запуске. Секрет остаётся в одном месте вместо копий в коде и .env-файлах по проектам.
Архитектура MCP устроена так, что сервер это подпроцесс, который спавнит клиент, и рабочая директория этого подпроцесса не всегда совпадает с вашей папкой разработки. Поэтому классический .env в корне проекта часто просто не подхватывается: если клиент запускает сервер из другой директории, файл не найдётся <cite index="8-1">— протокол полагается на то, что именно хост-приложение инжектит переменные окружения в процесс сервера при подключении, а не на локальный дотенв-файл</cite>.
Практический пример из настройки GitHub MCP для Claude Code:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxx"
}
}
}
}Токен генерируется в GitHub через Settings → Developer settings → Personal access tokens, и именно на этом шаге стоит выбрать fine-grained токен, а не classic. Возможности сервера полностью определяются правами самого токена: один и тот же бинарник сервера с read-only токеном только читает репозиторий, а с токеном на запись — открывает PR и создаёт issue <cite index="32-1">— конфиг JSON при этом остаётся идентичным, разница только в правах токена</cite>. Держите такие переменные в shell-профиле или менеджере секретов, а не в промптах чата: если вставить токен прямо в переписку с агентом, он осядет в истории диалога.
Как ограничить permissions MCP серверов до минимума?
Выдавайте серверу только те права, которые реально нужны для задачи. Read-only токен вместо полного доступа снижает ущерб от утечки в разы, а не на проценты.
Принцип минимальных прав для MCP работает так же, как для любого API-ключа: агент, который читает календарь, получает токен со scope calendar:events:read, а не общий доступ ко всему аккаунту <cite index="25-1">— самая частая ошибка конфигурации это выдача избыточного скоупа read:all там, где реально нужен read:calendar, что нарушает принцип наименьших привилегий и расширяет зону поражения при утечке</cite>.
Три конкретных шага для вайбкодера:
Fine-grained токен вместо classic PAT. Классический токен GitHub действует на все репозитории, к которым у вас есть доступ, даже если выдавали его под один проект. Fine-grained токен привязывается к конкретному репозиторию, и это стало базовой практикой для agent-дизайна в 2026 году <cite index="27-1">— токен, выпущенный под один репозиторий, всё равно даёт доступ на уровне организации при утечке, если это classic PAT, а не fine-grained</cite>.
Read-only по умолчанию. Начинайте с прав только на чтение, расширяйте до записи по факту задачи. Такой подход рекомендуют для GitHub, GitLab и большинства других MCP-интеграций одинаково <cite index="30-1">— агенты, которые делают только read-задачи, получают read_api и read_repository, ничего сверх этого</cite>.
Pin версии, не @latest. Указывайте точную версию пакета сервера. Это закрывает supply-chain риск, когда обновление подменяет поведение сервера без вашего ведома <cite index="13-1">— закреплённая версия пакета устраняет именно ту уязвимость цепочки поставок, к которой обычно и ведёт тег @latest</cite>.
Отдельно про флаг bypass permissions в Claude Code: он убирает запрос подтверждения перед каждым действием агента, что удобно для скорости, но снимает последний барьер перед выполнением скрытой инструкции из тула. Использовать его стоит только в изолированной песочнице, не в проекте с боевыми ключами.
| Тип сервера | Минимальный scope | Когда расширять |
|---|---|---|
| GitHub / GitLab | read-only на конкретный репозиторий | Нужно создавать issue, PR, комментарии |
| Файловая система | доступ только к рабочей папке проекта | Никогда не давайте доступ к домашней директории целиком |
| База данных | read-only роль, не service_role | Только под конкретную миграцию, временно |
| Внешний API | ключ с лимитом запросов и IP-фильтром | Продакшн-нагрузка с мониторингом |
Что делать, если MCP-сервер уже скомпрометирован?
Отозвать токен, выпустить новый с урезанными правами, проверить логи и убрать сервер из конфига до полного аудита кода.
Если вы подозреваете утечку, первым делом отзовите токен в панели сервиса, а не меняйте только конфиг. MCP 2.4 спецификация 2026 года добавила аудит-логи в реальном времени и MFA для высокорисковых вызовов тулов на уровне enterprise-развёртываний <cite index="11-1">— это упрощает разбор инцидента, потому что видно, какой именно вызов инструмента произошёл и когда</cite>. Для соло-разработчика без корпоративной инфраструктуры логика та же вручную: смотрите логи API провайдера за последние дни, ищите запросы не из вашей геолокации или в нетипичное время.
Пример из практики 2026 года: CVE-2026-21852 позволял красть API-ключ Claude Code, перенаправляя его запросы на прокси-сервер атакующего и перехватывая заголовок авторизации целиком <cite index="24-1">— уязвимость с оценкой CVSS 5.3, которая работает именно через подмену адреса, а не через взлом самого ключа</cite>. Отдельно исследователи нашли класс атак через injectable Sentry DSN у 2 388 организаций с успешной эксплуатацией в 85% случаев на Claude Code, Cursor и OpenAI Codex CLI <cite index="24-1">— и в этом случае поставщик сервиса отказался признавать класс уязвимости устранимым на уровне приёма данных</cite>. Вывод один: временно выключайте сервер из конфига до аудита, а не оставляйте включённым «на всякий случай».
Итог: главные правила защиты MCP credentials на июль 2026
Пять шагов покрывают большинство реальных инцидентов: переменные окружения, права на файл, read-only токены, pinning версий и ревью исходников перед установкой.
Все атаки выше объединяет одно: они эксплуатируют не протокол MCP, а конкретную ошибку конфигурации. Собранный чеклист закрывает именно эти точки.
| Правило | Что даёт |
|---|---|
| Credentials только через env, не hardcode в JSON | Секрет не размазан по коду, легче ротировать |
| Права на файл конфига только вашему пользователю | Закрывает чтение файла посторонним процессом |
| Read-only токен по умолчанию | Урезает blast radius при утечке |
| Fine-grained токен на конкретный проект | Ограничивает область компрометации |
| Pin версии пакета сервера | Закрывает supply-chain риск обновлений |
| Ревью исходников перед установкой | Снижает риск непроверенных из 10 000+ серверов |
| Отключение bypass permissions в боевом проекте | Сохраняет барьер подтверждения действий |
Мы в VibeCoderz для быстрого старта смотрим настройки в каталоге инструментов: сравнение по MCP-интеграциям есть на странице claude-code и на странице cursor. Если работаете с CI/CD и токенами на постоянной основе, полезно свериться с подборкой в каталоге агентов для devops.
Частые вопросы про MCP security config
Можно ли хранить API-ключ прямо в claude_desktop_config.json? Технически да, но не стоит. Файл хранит данные открытым текстом, и доступ к диску сразу отдаёт ключ. Переносите его в блок env и ограничивайте права на сам файл.
Чем tool poisoning отличается от prompt injection? Prompt injection прячет команду в контенте, который читает агент, например в issue. Tool poisoning прячет её в описании инструмента на сервере, и модель видит её при каждом вызове тула.
Нужно ли ограничивать permissions, если сервер локальный? Да. Локальный сервер работает с правами вашего пользователя и может читать файлы и сеть так же свободно, как вы сами за терминалом.
Что делать, если токен уже утёк? Отозвать его в панели сервиса, выпустить новый с урезанными правами, проверить логи API за последние дни и временно убрать сервер из конфига.
Безопасно ли использовать bypass permissions в Claude Code? Флаг убирает запрос подтверждения перед каждым действием, а вместе с ним и последний барьер перед скрытой инструкцией. Используйте только в песочнице, не в проекте с боевыми credentials.
Чем отличается защита MCP в Cursor и Claude Code? Формат конфига почти одинаковый, оба используют блок mcpServers с env-переменными. Claude Code дополнительно поддерживает project-level .mcp.json с локальной областью видимости, а Cursor подхватывает изменения без перезапуска.
Сколько MCP-серверов безопасно держать подключёнными одновременно? Технического лимита нет, но каждый сервер грузит описания тулов в контекст модели при старте сессии. Практический ориентир — 3-5 серверов на обычный workflow, больше десяти уже стоит собирать через единый гейтвей.
Разберитесь с конфигом сейчас, а не после инцидента: посмотрите обзоры инструментов в каталоге AI IDE и MCP-совместимых агентов на vibecoderz.ru/ide. Если нужен разбор конкретной конфигурации под ваш проект, запишитесь на консультацию к Максиму: t.me/maxnagovitsyn.
Обновлено: октябрь 2026.
