Read this article in English

A pessoa que construiu o agente pediu demissão. O offboarding roda no domingo, desabilita a conta, revoga as sessões — e na segunda-feira o agente que concilia pagamentos para de funcionar, porque rodava com a credencial dela. O cenário oposto é pior: ele continua funcionando. Alguém registrou uma aplicação genérica meses atrás, o segredo ainda é válido, e não há no diretório uma linha sequer dizendo a quem perguntar. Nos dois casos o problema não é o agente. É que ninguém precisou declarar, dentro do diretório, quem responde por ele.

A responsabilidade nomeada

O que é o Microsoft Entra Agent ID?

O Microsoft Entra Agent ID chegou à disponibilidade geral com constructos de identidade próprios para agentes, em vez de reaproveitar os que existem para pessoas e para aplicações. A documentação é direta sobre por que o reaproveitamento falha:

O Microsoft Entra Agent ID existe porque os service principals não têm a infraestrutura de governança de que os agentes de IA precisam. Não há patrocínio obrigatório, não há entradas de auditoria com noção de agente e não há ciclo de vida gerenciado por blueprint.

— Conceitos fundamentais do Microsoft Entra Agent ID

Atribuir uma conta de usuário comum ao agente é o outro atalho conhecido, e a orientação oficial o classifica como não recomendado: políticas de Acesso Condicional escritas para gente não se aplicam corretamente, as detecções do ID Protection ficam degradadas e processos de governança podem remover o acesso do agente por engano.

O problema que resolve

O problema não é autenticar; um segredo de aplicação já fazia isso. É que o agente sobrevive a quem o criou, muda de comportamento sem mudar de código e acumula acesso sem que ninguém precise justificar. Quando alguém pergunta “ainda precisamos dele?”, não há um campo no diretório com a resposta — há uma conversa.

Foi essa lacuna que o desenho fechou. O patrocinador é obrigatório na criação de identidades de agente e de blueprints, e não é um rótulo decorativo: é a pessoa ou o grupo que decide renovação, extensão e remoção. Sem patrocinador, o objeto não nasce.

Como funciona — passo a passo

1. Crie o blueprint. Ele é o molde e a base de autenticação. Configure ali as credenciais e as políticas que devem valer para toda a classe de agentes.
2. Nomeie o patrocinador. É requisito de criação. Em pedidos delegados sem patrocinador explícito, quem chamou vira patrocinador automaticamente; em pedidos apenas de aplicação, o serviço criador precisa informar um.
3. Derive as identidades de agente. Cada instância ganha identidade distinta. O dono do blueprint pode criá-las com permissão delegada — AgentIdentity.Create.All, AgentIdentity.ReadWrite.All ou AgentIdentity.ReadWrite.ManagedBy — sem papel de administrador.
4. Escolha o fluxo de autenticação. Agente interativo age on-behalf-of do usuário com permissões delegadas; agente autônomo usa a própria identidade por client credentials.
5. Decida se cabe conta de usuário. Só quando o agente precisa de sistemas que exigem objeto de usuário — caixa de correio, calendário, canal do Teams.
6. Escreva a política onde o token aponta. O Acesso Condicional é avaliado a cada emissão ou renovação de token, e mira o sujeito daquele token.

Blueprint e identidade: onde a credencial mora

A separação é o ponto técnico mais importante e o menos intuitivo. A identidade de agente não tem credencial. Quem guarda segredo ou certificado é o blueprint, e é ele que adquire token em nome de todas as identidades derivadas. Rotacionar uma credencial deixa de ser uma caça a segredos espalhados por pipelines e passa a ser uma operação em um objeto.

O efeito colateral é bom: uma política aplicada no blueprint alcança todas as identidades derivadas, inclusive as que ainda não existem. Escalar de dez para trezentos agentes não multiplica a superfície de política.

blueprint  ──guarda credencial──►  token
    │
    ├── identidade de agente A ──► recurso 1 (uma audiência)
    ├── identidade de agente B ──► recurso 2 (outra audiência)
    └── identidade de agente C ──► conta de usuário do agente (opcional, 1:1)

