Conceitos de identidade de agente no Microsoft Foundry

Uma identidade de agente é um tipo de identidade especializado do Microsoft Entra ID concebido especificamente para agentes de IA. Fornece uma estrutura padronizada para governar, autenticar e autorizar agentes de IA em todos os serviços da serviços Microsoft. Esta estrutura permite aos agentes aceder de forma segura a recursos, interagir com os utilizadores e comunicar com outros sistemas.

A Microsoft Foundry provisiona e gere automaticamente as identidades dos agentes ao longo de todo o ciclo de vida do agente. Esta integração simplifica a gestão de permissões, mantendo a segurança e a auditabilidade à medida que os agentes passam do desenvolvimento para a produção.

Este artigo explica como as identidades dos agentes se relacionam com os objetos do Microsoft Entra ID, como a Foundry as utiliza quando um agente liga a ferramentas e como aplicar o acesso de privilégio mínimo com o controlo de acesso baseado em funções (RBAC) do Azure.

Pré-requisitos

• Compreender a autenticação de Microsoft Entra ID e OAuth
• Familiaridade com controlo de acesso baseado em funções Azure (RBAC)
• Conhecimentos básicos sobre agentes de IA e os seus requisitos de execução

Para funções e âmbitos específicos de RBAC no Foundry, veja Azure role-based access control no Foundry.

Como funcionam as identidades dos agentes na Foundry

A Foundry utiliza identidades de agentes Microsoft Entra ID para suportar duas necessidades relacionadas:

• Gestão e governação: Dar aos administradores uma forma consistente de inventariar agentes, aplicar políticas e auditar atividades.
• Autenticação de ferramenta: Permite que um agente autentique-se em sistemas a jusante (por exemplo, Armazenamento do Azure) sem incorporar segredos em prompts, código ou cadeias de conexão.

A um nível geral, a Foundry faz o seguinte:

1. Provisione um blueprint de identidade do agente e uma ou mais identidades de agente no Microsoft Entra ID.
2. Atribui papéis RBAC (ou outros modelos de permissões, dependendo do sistema de destino) à identidade do agente.
3. Quando o agente invoca uma ferramenta, o Foundry solicita um token de acesso para o serviço downstream e usa esse token para autenticar a chamada à ferramenta.

Troca de tokens em tempo de execução

Quando um agente invoca uma ferramenta, ocorre automaticamente uma troca de tokens OAuth 2.0 em múltiplos passos entre o Agent Service, o Microsoft Entra ID e o recurso a jusante. Os programadores não gerem os tokens diretamente — o Serviço de Agentes gere toda a troca.

A troca progride por quatro fases:

• Autenticação do Blueprint: O Serviço de Agente apresenta as credenciais OAuth do Blueprint à Microsoft Entra ID. Isto prova que o Serviço de Agente está autorizado a agir em nome do plano e das suas identidades de agente.

• Emissão de token de identidade de agente: Microsoft Entra ID valida as credenciais do plano base e emite um token para uma identidade de agente específica. Este token é distinto dos tokens de utilizador humano ou de identidade gerida — identifica o agente como um ator independente no diretório.

