Сравнение MCP-шлюзов начинается с контроля

Большинству компаний не нужен MCP-шлюз, пока один разработчик подключает одного надежного ассистента к двум инструментам только для чтения. Шлюз требуется, когда доступ к инструментам становится общей функцией компании: появляются несколько пользователей и агентов, общие системы, операции записи, учетные данные, которым нельзя оставаться на ноутбуках, или аудитор с вопросом о том, кто и что одобрил. Если купить шлюз раньше, придется обслуживать еще один сервис. Если затянуть, правила доступа окажутся разбросаны по клиентам, которыми компания не управляет.

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

MCP быстро меняется. Любую заявленную здесь возможность поставщика нужно проверять в пилотном проекте, особенно версии транспортов, совместимость клиентов, варианты развертывания и функции со статусом предварительной версии. Архитектура переживает примечания к релизам. Таблицы функций быстро устаревают.

Шлюз нужен, когда доступ становится общим

Компании нужен MCP-шлюз, когда цена несогласованного доступа превышает затраты на работу центральной точки контроля. Количество серверов само по себе мало о чем говорит. Три сервера, способные развернуть приложение, изменить биллинг и прочитать записи клиентов, требуют более строгого контроля, чем тридцать публичных серверов с документацией.

Я смотрю на пять признаков. Первый, общее распространение: команды копируют определения серверов, переменные окружения и токены между несколькими клиентами. Второй, привилегированные действия: агент может записывать, удалять, развертывать, возвращать деньги, приглашать пользователей или менять конфигурацию. Третий, идентификация: компании нужно, чтобы инструмент действовал от имени сотрудника или рабочей нагрузки, которая начала вызов, а не через одну общую сервисную учетную запись. Четвертый, доказательства: службе безопасности или аудита нужна долговечная запись запроса, решения политики и результата. Пятый, эксплуатационная ответственность: кто-то должен одобрять серверы, закреплять версии, удалять скомпрометированные инструменты и поддерживать одинаковую конфигурацию клиентов.

Одного признака достаточно, если последствия серьезны. Финансовому агенту с единственным инструментом возврата денег нужен более строгий контроль, чем исследовательской группе с множеством публичных поисковых инструментов. С другой стороны, десяти инженерам с локальными серверами документации только для чтения может хватить управляемой конфигурации и защиты конечных устройств без шлюза в рабочем трафике.

Не ставьте шлюз на пути вызова лишь ради зрелого вида архитектурной схемы. Каждый переход добавляет варианты отказа, задержку, работу с сертификатами, обновления и дежурства. Если шлюз не может надежно применить правило, которое не способен обеспечить клиент или сервер, оставьте прямое подключение. Центральный реестр может решить задачу обнаружения, не принимая на себя рабочий трафик.

Помогает простой пороговый тест. Перечислите инструменты и отметьте, использует ли каждый из них учетные данные компании, обращается ли к закрытым данным, меняет ли состояние, пересекает ли доверенную зону и нужна ли сохраняемая аудиторская запись. Если у любого инструмента записи есть две отметки или у любого другого инструмента три, стоит проверить центральную точку контроля в пилоте. Это оценка риска, а не формула соответствия требованиям, но она мешает покупать продукт по количеству серверов.

Прокси, реестр, среда выполнения и шлюз отличаются

MCP-шлюз находится на пути данных и принимает решение по каждому значимому запросу. Реестр сообщает клиентам о доступных серверах. Среда выполнения запускает или размещает серверы. API-шлюз решает задачи HTTP и может ничего не понимать в методах MCP, именах инструментов, сессиях и потоковой передаче. Продукты могут объединять все четыре функции, но при закупке их нужно оценивать отдельно.

Это различие быстро обнаруживает типичную ошибку. Платформенная команда публикует одну конечную точку для пяти вышестоящих серверов и называет результат управляемым. Точка проверяет клиента и пересылает трафик, но каждый прошедший проверку пользователь видит и вызывает все инструменты. Команда централизовала маршрутизацию, а не авторизацию. Если на list_invoices и cancel_invoice действует одно правило доступа, граница протокола почти не участвует в защите.