Cada token tem exatamente um sujeito e uma audiência. Um agente que fala com três recursos pede três tokens, cada um com suas permissões — e cada pedido passa pelo Acesso Condicional.

No Foundry, a identidade vem pronta

Quem constrói agente no Microsoft Foundry não registra nada à mão. Ao criar o primeiro agente de um projeto, o Foundry provisiona sozinho um blueprint e uma identidade padrão, e a credencial desse blueprint é federada com a identidade gerenciada do projeto — não há segredo guardado para rotacionar depois. É a melhor versão do que a seção anterior descreveu.

O detalhe que morde vem em seguida: enquanto não é publicado, o agente compartilha a identidade do projeto com todos os outros agentes em desenvolvimento. A documentação chama isso de raio de alcance maior, e é literal — no diretório, cinco agentes em construção são um sujeito só. Não dá para aplicar política a um, auditar outro e dizer qual deles tocou o storage.

Publicar resolve e quebra ao mesmo tempo. O agente publicado ganha blueprint e identidade próprios, com agentIdentityId novo, e as atribuições de RBAC não acompanham. O agente que funcionava em desenvolvimento passa a tomar negativa em produção, com um erro que não parece permissão: parece defeito do agente.

Duas restrições fecham o quadro. Autenticação por identidade de agente vale hoje para MCP e A2A; as demais ferramentas seguem em chave ou repasse de OAuth, e isso se confere na documentação de cada uma. E a audiência do token precisa ser a do serviço de destino, não a URL do servidor MCP — audiência errada falha mesmo com RBAC correto.

O inventário é o que costura tudo: no centro de administração do Entra, em Agent ID > All agent identities, aparecem os agentes do Foundry, do Copilot Studio e os demais do locatário, no mesmo lugar onde se aplica Acesso Condicional, proteção de identidade e governança. O Foundry provisiona; o Entra governa.

Configurar na prática

O primeiro passo não tem comando: o agentIdentityId se lê no portal do Azure, em Overview > JSON View — no recurso do projeto enquanto o agente não foi publicado, e no recurso da aplicação de agente depois de publicado. É o mesmo identificador que entra em tudo o que vem a seguir.

Com ele em mãos, a identidade recebe função no recurso de destino como qualquer service principal:

az role assignment create \
  --assignee "<agentIdentityId>" \
  --role "Storage Blob Data Contributor" \
  --scope "/subscriptions/<id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<conta>"

A conexão é onde a audiência entra — e onde o desenho costuma falhar:

PROJECT_ENDPOINT="https://<conta>.services.ai.azure.com/api/projects/<projeto>"
azd ai project set "$PROJECT_ENDPOINT"

azd ai connection create minha-conexao-mcp \
  --kind remote-tool \
  --target https://<endpoint-do-servidor-mcp> \
  --auth-type agentic-identity \
  --audience "<audiencia-entra>"

--auth-type agentic-identity autentica com a identidade do agente; project-managed-identity usa a do projeto, quando todos os agentes devem ter o mesmo nível de acesso. A audiência é o identificador do serviço de destino — https://storage.azure.com para o Storage, por exemplo —, nunca a URL do servidor MCP. Audiência errada devolve token válido que o destino recusa, e o erro não se parece com problema de permissão.

Depois de publicar, o agentIdentityId é outro. Rode a verificação com o identificador novo antes de culpar o código do agente:

az role assignment list --assignee "<agentIdentityId>" --scope "<recurso>" --output table

Lista vazia é a assinatura da armadilha: o agente foi publicado e as funções ficaram na identidade compartilhada do projeto.

Dono, patrocinador e gerente

O modelo administrativo separa administração técnica de responsabilidade de negócio, e essa separação é deliberada: o patrocinador decide sobre o agente sem ganhar poder de configurá-lo.

