Conceitos de identidade do agente no Microsoft Foundry

Uma identidade de agente é um tipo de identidade especializada no Microsoft Entra ID projetada especificamente para agentes de inteligência artificial. Ele fornece uma estrutura padronizada para controlar, autenticar e autorizar agentes de IA em serviços Microsoft. Essa estrutura permite que os agentes acessem recursos com segurança, interajam com os usuários e se comuniquem com outros sistemas.

Microsoft Foundry provisiona e gerencia automaticamente as identidades dos agentes ao longo do ciclo de vida do agente. Essa integração simplifica o gerenciamento 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 de agentes se relacionam com os objetos do Microsoft Entra ID, como o Foundry as utiliza quando um agente chama ferramentas e como aplicar o princípio de privilégio mínimo com o controle de acesso baseado em função (role-based access control - RBAC) do Azure.

Pré-requisitos

• Noções básicas sobre autenticação Microsoft Entra ID e OAuth
• Familiaridade com Azure RBAC (controle de acesso baseado em função)
• Conhecimento básico de agentes de IA e seus requisitos de runtime

Para funções e escopos RBAC específicos do Foundry, consulte Azure controle de acesso baseado em função no Foundry.

Como as identidades do agente funcionam na Foundry

A Foundry usa identidades de agente Microsoft Entra ID para dar suporte a duas necessidades relacionadas:

• Gerenciamento e governança: dê aos administradores uma maneira consistente de inventariar agentes, aplicar políticas e atividade de auditoria.
• Tool authentication: permitir que um agente se autentique em sistemas downstream (por exemplo, Armazenamento do Azure) sem inserir segredos em prompts, código ou cadeias de conexão.

Em um alto nível, a Foundry faz o seguinte:

