Идентификатор агента 365

Агент 365 использует Microsoft Entra ID для агентов для представления каждого агента с уникальным идентификатором агента. Идентификатор агента — это принципал сервиса Microsoft Entra с servicePrincipalType установленным в ServiceIdentity .@odata.type#microsoft.graph.agentIdentity Администраторы управляют идентичностями агентов с помощью тех же контролей арендаторов, что и в других частях Microsoft Entra, включая условный доступ, предоставление разрешений и согласие, а также операции жизненного цикла.

Объекты идентичности

Модель состоит из трёх объектов. Не каждый агент использует все три.

Объект Description
Схема идентификации агента Шаблон в Microsoft Entra ID, который определяет тип агента. Он хранит учетные данные, декларируемые и наследуемые права, проверенного издателя и любые роли приложения. Один чертеж может создавать множество идентичностей агентов. Для информации о том, как приложения регистрируются в Microsoft Entra, см. раздел «Зарегистрировать приложение с платформа удостоверений Майкрософт».
Удостоверение агента Счёт, под которым ведёт отдельный агент. У него есть собственный идентификатор объекта, отображаемое имя, спонсор и назначение разрешений.
Учетная запись пользователя агента Необязательный второй аккаунт, созданный только тогда, когда агенту нужна учётная запись Microsoft Entra. Он может содержать лицензии и ресурсы Microsoft 365, такие как почтовый ящик. Доступно только для арендаторов, участвующих в программе предварительного просмотра Frontier. Идентификация агента имеет ноль или один аккаунт пользователя, и учетная запись каждого агента принадлежит ровно одному идентификатору агента.

Взаимосвязь чертежа и агента

Внутри арендатора стандартная регистрация заявки обычно имеет индивидуальные отношения с его руководителем сервиса. Модель агента — это один к многим: один чертеж может быть связан с множеством идентичностей агентов внутри арендатора.

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

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

Credentials

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

Поддерживаемые типы учетных данных в чертеже:

  • Учетные данные федеративной идентификации
  • Сертификаты и криптографические ключи
  • Секреты клиента

Для агентов, работающих на Azure, вы можете федерировать blueprint с управляемой идентичностью Azure, чтобы секрет не хранился в чертеже.

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

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

Учетная запись пользователя агента

Некоторым агентам необходимо получить доступ к системам, требующим пользовательской учётной записи Microsoft Entra. В таких случаях вы можете дать агенту второй аккаунт и отметить его в каталоге как AI-агента.

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

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

Important

Агенты с собственной учетной записью доступны только арендаторам, участвующим в программе предварительного просмотра Frontier.

Разрешения и процесс выполнения

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

Режим выполнения Description
S2S (сервис-сервис) Агент работает без пользовательского контекста и выступает в роли собственного идентификатора агента. Используйте этот режим для запланированных задач, мониторинга и фоновой обработки. Он использует разрешения приложений, а идентификатор агента является субъектом токена. Для базового шаблона OAuth см. раздел OAuth 2.0 client credentials grant.
OBO (от имени) Агент получает контекст авторизованного пользователя и действует от имени этого пользователя. Используйте этот режим, когда доступ зависит от личности пользователя или его прав. Он использует делегированные права; Пользователь является субъектом токена, а идентичность агента — актёром. Для подробностей реализации см. OAuth 2.0 On-Behalf-Of flow.
Агентный пользователь Агент работает со своей собственной учетной записью Microsoft Entra и выступает в роли этой учетной записи. Этот режим требует программы предварительного просмотра Frontier и используется, когда агенту нужны пользовательские ресурсы или пользовательские интерфейсы Microsoft 365, такие как почтовый ящик, присутствие в Teams или взаимодействия с Word и Outlook. Аккаунт пользователя агента является исполняющим обязанности пользователя, а идентификатор агента остаётся зарегистрированным агентом 365.

Например, ночная фоновая обработка обычно использует S2S; специфическое для пользователя действие в чате использует OBO; а чтение собственного почтового ящика агента использует Agentic-User. Модель разрешения и режим выполнения связаны, но не являются взаимозаменяемыми терминами: сначала выбирайте режим, затем подтверждаете приложение или делегированные разрешения и согласие, требуемые нижестоящим ресурсом.

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

  1. Определите, за кого агент должен действовать в операции: его идентификацию агента, авторизованного пользователя или собственную учётную запись.
  2. Убедитесь, что выбранный режим поддерживает контекст этого аккаунта и тип разрешения, требуемый целевой API или ресурсом.
  3. Предоставить необходимые возможности и согласие, затем выполнить дополнительные требования, такие как лицензии или предоставленный пользовательский ресурс.

Если какое-либо требование не поддерживается выбранным режимом, выберите другой режим или операцию. Для областей Microsoft Graph см. ссылку на разрешения Microsoft Graph.

Когда вы узнаете, какие права нужны агенту, решите, куда их назначить. Объявить общие базовые разрешения на чертеже, чтобы каждая созданная идентичность агента наследовала их, и назначить разрешения непосредственно идентификатору агента, когда доступ специфичен именно для этого агента. Azure role-based access control (RBAC) — исключение: чертежи не могут хранить роли Azure RBAC, поэтому назначайте эти роли напрямую каждому идентификатору агента. Идентификаторы агентов также могут содержать встроенные роли Microsoft Entra.

Important

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

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

Логи входа и аудита различают чертеж, идентификатор агента и пользовательскую запись агента. Рецензент может определить источник учетных данных, действующую личность и субъект токена. В операциях S2S идентификатор агента является субъектом токена. В операциях OBO авторизованный пользователь является субъектом, а идентификатор агента — актёром.

Что вы настраиваете

Когда вы переносите агента в Agent 365, вы регистрируете план идентификации агента в Microsoft Entra и создаёте идентичности агентов на его основе. Навык выполняет оба шага на стандартном пути make-a365-agent агента. На пути напарника с ИИ выполняет make-ai-teammate их. См. Быстрый старт: Подключите существующего агента к агенту 365.

Определите следующие пункты перед началом:

Item Description
Сколько чертежей Используйте один чертеж на каждой границе учетных данных. Используйте отдельные чертежи для агентов, которые не могут безопасно делиться учётными данными и унаследованными базовыми правами.
Какая модель разрешений Разрешения для приложений, делегированные разрешения или и то, и другое.
Нужен ли агент пользовательский аккаунт Только если требуется почтовый ящик, присутствие в Teams или профиль в организационном каталоге.
Кто являются спонсорами Каждый чертеж и идентичность каждого агента требуют как минимум одного спонсора — пользователя или группы.

Связанные материалы

  • Last updated on