Централизуйте доступ к MCP с помощью Durin

Зачем централизовать подключения MCP?

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

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

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

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

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

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

Как архитектура сочетается друг с другом

Клиент AI предлагает вызов инструмента. Durin получает запрос в личной конечной точке MCP и аутентифицирует запрашивающую сторону. Конечная точка принадлежит этой учетной записи: знание ее адреса не дает права другому лицу использовать ее. Вход в браузер и аутентификация клиента MCP — это отдельные шаги.

Клиент и его модель остаются за пределами Durin. Персональная конечная точка выбирает точку входа с привязкой к удостоверению. Внутри Durin текущие проверки и политика предшествуют подключению. Удаленные запросы MCP передаются на вышестоящий сервер MCP; собственные адаптеры вызывают провайдера API. Метаданные решений и результатов формируют контрольный журнал. Синтетическая песочница остается в пределах Durin и не связывается ни с одним поставщиком.

Открыть полноразмерную фигуру: Персональные проверки входа и доступа направляются к удаленным MCP или собственным API подключениям.

Утвержденное подключение описывает систему, доступную в рабочей области. Доступ по-прежнему зависит от текущего членства и состава команды запрашивающего, состояния подключения, выбранных учетных данных, проверенного инструмента, ресурса и проверки. Обнаружение инструмента открывает доступный каталог, но просмотр инструмента не является постоянным разрешением на его вызов.

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

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

Что происходит, когда агент вызывает инструмент?

Рассмотрим безопасное чтение: sandbox__read_document с ресурсом engineering/handbook. Песочница содержит краткий синтетический справочник без документов компании. Клиент передаёт имя инструмента и аргументы; Durin проверяет, может ли инициатор выполнить этот вызов сейчас.

Аутентифицируйте и проверьте доступ, а затем запишите решение политики. Deny останавливает вызов. Требуемое одобрение приостанавливает действие для независимой проверки и точной повторной попытки отправителя запроса. Продолжает отправляться только разрешенный в данный момент запрос. После попытки зарегистрированный результат: подтвержденный успех, подтвержденная неудача или неопределенный; неопределенность никогда не проявляется как успех.

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

1. Определите запрашивающего. Аутентификация должна соответствовать личной конечной точке и текущему членству в рабочей области.
2. Проверьте доступ. Подключение должно быть включено и проверено; объем команды, личный доступ, учетные данные, проверенный инструмент, разрешенный ресурс и проверка должны разрешать запрос.
3. Оцените политику. Проверенные запросы разрешаются по умолчанию после необходимых проверок. Администраторы могут выбрать запрет по умолчанию, независимо требовать одобрения записи или запретить запись. Ограничения команды и пользовательская политика могут еще больше ограничить результат.
4. Отправка только тогда, когда это разрешено. Отклоненный запрос останавливается до запуска инструмента. Ответ, требующий одобрения, означает необходимость проверки и повторной попытки; ни одно действие не выполнено.
5. Проверьте результат. Синтетическое чтение возвращает текст руководства в случае успеха. Записи о решениях и исполнении описывают то, что было разрешено, и то, что произошло на самом деле, как отдельные факты.

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

Подключите клиента к Durin

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

1. В Моей рабочей области откройте Connections и разверните Подключите своих агентов. Найдите конечную точку MCP. При появлении запроса выберите «Настроить конечную точку»; затем используйте Копировать URL. Сохраните скопированный адрес, связанный с вашей учетной записью.
2. Откройте «Подключения» → «Доступно» и запросите «песочницу» Durin. Администратор открывает запрос в разделе «Утверждения» и выбирает «Утвердить запрос». При необходимости будет создана песочница. Существующие политики доступа по-прежнему применяются; отключенная песочница требует, чтобы администратор включил ее.
3. Добавьте скопированную конечную точку в свой клиент MCP. Пример Claude Code ниже взят из того же генератора настроек, который используется на веб-сайте. Замените YOUR_PERSONAL_ENDPOINT_ID идентификатором в скопированном вами URL-адресе; показанный адрес является лишь заполнителем.

claude mcp add --transport http --scope user durin 'https://mcp.getdurin.com/mcp/u/YOUR_PERSONAL_ENDPOINT_ID'

Откройте Claude Code и используйте /mcp для аутентификации Durin.

Завершите аутентификацию, используя учетную запись, которой принадлежит конечная точка, а затем обновите инструменты клиента. Не вставляйте токен поставщика в URL-адрес конечной точки и не делитесь чужим адресом в качестве конфигурации команды. Если у вас уже есть сервер с именем durin, согласуйте существующую запись, прежде чем добавлять другую. Руководство по настройке клиента также охватывает Codex, Cursor и URL-адреса для конкретного подключения.

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

Попросите клиент вызвать sandbox__read_document с ресурсом engineering/handbook. Успешный ответ указывает, что это синтетический инженерный справочник без данных компании. Проверьте запрос и результат в журнале действий. Для более широкого обзора попросите администратора изучить аудит организации.

Администратор одобрил этот пример запроса руководства компании на установку. Видимый статус «Одобрено · установка ожидает» и примечание о проверке означают, что доступ провайдера по-прежнему требует проверки перед активацией. Этот запрос на подключение не связан с утверждением одного конкретного действия инструмента.

Открыть полноразмерную фигуру: Durin проверка подключения для справочника компании, в котором указано «Одобрено» · ожидается установка.

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

Обрабатывайте конфиденциальные записи сознательно

Для безопасной проверки согласований попросите администратора опубликовать правило, требующее одобрения изменений другим администратором. Отправьте sandbox__create_ticket с ресурсом engineering/roadmap и коротким синтетическим заголовком. Действие должен рассмотреть другой активный администратор. Один человек не может и запросить, и одобрить действие, даже имея права администратора.

Запрашивающая сторона отправляет запись и получает ожидающее действие. Его проверяет другой активный администратор. Точное утверждение возвращает контроль запрашивающей стороне без отправки. Запрашивающая сторона повторяет идентичный вызов со ссылкой на утверждение до истечения срока действия. Durin повторно проверяет текущий доступ и разрешение, прежде чем использовать его и потребовать одну попытку. Отклоненные, истекшие или признанные недействительными разрешения прекращаются. Неопределенная попытка требует расследования, прежде чем писать новую.

Открыть полноразмерную фигуру: Другой администратор одобряет, запрашивающая сторона повторяет попытку, а текущие проверки запрещают одну попытку выполнения.

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

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

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

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

Поймите границы перед развертыванием

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

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

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

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

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