Atomno labs

Безопасность MCP-серверов: чек-лист перед production

MCP — мощная штука, но как любая интеграция, требует security-мышления. Чек-лист из 12 пунктов перед подключением чужого MCP в проде.

· Atomno Labs ·
  • security
  • mcp
  • best-practices
  • production

MCP — отдельный процесс с доступом к env-vars, network и опционально файловой системе. Подключая MCP в production-проект, вы фактически добавляете зависимость уровня npm-пакета: код, который вы не писали, будет выполняться на ваших машинах. К этому надо относиться так же серьёзно, как к проверке зависимостей.

Вот 12-пунктовый чек-лист перед production-использованием.

1. Source code открыт?

Без открытого кода — даже не рассматривайте. Open-source — необязательное условие, но:

  • Без кода вы не можете проверить, что MCP не делает плохого.
  • Без кода нельзя форкнуть и допилить под себя.
  • Без кода community не находит и не репортит уязвимости.

Все 7 публичных MCP семьи atomno-mcp-* — MIT, code на GitHub.

2. Активность репозитория

Минимум:

  • ✅ Последний коммит — не старше 6 месяцев.
  • ✅ Есть выпущенные версии (релизы).
  • ✅ Issues отвечают (хоть как-то, не заброшено).
  • ✅ Число contributors > 1 (необязательно, но хорошо).

Если репо мёртвый — берите на свой риск. Скорее всего там баги в обработке ошибок и устаревшие зависимости.

3. Glama / mcpservers / awesome-mcp listing

Каталоги MCP делают базовую модерацию. Если MCP в:

  • Glama.ai с score AAA / AA / A — analyzer проверил безопасность и качество.
  • awesome-mcp-servers (15K⭐) — community-curated, мейнтейнер @punkpeye отсеивает явный мусор.
  • mcpservers.org — официальный listing с базовой валидацией.

— это базовый знак доверия. Не достаточный, но необходимый минимум.

4. Env-vars: в коде нет hardcoded токенов

Откройте код MCP. Поиск по «sk_», «api_key», «token» — не должно быть hardcoded значений. Все секреты — только через env-vars.

✅ Хорошо:

TOKEN = os.environ["MCP_FNS_CHECK_TOKEN"]

❌ Плохо:

TOKEN = "sk_real_token_xxxxx"  # NEVER

5. Зависимости с MAJOR-lock

Откройте pyproject.toml MCP. Все зависимости должны иметь верхнюю границу:

✅ Хорошо:

"httpx>=0.27.0,<1.0.0"
"pydantic>=2.6.0,<3.0.0"

❌ Плохо:

"httpx>=0.27.0"  # сломается, когда httpx 1.0 выйдет с breaking changes

Это снижает риск supply-chain атак (новая версия зависимости с уязвимостью не подтянется автоматически).

6. Test coverage

Если в репо нет tests/ — это red flag. Production-MCP должен иметь минимум:

  • Тесты на happy-path каждого тула.
  • Тесты на error-cases (4xx, 5xx, timeout).
  • Тесты на edge-cases (empty input, malformed response).

Минимум 80% coverage на core-логику (server.py, tools.py, client.py). У наших MCP — это обязательное требование релиза.

7. Изоляция при запуске

При первом подключении нового MCP — тестируйте в отдельном проекте или с отдельным профилем IDE:

# Отдельная папка
mkdir mcp-test && cd mcp-test
mkdir .cursor
echo '{"mcpServers": {"new-mcp": {"command": "uvx", "args": ["new-mcp"]}}}' > .cursor/mcp.json
cursor .

Если что-то пойдёт не так — заденет только тестовый проект.

8. autoApprove — только read-only тулы

В Cline / Continue / Cursor можно настроить «авто-апрув» тулов (агент вызывает без подтверждения).

Безопасно автоапрувить:

  • get_* — чтения.
  • check_* — проверки.
  • search_* — поиск.
  • list_* — выборки.

НЕ автоапрувьте:

  • create_* — создаёт что-то у провайдера.
  • delete_* — удаляет.
  • update_* — изменяет.
  • Любой тул с финансовыми последствиями.

Особенно критично для mcp-yukassa (платежи) и mcp-1c-bridge (создание документов в 1С) — там никаких автоапрувов.

9. Audit log включён

В Cursor: Settings → MCP → Logs. В Claude Desktop: ~/Library/Logs/Claude/mcp*.log. В Cline: Output panel.

Раз в неделю проверяйте: какие тулы вызывались, с какими аргументами, какие были отказы. Аномалии — повод разобраться.

10. Rate-limit’ы провайдера учтены

Государственные RU-API имеют жёсткие лимиты:

  • ФНС: 10 запросов/мин с одного IP.
  • ФССП: 30/мин.
  • Росреестр: ещё меньше.
  • ЦБ: вообще не лимитирует (но не злоупотребляйте).

Если ваш MCP будет вызываться чаще — провайдер заблокирует ваш IP. Нужен Pro-tier с hosted backend (мы агрегируем запросы и держим квоты на стороне сервера).

11. Disclaimer провайдера

В каждом нашем MCP в README и на сайте — disclaimer: «Не аффилированы с провайдером». Это важно:

  • Защищает вас от претензий провайдера за неправильное использование.
  • Юридически разделяет ответственность за soft-блокировки.

При подключении любого MCP — почитайте, что там в disclaimer. Если его нет — тоже red flag.

12. Rotation токенов

Все API-токены периодически ротируйте:

  • Pro-tier токены — раз в 90 дней.
  • Production-токены — раз в 180 дней.
  • При утечке — немедленно (ревокация на стороне провайдера).

В наших Pro-кабинетах есть кнопка «Rotate token» — выдаст новый, старый перестанет работать через 24h.

Бонусный пункт: SBOM

В будущем, когда вы будете аудировать всю security-цепочку — пригодится SBOM (Software Bill of Materials). Generate через uv pip compile + cyclonedx-py. Atomno Labs делает SBOM для своих MCP начиная с Q3 2026 (сейчас не у всех есть, в roadmap).

Чек-лист одной строкой

  • Code open-source.
  • Репо активный.
  • В каталогах (Glama / awesome-mcp / mcpservers).
  • Нет hardcoded токенов в коде.
  • Зависимости с MAJOR-lock.
  • Test coverage ≥ 80%.
  • Тестировал в изоляции перед production.
  • autoApprove только для read-only.
  • Audit log включён, проверяется еженедельно.
  • Rate-limit’ы провайдера учтены.
  • Disclaimer прочитан.
  • Rotation токенов настроен.

Если все 12 пунктов ✅ — MCP можно в production.

Что читать дальше


Понравилась статья?