1. Provisiona um blueprint de identidade de agente e uma ou mais identidades de agente no Microsoft Entra ID.
2. Atribui funções RBAC (ou outros modelos de permissão, 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 de ferramenta.

Troca de tokens de runtime

Quando um agente invoca uma ferramenta, uma troca de token OAuth 2.0 de várias etapas ocorre automaticamente entre o Serviço do Agente, Microsoft Entra ID e o recurso downstream. Os desenvolvedores não gerenciam tokens diretamente – o Serviço de Agente manipula toda a troca.

A troca progride por quatro estágios:

• Blueprint authentication: Agent Service apresenta as credenciais OAuth do blueprint para Microsoft Entra ID. Isso prova que o Serviço de Agente está autorizado a agir em nome do esquema e de suas identidades de agente.

• Emissão de token de identidade de agente: O Microsoft Entra ID valida as credenciais do blueprint e emite um token para a identidade de agente específico. Esse token é distinto dos tokens de identidade gerenciados ou de usuário humano– ele identifica o agente como um ator independente no diretório.

• Solicitação de token com escopo: 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 escopo para o público do serviço seguinte. O público-alvo é o identificador de recurso OAuth para o serviço de destino (por exemplo, https://storage.azure.com para Armazenamento do Azure).

• Chamada de ferramenta autenticada: Agent Service passa o token de acesso com escopo para o servidor MCP ou o ponto de extremidade A2A. O recurso downstream valida o token e verifica as atribuições de função RBAC da identidade do agente antes de conceder ou negar acesso.

A tabela a seguir lista valores comuns de audiência para serviços de Azure globais:

Termos usados neste artigo

Principais conceitos

A estrutura da plataforma ID do Agente introduz identidades formais de agente e modelos de identidade de agente no Microsoft Entra ID para representar agentes de IA. Você pode usar essa estrutura para se comunicar com segurança com agentes de IA. Essa estrutura também permite que esses agentes de IA se comuniquem com segurança com serviços Web, outros agentes de IA e vários sistemas.

Identidade do agente

Uma identidade de agente é uma entidade de serviço especial no Microsoft Entra ID. Refere-se a uma identidade que o "blueprint" da identidade do agente criou e está autorizada a representar.

Benefícios de segurança

As identidades do agente ajudam a resolver desafios de segurança específicos que os agentes de IA representam:

• Distinguir as operações que os agentes de IA realizam das operações que as identidades de força de trabalho, cliente ou carga de trabalho realizam.
• Permitir que os agentes de IA obtenham acesso adequado nos sistemas.
• Impedir que agentes de IA obtenham acesso a sistemas e funções de segurança críticas.
• Dimensione o gerenciamento de identidade para um grande número de agentes de IA que podem ser rapidamente criados e destruídos.

Recursos de autenticação

As identidades do agente dão suporte a dois principais cenários de autenticação:

• Atendimento (acesso delegado ou fluxo em nome de): o agente opera em nome de um usuário humano, usando o fluxo OAuth 2.0 em nome (OBO). O usuário se autentica primeiro no aplicativo e o aplicativo passa o token do usuário para o Serviço do Agente. Em seguida, o Serviço de Agente troca esse token por um que carrega a identidade do agente e as permissões delegadas do usuário. Essa abordagem significa que o agente só pode acessar recursos para os quais o usuário consentiu e está autorizado.
• Não supervisionado (fluxo somente de aplicativo): o agente atua sob sua própria autoridade, utilizando o fluxo de credenciais do cliente OAuth 2.0. O Serviço de Agente autentica o blueprint para Microsoft Entra ID, obtém um token para a identidade do agente e solicita um token de acesso com escopo para o recurso downstream. O acesso do agente é regido inteiramente por suas próprias atribuições de função RBAC, pelas permissões no nível do aplicativo do Microsoft Graph ou por outras políticas de autorização, não havendo envolvimento de nenhum usuário humano.

Projeto de identidade do agente

Um esquema de identidade do agente serve como o modelo reutilizável a partir do qual todas as identidades de agente associadas são criadas. Corresponde a um tipo, tipo ou classe de agentes. Ele atua como o objeto de gerenciamento para todas as instâncias de identidade do agente dessa classe.

Funcionalidades de esquemas

Os esquemas de identidade do agente servem a três finalidades essenciais.

Classificação de tipo: o blueprint estabelece a categoria de agente, como "Agente de Vendas Contoso". Essa classificação permite que os administradores:

• Aplique políticas de Acesso Condicional a todos os agentes desse tipo.
• Desabilite ou revogue permissões para todos os agentes desse tipo.
• Audite e governe agentes em grande escala por meio de controles consistentes baseados em modelos.

Autoridade de criação de identidade: os serviços que criam identidades de agente usam o modelo para autenticar-se. Os blueprints têm credenciais OAuth que os serviços usam para solicitar tokens do Microsoft Entra ID para criar, atualizar ou excluir identidades do agente. Essas credenciais incluem segredos do cliente, certificados ou credenciais federadas, como identidades gerenciadas.

Plataforma de autenticação em tempo de execução: O serviço de hospedagem usa a estrutura durante a autenticação em tempo de execução. O serviço solicita um token de acesso usando as credenciais OAuth do blueprint. Em seguida, ele apresenta esse token ao Microsoft Entra ID para obter um token para uma de suas identidades de agente.

Metadados de plano

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

• O nome do tipo de agente: "Agente de Vendas Contoso".
• O editor ou organização responsável pelo blueprint: "Contoso".
• As funções que o agente pode executar: "gerente de vendas" ou "representante de vendas".
• Microsoft Graph permissões ou escopos delegados: "leia o calendário do usuário conectado".

Credenciais de identidade federadas

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

A opção de credencial federada é a mais relevante para a Foundry. Quando o Foundry provisiona um blueprint de identidade de agente para seu projeto, o blueprint estabelece uma relação de confiança com a identidade gerenciada do projeto. A cadeia de autenticação funciona da seguinte maneira:

• O roteiro de identidade do agente possui uma relação de confiança por credenciais federadas com a identidade gerenciada do projeto.
• Em tempo de execução, o Serviço de Agente usa a identidade gerenciada para autenticar o blueprint junto ao Microsoft Entra ID. Nenhum segredo ou certificado do cliente é necessário.
• Entra ID valida a credencial federada e emite um token para a identidade agente (o principal de serviço).
• Em seguida, o token de identidade do agente é trocado por um token de acesso com escopo direcionado ao público do recurso downstream.

Essa cadeia foi projetada para eliminar segredos armazenados na configuração do blueprint. Azure gerencia a rotação de credenciais por meio da infraestrutura da identidade gerenciada e cada camada – identidade gerenciada, identidade do agente e recurso downstream – tem atribuições de função independentes e com menos privilégios. No entanto, algumas configurações de ferramenta ainda expõem a identidade gerenciada do projeto como uma opção de autenticação.

Integração do Foundry

A Foundry integra-se automaticamente com ID do agente Microsoft Entra criando e gerenciando identidades em todo o ciclo de vida de desenvolvimento do agente. Quando você cria seu primeiro agente em um projeto do Foundry, o sistema provisiona um blueprint de identidade de agente padrão e uma identidade de agente padrão para seu projeto.

Identidade do projeto compartilhado

Todos os agentes não publicados ou em desenvolvimento no mesmo projeto compartilham uma identidade comum. Esse design simplifica o gerenciamento de permissões porque agentes não publicados normalmente exigem os mesmos padrões de acesso e configurações de permissão. A abordagem de identidade compartilhada oferece estes benefícios:

• Administração simplificada: os administradores podem gerenciar centralmente permissões para todos os agentes em desenvolvimento em um projeto.
• Expansão de identidade reduzida: o uso de uma única identidade por projeto impede a criação desnecessária de identidade durante a experimentação inicial.
• Autonomia do desenvolvedor: depois que a identidade compartilhada é configurada, os desenvolvedores podem criar e testar agentes de forma independente sem configurar repetidamente novas permissões.

Para encontrar o blueprint de identidade do agente compartilhado e a identidade do agente, acesse seu projeto do Foundry no Azure portal. No painel Visão geral , selecione Exibição JSON. Escolha a versão mais recente da API para exibir e copiar as identidades.

Identidade de agente distinta

Quando as permissões, a auditabilidade ou os requisitos de ciclo de vida de um agente divergem dos padrões do projeto, você deve atualizar para uma identidade distinta. A publicação de um agente cria automaticamente um blueprint (ou plano) dedicado de identidade de agente e uma identidade de agente. Ambos estão vinculados ao recurso do aplicativo do agente. Essa identidade distinta representa a autoridade do sistema do agente para acessar seus próprios recursos.

Cenários comuns que exigem identidades distintas incluem:

• Agentes prontos para teste de integração.
• Agentes preparados para consumo em produção.
• Agentes que exigem conjuntos de permissões exclusivos.
• Agentes que precisam de trilhas de auditoria independentes.

Para localizar o blueprint de identidade do agente distinto e a identidade do agente, acesse o recurso do aplicativo de agente no portal do Azure. No painel Visão geral , selecione Exibição JSON. Escolha a versão mais recente da API para exibir e copiar as identidades.

Ferramentas de automação e implantação

Ferramentas de implantação como a CLI do Desenvolvedor do Azure (azd) fornecem automação limitada para permissões de identidade do agente:

• Development: azd atribui automaticamente o usuário do Azure AI à identidade compartilhada do agente de projeto para agentes não publicados
• Produção: Agentes publicados recebem identidades distintas que exigem atribuições de função manuais

o azd não configura o Registro de Contêineres, o Application Insights ou as permissões de recurso personalizadas. Para implantações de produção e os requisitos de permissão completos para agentes hospedados, consulte a referência de permissões do agente hospedado.

Autenticação de ferramenta

Os agentes acessam recursos e ferramentas remotos usando identidades de agente para autenticação. O mecanismo de autenticação difere com base no status de publicação do agente:

• Agentes não publicados: autentique usando a identidade do agente do projeto compartilhado.
• Agentes publicados: autentique usando a identidade de agente exclusiva associada ao aplicativo do agente.

Ao publicar um agente, você deve reatribuir permissões RBAC à nova identidade do agente para todos os recursos que o agente precisa acessar. Essa reatribuição garante que o agente publicado mantenha o acesso apropriado enquanto opera sob sua identidade distinta.

Atribuir permissões à identidade do agente

A identidade do agente é um service principal no Microsoft Entra ID. Você atribui funções RBAC a ela da mesma forma que atribui funções a qualquer outro principal de serviço ou identidade gerenciada. Use a agentIdentityId exibição JSON do seu projeto ou do aplicativo agente como o atribuídor.

Por exemplo, para conceder acesso de leitura/gravação a uma identidade de agente em uma conta de armazenamento, atribua a função Colaborador de Dados de Blob de Armazenamento no escopo 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 atribuição:

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

Atribuições de função comuns para ferramentas de agente:

Ferramentas com suporte

Atualmente, as ferramentas que dão suporte à autenticação com uma identidade de agente são:

• Protocolo de Contexto de Modelo (MCP): use a identidade do agente para autenticar-se nos servidores MCP que dão suporte à autenticação de identidade do agente. Para obter detalhes, consulte Protocolo de Contexto de Modelo e autenticação de servidor MCP.
• Agente para Agente (A2A): habilite a comunicação segura entre agentes usando identidades de agente. Para obter detalhes, consulte a ferramenta Agent-to-Agent 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 chave ou passagem de identidade OAuth). Use a documentação da ferramenta para confirmar a autenticação com suporte.

Configurar conexões de ferramenta

Para conectar um servidor MCP ou um ponto de extremidade A2A com a autenticação de identidade do agente, crie uma conexão de projeto que especifique o tipo de autenticação e o público-alvo para o serviço downstream. O tipo de autenticação depende da ferramenta:

Quando o agente invoca a ferramenta, o Serviço de Agente usa a identidade do agente para obter um token de acesso delimitado para o valor de audiência e, em seguida, passa esse token para o endpoint da ferramenta para autenticação.

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

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

Considerações de segurança

As identidades do agente ajudam você a reduzir o risco removendo a necessidade de inserir credenciais de longa duração nas configurações do agente. Use estas práticas para manter o acesso com privilégios mínimos e auditáveis:

• Atribua apenas as permissões que o agente precisa para suas ações de ferramenta. Prefira escopos mais restritos (recurso ou grupo de recursos) em vez de acesso em toda a assinatura.
• Considere a identidade do projeto compartilhado como uma área de impacto mais ampla. Se um agente precisar de controles mais rígidos ou auditoria separada, publique-o para que ele obtenha uma identidade distinta e atribua funções a essa nova identidade.
• Examine e registre o acesso a servidores e ferramentas não Microsoft. Se uma chamada de ferramenta sair dos serviços da Microsoft, o tratamento e a retenção de dados dependerão do provedor externo.

Limitações

• Atualmente, apenas algumas ferramentas dão suporte à autenticação de identidade do agente. Verifique a documentação da ferramenta para autenticação com suporte.
• A publicação de um agente altera qual identidade é usada para chamadas de ferramenta (identidade de projeto compartilhada versus identidade de agente distinta). Planeje a reatribuição de função ao publicar.

Problemas comuns

Esses problemas geralmente causam falhas de autenticação de ferramenta ao usar identidades de agente:

• Funções atribuídas à identidade incorreta: confirme se você concedeu permissões à identidade atual usada pelo agente (identidade de projeto compartilhado para agentes não publicados, identidade distinta para agentes publicados).
• Atribuições de função ausentes: Verifique se a identidade do agente possui a função RBAC necessária no recurso de destino. Para funções e escopos do Foundry, consulte controle de acesso baseado em papéis no Azure Foundry.
• Incorrect audience: verifique se o destinatário corresponde ao serviço posterior que você está chamando (por exemplo, https://storage.azure.com para Armazenamento do Azure).

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

• Protocolo de contexto de modelo
• Ferramenta de Agente para Agente

Gerenciar identidades do agente

As identidades do agente persistem enquanto existir o projeto Foundry associado ou o recurso de aplicação do agente. Quando você exclui um projeto do Foundry, o blueprint de identidade do agente associado e a identidade do agente compartilhado são removidos. Os agentes publicados têm seu próprio ciclo de vida de identidade vinculado ao recurso de aplicativo do agente – excluir o aplicativo do agente remove sua identidade distinta.

Você pode exibir e gerenciar todas as identidades do agente em seu locatário por meio do centro de administração do Microsoft Entra. Entre no centro de administração do Microsoft Entra e navegue até ID do Entra>ID do agente>Todas as identidades de agentes para ver um inventário de todos os agentes em seu locatário, incluindo agentes do Foundry, agentes do Microsoft Copilot Studio e outros.

Nessa experiência, você pode habilitar controles de segurança internos, incluindo:

• Acesso Condicional: aplicar políticas de acesso a identidades de agente.
• Proteção de identidade: monitore e proteja as identidades do agente contra ameaças.
• Acesso à rede: controlar o acesso baseado em rede para agentes.
• Governança: Gerenciar expiração, proprietários e patrocinadores das identidades de agente.

Para obter mais informações sobre os recursos do ID do agente Microsoft Entra, consulte a documentação do Microsoft Entra.

Conteúdo relacionado

• Aplicações Agent no Microsoft Foundry
• Controle de acesso baseado em papéis do Azure no Foundry
• Autenticação do servidor MCP
• Autenticação do Agent2Agent (A2A)
• Documentação ID do agente Microsoft Entra