Microsoft corrige falha de escopo em função do Entra ID que permitia tomada de service principals

Usuários com a função Agent ID Administrator podiam assumir propriedade de service principals fora do escopo de agentes de IA e adicionar credenciais próprias para autenticação no locatário.

Componente	Função interna privilegiada Agent ID Administrator do Microsoft Entra ID e controles de propriedade de service principals em um locatário.
Vetor	Usuário já atribuído à função Agent ID Administrator podia tornar-se proprietário de service principals arbitrários, inclusive não relacionados a agentes de IA, e adicionar credenciais próprias ao principal.
Impacto	Autenticação como o service principal assumido, com operação limitada ao conjunto de permissões já concedido a esse principal; o risco aumenta quando o principal possui funções de diretório privilegiadas ou permissões de aplicativo de alto impacto no Graph.
Prioridade	Auditar uso da função Agent ID Administrator, alterações de proprietário e criação de credenciais em service principals, com atenção especial aos principais privilegiados.
Correção	A Microsoft aplicou correção em 9 de abril de 2026 em todos os ambientes de nuvem; tentativas de atribuir propriedade sobre service principals não associados a agentes por meio dessa função passaram a retornar Forbidden.

Resumo técnico

A vulnerabilidade corrigida no Microsoft Entra ID estava ligada ao escopo efetivo da função interna privilegiada Agent ID Administrator, criada para administrar o ciclo de vida de identidades de agentes de inteligência artificial dentro de um locatário. A finalidade da função era permitir operações administrativas sobre identidades de agentes, incluindo autenticação segura, acesso a recursos necessários e descoberta de outros agentes. O problema estava na aplicação das permissões sobre primitivas compartilhadas de identidade: a função conseguia atuar sobre service principals que não pertenciam ao conjunto de identidades de agentes, abrindo um caminho de abuso para tomada de controle de identidades de aplicação.

O fluxo de abuso dependia de uma pré-condição importante: o operador precisava já possuir a função Agent ID Administrator. A falha não descreve acesso inicial, exploração remota anônima, vazamento de dados ou comprometimento automático do locatário. O impacto técnico confirmado era a possibilidade de o usuário com essa função tornar-se proprietário de service principals arbitrários e, em seguida, adicionar credenciais próprias para autenticar-se como aquele principal. A partir desse ponto, a ação disponível ao invasor ficaria condicionada às permissões existentes do service principal escolhido, o que torna a postura do locatário o fator central de risco.

A gravidade operacional cresce quando existem service principals com privilégios elevados, funções de diretório sensíveis ou permissões de aplicativo de alto impacto no Graph. Nesses casos, assumir a identidade da aplicação pode converter uma função originalmente voltada a agentes de IA em um caminho de escalonamento de privilégio dentro do Entra ID. A correção aplicada em 9 de abril de 2026 passou a bloquear a atribuição de propriedade sobre service principals não relacionados a agentes quando a tentativa parte dessa função, retornando Forbidden para esse tipo de operação.

Fluxo técnico

O mecanismo explorável envolvia a relação entre função administrativa, propriedade de service principal e credenciais de autenticação. No Entra ID, um service principal representa a identidade de uma aplicação ou serviço dentro de um locatário. Quando um usuário consegue tornar-se proprietário desse objeto, ele passa a ter uma posição administrativa relevante sobre aquela identidade. A condição descrita permitia que a função Agent ID Administrator, apesar de ter sido introduzida para identidades de agentes de IA, fosse usada para assumir propriedade de service principals fora desse domínio funcional.

Depois de tornar-se proprietário, o usuário podia adicionar credenciais próprias ao service principal. Essa etapa é crítica porque transforma controle administrativo sobre o objeto em capacidade prática de autenticação. Em vez de apenas visualizar ou ajustar metadados, o operador passa a conseguir se autenticar como o principal assumido. A sessão resultante não ganha permissões mágicas ou externas ao objeto; ela herda o alcance já concedido ao service principal no locatário. Por isso, o mesmo comportamento pode ter impacto moderado em um principal pouco privilegiado ou impacto severo em uma identidade usada para automação administrativa, integrações críticas ou permissões amplas no Graph.

A falha também ilustra um problema recorrente em plataformas de identidade modernas: novos tipos de identidade, como agentes de IA, frequentemente são implementados sobre componentes já existentes. Quando uma função nova recebe permissões sobre uma base compartilhada sem delimitação rigorosa, o limite pretendido pode ficar mais amplo do que o desenho funcional sugere. Nesse caso, a função de administração de agentes não ficou restrita aos objetos de agente e alcançou service principals genéricos. A correção fechou essa diferença de escopo ao impedir que a função fosse usada para atribuir propriedade em principais não associados a agentes.

Superfície afetada

A superfície relevante não é composta por endpoints públicos ou versões de software instaladas localmente, mas por objetos e funções de identidade dentro do Microsoft Entra ID. O ponto de entrada é a atribuição da função Agent ID Administrator a usuários ou contas administrativas. O ativo de maior valor é o conjunto de service principals existentes no locatário, principalmente aqueles que acumulam permissões sensíveis, participam de automações administrativas ou possuem permissões de aplicativo capazes de alterar diretórios, consultar objetos ou executar ações de alto impacto no Graph.