У реестра другая работа. Он фиксирует владельца, происхождение, поддерживаемые версии, одобренные клиенты и статус вывода из эксплуатации. Реестр может помешать разработчикам брать инструменты из случайных репозиториев, но не остановит клиента, который вызывает ранее настроенную конечную точку. Если удаление должно вступать в силу быстро, реестру нужны средства распространения настроек или шлюз.

Среда выполнения решает еще одну задачу: локальные серверы остаются программами с зависимостями и правами операционной системы. Docker MCP Gateway сосредоточен на этом слое. Он запускает серверы в изолированных контейнерах, ограничивает привилегии, сетевой доступ и ресурсы, а также централизует маршрутизацию и учетные данные. Это удобно для рабочих станций разработчиков и управления жизненным циклом серверов. Но такая изоляция сама по себе не отвечает на корпоративный вопрос, может ли Алиса вызвать merge_pull_request только в репозиториях своей группы. Проверяйте слой политик отдельно от песочницы.

Обычный API-шлюз может стать правильной основой, если MCP входит в уже работающую платформу как еще один протокол. Там уже есть сертификаты, высокая доступность, интеграция с системой идентификации, ограничения частоты, журналы и операторы. Но сопоставление пути /mcp с проверкой JWT еще не означает понимания протокола. Спросите, разбирает ли продукт tools/call, понимает ли обнаружение инструментов, сохраняет ли семантику потоков, фильтрует ли показываемые инструменты и применяет ли правила к аргументам, не повреждая ответы JSON-RPC.

Формулируйте требование глаголами. «Регистрировать серверы» относится к каталогу. «Запускать ненадежные локальные серверы» относится к среде выполнения. «Отклонить запрос этого пользователя на удаление в production до исполнения» относится к шлюзу и системе авторизации. Такой словарь не позволяет красивой плоскости управления скрыть слабую плоскость данных.

Личность должна доходить до решения политики

Шлюз должен знать, какой человек или рабочая нагрузка начал вызов, какой клиент его передал и от чьего имени действие выполнит вышестоящая система. Если свести эти личности к одному API-ключу, развертывание упростится, а аудиторский след почти потеряет смысл.

У авторизации две стороны. На входе MCP-клиент проходит проверку в шлюзе. На выходе шлюз подтверждает себя перед MCP-сервером или API, на котором тот работает. Учетные данные должны отличаться, а шлюз обязан связывать их явной политикой. Простая передача входящего bearer-токена вышестоящему сервису кажется удобной, потому что избавляет от обмена токенами и их хранения. Это плохое сокращение пути.

Спецификация MCP Authorization прямо запрещает сквозную передачу токенов. Сервер обязан проверить, что токен выпущен именно для него как для целевой аудитории. Сопутствующий документ Security Best Practices объясняет риск «запутавшегося посредника»: прокси, который принимает и пересылает токен для другого ресурса, позволяет обойти меры контроля и лишает аудит четкой ответственности. Я согласен с запретом и отверг бы любой проект шлюза, где пересылку заголовка выдают за делегированную идентификацию.

Надежный шлюз поддерживает один из трех вариантов выхода. Он может использовать собственные сервисные учетные данные для строго ограниченных машинных действий. Может хранить отдельное OAuth-разрешение пользователя и обновлять его, не показывая токен клиенту. Наконец, может обменять входящую личность на короткоживущий токен, ограниченный вышестоящим ресурсом. Выбор зависит от того, кто должен считаться исполнителем операции: пользователь, приложение или подконтрольная учетная запись автоматизации.

Просите поставщиков показывать отзыв доступа, а не только вход. Отключите пользователя в системе идентификации при открытой MCP-сессии. Удалите его из одной группы. Отзовите вышестоящее OAuth-разрешение. Смените секрет серверной части. Следующий чувствительный вызов должен завершиться отказом по ожидаемой причине, а журнал должен показать, какие учетные данные или правило изменились. Если шлюз проверяет личность только в начале сессии, старые права могут действовать еще долго.

Личность клиента тоже важна. Надежный ассистент для разработки и неизвестный настольный клиент не должны получать одно одобрение только потому, что ими пользуется тот же сотрудник. Текущие рекомендации MCP по безопасности требуют отдельного согласия для каждого клиента в проксируемых потоках авторизации. В компании это обычно означает регистрацию разрешенных типов клиентов, привязку URI перенаправления, хранение согласий и решение о том, будет ли динамическая регистрация открытой, ограниченной или отключенной.

