У каждого MCP server на HostedMCP внизу есть короткая пометка: серверы из каталога работают с теми правами, которые вы им даёте, поэтому перед установкой проверьте исходники. Мы добавили её потому, что самая частая проблема безопасности в MCP — не хитрый эксплойт, а кто-то вставил URL базы данных с полным доступом на запись в сервер, который нашёл пять минут назад.
Этот гайд охватывает оба вида рисков. Обычные, вроде слишком широких прав, — с них начинается большинство инцидентов. Риски на уровне протокола, вроде token passthrough и confused deputy, важны, если вы пишете или хостите серверы. Каждый из них мы привязали к официальным рекомендациям по безопасности MCP для ревизии 2026-07-28, а также к тому, что видим в собственном каталоге.
Основные выводы
- Большинство инцидентов в MCP начинается с обычных ошибок: слишком широкие права и серверы, которые никто не проверял.
- Модель читает недоверенный текст, поэтому любую доступную ей тулу можно направить через веб-страницу, issue или письмо.
- Локальные серверы работают с вашими правами; удалённые серверы должны следовать OAuth 2.1 и никогда не передавать токены дальше.
- Минимальный доступ, подтверждение для всего, что пишет, закреплённые версии и меньше серверов на агента предотвращают большинство проблем.
| Риск | Кого затрагивает | Основная защита |
|---|---|---|
| Prompt injection через контент | Всех, чей агент читает веб-страницы, issue или письма | Подтверждение перед записью; никаких необратимых тулов рядом с недоверенным вводом |
| Локальный сервер работает от вашего имени | Всех, кто устанавливает stdio-серверы | Доверенные издатели, ограниченные секреты, закреплённые версии |
| Ошибки OAuth в удалённых серверах | Разработчиков и хостов серверов | Следовать спецификации авторизации MCP; никакого token passthrough |
| Слишком много всего в одном месте | Агентов с множеством серверов | Давать каждому агенту только те серверы, которые нужны для его задачи |
Почему MCP меняет картину безопасности
Традиционная интеграция — это код, который написал разработчик и который вызывает API так, как было задумано заранее. С MCP модель во время выполнения решает, какой инструмент вызвать и с какими аргументами, опираясь на всё, что есть в её контексте. Часть этого контекста — текст, который никто из вашей команды не писал: веб-страница, которую загрузила модель, issue на GitHub, письмо, результат работы другого инструмента.
В этом предложении — вся суть проблемы. Модель принимает решения, читая недоверенный ввод. Большинство рисков MCP сводятся к одному из двух: «недоверенный текст повлиял на вызов инструмента» или «у инструмента было больше доступа, чем нужно, когда это произошло».
Риск 1: prompt injection через контент
Допустим, вы подключили GitHub server с правом комментировать и закрывать issues, и просите агента разобрать новые issues. В одном из них, глубоко в длинном логе, спрятана строка, которая велит ассистенту закрыть все открытые issues как дубликаты. Модель, следующая инструкциям из данных, сделает именно это.
Протокол этому никак не мешает: рассуждения модели протокол проверить не может. Помогает эшелонированная защита. Хорошие хосты запрашивают подтверждение перед инструментами, которые меняют данные, и показывают вам аргументы вызова. Хорошие серверы помечают инструменты, которые пишут или удаляют, чтобы хосты могли обращаться с ними иначе. А ещё можно держать доступ агента узким под задачу: для разбора нужно читать и ставить метки, а не закрывать и удалять.
Внимание
Агент, который читает недоверенный контент, не должен располагать инструментами для необратимых действий без подтверждения человеком. Этого правила придерживаемся и мы сами.
Риск 2: локальный сервер работает от вашего имени
Локальный сервер — это программа на вашем компьютере, которую запускает ваше AI-приложение с правами вашего пользователя. Она может читать файлы, доступные вам, и выходить в сеть, доступную вам. В рекомендациях по безопасности MCP это выделено в отдельный риск: вредоносный или скомпрометированный локальный сервер может выполнять произвольные команды с привилегиями клиента — поэтому при установке в один клик нужно явное согласие и показ точной команды.
Локальные серверы составляют большую часть нашего каталога, особенно среди инструментов для разработчиков, и многим из них нужны секреты. На 11 ноября 2026 года 11 660 серверов объявляли переменные окружения, и 12 757 из этих переменных были помечены как секреты: API-ключи, токены и пароли, которые лежат в конфигурационном файле вашего клиента.
Как серверы в нашем каталоге, по их словам, выполняют аутентификацию — по README, которые прочитала наша модель обогащения данных (измерено November 14, 2026):
| Аутентификация | Серверы | Поделиться |
|---|---|---|
| Нет | 18 605 | 46% |
| API ключ или OAuth | 10 520 | 26% |
| API ключ или токен | 9 248 | 23% |
| OAuth | 2 389 | 6% |
Что с этим делать — в основном здравый смысл, применённый последовательно.
Предпочитайте серверы от вендора продукта или от издателя, чьи другие работы вы можете посмотреть. На страницах серверов мы показываем издателя и отмечаем официальные серверы.
Проверьте, что исходный код открыт и проект жив. Пакет без привязанного репозитория или репозиторий, последний раз изменённый год назад, — это более крупная ставка. На каждой странице HostedMCP показаны дата последнего коммита и дата релиза.
Прочитайте список инструментов перед установкой. Если у сервера «погоды» есть инструмент, выполняющий команды оболочки, остановитесь.
Ограничьте область действия секрета. Дайте серверу базы данных пользователя только для чтения. Дайте серверу GitHub fine-grained токен для одного репозитория. Направьте файловый сервер на одну папку проекта и никогда — на ваш домашний каталог.
Совет
Закрепляйте версии для всего важного.
npx -y some-server@latestпри каждом запуске выполняет то, что было опубликовано последним;npx -y some-server@1.4.2выполняет версию, которую вы проверили.
В спецификации назван ещё один локальный риск, о котором стоит знать, если вы запускаете прокси: в конфигурации, где веб-страница может достучаться до локального MCP-прокси, ошибка cross-site scripting на этой странице может перерасти в выполнение команд через stdio-сервер прокси. Если вы запускаете MCP-шлюз или прокси на localhost, относитесь к нему как к любому другому локальному сервису с поверхностью атаки.
Риск 3: удалённые серверы и OAuth
Удалённые серверы не касаются вашей машины, но хранят токены множества пользователей и обращаются от их имени к другим сервисам — отсюда свой набор проблем. В списке лучших практик безопасности MCP несколько из них названы прямо.
| Атака | Что идёт не так | Защита |
|---|---|---|
| Передача токена насквозь | Сервер принимает токен, выданный не ему, или передаёт токен пользователя вышестоящему сервису | Принимать только токены, выданные этому серверу; никогда не передавать их дальше |
| Confused deputy | Прокси со статическим client ID выдаёт вредоносному клиенту код без реального согласия | Согласие для каждого клиента на стороне прокси |
| Server-side request forgery | OAuth discovery указывает клиенту на внутренние URL, например на метаданные облака | Клиенты проверяют URL из discovery |
| Mix-up attack | Вредоносный сервер авторизации отправляет код на token endpoint честного сервера | Проверка iss (RFC 9207), добавлена в 2026-07-28 |
| Злоупотребление authorization URL | Сервер возвращает javascript: URL или символы оболочки |
Клиенты проверяют URL перед открытием |
| Подмена redirect на localhost | Другой локальный процесс перехватывает код, отправленный на localhost |
Аккуратная обработка redirect в десктопных клиентах |
| Слишком широкие scopes | Утёкший токен позволяет сделать гораздо больше, чем требовалось для задачи | Запрашивать минимально необходимый scope |
Правило, стоящее за первой строкой, однозначно: MCP server не должен принимать токены, которые не были явно выданы для этого MCP server.
В редакции 2026-07-28 также объявлен устаревшим OAuth Dynamic Client Registration в пользу Client ID Metadata Documents, а stateless-дизайн заменил сессии протокола, так что прежние опасения насчёт перехвата сессий теперь формулируются как перехват state-хэндлов, которые выдаёт сервер. Если ваш сервер хранит состояние, делайте эти хэндлы непредсказуемыми и привязывайте их к пользователю.
Риск 4: слишком много в одном месте
Самый незаметный риск — концентрация. Один агент с сервером GitHub, сервером Slack, сервером базы данных и сервером браузера может читать код, читать сообщения, запрашивать данные клиентов и посещать любой сайт — всё в одном контексте. И одной внедрённой инструкции есть с чем работать, включая способы отправить данные наружу.
Разделение помогает. Давайте агенту серверы для текущей задачи, а не всё, что у вас есть. Держите серверы, которые читают конфиденциальные данные, подальше от серверов, которые могут публиковать во внешний мир, или хотя бы требуйте подтверждения для исходящих.
Чек-лист для тех, кто устанавливает серверы
Прежде чем добавлять сервер, несколько минут проверки избавят от большинства проблем.
- Выясните, кто его публикует. Официальный вендор или мейнтейнер, которого можно найти.
- Убедитесь, что код открыт и проект поддерживается в последнее время.
- Прочитайте названия и описания всех инструментов. Всё, что не соответствует назначению сервера, — тревожный сигнал.
- Дайте минимальный доступ: пользователи только для чтения, токены на один репозиторий, одна папка.
- Держите операции записи и удаления за подтверждением и не давайте постоянного разрешения, пока не доверяете серверу.
- Фиксируйте версии серверов, от которых зависите, и обновляйте их осознанно.
- Удаляйте серверы, которыми больше не пользуетесь. Каждый установленный сервер — это поверхность атаки и расход контекстного окна.
На каждой странице сервера на HostedMCP указаны издатель, последний коммит, необходимые переменные окружения и полный список инструментов — это закрывает первые четыре проверки за минуту.
Чек-лист для тех, кто делает серверы
Если вы поддерживаете сервер, ответственности на вас больше.
- Давайте доступ только к минимальному набору инструментов, которого достаточно для задачи, и называйте их по выполняемым действиям.
- Помечайте инструменты, которые пишут или удаляют данные, подсказкой destructive, чтобы хосты могли сначала спросить подтверждение.
- Проверяйте каждый аргумент так, будто он пришёл от злоумышленника, потому что так может и оказаться.
- Пишите логи в stderr, никогда в stdout, и никогда не логируйте секреты.
- Для удалённых серверов следуйте спецификации авторизации MCP: OAuth 2.1, принимайте только токены, выданные для вашего сервера, без передачи токенов, с узкими scope.
- Относитесь к дескрипторам состояния как к секретам: случайные, привязанные к пользователю, недолговечные.
- Документируйте каждое разрешение и переменную окружения, которые нужны вашему серверу, только с placeholder-значениями.
Наше руководство по созданию MCP server показывает основы с текущими SDK, а MCP vs API объясняет, почему возвращать меньше данных — это тоже выигрыш в безопасности.
Работа с MCP в команде
Как только MCP начинает использовать больше нескольких человек, установка «кто как умеет» перестаёт масштабироваться. Несколько привычек делают процесс управляемым.
| Привычка | Чем помогает |
|---|---|
| Утверждённый список серверов с закреплёнными версиями в репозитории | Все запускают одни и те же проверенные версии |
| Отдельные идентичности для агентов | В журналах аудита видно, какие действия выполнил агент; при отзыве доступа никто не остаётся заблокированным |
| Hosted-серверы для SaaS-продуктов | Никаких API-ключей на ноутбуках; доступ регулируется административными настройками продукта |
| Логирование вызовов инструментов | После неожиданного инцидента в логах видно, какой контент повлиял на модель |
| Проверка обновлений как зависимостей | Новый код, получающий ваши права, прочитывается до запуска |
Ведите утверждённый список. Выберите серверы, которые команда может использовать, закрепите их версии и распространяйте конфигурацию через репозиторий, а не через домашний каталог каждого разработчика. Для этого и существуют .mcp.json уровня проекта в Claude Code и .vscode/mcp.json рабочей области в VS Code, а в наших руководствах по клиентам показано, где каждый инструмент хранит конфигурацию проекта.
Дайте агентам собственные идентичности. Сервисная учётная запись или токен бота для агента, отдельные от учётных данных любого человека, делают очевидным в журналах аудита, какие действия выполнил агент, и позволяют отозвать доступ, никого не блокируя.
Предпочитайте hosted-серверы для SaaS. Когда вендор запускает MCP server для собственного продукта, вы избавляетесь от раздачи API-ключей на ноутбуки, а доступ регулируется теми же OAuth-разрешениями и административными настройками, что и остальной продукт. Наш список удалённых серверов — быстрый способ увидеть, какие вендоры его предлагают.
Логируйте вызовы инструментов. Большинство хостов умеют записывать, какие инструменты запускались и с какими аргументами. Храните эти логи там же, где остальные журналы аудита, и просматривайте их после любого неожиданного события; обычно они точно показывают, какой фрагмент контента повлиял на модель.
Проверяйте обновления как зависимости. Обновление сервера — это новый код, работающий с вашими правами. Читайте changelog для серверов, которые могут писать в продакшен-системы, так же, как вы бы читали его для библиотеки.
Что HostedMCP проверяет, а что нет
Мы — каталог, а не аудитор безопасности, и стоит чётко обозначить границу. Для каждого листинга мы читаем репозиторий, пакеты и README, фиксируем издателя, последний коммит, релизы и объявленные переменные окружения и показываем полный список инструментов. Листинги массовых издателей помечаются, а форки и зеркала объединяются с оригиналом.
Мы не запускаем серверы и не аудируем их код. Листинг на HostedMCP означает, что мы его нашли и точно описали, а не что он безопасен для вашей среды. Это решение остаётся за вами, а чек-листы выше — это то, как мы бы его принимали.
Если вы только начинаете во всём этом разбираться, что такое MCP и что такое MCP server — хорошие точки старта, а наш список удалённых серверов — самый простой способ попробовать серверы, которые вообще не касаются вашей машины.