A exposição é mais perigosa em ambientes onde service principals privilegiados não recebem governança equivalente à aplicada a contas humanas. Identidades não humanas costumam permanecer ativas por longos períodos, acumular permissões para integrações e receber credenciais adicionais durante mudanças de automação. Se esses principais também puderem receber novos proprietários ou novas credenciais sem detecção, uma função aparentemente restrita pode virar um caminho indireto para operar com permissões de uma aplicação crítica. A análise deve separar service principals comuns daqueles com papéis de diretório, permissões amplas ou uso em processos administrativos.

• Usuários e grupos com atribuição da função Agent ID Administrator no Microsoft Entra ID.
• Service principals com permissões elevadas, funções privilegiadas de diretório ou permissões de aplicativo de alto impacto no Graph.
• Eventos de alteração de proprietário em service principals, principalmente quando o novo proprietário possui relação com administração de agentes de IA.
• Criação, adição ou rotação inesperada de credenciais em service principals após mudanças de propriedade.

Hunting e telemetria

A investigação deve começar por trilhas de auditoria de identidade, porque o abuso depende de alterações administrativas em objetos do Entra ID. O primeiro eixo é a atribuição e o uso da função Agent ID Administrator: quando ela foi concedida, a quem foi concedida, por qual processo e se houve uso próximo a eventos de propriedade de service principal. O segundo eixo é a linha do tempo de alterações nos próprios principais, procurando adição de proprietários, remoção de proprietários anteriores e criação de credenciais. Uma sequência em que um usuário com a função assume propriedade e logo depois adiciona credencial ao mesmo principal deve ser tratada como evento de alto risco.

A telemetria também precisa considerar a sensibilidade do service principal afetado. Nem toda alteração de credencial indica exploração, mas mudanças em identidades com permissões privilegiadas exigem validação rigorosa. O hunting deve correlacionar criação de credenciais com autenticações subsequentes do principal, uso de permissões do Graph e alterações administrativas realizadas depois da nova credencial. A ausência de IoCs de rede, hashes ou domínios no material técnico torna inadequado buscar indicadores estáticos; o foco defensivo deve ser comportamento de identidade, mudanças de configuração e sequência temporal de eventos.

Como a correção passou a retornar Forbidden para tentativas de atribuir propriedade sobre service principals não associados a agentes usando a função afetada, eventos de falha após 9 de abril de 2026 também podem ser úteis. Eles podem indicar automações legítimas quebradas pela mudança de escopo ou tentativas de repetir o caminho de abuso. Em ambos os casos, vale revisar o motivo de a função estar sendo usada contra objetos fora do domínio de agentes e confirmar se há controles de menor privilégio para a tarefa pretendida.

• Eventos de atribuição, ativação ou uso da função Agent ID Administrator por usuários que não deveriam administrar identidades de agentes.
• Alterações de proprietário em service principals sensíveis, especialmente quando o proprietário adicionado é o mesmo usuário que cria credenciais depois.
• Criação de credenciais em service principals logo após mudança de propriedade ou fora de janelas de manutenção conhecidas.
• Autenticações recentes do service principal afetado seguidas de uso de permissões privilegiadas ou ações administrativas no locatário.
• Erros Forbidden em tentativas de atribuição de propriedade sobre service principals não relacionados a agentes após a correção.

Mitigação

A primeira medida é confirmar que o locatário opera após a correção aplicada pela Microsoft em 9 de abril de 2026, na qual a tentativa de usar Agent ID Administrator para assumir propriedade de service principals não associados a agentes é bloqueada. Como a correção foi distribuída nos ambientes de nuvem, a resposta defensiva local deve concentrar-se na validação da postura, no inventário de atribuições e na busca por alterações feitas antes da mudança. O objetivo é identificar se algum service principal recebeu proprietário ou credencial indevida enquanto o escopo permissivo ainda estava presente.

Em seguida, a organização deve reduzir a exposição de identidades privilegiadas. A função Agent ID Administrator deve ser concedida somente a operadores ou processos que realmente administram identidades de agentes de IA. Service principals com funções privilegiadas, permissões amplas ou participação em automações críticas devem ter proprietários revisados, credenciais inventariadas e uso monitorado. Onde possível, credenciais antigas ou desconhecidas devem ser removidas após validação de dependências, e qualquer credencial adicionada em período suspeito deve disparar investigação e rotação controlada.

A mitigação madura também exige separar governança de contas humanas e identidades não humanas apenas quando houver motivo técnico claro; em termos de risco, ambas podem carregar privilégios equivalentes. Service principals privilegiados precisam de revisão periódica, aprovação para novos proprietários, trilha de auditoria para criação de credenciais e alertas quando funções administrativas novas interagirem com objetos fora de seu escopo esperado. Essa abordagem reduz a chance de uma falha de delimitação de função transformar-se em escalonamento de privilégio silencioso dentro do locatário.

• Revisar todos os usuários e grupos com Agent ID Administrator e remover atribuições desnecessárias.
• Auditar alterações de proprietário em service principals realizadas antes e depois de 9 de abril de 2026.
• Inventariar credenciais adicionadas a service principals privilegiados e rotacionar aquelas que não tiverem justificativa operacional validada.
• Criar alertas para combinação de mudança de proprietário, criação de credencial e autenticação subsequente pelo mesmo service principal.
• Aplicar governança específica para service principals com funções de diretório privilegiadas ou permissões de aplicativo de alto impacto no Graph.