MCP-совместимость стала строкой в RFP — аналитики фиксируют, что поддержка протокола и соответствие governance переходят из дифференциаторов в базовые требования закупок. Проблема: за чекбоксом «MCP-совместимо» прячется что угодно — от управляемого шлюза с OAuth до локального stdio-сервера без авторизации. Сканирование 5 205 open-source MCP-серверов показало: больше половины живут на статических ключах, и лишь 8.5% используют OAuth. Спрашивать надо не «есть ли MCP», а «как именно».
Почему «MCP-совместимо» ничего не значит
Протокол описывает формат общения, а не контроли: аудит, песочница и проверка tool-описаний остаются на совести реализации. Два вендора с одинаковой галочкой могут различаться как «домофон с журналом» и «открытая дверь с табличкой». RFP должен требовать механизмы, а не аббревиатуру.
12 вопросов: auth / audit / data / ops
Авторизация:
- OAuth 2.1 с PKCE для всех сетевых серверов? Токены короткоживущие (<1 часа), с привязкой к ресурсу, без token passthrough?
- Scope на уровне инструментов (read/write/admin), deny-by-default? Кто и как выдаёт scope — через approve-процесс?
- Куда деваются секреты к downstream-системам — брокер на сервере или раздаётся агентам и конфигам?
Аудит:
4. Логируется ли каждый tools/call с agent × human_delegator × tool × ресурс × результат × версия политики? Ретеншен и tamper-evidence?
5. Есть ли экспорт в SIEM (CEF/LEEF, OTel) и готовый evidence pack для SOC 2 / 152-ФЗ?
6. Видно ли фактическое использование scope — чтобы резать неиспользуемые права?
Данные: 7. Где исполняется и хранится: on-prem / ru-облако / зарубежный SaaS? Резидентность данных и логов — где именно? 8. Как изолируются tenant друг от друга — серверный tenant, scoped-инструменты, тесты на cross-tenant утечки? 9. Маскирование PII и секретов — до попадания в контекст модели или после?
Эксплуатация:
10. Rate limits, квоты и circuit breaker на агента/инструмент — из коробки или «напишите сами»?
11. Registry одобренных серверов: approve-workflow, версионирование tools/list, блокировка silent-обновлений?
12. SLA, kill switch и отзыв за минуты: где кнопка аварийного отключения и кто её нажимает?
Red flag ответы
- «Авторизация — API-ключи, ротация по регламенту» — статика без expiry, именно её находят в половине серверов;
- «Аудит — логи приложения, посмотрите сами» — нет связки вызовов, нет evidence;
- «Данные — в нашем облаке» без указания юрисдикции и договора;
- «Лимиты не нужны, модель сама аккуратная» — runaway узнают из счёта;
- «Registry не требуется, подключайте любые серверы» — supply chain без ворот;
- «On-prem — в roadmap» третий год подряд.
Один red flag — повод для уточняющих вопросов, два — для вычёркивания.
Минимальный пилот 2 недели
До контракта прогоните вендора на трёх сценариях: агент с read-доступом к тестовой базе (проверяем scope и маскирование), симуляция runaway-цикла (проверяем лимиты и breaker), отзыв доступа (проверяем kill switch и каскад). Плюс запросите реальный экспорт аудита за пилот — если evidence pack собирается руками, в проде будет так же.
Где Codenik
Codenik закрывает чек-лист архитектурно: OAuth с короткоживущими токенами вместо статики, секреты в брокере, каждый вызов в журнале с экспортом в SIEM, серверный tenant, маскирование до контекста, лимиты и breaker на шлюзе, registry с approve и kill switch в одну операцию. Пилот — две недели на ваших сценариях, evidence pack — из коробки, а не скриптами после покупки.
Короткий вывод
В RFP пишите не «MCP», а двенадцать механизмов: auth, scope, секреты, аудит, evidence, использование, резидентность, tenant, маскирование, лимиты, registry, kill switch. Вендор, который отвечает конкретно и показывает на пилоте, — кандидат; вендор с галочками — будущий техдолг.