Identidades de agentes, princípios de serviço e aplicativos

O modelo de aplicativo do agente apresenta tipos específicos de entidade de serviço com funções e características distintas em comparação com entidades de serviço de aplicativo não gerenciadas. Este artigo explica os principais de serviço no modelo de aplicação do agente, como eles se relacionam com o esquema de identidade do agente e diferem dos principais de serviço de aplicação não-agente.

Principal de esquema de identidade do agente

Os principais do blueprint de identidade do agente são criados automaticamente quando um blueprint de identidade do agente é instanciado em um inquilino. Essas entidades de serviço fornecem a representação em tempo de execução do modelo de identidade do agente no diretório do locatário e permitem que o modelo de identidade do agente execute operações como criar instâncias e gerenciar o ciclo de vida.

O processo de criação envolve operações de consentimento que exigem permissões como AgentIdentity.Create e ServicePrincipal.Manage.OwnedBy. O principal de blueprint de identidade do agente permite que o blueprint de identidade do agente obtenha tokens somente para aplicativos para chamadas do Microsoft Graph necessárias para criar e gerenciar identidades de agente. Esse processo é essencial porque os próprios modelos do agente não podem obter tokens diretamente para operações no Microsoft Graph.

Identidade do agente como principal de serviço

As identidades do agente são modeladas como entidades de serviço de locatário único com uma nova classificação de subtipo "agente". Esse design usa a infraestrutura de entidade de serviço do Microsoft Entra ID existente, além de adicionar restrições e comportamentos específicos de agentes.

As identidades de agentes herdam suas propriedades de protocolo do modelo de identidade do agente pai através da relação ParentID. Ao contrário das entidades de serviço sem agente que operam de forma independente, as identidades do agente exigem o modelo de identidade do agente pai para operações de personificação e troca de tokens.

As identidades dos agentes podem receber permissões diretamente e aparecer em registros de entrada quando os tokens são emitidos para operações de agentes. Eles servem como a identidade primária que os clientes consideram ao gerenciar permissões e acessos de agentes.

A entidade de blueprint de identidade do agente cria entidades de serviço de identidade do agente usando chamadas do Microsoft Graph com tokens somente de aplicativo e funções apropriadas. O processo de criação estabelece a relação pai-filho e configura as relações FIC (Federated Identity Credential) necessárias para representação.

Agentes criados usando entidades de serviço de aplicativo

Antes da introdução da plataforma de identidade do agente da Microsoft, alguns aplicativos da Microsoft, como o Microsoft Copilot Studio e o Azure AI Foundry, usavam entidades de serviço do agente de aplicativo para garantir que seus agentes fossem protegidos com identidades. Eles são mostrados juntamente com objetos de identidade de agente no seu ambiente na lista Todas as Identidades do Agente.

Eles podem ser diferenciados nesta lista filtrando para encontrar aqueles que usam identidades de agentes. Com o filtro, você pode mostrar objetos de identidade do agente ou agentes usando entidades de serviço de aplicativo. Consulte a lista de colunas na lista Todas as identidades de agentes.

Esses agentes que usam a entidade de serviço se comportam da mesma forma que as entidades de serviço de aplicativo e não têm as mesmas diferenças das entidades de serviço de aplicativo que as identidades do agente ou as entidades de blueprint de identidade do agente.

Principais diferenças das entidades de serviço nonagent

As seções a seguir descrevem as principais diferenças entre as entidades de serviço do agente e as entidades de serviço de aplicativo não engenhosas.

Modelo de Impersonação

Os principais de serviço não-agentivos operam usando suas próprias credenciais e identidade. As entidades de serviço do agente usam um modelo de representação em que o plano de identidade do agente representa a identidade do agente para executar operações em nome da instância.

Esse modelo de representação permite que o blueprint de identidade do agente obtenha tokens em que a identidade do agente aparece como o cliente, mesmo que o blueprint de identidade do agente esteja executando a troca de tokens real. Os tokens resultantes mantêm a identidade do agente nos logs de auditoria, permitindo ao modelo de identidade do agente orquestrar fluxos de tokens complexos.

Relacionamento de múltiplas instâncias

Aplicativos não-agentes normalmente têm uma relação de um para um entre o aplicativo e a entidade de serviço. O modelo de aplicativo de agente introduz uma relação um-para-muitos em que um blueprint de identidade de agente pode ter vários princípios de serviço de identidade de agente entre e dentro de locatários.

Esse modelo de múltiplas instâncias permite cenários como a criação de várias identidades de agente por canal do Teams, por projeto ou por unidade organizacional, todas derivando suas propriedades de protocolo de uma mesma estrutura de identidade de agente principal.

Gerenciamento de credenciais em tempo de execução

Principais de serviço não-agenticos gerenciam suas próprias credenciais (certificados, segredos e identidades gerenciadas). A entidade de serviço apresenta essas credenciais para obter tokens para si mesma ou para executar operações em nome de usuários. As identidades dos agentes dependem de credenciais do modelo de identidade do agente pai e não podem gerenciar credenciais de forma independente. As entidades de serviço de identidade do agente não executam a autenticação direta.

Modelo de consentimento e permissão

As entidades de serviço não agentivas recebem permissões por meio de atribuição direta ou consentimento do administrador. Os principais de serviço do agente dão suporte tanto à atribuição direta de permissões quanto à herança de aplicativos pai.

Quando a herança de permissões delegadas está habilitada, uma identidade de agente pode herdar permissões delegadas do blueprint de identidade do agente pai, reduzindo a complexidade do consentimento para cenários de várias instâncias. Essa herança se aplica quando a representação é usada e permite o gerenciamento eficiente de permissões em várias instâncias.

Permissão e atribuição de função

Os princípios de serviço do agente dão suporte a permissões de aplicativo (para operações de aplicativo apenas) e permissões delegadas (para operações delegadas ao usuário). A atribuição de permissão pode ser direta ou herdada dependendo dos requisitos do cenário.

Atribuição direta: as permissões podem ser atribuídas diretamente a uma identidade de agente para requisitos de acesso específicos de instância.

Atribuição herdada: Quando InheritDelegatedPermissions está habilitada no principal de serviço, as identidades de agente herdam permissões delegadas do modelo de identidade do agente pai, simplificando o gerenciamento de permissões em cenários de múltiplas instâncias.

Atribuição de função: As identidades dos agentes podem ser atribuídas a funções RBAC (Controle de Acesso Baseado em Função) do Azure e funções de diretório, como principais de serviço não agenciais, habilitando o acesso a recursos e operações administrativas. Blueprint de identidade do agente não pode ser atribuída a funções do RBAC do Azure

Auditoria e registro em log

As entidades de serviço do agente mantêm identidades distintas em logs de auditoria e relatórios de entrada. Quando uma identidade de agente executa operações, os logs mostram a identidade do agente como o cliente representante, indicando a relação com o modelo de identidade do agente pai.

Os logs de entrada diferenciam entre esboços de identidade do agente, identidades do agente e usuários do agente. Essa diferenciação permite identificação de função clara (cliente, credencial, assunto) dependendo da operação específica que está sendo executada. Isso possibilita auditorias das operações dos agentes.