Не связывайте авторизацию с тем, что модель утверждает о себе. Аргументы инструмента вроде requested_by, текст запроса со словами «финансовый директор это одобрил» и созданная агентом причина остаются ненадежными входными данными. Берите личность из проверенных учетных данных и метаданных рабочей нагрузки, переданных вне контекста модели. Агент может объяснить запрос, но не подтвердить собственные полномочия.

Политика на уровне инструмента только начинает работу

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

Списки разрешенных инструментов полезны: они сужают обнаружение и выполнение до одобренного набора и делают принцип минимальных прав понятным людям. Kong документирует глобальные списки доступа и списки для отдельных MCP-инструментов. Gravitee связывает области OAuth с отдельными MCP-инструментами и может запросить решение у внешней системы авторизации. TrueFoundry и Portkey описывают контроль доступа к отдельным инструментам, а MCP-порталы Cloudflare позволяют администраторам выбирать инструменты, которые видны через портал. Это содержательные механизмы, но флажок «RBAC инструментов» не доказывает контроля на уровне ресурса.

Попросите поставщика проверить аргументы. Дайте разработчику право читать развертывания в staging, но запретите production. Затем отправьте тот же инструмент, изменив только один аргумент:

{
  "jsonrpc": "2.0",
  "id": 41,
  "method": "tools/call",
  "params": {
    "name": "get_deployment",
    "arguments": {"environment": "production", "service": "billing"}
  }
}

Ожидаемый отказ должен сохранить оболочку JSON-RPC и выдать оператору стабильный идентификатор политики. Ваш контракт ошибки может отличаться, но определите его до проверки:

{
  "jsonrpc": "2.0",
  "id": 41,
  "error": {
    "code": -32003,
    "message": "Tool call denied by policy",
    "data": {"policy_id": "env-read-scope", "decision_id": "req-7f2a"}
  }
}

Этот артефакт одновременно проверяет четыре свойства: корректный для протокола отказ, проверку аргументов, машиночитаемое решение и сквозную корреляцию. Повторите тест с отсутствующим полем, массивом вместо строки, лишними свойствами, похожим символом Unicode и слишком большим значением. Код политики, который рассчитывает на чистый вывод модели, в рабочей среде сломается.

Для операций записи с серьезными последствиями часто нужно состояние одобрения между разрешением и запретом. Запись об одобрении должна связывать точный инструмент, нормализованные аргументы, пользователя, клиента, срок действия и версию политики. Если проверяющий видит «развернуть billing», но сохраненный запрос позже позволяет изменить тег образа или среду, одобрение ничего не контролирует. Вычисляйте хеш канонического запроса и отклоняйте выполнение при любом существенном изменении.

Не заставляйте человека одобрять каждый вызов. Усталость от подтверждений превращает решение в рефлекс и тормозит полезную автоматизацию. Автоматически разрешайте ограниченное чтение, требуйте одобрения для исключительных операций записи и запрещайте действия, которые агент не должен выполнять никогда. Шлюзу также нужны ограничения частоты и параллельности по личности и инструменту, но они сдерживают злоупотребления, а не заменяют авторизацию.

Журналу аудита нужны решения, а не стенограммы

Хорошая аудиторская запись MCP объясняет, кто запросил действие, как шлюз его понял, почему разрешил или отклонил вызов, какую вышестоящую личность использовал и завершилась ли операция. В необработанной стенограмме запроса нет контекста политики. Полная стенограмма также может собрать секреты, персональные данные, исходный код и вывод модели, которые компания не собиралась хранить.

Для каждого вызова записывайте идентификатор запроса, время, проверенного субъекта, личность клиента, версию сервера и инструмента, нормализованное имя инструмента, версию политики, решение, код причины, ссылку на одобрение при его наличии, вышестоящую цель, задержку и итог. Аргументы сохраняйте выборочно. Среда развертывания и имя репозитория могут быть уместны, а токен доступа, содержимое документа, результат SQL или сообщение клиента обычно нет. Скрывайте чувствительные данные до долговременной записи, а не в запросе к панели.

