Понятия идентичности агента в Microsoft Foundry

Удостоверение типа agent identity — это специальный тип удостоверения в Microsoft Entra ID, предназначенный именно для агентов ИИ. Она предоставляет стандартизованную платформу для управления, проверки подлинности и авторизации агентов ИИ в Microsoft services. Эта инфраструктура позволяет агентам безопасно получать доступ к ресурсам, взаимодействовать с пользователями и общаться с другими системами.

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

В этой статье объясняется, как удостоверения агента связаны с объектами Microsoft Entra ID, как Foundry использует их при вызове средств агента и как применить доступ с минимальными привилегиями с помощью управления доступом на основе ролей Azure (RBAC).

Предпосылки

• Понимание аутентификации Microsoft Entra ID и OAuth
• Знакомство с ролевым управлением доступом Azure (RBAC)
• Основные знания агентов ИИ и их требования к среде выполнения

Для просмотра ролей и областей Foundry, связанных с управлением доступом на основе ролей (RBAC), см. раздел Azure управление доступом на основе ролей в Foundry.

Как работают идентификаторы агентов в Foundry

Foundry использует удостоверения агента Microsoft Entra ID для поддержки двух связанных потребностей:

• Управление и управление. Предоставление администраторам согласованного способа инвентаризации агентов, применения политик и действий аудита.
• Tool authentication: пусть агент проходит проверку подлинности в подчиненных системах (например, Azure Storage) без внедрения секретов в запросы, код или строки подключения.

На высоком уровне Foundry делает следующее:

1. Подготавливает схему удостоверения агента и одно или несколько агентских удостоверений в Microsoft Entra ID.
2. Назначает роли RBAC (или другие модели разрешений в зависимости от целевой системы) идентификатору агента.
3. Когда агент вызывает инструмент, Foundry запрашивает токен доступа для нижестоящего сервиса и использует этот токен для проверки подлинности вызова инструмента.

Обмен маркерами выполнения

Когда агент вызывает средство, многократный обмен токенами OAuth 2.0 выполняется автоматически между службой агентов, Microsoft Entra ID и вторичным ресурсом. Разработчики не управляют токенами напрямую — служба агентов обрабатывает весь обмен.

Обмен выполняется на четырех этапах:

• Аутентификация чертежа: служба агента представляет учетные данные OAuth чертежа для Microsoft Entra ID. Это свидетельствует о том, что служба агента имеет право действовать от имени плана и его удостоверений агента.

• Выдача токена идентификации агентом: Microsoft Entra ID проверяет учетные данные схемы и выдает токен для конкретного удостоверения агента. Этот токен отличается от токенов пользовательского или управляемого удостоверения — он определяет агента как независимого субъекта в каталоге.

