Dopamine/AI
AI

41% MCP-серверов в реестре — без авторизации. Разбираюсь, что такое MCP и как не словить дыру в безопасности

Полгода назад я объяснял заказчикам, что такое MCP, на пальцах и с извинениями - «ну это как бы протокол, чтобы модель дотягивалась до ваших данных, сорри, сыровато ещё». Сегодня на MCP сидит весь рынок: OpenAI, Google, Microsoft — все за последний год. А в реестре серверов, на минуточку, почти половина — без авторизации вообще. То есть люди тащат в прод интеграцию, которая раздаёт доступ к своим API и базам всем подряд, и даже не знают об этом.

Ну тут вот нарисовано как оно работает 
Ну тут вот нарисовано как оно работает 

Разберу по-честному: что такое MCP, как я сам его использую в стеке (FastAPI + MCP-серверы + PostgreSQL), какие там реальные цифры и где рынок массово стреляет себе в ногу.

Что такое MCP простыми словами

Model Context Protocol придумала Anthropic в ноябре 2024 — как единый стандарт, чтобы не городить кастомную интеграцию под каждую пару «модель + внешний сервис». До MCP это выглядело так: хочешь, чтобы агент лазил в Notion, Slack, Postgres и твой внутренний API — пиши четыре разных адаптера, для каждой модели отдельно. После MCP — один сервер, который одинаково понимают Claude, ChatGPT и Gemini.

По сути это «USB-C для ИИ»: не самое оригинальное сравнение, но точное — раньше было двадцать проприетарных разъёмов, теперь один стандартный.

В декабре 2025 Anthropic отдала протокол в Linux Foundation (в Agentic AI Foundation) — то есть это больше не «фича Anthropic», а открытый индустриальный стандарт с чужим правлением. И рынок отреагировал моментально: OpenAI подключилась в марте 2025, Google — в апреле, Microsoft — в мае. Полгода — и стандарт де-факто.

Цифры на сегодня: 17 800+ MCP-серверов в каталоге mcp.so, 97 миллионов скачиваний SDK в месяц, 40k+ звёзд на GitHub. Это уже не «модная штука для энтузиастов», это инфраструктура.

Как это устроено технически

Три слоя:

  • Host — приложение, в котором сидит модель (Claude Desktop, Cursor, твой собственный бэкенд)
  • Client — обработчик протокола внутри хоста, один клиент на один сервер
  • Server — то, что реально даёт модели возможности: доступ к БД, API, файловой системе

Связь идёт через JSON-RPC 2.0, транспорт — либо stdio (локальный процесс, самый частый вариант для дев-окружения), либо Streamable HTTP для удалённых серверов.

Внутри сервер отдаёт три типа примитивов:

  • Tools — исполняемые функции, которые модель может вызывать (отправить запрос, записать в базу, дёрнуть внешний API)
  • Resources — данные только на чтение, контекст без побочных эффектов
  • Prompts — переиспользуемые шаблоны запросов

Разделение принципиальное: Tools — это то, что модель может сделать, Resources — то, что она может увидеть. Смешивать их в одном непрозрачном «доступе ко всему» — первый шаг к разделу про дыры в безопасности ниже.

Как я это использую в проде

В своём стеке (Telegram-агент на Claude API + FastAPI + PostgreSQL) MCP-серверы — это не украшение, а рабочая шина между агентом и остальной инфраструктурой. Оркестратор выполняет MCP на клиентской стороне: агент не «магически знает» про базу или инструменты, он получает список доступных Tools от подключённых серверов и решает, какой вызвать под конкретную задачу.

Практическая польза именно в этом: когда появляется новый источник данных или инструмент, не нужно переписывать промпт-инжиниринг под него — подключаешь ещё один MCP-сервер, и агент сам разбирается, что он умеет.

Минус, о котором молчат в восторженных постах: чем больше подключённых серверов, тем больше площадь атаки и тем проще агенту вызвать не тот инструмент не в том контексте. Это подводит к самому неприятному разделу.

Тёмная сторона: 41% без авторизации

Свежий разбор реестра MCP-серверов показал: у ~41% серверов нет авторизации вообще. Подключаешь такой сервер в свой стек — и по факту открываешь доступ к данным и инструментам за ним всем, кто умеет постучаться в эндпоинт.

Причём протокол тут ни при чём — MCP описывает формат общения, а не гарантирует качество и безопасность конкретной реализации. Это как HTTP: сам протокол не виноват, что кто-то развернул сервер без TLS.

Основные грабли рынка, помимо отсутствия авторизации:

  • Overpermissioning — сервер с одним catch-all скоупом вместо разделения доступа по конкретным возможностям. Агенту для чтения таблицы не нужен доступ на запись во всю базу.
  • Утечка токенов — сервер логирует заголовки авторизации или секреты в открытом виде, и это потом всплывает в чужих логах или трейсах.
  • Недоверенный контент — MCP-серверы для браузера тянут внешние страницы как контекст модели; удобно для тестирования UI, но это прямой канал для инъекции чужого текста в промпт агента.

Чек-лист перед тем, как подключить чужой MCP-сервер

Рабочая последовательность, которой сам придерживаюсь:

  1. Сформулируй одно конкретное действие, которое должен уметь агент — не подключай сервер «на всякий случай»
  2. Ищи реализацию от владельца сервиса или в официальных репозиториях протокола, а не первую ссылку из выдачи
  3. Проверь репозиторий: лицензию, как описана авторизация, когда было последнее обновление
  4. Тестируй на непродакшн-доступах: подключил → проверил список открывшихся Tools → прогнал безопасные тесты на тестовых данных → посмотрел логи → только потом добавляй следующую интеграцию
  5. Начинай с read-only и минимальных прав, расширяй по необходимости, а не наоборот

Звучит как занудство, но именно это занудство отделяет «у меня агент дотягивается до нужных данных» от «у меня агент — открытая дверь в прод».

Что дальше

Готовый стартер MCP-сервера — со структурой, авторизацией из коробки и примером инструмента — я выложил у себя в DopamineAgency, чтобы не раздувать статью кодом. Берите как основу вместо разработки с нуля.

Сейчас как раз тестирую, как ведёт себя агент при подключении сразу нескольких MCP-серверов одновременно — где начинает путаться в том, какой инструмент вызвать. Результаты и разбор — тоже в канале.

11