Проверьте, различают ли журналы следующие исходы: шлюз отклонил вызов, вышестоящая система отказала, сеть не дождалась ответа, пользователь отменил одобрение и инструмент вернул деловую ошибку. Для безопасности и эксплуатации это разные события. Единственное поле failed=true заставит восстанавливать инцидент по неполным трассировкам.

Наблюдаемости нужны и измерения, связанные с MCP. Одного статуса HTTP мало, потому что ошибки JSON-RPC могут приходить в успешных HTTP-ответах, а потоковая передача способна оборваться после получения заголовков. Отслеживайте метод, инструмент, сервер, поведение сессии, полноту ответа и решение политики. Убедитесь, что трассировка не буферизует и не поглощает поток. Microsoft предупреждает: чтение тела потокового ответа MCP в некоторых политиках API Management ломает поток. Именно такие детали реализации скрывает эффектное обещание наблюдаемости.

Срок хранения должен зависеть от данных, а не от энтузиазма AI-команды. Метаданные политики храните достаточно долго для расследований и соблюдения требований. Чувствительные данные запроса сохраняйте только ради названной задачи, с более строгим доступом и коротким сроком. Если поставщик не умеет скрывать вложенные поля аргументов до записи, его функция аудита создаст вторую систему чувствительных данных, которую придется защищать.

Нынешние поставщики решают разные задачи компаний

Молодой рынок делится на привычные API-платформы с поддержкой MCP, AI-шлюзы, расширившиеся за пределы трафика моделей, облачные платформы безопасности со средствами контроля агентов и специализированные открытые шлюзы. Сначала сравнивайте модель эксплуатации, затем функции.

Microsoft Azure API Management логично рассматривать компании, сосредоточенной на Azure и уже использующей APIM. Документация охватывает сквозное проксирование MCP-серверов, публикацию REST API как MCP-инструментов, политики, продукты, квоты, мониторинг и самостоятельно размещаемый шлюз в поддерживаемых тарифах. Azure API Center добавляет обнаружение. Главное преимущество, повторное использование организационной системы: та же платформенная команда, система идентификации, сеть и процесс политик управляют API и инструментами. Нужно учитывать различия тарифов, предварительные версии API для некоторых функций управления и описанные ограничения. Например, в основном наборе MCP-функций APIM поддерживает инструменты, но не ресурсы и подсказки MCP. Отдельный тариф Microsoft AI Gateway добавляет управляемый каталог и федерацию, однако он пока находится в предварительной версии и должен оцениваться именно так.

Kong подходит компаниям, которые уже используют его как уровень применения правил API или хотят держать трафик MCP, моделей и API в одном семействе шлюзов. Документация по MCP-прокси и OAuth рассматривает внешние серверы, интеграцию с поставщиком идентификации, удаление переданных клиентом учетных данных и списки доступа к отдельным инструментам. Это заметно серьезнее обычного HTTP-прокси. Но проверка должна установить, каким средствам нужны корпоративные продукты или определенные версии, чем отличаются Konnect и самостоятельное развертывание и может ли правило для аргументов обращаться к вашей системе авторизации.

Gravitee стоит проверить, если компания хочет объединить управление API, доступом и MCP в одной плоскости управления. Текущая документация описывает MCP-прокси с пониманием протокола, преобразование управляемых API в MCP-серверы, области OAuth для отдельных инструментов и дополнительные решения авторизации через системы вроде OpenFGA. Поэтому продукт интересен для смешанной среды API и агентов. Проверьте зрелость пути MCP с конкретными клиентами и транспортами и отделите выпущенные функции от планов разных модулей Gravitee.

Solo.io agentgateway выбирает специализированный подход для облачной инфраструктуры. Открытая плоскость данных предназначена для трафика MCP, моделей и взаимодействия между агентами, а Solo продает корпоративную эксплуатацию и управление вокруг нее. Архитектура хорошо подходит командам, знакомым с Kubernetes, концепциями Gateway API, самостоятельным размещением и составными политиками. Для небольшой компании без платформенной инженерии те же свойства станут нагрузкой. Отдельно оценивайте открытую сборку, которую можете обслуживать сами, и корпоративные функции, поддержку и компоненты реестра.