Dois limites que aparecem cedo em locatário grande: identidade, blueprint e principal aceitam até 100 patrocinadores, com no máximo cinco grupos; a conta de usuário do agente aceita cinco. E nem todo grupo serve — valem grupos dinâmicos (segurança ou Microsoft 365) e grupos de associação atribuída do Microsoft 365; ficam de fora grupos atribuíveis a função e grupos de segurança de associação atribuída.

Uma decisão de produto merece atenção: quem tem papel administrativo de Agent ID não vira patrocinador automaticamente. A justificativa oficial é evitar sobrecarregar administradores com responsabilidade direta por agentes individuais. Responsabilidade não escala por cargo.

Quando o patrocinador sai da empresa

Aqui o título deste artigo encontra a resposta. O Entra ID Governance publicou três tarefas de Lifecycle Workflows para o ciclo de vida do patrocínio:

• Enviar e-mail ao gerente sobre mudanças de patrocínio
• Enviar e-mail aos copatrocinadores sobre mudanças de patrocínio
• Transferir o patrocínio da identidade de agente para o gerente

As três são tarefas de mover e leaver e só aparecem em templates dessas categorias. Não são um alerta no painel: são a mesma máquina que já move e desliga pessoas, agora ciente de que existe um agente do outro lado da relação. O objetivo declarado é evitar agentes órfãos.

patrocinador muda de área ou sai
        │
        ├── notifica gerente e copatrocinadores
        └── transfere patrocínio para o gerente
                 └── agente segue com dono de negócio nomeado

Vale conferir o licenciamento antes de desenhar em cima disso: governança de identidades de agente exige Microsoft 365 E7 (que inclui Agent 365 e o Entra Suite) ou uma licença Microsoft Agent 365 com pelo menos Entra ID P1 ou Microsoft 365 E3.

O sujeito do token decide a política

Esta é a parte que costuma quebrar desenhos aparentemente corretos. A política de Acesso Condicional não mira “o agente”. Mira o sujeito do token que está sendo emitido — e o sujeito muda conforme o padrão de acesso.

Duas consequências práticas. A primeira: se o seu agente atende usuários por OBO e você escreveu a política mirando identidades de agente, ela não está sendo avaliada onde você pensa. A segunda: mirar o blueprint cobre todas as identidades derivadas, presentes e futuras, mas não cobre as contas de usuário dos agentes — elas precisam de política própria.

Existem templates prontos para os cenários mais comuns: agente autônomo, agente em nome do usuário e bloqueio de identidades de agente de alto risco. O Acesso Condicional para agentes pede Entra ID P1 ou P2 mais licença Microsoft Agent 365 por usuário, com a aplicação do licenciamento ainda por vir; controles de rede dependem do Entra Internet Access.

O que já está no ar não precisa recomeçar

Nada disso obriga a reescrever a frota. Há caminhos documentados para migrar registros de aplicação personalizados e agentes do Copilot Studio; fora do ecossistema Microsoft, os padrões para agentes de terceiros cobrem sidecar e federação, com guias para AWS, GCP e n8n. Do lado do código, o Auth SDK em sidecar é um contêiner companheiro que cuida de aquisição e validação de token e das chamadas downstream — a lógica de identidade sai do agente. A exclusão tem limpeza em cascata e soft-delete, o que importa quando alguém desliga o agente errado numa sexta-feira.

Duas notas de direção: as experiências de registro estão convergindo para o Microsoft Agent 365 como lugar único de descoberta, com o Entra seguindo como fundação de identidade; e o assistente de criação de blueprints no portal ainda está em preview — construa por API ou por infraestrutura como código o que precisa ser reproduzível.

Boas práticas para produção

