MCP Архитектура управления техническими директорами.
Руководство технического директора по MCP архитектуре управления, границам доверия, семантике утверждения и производственному доверию.
Коротко о решении
Сохраняйте маршрутизацию протокола, авторизацию, разрешения поставщика, выполнение и операции как отдельные архитектурные задачи.
Шлюз — это граница доверия
Шлюз полезен, когда он является местом, где запрос получает контекст: кто задает вопрос, какой клиент действует, какое подключение является целевым, какой инструмент и ресурс задействованы и какая версия политики применяется. Этот контекст позволяет командам платформы принять детерминированное решение перед отправкой.
Нельзя считать маршрутизацию проверкой полномочий. Шлюз должен проверять аудиторию токена и учётные данные, соблюдать границы согласия провайдера и отклонять запрос, если полномочия или охват ресурсов неизвестны.
Иллюстративный сценарий: инструмент меняет форму
Представьте, что вышестоящий инструмент добавляет новый аргумент, который преобразует чтение в запись. Шлюз, который просто пересылает JSON, может продолжать работать, хотя его политика и модель проверки отстают. Управляемый путь рассматривает изменения схемы и возможностей как входные данные для проверки. Это иллюстративный сценарий проектирования, а не событие, о котором сообщается.
Смоделируйте путь как отдельные этапы: аутентификация, авторизация, получение одобрения, когда это необходимо, запись намерения, отправка и классификация результатов поставщика. Такое разделение делает повторные попытки и неопределенные записи явными, а не случайными.
Контрольный список архитектуры
Прежде чем масштабировать подключения, запишите ответы на эти вопросы:
- Какие клиенты MCP поддерживаются и как проверяются их версии и конфигурации?
- Как вышестоящие удостоверения, области действия, согласия и аудитории токенов отделены от удостоверений шлюза?
- Где хранятся и изменяются проверенные инструменты, схемы, ресурсы и версии политик?
- Как утверждения привязаны к конкретному субъекту, аргументам, схеме, сроку действия и количеству использований?
- Как представляются и согласовываются тайм-ауты и неоднозначные записи поставщика?
- Какие элементы управления обеспечивают выход, частное подключение, хранение, резервное копирование и восстановление?
Ограниченная оценка с Durin
Durin дает команде платформы конкретный путь запроса для выполнения: проверка подлинности, проверка политики разрешения по умолчанию, дополнительные элементы управления утверждением или запретом, подключения с ограниченной областью и аудит. Рабочая область оценки может проверить модель перед активацией поставщика. Обнаружение, удаленная активация поставщика, размещенная идентификация, частное подключение и обеспечение эксплуатации — это проверки доверия к производству.
Используйте эту границу для создания записи решения по архитектуре. Назовите возможности, которые подтверждает шлюз, возможности сети или клиентов, которые должны доказать, а также шлюзы, которые должны пройти, прежде чем они станут доступными для производства.