Идентификация агента: Как связать человека с ИИ-агентом

Ключевые выводы

• Проблема "Знай своего агента" (KYA) не решается простым именованием агента. Надежный контроль — это цепочка делегирования, которая связывает аутентифицированного человека, зарегистрированного клиента, предоставленные области действия, контекст организации и каждое результирующее действие.
• Размещенная конечная точка Didit Model Context Protocol (MCP) предоставляет 115 инструментов в 19 доменах и использует Open Authorization (OAuth) 2.1 с Proof Key for Code Exchange (PKCE) и динамической регистрацией клиентов.
• MCP действует от имени вошедшего в систему пользователя Didit. Он наследует роль этого пользователя в организации, поэтому подключенный агент не может получить разрешения, которых у человека уже не было.
• Ключ приложения, хранящийся в файле конфигурации, подтверждает владение учетными данными, а не то, какой человек делегировал конкретное действие. Общие ключи объединяют нескольких операторов и агентов в одну идентификацию приложения.
• Подотчетность требует как принуждения, так и доказательств: токены с ограниченной областью действия и проверки ролей перед действием, а затем записи аудита, которые показывают, кто что изменил.

Didit уже реализовал этот механизм. Его размещенный сервер MCP подключает ИИ-клиента к операциям идентификации и предотвращения мошенничества через вошедшего в систему пользователя, а не рассматривает агента как анонимного владельца секрета приложения. Конечная точка бесплатна, использует безграмотный потоковый HTTP и предоставляет 115 инструментов. Реализация также доступна в общедоступном репозитории GitHub под лицензией MIT.

Этот артефакт меняет полезный вопрос. Вместо того чтобы спрашивать об очередном определении KYA, спросите: когда агент создает сеанс проверки, считывает решение или изменяет данные рабочей области, что доказывает, какой человек это авторизовал, что этот человек разрешил и какая организация приняла действие?

Привязка человека — это цепочка делегирования

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

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

Каждое звено отвечает на свой вопрос. Аутентификация говорит, кто вошел в систему. OAuth говорит, какой клиент получил делегированный доступ. Области действия говорят, какие классы операций были одобрены. Роли говорят, что пользователь может делать внутри организации. Записи аудита говорят, что произошло на самом деле. Объединение этих элементов управления в один значок "проверенного агента" скрывает самую важную часть: полномочия контекстуальны и отзываемы.

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

Почему ключ в файле конфигурации не проходит проверку подотчетности

Ключ API приложения может быть подходящим для контролируемой интеграции "сервер-сервер". Сам по себе он не является механизмом привязки "человек-агент". Скопированный ключ обычно отвечает на один вопрос: "Обладает ли этот вызывающий объект учетными данными, принятыми для этого приложения?" Он не отвечает на вопросы, кто запустил агента, кто одобрил текущую задачу или пришли ли два вызова с одним и тем же ключом от разных людей.

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

Didit намеренно не предлагает путь ключа приложения для своей размещенной конечной точки MCP. Внутренние интеграции по-прежнему могут использовать REST API Didit с учетными данными приложения, но удаленный доступ к MCP требует пользовательского потока OAuth. Это разделение имеет значение: учетные данные REST представляют интеграцию приложения; токен MCP представляет делегированный доступ от вошедшего в систему пользователя.

OAuth 2.1, PKCE и динамическая регистрация клиентов

OAuth является примитивом делегирования в этой конструкции. Поток не передает пароль пользователя агенту и не помещает многоразовый секрет платформы в конфигурацию MCP. Вместо этого ИИ-клиент получает ограниченный токен доступа после того, как пользователь аутентифицируется в Didit и одобряет доступ.

1. Зарегистрируйте клиента

Динамическая регистрация клиентов позволяет совместимому клиенту MCP регистрироваться на сервере авторизации Didit без предварительно подготовленного вручную идентификатора клиента. Это дает серверу авторизации отдельную регистрацию клиента, которой он может выдавать доступ. Регистрация идентифицирует клиента OAuth; сама по себе она не подтверждает, что программное обеспечение клиента заслуживает доверия.

2. Привяжите ответ авторизации к клиенту

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

3. Аутентификация и согласие

Пользователь входит в консоль Didit Business Console, которая действует как сервер авторизации, и одобряет запрошенные области действия. Didit рекламирует didit:verification для операций проверки и didit:management для управления рабочей областью. Клиент должен запрашивать только ту область действия, которая требуется для задачи.

4. Проверяйте каждый вызов

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

Руководство по аутентификации MCP описывает поток, а обзор MCP объясняет размещенную конечную точку и клиентскую модель.

Действие от имени пользователя делает полномочия понятными

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

Затем агент может вызвать didit_session_create для создания сеанса проверки и didit_session_get_decision для получения его результата. Это реальные имена инструментов, ориентированные на домен, в текущем каталоге MCP. Пользователь, у которого нет необходимого разрешения, не получает его, подключая агента; те же границы авторизации организации по-прежнему применяются.

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

Аудируемость: от "кто может действовать?" до "кто что сделал?"

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

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

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

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

Что привязка доказывает — и что нет

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

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

Этот многоуровневый подход делает KYA честным. Идентификация агента, идентификация человека, делегированная авторизация, политика выполнения и доказательства аудита являются связанными элементами управления, а не взаимозаменяемыми метками.

Рабочая реализация, которую вы можете изучить

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

Для контекста продукта полный пакет KYC стоит 0,33 доллара США и объединяет проверку личности, пассивную проверку живости, сопоставление лиц и анализ IP-адресов. Didit включает 500 бесплатных проверок в месяц и используется более чем 2000 компаниями в производстве. Сам сервер MCP бесплатен, поэтому команды могут оценить модель делегирования и разрешений без добавления отдельной платы за коннектор.

Чтобы узнать, как этот механизм вписывается в более широкие рабочие процессы агентов, прочитайте как MCP для идентификации и мошенничества работает для ИИ-агентов и справочник по инструментам Didit MCP.

Привяжите агента, прежде чем доверять действию

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

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