• Um blueprint por classe de agente, não por agente. O blueprint é onde a política pega; um por instância desmonta a vantagem.
• Prefira grupo a pessoa como patrocinador nos agentes críticos. Grupo dinâmico sobrevive a uma saída; nome próprio, não.
• Só crie conta de usuário do agente quando um sistema exigir objeto de usuário. Ela dobra a superfície: caixa de correio, licença e política de Acesso Condicional separada.
• Escreva a política a partir do fluxo, não do organograma. Descubra primeiro quem é o sujeito do token em cada chamada.
• Teste a saída antes que ela aconteça: simule o desligamento do patrocinador e confira se o agente continua com responsável nomeado.
• Trate a rede como camada independente. Identidade forte não substitui isolamento por private endpoint; as duas coisas se somam.

O que precisa estar de pé

Fundação

Todo agente em produção tem identidade própria — nem service principal genérico, nem conta de pessoa. O patrocinador está preenchido e o licenciamento necessário está contratado.

Está de pé quando um inventário de agentes responde “quem responde por este?” sem abrir uma conversa.

Produção com contexto

O sujeito do token é conhecido em cada padrão de acesso, e a política de Acesso Condicional mira onde ele está. As contas de usuário de agente têm política própria.

Está de pé quando desligar o patrocinador dispara transferência de patrocínio, e não uma interrupção de serviço.

Escala e eficiência

Políticas vivem no blueprint e alcançam identidades futuras. Acesso é concedido por pacote de acesso com justificativa, e a exclusão é reversível dentro da janela de soft-delete.

Está de pé quando adicionar o tricentésimo agente não adiciona nenhuma política nova.

A ordem é causal, não cronológica.

Perguntas frequentes (FAQ)

Preciso migrar todos os agentes de uma vez?

Não. Há guias específicos para registros de aplicação personalizados e para agentes do Copilot Studio. Comece pelos que acessam dados sensíveis ou rodam sem supervisão — são os que ficam órfãos com maior custo.

A identidade de agente guarda segredo?

Não. Ela se autentica com tokens emitidos pelo blueprint, que detém a credencial. É por isso que rotação e revogação são operações no blueprint.

Uma política no blueprint cobre tudo?

Cobre todas as identidades de agente derivadas dele, inclusive as futuras. Não cobre as contas de usuário dos agentes, que exigem política própria.

Qualquer grupo pode ser patrocinador?

Não. Valem grupos dinâmicos, de segurança ou Microsoft 365, e grupos de associação atribuída do Microsoft 365. Grupos atribuíveis a função e grupos de segurança de associação atribuída não são aceitos.

Conclusão

Um agente em produção é um trabalhador sem crachá e sem chefe até que alguém decida o contrário. O Entra Agent ID transformou essa decisão em campo obrigatório: o blueprint guarda a credencial, a identidade de agente carrega o contexto, o patrocinador responde pelo propósito e o workflow garante que a resposta continue existindo depois que a pessoa sair. É menos glamouroso que a conversa sobre capacidade dos modelos, e é o que separa um piloto de uma operação auditável. Quando escrevi sobre delegação entre agentes, a conclusão foi que a identidade precisa atravessar cada fronteira. Agora ela tem onde morar.

Referências oficiais

• O que é o Microsoft Entra Agent ID
• Novidades no Microsoft Entra Agent ID
• Conceitos fundamentais
• Relações administrativas: donos, patrocinadores e gerentes
• Identidades de agente, service principals e aplicações
• Planejar a arquitetura de identidade de agente
• Boas práticas do Agent ID
• Padrões de projeto de identidade de agente
• Tarefas de patrocínio em Lifecycle Workflows
• Governança de identidades de agente
• Pacotes de acesso para identidades de agente
• Acesso Condicional para agentes
• Como mirar identidades de agente no Acesso Condicional
• Fluxo OAuth on-behalf-of para agentes
• Fluxo OAuth de agente autônomo
• Identidade de agente no Microsoft Foundry
• Autenticação de servidores MCP no Microsoft Foundry

👉 Se você já tem agentes em produção — especialmente os que rodam sem supervisão humana, comece perguntando quem responde por cada um.
Quer trocar ideia sobre identidade de agente, Acesso Condicional e governança? Me chama no LinkedIn.