TL, DR
O Microsoft Plataforma de Identidade do Agente (A pré-visualização dá aos agentes de IA suas próprias identidades em Entra ID (plantas, identidades de agentes, usuários de agentes) para que você possa governá-los e protegê-los como qualquer outra entidade. Para gerenciar esse novo plano de controle, a Microsoft introduziu o Administrador de ID do agente função. Em teoria, seu escopo se restringe a objetos relacionados ao agente.
Descobrimos que as contas com só A função de Administrador de ID do Agente poderia assumir o controle entidades de serviço arbitrárias – incluindo aquelas que não têm nada a ver com as identidades dos agentes – tornando-se proprietárias, adicionando credenciais e autenticando-se como essa entidade. Isso é uma aquisição completa do principal.Em inquilinos onde existem chefes de serviço com altos privilégios, torna-se um escalação de privilégios caminho.
Embora a função de Administrador de ID de Agente ainda não seja amplamente utilizada, a maioria dos locatários possui pelo menos uma entidade de serviço privilegiada. Também observamos que muitos locatários já utilizam identidades de agente, às vezes em grande escala. À medida que a adoção da função de Administrador de ID de Agente aumenta, essa lacuna de escopo pode se tornar um risco significativo para a segurança de identidade.
Divulgamos esse comportamento ao Centro de Resposta de Segurança da Microsoft (MSRC), e ele foi corrigido em todas as nuvensA função de Administrador de ID de Agente não pode mais gerenciar proprietários de entidades de serviço que não sejam agentes.
Se você já está familiarizado com os conceitos descritos acima, pule para a próxima seção. Onde a fronteira se rompe.
A análise a seguir baseia-se nos resultados completos de nossa pesquisa.
O que você precisa saber
Aplicações e princípios de serviço em Entra ID
Registrar um aplicativo na Microsoft Entra ID cria dois objetos relacionados no inquilino residencial, que é o locatário onde o aplicativo foi originalmente registrado: um objeto de aplicação e uma serviço principal.
O Formulário on line O objeto serve como definição global do aplicativo e descreve sua configuração.
O princípio de serviço Representa o aplicativo como uma identidade dentro de um locatário e é o objeto que autentica, recebe funções e permissões e acessa recursos. Se o aplicativo estiver configurado como Multi inquilino, entidades de serviço adicionais são criadas em outros locatários quando o aplicativo é usado neles, todas baseadas no mesmo objeto de aplicativo.
Microsoft Entra ID possui diferentes tipos de princípios de serviço, tais como: serviço de aplicação diretores e identidades gerenciadas. An principal do serviço de aplicação É a instância de um aplicativo em um locatário, criada a partir do objeto do aplicativo.
Neste blog, focamos apenas neste tipo, uma vez que o comportamento aqui descrito se aplica especificamente a entidades de serviço de aplicação.
Microsoft Inserir ID do Agente
Microsoft Inserir ID do Agente permite tratar agentes de IA como identidades de primeira classe em Entra IDIsso significa acesso condicional, governança e gerenciamento do ciclo de vida para agentes de IA em seu tenant. Nos bastidores, ele é construído sobre o Plataforma de identidade do agente da Microsoft, uma estrutura de identidade e autorização para agentes de IA. Ela introduz alguns novos tipos de objetos (modelos, identidades de agentes, usuários de agentes), todos gerenciáveis via Microsoft Graph (atualmente, apenas API beta). A plataforma ainda está em versão prévia, mas as funções já estão disponíveis publicamente para atribuição e uso.
Em resumo, a plataforma introduz:
- PlantasOs modelos que definem e criam identidades de agentes.
- Princípios do projeto: A instância específica do locatário de um modelo quando ele é adicionado a um locatário.
- Identidades dos agentesPrincipais princípios de serviço especiais que os agentes de IA usam para autenticar em APIs e serviços.
- Usuários agentesEsses são objetos opcionais semelhantes a usuários para agentes que precisam de um UPN ou um endereço de e-mail e são usados em fluxos de autenticação em nome de terceiros.
Por que isso importa: As identidades dos agentes são construídas sobre primitivas de diretório familiares: aplicativos, entidades de serviço e usuários. É exatamente nessa base compartilhada que reside nossa descoberta.
Função de Administrador de ID de Agente
A Microsoft adicionou o Administrador de ID do agente função para gerenciar o novo plano de controle de identidade do agente. De acordo com a documentação, é definido para:
Em outras palavras: só coisas de agenteNem todos os principais de serviço são iguais. Essa distinção é importante. Os principais de serviço são as identidades por trás da automação, CI/CD, ferramentas de segurança e integrações privilegiadas. Quem os controla controla grande parte do ambiente.
Mais uma observaçãoOs documentos dizem que essa função é privilegiadoPorém, na interface do Entra (que se baseia nas definições de função de diretório beta), isso não é exibido dessa forma. Isso pode levar os administradores a atribuí-la sem a mesma análise criteriosa que dedicariam a funções privilegiadas.
A Microsoft confirmou a discrepância entre a interface do usuário do Entra e a documentação. em relação a o indicador “privilegiado” será consertado.
Onde a fronteira se rompe
Eis o que observamos: um usuário com a função de Administrador de ID do Agente pode adicionar a si mesmo como proprietário de entidades de serviço além das identidades relacionadas ao agente, incluindo entidades de serviço arbitrárias no locatário. A partir daí, ele pode adicionar credenciais e autenticar-se como esses aplicativos.
Etapa 1: Adicionarproprietário(s) (obtido contra principais de serviço não agentes; você pode adicionar a si mesmo ou outros principais):
Etapa 2: Adicionar credenciais (Só funcionou depois que nos tornamos proprietários):
A linha inferior: A propriedade é um tomada primitiva – Torne-se proprietário, adicione um segredo e autentique-se como essa entidade de serviço.
Embora o papel seja destinado a agente identidades, na prática pode mudar a propriedade em qualquer princípio de serviço.
Por que achamos que isso acontece: Algumas das identidades de agentes são implementadas como entidades de serviço (e tipos relacionados). A função possui ações como:
microsoft.directory/agentIdentities/owners/updatemicrosoft.directory/agentIdentityBlueprintPrincipals/owners/update
Assim, os administradores podem gerenciar os proprietários dos objetos do agente. Se essas verificações não forem estritamente limitadas às entidades de serviço com suporte do agente, a permissão se estenderá ao plano geral da entidade de serviço.
Uma lacuna de escopo clássica Quando um tipo de objeto herda de outro.
Nós fizemos não veja o mesmo para aplicaçõesA adição do próprio usuário como proprietário do recurso Application foi negada. Portanto, o problema parece ser específico da interface de serviço.
Após a correção, as tentativas de atribuir a propriedade de entidades de serviço que não sejam agentes usando a função de Administrador de ID do Agente agora são bloqueadas. A operação resulta no seguinte erro:
Impacto
aquisição do principal serviço
Obter a propriedade de uma entidade de serviço proporciona uma posição privilegiada em uma rota de ataque. Uma vez que um invasor se torna proprietário, ele pode adicionar credenciais, autenticar-se como a entidade de serviço e operar dentro do escopo de suas permissões existentes, como acesso à API, funções de diretório ou integrações.
O impacto depende dos privilégios atribuídos à entidade de serviço alvo. Em ambientes onde as entidades de serviço são amplamente utilizadas ou possuem permissões elevadas, isso pode levar a uma escalada significativa. A postura do locatário também pode influenciar o impacto, por exemplo, em casos de aplicativos com ampla permissão ou configurações permissivas.
Antes da correção, a função de Administrador de ID do Agente permitia atribuir a propriedade de entidades de serviço além das identidades relacionadas ao agente, possibilitando recursos semelhantes a funções como Administrador de Aplicativos, mas sem ser especificamente limitada a casos de uso de agentes.
Quando o alvo é privilegiado
A questão da escalada é simples: if Uma entidade de serviço possui privilégios elevados (funções de diretório, permissões de alto impacto no Graph); ao assumi-la, você obtém esses privilégios. Muitas organizações possuem entidades de serviço desse tipo.
Você pode descobrir quais entidades de serviço são privilegiadas e, em seguida, direcioná-las. Na prática, isso significa dois tipos de verificações:
- Principais servidores com funções privilegiadas no diretórioUse a API do Microsoft Graph (Beta,
isPrivileged(sobre definições de função) para listar quais entidades de serviço detêm funções de diretório de nível administrativo. - Entidades de serviço com permissões de alto impacto no GraphConsultar atribuições de função de aplicativo ao Microsoft Graph para permissões confidenciais (por exemplo,
Directory.ReadWrite.All,RoleManagement.ReadWrite.Directory,Application.ReadWrite.All).
Enumere os principais responsáveis pelo serviço privilegiado
Execute o seguinte após az login. Requer jqUse uma conta que possa ler as atribuições de função e as atribuições de função do aplicativo (por exemplo, Administrador de ID do Agente).
1. Entidades de serviço com funções de diretório privilegiadas
BASE="https://graph.microsoft.com"
roles="$(az rest -m GET --url "${BASE}/beta/roleManagement/directory/roleDefinitions?\$filter=isPrivileged eq true&\$select=id,displayName" -o json)"
u="${BASE}/beta/roleManagement/directory/roleAssignments?\$expand=principal(\$select=id,displayName)&\$top=999"
{
echo -e "SP_NAME\tSP_ID\tROLE"
echo -e "--------\t------\t----"
while :; do
j="$(az rest -m GET --url "$u" -o json 2>/dev/null)" || break
jq -r --argjson roles "$roles" '
($roles.value | map(select(.displayName|test("Reader";"i")|not) | {key:.id, value:.displayName}) | from_entries) as $r
| .value[]
| select(.principal."@odata.type"=="#microsoft.graph.servicePrincipal")
| select($r[.roleDefinitionId] != null)
| [.principal.displayName, (.principal.id // .principalId), $r[.roleDefinitionId]] | @tsv
' <<<"$j"
u="$(jq -r '."@odata.nextLink"//empty' <<<"$j")"
[[ -z "$u" ]] && break
done | sort -t$'\t' -k1,1
} | column -t -s $'\t'
2. Entidades de serviço com permissões de aplicativo do Graph de alto impacto
BASE="https://graph.microsoft.com"
PERM_IDS='["9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8","06b708a9-e830-4db3-a914-8e69da51d44f","1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9","19dbc75e-c2e2-444c-a770-ec69d8559fc7","dd199f4a-f148-40a4-a2ec-f0069cc799ec","50483e42-d915-4231-9639-7fdb7fd190e5","01c0a623-fc9b-48e9-b794-0756f8e8f067","62a82d76-70ea-41e2-9197-370581804d09","cc117bb9-00cf-4eb8-b580-ea2a878fe8f7"]'
PERM_NAMES='{"9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8":"RoleManagement.ReadWrite.Directory","06b708a9-e830-4db3-a914-8e69da51d44f":"AppRoleAssignment.ReadWrite.All","1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9":"Application.ReadWrite.All","19dbc75e-c2e2-444c-a770-ec69d8559fc7":"Directory.ReadWrite.All","dd199f4a-f148-40a4-a2ec-f0069cc799ec":"RoleAssignmentSchedule.ReadWrite.Directory","50483e42-d915-4231-9639-7fdb7fd190e5":"UserAuthenticationMethod.ReadWrite.All","01c0a623-fc9b-48e9-b794-0756f8e8f067":"Policy.ReadWrite.ConditionalAccess","62a82d76-70ea-41e2-9197-370581804d09":"Group.ReadWrite.All","cc117bb9-00cf-4eb8-b580-ea2a878fe8f7":"User-PasswordProfile.ReadWrite.All"}'
GRAPH_SP_ID="00000003-0000-0000-c000-000000000000"
az rest --method GET --url "${BASE}/v1.0/servicePrincipals(appId='${GRAPH_SP_ID}')/appRoleAssignedTo" -o json 2>/dev/null \
| jq -r --argjson ids "$PERM_IDS" --argjson names "$PERM_NAMES" '
["SP_NAME", "SP_ID", "PERMISSIONS"], ["--------", "------", "-------------"],
([.value[] | select(.appRoleId as $rid | $ids | index($rid))] | group_by(.principalId)[] |
[.[0].principalDisplayName, .[0].principalId, ([.[].appRoleId | $names[.]] | join(", "))]) | @tsv
' | column -t -s $'\t'
Observação: Essas técnicas não filtram especificamente as entidades de serviço que não são agentes.
Fluxo de ataque de ponta a ponta
A figura abaixo puxa enumeração (os scripts acima) e assumir o controle em uma única visualização.
Gravação de demonstração
O vídeo mostra o fluxo: encontrar uma entidade de serviço privilegiada (para a demonstração, pesquisamos apenas funções de diretório), assumir o controle dela e, em seguida, fazer login.
Demonstração: Um usuário de teste com Administrador de ID do agente assume um privilégio não-agente O usuário principal do serviço (com a função de Administrador Global atribuída) faz login com as novas credenciais – escalonamento de privilégios.
A demonstração foi simulado com o Gráfico beta API; nós também confirmado o mesmo comportamento do bug em v1.0.
instantâneo do mundo real
Analisamos os ambientes dos clientes: o Administrador de ID do agente A função ainda não é amplamente utilizada, mas a estrutura para o processo de escalonamento já está em uso. Cerca de 99% dos inquilinos Ter pelo menos uma entidade de serviço privilegiada (não necessariamente relacionada a um agente). Um pouco mais da metade utilizam identidades de agentes – e dessas, quase metade possui mais de 100. À medida que mais organizações atribuem a função de gerenciar identidades de agentes, a lacuna de escopo se torna um risco real.
Takeaways
A Microsoft abordou esse problema, mas a conclusão permanece: novos tipos de identidade são frequentemente construídos sobre primitivas existentes, o que pode levar a lacunas na forma como as permissões de função são definidas. Nesse caso, resultou em um acesso mais amplo do que o pretendido. Validar essas suposições é essencial. Além disso, o risco geral é influenciado pela postura do locatário, particularmente em relação a entidades de serviço privilegiadas, onde o abuso de propriedade continua sendo uma via de ataque conhecida e impactante.
Por que isso passou despercebido?
- Alterações de propriedade em entidades de serviço podem parecer atividades normais de administração de aplicativos, a menos que você correlacione quem realizou a ação com o tipo de entidade de serviço de destino.
- Funções que não estejam claramente marcadas como altamente privilegiadas na interface do usuário do Entra podem ser atribuídas com menos rigor.
- Não existe um sinal integrado que indique quando uma função está atuando fora do seu escopo esperado; isso requer correlacionar a atividade da função com o recurso afetado.
Recomendações
- Monitorar o uso de funções sensíveis.: especialmente ações que envolvam a titularidade do serviço principal ou alterações de credenciais.
- Alerta sobre mudanças na propriedade principal do serviçoEsses são alguns dos eventos de maior relevância na governança do aplicativo Entra.
- Trate os funcionários de serviços privilegiados como joias da coroa.Auditar quais entidades de serviço possuem funções de diretório ou permissões de alto impacto no Graph; protegê-las e monitorá-las.
- Auditoria na criação de credenciais para prestadores de serviços.Novos segredos ou certificações sobre princípios de serviços de alto valor devem ser raros e revisados.
Detecções
ObservaçãoEssas detecções foram criadas para o problema descrito, mas como ele já foi corrigido, podem ser usadas como modelos para identificar padrões semelhantes.
Contas atribuídas ao Administrador de ID do Agente
- Via CLI do AzureObter tarefas atuais:
# Role definition ID for Agent ID Administrator
az rest --method GET \
--url "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?\$filter=roleDefinitionId eq 'db506228-d27e-4b7d-95e5-295956d6615f'" \
--query "value[].principalId" -o tsv
- Por meio do Log Analytics (AuditLogs): consultar atividades de atribuição de função para a função de Administrador de ID do Agente (ajustar a tabela e o intervalo de tempo conforme necessário).
AuditLogs
| where OperationName has "Add member to role"
| where tostring(TargetResources) has "db506228-d27e-4b7d-95e5-295956d6615f" //
Agent ID Administrator
| mv-expand TR = TargetResources
| summarize
Role = max(iff(TR.type == "Role", tostring(TR.displayName), "")),
Assignee = max(iff(TR.type != "Role", tostring(TR.displayName), "")),
AssigneeUPN = max(iff(TR.type != "Role", tostring(TR.userPrincipalName),"")),
AssigneeId = max(iff(TR.type != "Role", tostring(TR.id), ""))
by TimeGenerated,
Result,
Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName),
tostring(InitiatedBy.app.displayName))
| order by TimeGenerated desc Atividades (Análise de Logs / Logs de Auditoria)
- Adicionar proprietário ao principal de serviço: eventos bem-sucedidos. Ajuste o intervalo de tempo conforme necessário.
let AgentIdAdminActors = dynamic(["obj-id1","obj-id2"]); // principals assigned
Agent ID Administrator
AuditLogs
| where OperationName == "Add owner to service principal"
| where Result == "success"
| where coalesce(InitiatedBy.user.id, InitiatedBy.app.id) in (AgentIdAdminActors)
| order by TimeGenerated desc - Adicionar credenciais à entidade de serviço: eventos bem-sucedidos.
AuditLogs
| where OperationName == "Add service principal credentials"
| where Result == "success"
| project
TimeGenerated,
OperationName,
Result,
Actor = coalesce(InitiatedBy.user.userPrincipalName,
InitiatedBy.app.displayName),
TargetSP = TargetResources[0].displayName,
TargetSPId = TargetResources[0].id
| order by TimeGenerated desc Cronograma de divulgação
- 24 de fevereiro de 2026 – Vulnerabilidade identificada
- 1º de março de 2026 – Relatório submetido à Microsoft (MSRC)
- 3 de março de 2026 – Caso aberto pela Microsoft
- 26 de março de 2026 – A Microsoft confirmou o comportamento.
- 4 de abril de 2026 – A correção atingiu o estágio de pré-lançamento e o comportamento deixou de ser reproduzível.
- 9 de abril de 2026 – A MSRC confirmou que a correção foi totalmente implementada.
Identidades dos agentes Fazem parte da mudança mais ampla em direção a identidades não humanas, criadas para a era dos agentes de IA. A Plataforma de Identidade de Agentes da Microsoft representa um grande avanço na forma como as organizações podem gerenciá-las e governá-las.
Esta pesquisa destaca um aspecto importante desse modelo: as identidades dos agentes dependem de componentes de identidade existentes, como as entidades de serviço. Quando as permissões de função são aplicadas sobre bases compartilhadas sem um escopo rigoroso, o acesso pode se estender além do que foi originalmente planejado. Nesse caso, essa lacuna levou a um acesso mais amplo, especialmente quando entidades de serviço privilegiadas estavam envolvidas.
A Microsoft já abordou essa questão.Mas isso reforça uma conclusão mais ampla: validar como as funções são definidas e onde as permissões se aplicam é essencial, principalmente ao lidar com componentes de identidade compartilhados.
Para obter orientações práticas sobre como monitorar e proteger seu ambiente, consulte o Recomendações sob a Takeaways seção acima.