TrueFoundry и Portkey пришли со стороны AI-шлюзов. Оба поставщика описывают централизованные реестры MCP, единую точку клиентского доступа, работу с вышестоящими учетными данными, доступ к инструментам, журналы и защитные правила. TrueFoundry заявляет сопоставление токенов для отдельных пользователей, RBAC и ABAC, процессы одобрения и варианты развертывания в рамках более широкой AI-платформы. Portkey описывает выдачу прав рабочим пространствам и пользователям, подстановку учетных данных, доступность отдельных инструментов, одобрения и единое представление с трафиком моделей. Эти продукты могут сократить интеграционную работу AI-команды, но покупателю нужно проверить точность передачи личности, размещение плоскости данных, место хранения журналов, расширяемость политик и поведение при недоступности размещаемой поставщиком плоскости управления.

MCP-порталы Cloudflare разумно рассматривать организациям, которые уже используют Cloudflare Access и Gateway. Порталы собирают серверы за одной конечной точкой, проверяют пользователей через Access, выбирают видимые инструменты и могут направлять трафик через средства предотвращения утечки данных. Так управление MCP присоединяется к существующей границе защищенного доступа. Проверьте работу с вышестоящим OAuth, потребности локальных серверов и транспортов помимо HTTP, авторизацию с учетом аргументов, региональную маршрутизацию и точный состав лицензии. Не предполагайте, что каждая функция Cloudflare Gateway автоматически работает с MCP-порталами.

Docker MCP Gateway начинает со среды выполнения серверов и распространения настроек среди разработчиков. Он умеет запускать MCP-серверы в изолированных контейнерах, подставлять учетные данные, ограничивать ресурсы и сетевой доступ и собирать подключения клиентов в одном месте. Для компании, которая хочет избавиться от произвольных локальных процессов и повторяющейся настройки рабочих станций, это конкретная польза. Документация Docker также относит некоторые функции управления к предложению только по приглашению. Поэтому при закупке отделяйте открытый шлюз и процесс Docker Desktop от Docker AI Governance. Такой продукт может дополнять удаленный шлюз политик, а не заменять его.

Абсолютного победителя в этом сравнении нет. Наличие APIM склоняет выбор к Microsoft, Kong или Gravitee. Платформа на Kubernetes может выбрать agentgateway. Компания, покупающая более широкую плоскость управления AI, рассмотрит TrueFoundry или Portkey. У службы безопасности с Cloudflare будет свой короткий путь, а платформе разработчиков, которую беспокоят локальные серверные процессы, стоит проверить Docker. Самый дешевый продукт, соответствующий вашей модели эксплуатации, обычно лучше продукта с самой длинной страницей функций.

Выбор между разработкой и покупкой зависит от сложности политик

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

Используйте взвешенную оценку вместо подсчета функций. Оцените каждый вариант от 0 до 5, умножьте результат на вес и потребуйте письменное доказательство из проверки. Слайд получает ноль. Рабочая демонстрация в вашей среде получает три. Автоматический приемочный тест вместе с назначенным оператором может получить пять.

Веса намеренно мешают театру функций. Идентификация и работа с учетными данными доминируют, потому что ошибка превращает шлюз в концентратор привилегий. Стоимость за три года получает меньшую долю, поскольку команды постоянно недооценивают внутреннюю инженерную работу и преувеличивают экономию на лицензиях. Считайте деньги после технических причин для отказа, а не до них.

Для самостоятельной разработки оцените как минимум следующие потоки работы: прокси протокола и тесты совместимости, аутентификация, интеграция политик, жизненный цикл вышестоящих токенов, распространение конфигурации, очистка аудиторских данных, высокая доступность, обновления и реакция на инциденты. Обратный прокси с проверкой JWT остается прототипом, а не готовым шлюзом. Разработка все же может выиграть, если существующий шлюз предоставляет большую часть этих компонентов, а адаптер MCP остается небольшим.

Задайте причины для отказа до подсчета баллов. Среди них сквозная передача токенов, общие вышестоящие учетные данные для действий, где требуется личная ответственность, отсутствие очистки до записи, невозможность централизованно отозвать инструмент и размещаемый путь данных с нарушением требований к месту хранения. Высокая сумма баллов не должна позволить красивым панелям компенсировать сломанное свойство безопасности.