• Pedido de token com âmbito: O Serviço de Agente apresenta o token de identidade do agente de volta ao Microsoft Entra ID e solicita um novo token de acesso com âmbito para o público do serviço a jusante. O público é o identificador de recurso OAuth para o serviço-alvo (por exemplo, https://storage.azure.com para Armazenamento do Azure).

• Chamada de ferramenta autenticada: O Serviço de Agente passa o token de acesso com escopo ao servidor MCP ou ao endpoint A2A. O recurso a jusante valida o token e verifica as atribuições de funções RBAC da identidade do agente antes de conceder ou negar o acesso.

A tabela seguinte lista valores de audiência comum para serviços Azure globais:

Termos usados neste artigo

Conceitos-chave

O framework da plataforma Agent ID introduz identidades de agente formais e planos de identidade de agente no Microsoft Entra ID para representar agentes de IA. Pode usar esta estrutura para comunicar de forma segura com agentes de IA. Este framework também permite que esses agentes de IA comuniquem de forma segura com serviços web, outros agentes de IA e vários sistemas.

Identidade do agente

Uma identidade de agente é um princípio de serviço especial no Microsoft Entra ID. Representa uma identidade que o blueprint de identidade do agente criou e está autorizado a imitar.

Benefícios de segurança

As identidades dos agentes ajudam a resolver desafios de segurança específicos que os agentes de IA colocam:

• Distingua as operações que os agentes de IA realizam das operações que as identidades da força de trabalho, do cliente ou da carga de trabalho realizam.
• Permitir que os agentes de IA obtenham acesso adequado entre sistemas.
• Impedir que agentes de IA acedam a funções e sistemas críticos de segurança.
• Escale a gestão de identidade para um grande número de agentes de IA que possam ser rapidamente criados e destruídos.

Capacidades de autenticação

As identidades dos agentes suportam dois cenários chave de autenticação:

• Intermediado (acesso delegado ou fluxo de representação): O agente opera em nome de um utilizador humano, utilizando o fluxo OAuth 2.0 de representação (OBO). O utilizador autentica-se primeiro na aplicação, e esta passa o token do utilizador para o Serviço Agente. O Serviço de Agente troca então esse token por um que transporta tanto a identidade do agente como as permissões delegadas pelo utilizador. Esta abordagem significa que o agente só pode aceder a recursos aos quais o utilizador consentiu e está autorizado.
• Fluxo sem supervisão (apenas de aplicação): O agente opera sob sua própria autoridade, utilizando as credenciais do cliente no fluxo OAuth 2.0. Agent Service autentica o blueprint para o Microsoft Entra ID, obtém um token para a identidade do agente e solicita um token de acesso delimitado para o recurso downstream. O acesso do agente é totalmente governado pelas suas próprias atribuições de funções RBAC, permissões ao nível da aplicação Microsoft Graph ou outras políticas de autorização — não está envolvido nenhum utilizador humano.

Plano de identidade do agente

Um plano de identidade de agente serve como o modelo regulador reutilizável a partir do qual todas as identidades de agente associadas são criadas. Corresponde a um tipo, tipo ou classe de agentes. Atua como objeto de gestão para o conjunto de identidades de agente dessa classe.

Capacidades do Blueprint

Os planos de identidade do agente cumprem três propósitos essenciais:

Classificação por tipo: O blueprint estabelece a categoria de agente, como "Agente de Vendas Contoso." Esta classificação permite aos administradores:

• Aplique políticas de Acesso Condicional a todos os agentes desse tipo.
• Desative ou revoge permissões para todos os agentes desse tipo.
• Auditar e governar agentes em escala através de controlos consistentes baseados em modelos.

Autoridade de criação de identidade: Os serviços que criam identidades de agentes utilizam o blueprint para autenticar. Os Blueprints têm credenciais OAuth que os serviços usam para solicitar tokens ao Microsoft Entra ID para criar, atualizar ou eliminar identidades de agentes. Estas credenciais incluem segredos de clientes, certificados ou credenciais federadas como identidades geridas.

Plataforma de autenticação em tempo de execução: O serviço de alojamento utiliza o plano durante a autenticação em tempo de execução. O serviço solicita um token de acesso utilizando as credenciais OAuth do blueprint. Depois, apresenta esse token ao Microsoft Entra ID para obter um token para uma das identidades dos seus agentes.

Metadados do blueprint

Por exemplo, uma organização pode usar um agente de IA chamado "Agente de Vendas Contoso". O plano define informações como:

• O nome do tipo de agente é "Contoso Sales Agent".
• O editor ou organização responsável pelo projeto: "Contoso."
• As funções que o agente pode desempenhar: "gestor de vendas" ou "representante de vendas".
• Permissões do Microsoft Graph ou escopos delegados: "leia o calendário do utilizador com sessão iniciada."

Credenciais de identidade federada

As credenciais OAuth do blueprint determinam como o Serviço de Agente se autentica no Microsoft Entra ID durante a troca de tokens em tempo de execução. Os Blueprints suportam três tipos de credenciais:

A opção de credencial federada é a mais relevante para a Foundry. A Foundry, ao fornecer um modelo de identidade do agente para o seu projeto, estabelece uma relação de confiança com a identidade gerida do projeto. A cadeia de autenticação funciona da seguinte forma:

• O esquema de identidade do agente tem uma relação de confiança federada de credenciais com a identidade gerida do projeto.
• Durante a execução, o Serviço de Agente utiliza a identidade gerida para autenticar o blueprint com o Microsoft Entra ID. Não é necessário segredo do cliente nem certificado.
• Entra ID valida a credencial federada e emite um token para a identidade do agente (o principal de serviço).
• O token de identidade do agente é então trocado por um token de acesso com âmbito direcionado ao público-alvo do recurso a jusante.

Esta cadeia foi concebida para eliminar segredos armazenados na configuração do blueprint. O Azure gere a rotação de credenciais através da infraestrutura da identidade gerida, e cada camada — identidade gerida, identidade do agente, e recurso downstream — tem atribuições independentes de menor privilégio. No entanto, algumas configurações de ferramentas ainda expõem a identidade gerida pelo projeto como uma opção de autenticação.

Integração de fundição

O Foundry integra-se automaticamente com o ID do Agente Microsoft Entra, criando e gerindo identidades ao longo do ciclo de vida do desenvolvimento do agente. Quando cria o seu primeiro agente num projeto Foundry, o sistema fornece um blueprint padrão de identidade de agente e uma identidade de agente padrão para o seu projeto.

Identidade partilhada do projeto

Todos os agentes não publicados ou em desenvolvimento dentro do mesmo projeto partilham uma identidade comum. Este design simplifica a gestão de permissões porque agentes não publicados normalmente requerem os mesmos padrões de acesso e configurações de permissões. A abordagem de identidade partilhada oferece estes benefícios:

• Administração simplificada: Os administradores podem gerir centralmente as permissões de todos os agentes em desenvolvimento dentro de um projeto.
• Redução da expansão da identidade: A utilização de uma única identidade por projeto evita a criação desnecessária de identidade durante a experimentação inicial.
• Autonomia do programador: Depois de configurada a identidade partilhada, os programadores podem construir e testar agentes de forma independente, sem ter de configurar repetidamente novas permissões.

Para encontrar o blueprint de identidade do agente partilhado e a identidade do agente, vá ao seu projeto Foundry no portal Azure. No painel de Visão Geral , selecione Visualização JSON. Escolha a versão mais recente da API para visualizar e copiar as identidades.

Identidade distinta do agente

Quando as permissões, a auditabilidade ou os requisitos do ciclo de vida de um agente divergem dos padrões do projeto, deve atualizar para uma identidade distinta. Publicar um agente cria automaticamente um plano diretor dedicado à identidade do agente e a identidade correspondente do agente. Ambos estão ligados ao recurso de aplicação do agente. Esta identidade distinta representa a autoridade do sistema do agente para aceder aos seus próprios recursos.

Cenários comuns que exigem identidades distintas incluem:

• Agentes prontos para testes de integração.
• Agentes preparados para uso em produção.
• Agentes que exigem conjuntos de permissões únicos.
• Agentes que precisam de trilhas de auditoria independentes.

Para encontrar o modelo distinto de identidade do agente e a própria identidade do agente, aceda ao recurso de aplicação do seu agente no portal Azure. No painel de Visão Geral , selecione Visualização JSON. Escolha a versão mais recente da API para visualizar e copiar as identidades.

Automação e ferramentas de implementação

Ferramentas de implementação como o Azure Developer CLI (azd) fornecem automação limitada para permissões de identidade de agente:

• Development: o azd atribui automaticamente o Utilizador de Azure AI à identidade partilhada do agente de projeto para agentes não publicados
• Produção: Os agentes publicados recebem identidades distintas que requerem atribuições manuais de funções

O azd não configura o Registo de Contêineres, Application Insights ou permissões de recursos personalizados. Para implementações em produção e os requisitos completos de permissões para agentes alojados, consulte Referência de permissões de agentes hospedados.

Autenticação de ferramentas

Os agentes acedem a recursos e ferramentas remotas utilizando identidades de agentes para autenticação. O mecanismo de autenticação difere consoante o estado de publicação do agente:

• Agentes não publicados: Autentique usando a identidade de agente do projeto partilhado.
• Agentes publicados: Autentique-se usando a identidade única do agente, que está associada à aplicação do agente.

Quando publica um agente, deve reatribuir permissões RBAC à nova identidade do agente para quaisquer recursos que o agente precise aceder. Esta reatribuição assegura que o agente publicado mantém o acesso adequado enquanto opera sob a sua identidade distinta.

Atribuir permissões à identidade do agente

A identidade do agente é um principal de serviço no serviço Microsoft Entra ID. Atribui-lhe funções RBAC da mesma forma que atribuis funções a qualquer outro principal de serviço ou identidade gerida. Usa a agentIdentityId vista JSON do teu projeto ou da aplicação agente como o cessionário.

Por exemplo, para conceder a um agente identidade acesso de leitura/escrita a uma conta de armazenamento, atribua o papel Storage Blob Data Contributor no âmbito da conta de armazenamento.

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

Para verificar a tarefa:

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

Designações comuns de funções para ferramentas de agentes:

Ferramentas suportadas

Atualmente, as ferramentas que suportam autenticação com identidade de agente são:

• Protocolo de Contexto de Modelo (MCP): Use a identidade do seu agente para autenticar-se em servidores MCP que suportem autenticação de identidade de agente (versão de pré-visualização). Para mais detalhes, consulte Protocolo de Contexto de Modelo e autenticação do servidor MCP.
• Agente-para-Agente (A2A): Permitir a comunicação segura entre agentes utilizando identidades de agentes (versão de pré-visualização). Para mais detalhes, consulte a ferramenta Agent-para-Agente e a autenticação Agent2Agent (A2A).

Outras ferramentas e integrações podem usar métodos de autenticação diferentes (por exemplo, autenticação baseada em chaves ou passagem de identidade OAuth). Use a documentação da ferramenta para confirmar a autenticação suportada.

Configurar ligações de ferramentas

Para ligar um servidor MCP ou endpoint A2A com autenticação de identidade de agente, crie uma ligação ao projeto que especifique o tipo de autenticação e o público-alvo do serviço a jusante. O tipo de autenticação depende da ferramenta:

Quando o agente invoca a ferramenta, o Serviço do Agente usa a identidade do agente para obter um token de acesso com o âmbito do valor da audiência , passando depois esse token para o endpoint da ferramenta para autenticação.

Para instruções de configuração passo a passo, veja:

• Configurar autenticação do servidor MCP
• Autenticação Agent2Agent (A2A)

Considerações de segurança

As identidades dos agentes ajudam-no a reduzir riscos ao eliminar a necessidade de incorporar credenciais duradouras nas configurações dos agentes. Use estas práticas para manter o acesso com privilégio mínimo e auditável:

• Atribui apenas as permissões que o agente precisa para as ações da sua ferramenta. Prefiro escopos estreitos (recursos ou grupos de recursos) ao acesso por subscrição.
• Trate a identidade partilhada do projeto como um raio de explosão mais amplo. Se um agente precisar de controlos mais rigorosos ou auditorias separadas, publique-o para que ganhe uma identidade distinta e atribua funções a essa nova identidade.
• Revê e regista o acesso a ferramentas e servidores que não sejam da Microsoft. Se uma chamada de ferramenta sair dos serviços da Microsoft, o tratamento e a retenção dos seus dados dependerão do fornecedor externo.

Limitações

• Apenas algumas ferramentas suportam atualmente autenticação de identidade de agente. Verifique a documentação da ferramenta para autenticação suportada.
• Publicar um agente altera qual a identidade usada nas chamadas de ferramenta (identidade de projeto partilhada versus identidade distinta de agente). Planeie a reatribuição de funções ao publicar.

Questões comuns

Estes problemas causam frequentemente falhas na autenticação de ferramentas ao utilizar identidades de agentes:

• Funções atribuídas à identidade errada: Confirme que concedeu permissões à identidade atual usada pelo agente (identidade partilhada do projeto para agentes não publicados, identidade distinta para agentes publicados).
• Atribuições de funções em falta: Garanta que a identidade do agente tenha a função RBAC exigida no recurso alvo. Para papéis e âmbitos da Foundry, veja Controlo de acesso baseado em papéis pelo Azure na Foundry.
• Destinatário incorreto: Garanta que o destinatário corresponde ao serviço downstream que está a chamar (por exemplo, https://storage.azure.com para Armazenamento do Azure).

Para resolução de problemas específica de ferramentas, consulte a documentação da ferramenta:

• Protocolo de Modelo de Contexto
• Ferramenta Agente-para-Agente

Gerir identidades de agentes

As identidades dos agentes mantêm-se enquanto existir o projeto Foundry ou recurso de aplicação do agente associado. Quando elimina um projeto Foundry, o plano de identidade do agente associado e a identidade de agente partilhada são removidos. Os agentes publicados têm o seu próprio ciclo de vida da identidade ligado ao recurso da aplicação do agente — ao eliminar a aplicação do agente, a sua identidade distinta é removida.

Pode visualizar e gerir todas as identidades dos agentes no seu tenant através do centro de administração Microsoft Entra. Inicia sessão no centro de administração Microsoft Entra e navega por Entra ID>ID do Agente>Todas as identidades dos agentes para veres um inventário de todos os agentes do teu tenant, incluindo agentes da Foundry, Microsoft Copilot Studio agentes, e outros.

Nesta experiência, pode ativar controlos de segurança incorporados, incluindo:

• Acesso Condicional: Aplicar políticas de acesso às identidades dos agentes.
• Proteção de identidade: Monitorizar e proteger as identidades dos agentes contra ameaças.
• Acesso à rede: Controla o acesso baseado em rede para agentes.
• Governação: Gerir expirações, detentores e patrocinadores, relativas às identidades dos agentes.

Para mais informações sobre ID do Agente Microsoft Entra funcionalidades, consulte Microsoft Entra documentação.

Conteúdo relacionado

• Aplicações de agentes na Microsoft Foundry
• Controlo de acesso baseado em funções do Azure no Foundry
• Autenticação do servidor MCP
• Autenticação Agent2Agent (A2A)
• Documentação do ID do Agente Microsoft Entra