• Запросить токенаScoped: служба агента предоставляет маркер удостоверения агента обратно в Microsoft Entra ID и запрашивает новый маркер доступа, ограниченный audience нижестоящей службы. Аудитория — это идентификатор ресурса OAuth для целевой службы (например, https://storage.azure.com для Azure Storage).

• Вызов аутентифицированного инструмента: служба агента передает контекстный токен доступа на сервер MCP или конечную точку A2A. Последующий ресурс подтверждает токен и проверяет назначенные роли RBAC для удостоверения агента перед предоставлением или запретом доступа.

В следующей таблице перечислены общие значения аудитории для глобальных служб Azure:

Нисходящая служба	Значение аудитории
Azure Storage	https://storage.azure.com
Azure Logic Apps	https://logic.azure.com
Azure Cosmos DB	https://cosmos.azure.com
Microsoft Graph	https://graph.microsoft.com
Azure Key Vault	https://vault.azure.net

Это важно

Неправильное значение параметра audience приводит к сбоям проверки подлинности даже при правильном назначении ролей RBAC. Аудитория должна соответствовать идентификатору ресурса нижней службы, а не URL-адресу самого сервера MCP.

Термины, используемые в этой статье

Срок	Что это означает для Foundry
Удостоверение агента	Принципал службы Microsoft Entra ID, представляющий агент в режиме выполнения.
Схема идентификации агента	Объект Microsoft Entra ID, который регулирует класс идентичностей агента и используется для операций жизненного цикла.
agentIdentityId	Идентификатор, используемый при назначении разрешений для идентичности агента.
Аудитория	Идентификатор ресурса для нижестоящей службы, для которой предназначен маркер (например, https://storage.azure.com).

Основные понятия

Платформа идентификаторов агента вводит формальные идентичности агентов и чертежи идентичности агентов в Microsoft Entra ID для представления агентов ИИ. Эту платформу можно использовать для безопасного взаимодействия с агентами ИИ. Эта платформа также позволяет этим агентам ИИ безопасно взаимодействовать с веб-службами, другими агентами ИИ и различными системами.

Замечание

Платформа Microsoft Entra Agent ID в настоящее время находится в предварительной версии. Функции и API могут изменяться до общедоступной доступности.

Удостоверение агента

Учетная запись агента — это специальная учетная запись службы в Microsoft Entra ID. Он представляет личность, созданную схемой идентичности агента и уполномоченной совершать действия от имени.

Преимущества безопасности

Удостоверения агентов помогают решить определенные проблемы безопасности, которые представляют агенты ИИ:

• Различайте операции, выполняемые агентами ИИ, от операций, выполняемых сотрудниками, клиентами или идентификаторами рабочих нагрузок.
• Разрешить агентам ИИ получать целесообразный доступ в различных системах.
• Запретить агентам ИИ получать доступ к критически важным ролям и системам безопасности.
• Масштабирование управления удостоверениями до большого количества агентов ИИ, которые можно быстро создать и уничтожить.

Возможности проверки подлинности

Идентификации агента поддерживают два ключевых сценария аутентификации.

• Участие (делегированный доступ или поток доступа от имени): агент действует от имени пользователя, используя поток OAuth 2.0 от имени (OBO). Пользователь сначала проходит проверку подлинности в приложении, а приложение передает маркер пользователя службе агента. Затем служба агента обменивает этот токен на токен, содержащий как идентификацию агента, так и делегированные разрешения пользователя. Этот подход означает, что агент имеет доступ только к ресурсам, на которые пользователь дал согласие и для которых у него есть разрешение.
• Автономный (поток только для приложений): агент действует по собственному усмотрению, использует поток учетных данных клиента OAuth 2.0. Служба агента проверяет подлинность плана в Microsoft Entra ID, получает токен для идентичности агента и запрашивает специализированный токен доступа для ресурса на нижних уровнях. Доступ агента полностью регулируется собственными назначениями ролей RBAC, разрешениями уровня приложения Microsoft Graph или другими политиками авторизации — без участия человека.

Схема идентификации агента

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

Возможности схемы

Схемы идентификации агента служат тремя основными целями:

Классификация типов: схема устанавливает категорию агента, например "Агент продаж Contoso". Эта классификация позволяет администраторам:

• Примените политики условного доступа ко всем агентам этого типа.
• Отключите или отмените разрешения для всех агентов этого типа.
• Аудит и управление агентами в крупном масштабе с помощью последовательных элементов управления на основе шаблона.

Центр создания удостоверений: службы, создающие удостоверения агента, используют схему для проверки подлинности. Планы имеют учетные данные OAuth, которые службы используют для запроса токенов из Microsoft Entra ID для создания, обновления или удаления удостоверений агента. Эти учетные данные включают секреты клиента, сертификаты или федеративные учетные данные, такие как управляемые удостоверения.

Платформа проверки подлинности среды выполнения. Служба размещения использует схему во время проверки подлинности среды выполнения. Служба запрашивает токен доступа с помощью учетных данных OAuth шаблона. Затем он представляет этот маркер для Microsoft Entra ID для получения маркера для одного из удостоверений агента.

Метаданные чертежа

Например, организация может использовать агент ИИ с именем "Агент продаж Contoso". Схема определяет такие сведения, как:

• Имя типа агента: "Агент продаж Contoso".
• Организация или издатель, ответственный за проект: Contoso.
• Роли, которые может выполнять агент: "менеджер по продажам" или "представитель продаж".
• Microsoft Graph разрешения или делегированные области действия: "чтение календаря пользователя, вошедшего в систему".

Учетные данные федеративной идентификации

Учетные данные OAuth схемы определяют, как служба агента выполняет проверку подлинности в Microsoft Entra ID во время обмена маркерами runtime. Схемы поддерживают три типа учетных данных:

Тип учетных данных	Принцип работы	Trade-offs
Секрет клиента	Общая строка секрета, хранящаяся в регистрации Entra ID плана.	Настраивается проще всего, но требует поворота вручную и безопасного хранения.
Сертификат	Сертификат X.509, используемый для проверки подлинности на основе утверждений.	Сильнее, чем секреты клиента, но требует управления жизненным циклом сертификатов.
Федеративные учетные данные (управляемая идентичность)	Отношение доверия между планом и управляемым удостоверением или служебным принципалом. Секрет не хранится в схеме.	Рекомендуется для эксплуатации в производственной среде. Azure автоматически управляет сменой учетных данных.

Параметр федеративных учетных данных является наиболее актуальным для Foundry. Когда Foundry подготавливает шаблон удостоверения агента для вашего проекта, этот шаблон устанавливает доверительные отношения с управляемым удостоверением проекта. Цепочка проверки подлинности работает следующим образом:

• Схема удостоверения агента имеет федеративное отношение доверия учетных данных с управляемым удостоверением проекта.
• Во время выполнения служба агента использует управляемое удостоверение для проверки подлинности схемы в Microsoft Entra ID. Секрет клиента или сертификат не требуется.
• Entra ID проверяет федеративные учетные данные и выдает токен для идентификации агента (субъект-служба).
• Затем маркер удостоверения агента обменивается на токен с ограниченной областью доступа, ориентированный на целевую аудиторию нижестоящего ресурса.

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

Замечание

Управляемое удостоверение проверяет подлинность blueprint для Entra ID. Он напрямую не обращается к нижестоящему ресурсу. Удостоверение агента, а не управляемое удостоверение, — это субъект, которому требуются назначения ролей RBAC в целевом ресурсе.

Интеграция с Foundry

Foundry автоматически интегрируется с Microsoft Entra Agent ID, создавая и управляя удостоверениями в течение всего жизненного цикла разработки агента. При создании первого агента в проекте Foundry система подготавливает стандартную схему удостоверения и стандартное удостоверение агента для вашего проекта.

Общее обозначение проекта

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

• Администрирование упрощено: Администраторы могут централизованно управлять разрешениями для всех агентов, находящихся в разработке, в проекте.
• Reduced identity sprawl. Использование одного удостоверения на проект предотвращает создание ненужных удостоверений на начальном этапе эксперимента.
• Автономия разработчика. После настройки общей идентификации разработчики могут самостоятельно создавать и тестировать агенты без повторной настройки новых разрешений.

Чтобы найти чертеж общей идентичности агента и идентичность агента, перейдите в проект Foundry на портале Azure. На панели обзора выберите представление JSON. Выберите последнюю версию API для просмотра и копирования идентификаторов.

Снимок экрана представления JSON на портале Azure, отображающий шаблон идентификации агента и данные идентификации агента для проекта Foundry.

Уникальное удостоверение агента

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

Ниже приведены распространенные сценарии, требующие отдельных идентичностей:

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

Чтобы найти отдельную схему идентификации агента и удостоверение агента, перейдите к ресурсу приложения агента на портале Azure. На панели обзора выберите представление JSON. Выберите последнюю версию API для просмотра и копирования идентификаторов.

Средства автоматизации и развертывания

Средства развертывания, такие как интерфейс командной строки разработчика Azure (azd), предоставляют ограниченную автоматизацию для разрешений удостоверения агента:

• Разработка: azd автоматически назначает Azure AI User общей агентской идентичности проекта для неопубликованных агентов
• Промышленная среда: опубликованные агенты получают отдельные идентификаторы, для которых требуется вручную назначить роли.

azd не настраивает реестр контейнеров, Application Insights или пользовательские разрешения ресурсов. Сведения о рабочих развертываниях и полных требованиях к разрешениям для размещенных агентов см. в справочнике по разрешениям размещенного агента.

Проверка подлинности инструмента

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

• Неопубликованные агенты: Проверка подлинности с использованием идентификации агента общего проекта.
• Опубликованные агенты: Аутентификация с использованием уникального идентификатора агента, связанного с приложением агента.

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

Назначьте разрешения для идентификации агента

Удостоверение агента — это учетная запись службы в Microsoft Entra ID. Назначьте ему роли RBAC так же, как вы назначаете роли любому другому субъекту службы или управляемому удостоверению. Используйте agentIdentityId из представления JSON вашего проекта или приложения агента в качестве назначенного.

Например, чтобы предоставить удостоверению агента доступ на чтение и запись к учетной записи хранения данных, назначьте роль Соучастник данных хранилища Blob в области учетной записи хранения данных:

az role assignment create \
    --assignee "<agentIdentityId>" \
    --role "Storage Blob Data Contributor" \
    --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>"

Чтобы проверить назначение, выполните следующие действия.

az role assignment list \
    --assignee "<agentIdentityId>" \
    --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>" \
    --output table

Распространенные назначения ролей для инструментов агента:

Сценарий инструмента	Требуемая роль	Целевая область
Сервер MCP, который считывает и записывает большие двоичные объекты	Вкладчик данных хранилища BLOB	учетная запись хранения
Сервер MCP, который активирует приложения логики	Оператор Logic Apps Standard (предварительная версия)	Ресурс приложения логики
Средство A2A, которое запрашивает Cosmos DB	Встроенный модуль чтения данных Cosmos DB	Учетная запись Cosmos DB

Это важно

При публикации агента он получает новый отдельный идентификатор agentIdentityId. Повторите эти назначения ролей для нового удостоверения. Роли идентификации общего проекта не переносятся на идентификацию опубликованного агента.

Tip

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

Поддерживаемые инструменты

В настоящее время средства, поддерживающие проверку подлинности с помощью удостоверения агента:

• Протокол контекста модели (MCP): используйте удостоверение агента для проверки подлинности с серверами MCP, поддерживающими проверку подлинности удостоверений агента (предварительная версия). Дополнительные сведения см. в разделе "Протокол контекста модели " и проверка подлинности сервера MCP.
• Агент — агент (A2A): включение безопасного взаимодействия между агентами с помощью удостоверений агента (предварительная версия). Дополнительные сведения см. в разделе "Средство "агент — агент" и проверка подлинности Agent2Agent (A2A).

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

Настройка подключений к инструменту

Чтобы подключить сервер MCP или конечную точку A2A с проверкой подлинности удостоверения агента, создайте подключение к проекту, указывающее тип проверки подлинности и целевую аудиторию для нижестоящей службы. Тип проверки подлинности зависит от средства:

Тип инструмента	Значение типа проверки подлинности	Категория подключения
Сервер MCP	AgenticIdentityToken	RemoteTool
Конечная точка A2A	AgenticIdentity	RemoteA2A

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

Пошаговые инструкции по настройке см. в следующих руководствах.

• Настройка проверки подлинности сервера MCP
• Проверка подлинности Agent2Agent (A2A)

Вопросы безопасности

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

• Назначьте только те разрешения, которые необходимы агенту для работы с инструментом. Предпочитайте узкие области (ресурс или группу ресурсов) вместо доступа на уровне подписки.
• Рассматривайте общую идентичность проекта как более широкий охват рассматриваемого объекта. Если агент нуждается в более жестких элементах управления или отдельном аудите, опубликуйте его, чтобы он приобрел отдельную идентичность, и назначьте роли этой новой идентичности.
• Просмотрите и зафиксируйте доступ к средствам и серверам, не относящимся к Microsoft. Если вызов средства выходит за пределы сервисов Microsoft, обработка и хранение ваших данных зависят от внешнего поставщика.

Ограничения

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

Распространенные проблемы

Эти проблемы часто вызывают сбои аутентификации инструментов при использовании удостоверений агента.

• Роли, назначенные неправильному удостоверению. Убедитесь, что вы предоставили разрешения текущему удостоверению, используемому агентом (удостоверение общего проекта для неопубликованных агентов, уникальное удостоверение для опубликованных агентов).
• Отсутствующие назначения ролей: Убедитесь, что удостоверение агента имеет необходимую роль RBAC на целевом ресурсе. Сведения о ролях и областях Foundry см. в разделе Azure управление доступом на основе ролей в Foundry.
• Некорректная аудитория: Убедитесь, что аудитория соответствует вызываемой ниже службе (например, https://storage.azure.com для Azure Storage).

Сведения об устранении неполадок с конкретным инструментом см. в документации по инструменту:

• Протокол контекста модели
• Средство "Агент — агент"

Управление удостоверениями агента

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

Вы можете просматривать и управлять всеми удостоверениями агента в вашем клиенте через Microsoft Entra Admin Center. Войдите в Microsoft Entra admin center и перейдите к Entra ID>Agent ID>Все удостоверения агентов, чтобы ознакомиться с инвентаризацией всех агентов в арендаторе, включая агентов Foundry, агентов Microsoft Copilot Studio и других.

В этом интерфейсе можно включить встроенные элементы управления безопасностью, в том числе:

• Conditional Access: Применение политик доступа к удостоверениям агента.
• Защита идентификации: мониторинг и защита удостоверений агентов от угроз.
• Network access: Управление сетевым доступом для агентов.
• Управление: управление истечением срока действия, владельцами и спонсорами для удостоверений агентов.

Дополнительные сведения о функциях Microsoft Entra Agent ID см. в документации Microsoft Entra.

Связанный контент

• Приложения агента в Microsoft Foundry
• Управление доступом на основе ролей в Azure Foundry
• Проверка подлинности сервера MCP
• Проверка подлинности Agent2Agent (A2A)
• Microsoft Entra Agent ID документация