Пилот должен попытаться сломать шлюз

Пилот должен воспроизводить самый неудобный путь доступа из вашей работы, а не лучшую демонстрацию поставщика. Возьмите один инструмент чтения, один инструмент записи, один SaaS-сервер с пользовательской авторизацией, один внутренний сервер и хотя бы два типа клиентов. Включите клиент, под который поставщик не оттачивал демонстрацию.

Выполните фиксированную приемочную последовательность. Сначала подключитесь и получите список инструментов как пользователь со всеми правами. Затем удалите одно разрешение и убедитесь, что изменились и обнаружение, и выполнение. После этого поменяйте защищенный аргумент, отзовите вышестоящее разрешение во время активной сессии и повторите тот же запрос с тем же идентификатором JSON-RPC. Вызовите тайм-аут вышестоящей системы после получения заголовков ответа. Обновите определение сервера, пока клиент сохраняет сессию. В конце найдите во всех журналах подставленный секрет и значение персональных данных, которые система должна была скрыть.

Запишите результат в таблицу решений из четырех столбцов: тест, ожидаемая мера контроля, наблюдаемый результат, место доказательства. Если политика разрешает, сохраните трассировки пакетов и экспортированные журналы. Попросите поставщика объяснить каждый частичный успех. «Панель со временем обновилась» не означает успешного отзыва, а «клиент скрыл запрещенный инструмент» не считается успехом, если прямой вызов по-прежнему работает.

Измеряйте задержку, но не улучшайте медиану в ущерб поведению при сбоях. Вызовы инструментов часто ждут внешние системы, поэтому несколько миллисекунд на проверку политики могут быть приемлемы. Сломанные потоки, повторная запись после повтора запроса, потерянная отмена и шлюз, который при отказе пропускает трафик, неприемлемы. Убедитесь, что повторы применяются только к безопасным операциям, а шлюз отличает идемпотентное чтение от изменения состояния.

Проверьте и потерю плоскости управления. Действующие и новые сессии, обновления политик, отзыв, журналы и обнаружение серверов могут вести себя по-разному при исчезновении управляющего сервиса. Решите, какие функции обязаны закрывать доступ, а какие могут работать по последней надежной конфигурации. Компания, которой нужно экстренно удалить инструмент, не может принять плоскость данных, сохраняющую старый доступ несколько часов без отдельного аварийного выключателя.

Пилот заканчивается планом эксплуатации. Назовите тех, кто одобряет серверы, владеет политиками, реагирует на отказ авторизации, проверяет чувствительные журналы и принимает запросы команд на новый инструмент. Если вместо имен остались пустые строки, шлюз соберет технический трафик в центре, но организационный доступ сохранит стихийный характер.

Первая покупка решает вопрос ответственности

Выберите самый небольшой шлюз, который обеспечивает нужную границу и подходит команде эксплуатации. Многим стартапам стоит отложить покупку широкой платформы, централизовать только привилегированные удаленные инструменты и оставить безопасные локальные серверы документации вне шлюза. Регулируемой компании с действующей API-платформой часто безопаснее расширить знакомую плоскость управления, чем добавить модный специализированный продукт.

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

Первым внутренним артефактом должна стать карта владельцев инструментов, а не список поставщиков. Для каждого привилегированного инструмента назначьте владельца, класс данных, разрешенные личности, модель вышестоящих учетных данных, политику записи и путь вывода из эксплуатации. Карта покажет, нужен ли реестр, среда выполнения, шлюз политик или все три компонента. Она также даст поставщикам конкретную задачу для пилота.

В oleg.is я использую Team & AI Audit, когда основателю нужна такая эксплуатационная карта, связанная со стоимостью инженерной команды и пятидневным процессом принятия решения. Тогда выбор шлюза следует за моделью доступа, а не диктует ее.

Не подписывайте договор, пока один запрещенный запрос записи в production не выдаст ожидаемую личность, версию политики, нормализованные аргументы и причину, а вышестоящая система ничего не получит. Этот тест говорит о MCP-шлюзе больше, чем еще сотня флажков в сравнительной таблице.