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

Идентичность ИИ-агента состоит из проверяемых атрибутов, по которым сервис отличает конкретного агента от людей, сервисных учётных записей и других агентов: идентификатора, издателя учётных данных, оператора, версии, конфигурации, среды исполнения. У идентичности собственный жизненный цикл, и она криптографически связана с принципалом, то есть человеком или организацией, от имени которых работает агент. Эксперты NIST поставили отдельную проверяемую идентичность агента первой из десяти принципов проектирования систем управления идентичностью агентов.

Кратко:

• Что входит: идентификаторы агента и экземпляра, издатель credential, оператор, версия, инструменты, среда исполнения.
• Кто выпускает: издатель выпускает и отзывает credential, оператор запрашивает выпуск и хранит ключи.
• Как проверяет сервис: сверяет подпись, срок, издателя и статус отзыва.
• Когда меняется риск: при смене версии, инструментов или среды оператор записывает событие и может перевести агента в статус «изменение».
• Чего не доказывает: полномочия сервис проверяет при авторизации, принципала оператор или сервис проверяет при KYC или KYB.

Что входит в идентичность ИИ-агента

По первому принципу NIST идентичность агента отличима от идентичностей людей и сервисных учётных записей и в идеале привязана к программной нагрузке, среде и утверждённой конфигурации. Под ИИ-агентом понимают программную систему, которая с определённой автономностью планирует и выполняет действия ради цели.

Таблица 1. Атрибуты идентичности ИИ-агента

Идентификатор однозначен только вместе с издателем: по проекту IETF WIMSE Architecture идентификатор программной нагрузки уникален в пределах домена доверия. Ближе всего к агенту модель workload identity, идентичность сервиса, контейнера или процесса. Учёт агента как отдельного программного объекта называют машинной идентичностью агента.

Чем экземпляр отличается от ИИ-агента

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

Права в политике доступа оператор привязывает к идентичности агента и его назначению. По идентификатору экземпляра служба информационной безопасности (ИБ) видит, какой запуск отправил запрос, и останавливает скомпрометированный экземпляр, не затрагивая остальные.

Цепочка идентичности агента

В нашей модели цепочка идёт от принципала к запросу, и сервис принимает запрос, только если действуют все звенья.

1. Принципал: человек или организация, от имени которых работает агент; оператор или сервис проверяет их при KYC или KYB.
2. Оператор: организация или команда, которая развёртывает агента и управляет его использованием.
3. Агент: логическая сущность с идентификатором, версией и конфигурацией.
4. Экземпляр: запуск агента под конкретную задачу.
5. Credential: учётные данные экземпляра с ограниченным сроком действия.
6. Запрос: обращение экземпляра к сервису с подписью или предъявлением удостоверения экземпляра (credential).

Доверенная сторона отклоняет запрос с технически верной подписью, если credential отозван, работа оператора приостановлена или связь с принципалом прекращена.

Кто выпускает credential и кто его отзывает

Агент подтверждает идентичность с помощью credential агента: сертификата X.509, подписанного токена или ключа с доказательством владения.

• Издатель (issuer) выпускает credential в своём домене доверия и отзывает его.
• Оператор запрашивает выпуск, хранит ключи и инициирует отзыв при смене версии, договора или владельца процесса.
• Доверенная сторона, то есть сервис, принимающий запрос, проверяет подпись, срок, издателя и статус отзыва.

Авторы WIMSE предупреждают, что bearer-токен можно похитить и предъявить в другом месте, и предлагают credential, привязанный к ключу, с ограниченным сроком действия. Эксперты NIST советуют отказаться от долгоживущих bearer-токенов и статических секретов.

Сценарий: отказ из-за отозванного credential

1. Запрос: экземпляр агента закупок обращается к API поставщика с подписанным токеном.
2. Проверка: доверенная сторона сверяет подпись, срок и статус у издателя; издатель отозвал credential накануне, после прекращения договора с подрядчиком-оператором.
3. Решение: доверенная сторона отказывает с причиной «credential отозван», заказ не создаётся, оператор уведомляет принципала.
4. Журнал: доверенная сторона записывает идентификаторы агента и экземпляра, издателя, причину отказа и время.

Почему версия модели и инструменты меняют риск агента

Идентификатор агента может оставаться прежним, пока профиль риска меняется. Агент поддержки с новым инструментом возврата средств получает доступ к деньгам, а агент на новой версии модели может иначе выполнять те же инструкции.

Поэтому оператор записывает каждое изменение версии, инструментов или среды отдельным событием и может перевести агента в статус «изменение» до подтверждения владельцем процесса. Такие события служба ИБ отслеживает в рамках непрерывного KYA.

Почему общего API-ключа и учётной записи сотрудника недостаточно

• Не видно, кто отправил запрос. Если агент работает под общим ключом или под учётной записью сотрудника, в журнале остаётся только владелец ключа или сотрудник. После спорной операции служба ИБ не может отличить запрос человека от запроса агента и не может понять, какой из запусков агента его отправил. По оценке NIST, у агента с собственной идентичностью каждое действие можно проследить до конкретного программного компонента.
• У агента лишние права. Под учётной записью сотрудника агент получает все права сотрудника, хотя для задачи ему обычно нужна лишь их часть. Общий ключ команда, как правило, выпускает с широкой областью действия и без срока. NIST рекомендует другой подход. Пока агент простаивает, постоянных прав у него нет. Доступ он получает только на время задачи и только в том объёме, который для неё нужен.
• Агента нельзя остановить точечно. Если отозвать общий ключ, доступ потеряют все, кто им пользуется. Если заблокировать учётную запись, работать не сможет и сотрудник. Отдельный идентификатор экземпляра позволяет отключить один скомпрометированный запуск, а остальная работа продолжится.

Что запрос отправил именно заявленный агент, сервис проверяет при аутентификации ИИ-агентов.

Какие статусы проходит идентичность ИИ-агента

NIST рекомендует вести жизненный цикл идентичности агента отдельно от жизненного цикла людей. Статусы оператор хранит в реестре ИИ-агентов.

Таблица 2. Статусы идентичности ИИ-агента

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

Что идентичность ИИ-агента не доказывает

По идентичности сервис устанавливает, какой агент и какой экземпляр отправил запрос. Допустимо ли действие, сервис решает при авторизации по правилам делегирования полномочий ИИ-агенту.

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