Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
A ID do Microsoft Entra Agent apresenta novas construções de identidade, bem como novas maneiras de pensar sobre padrões de autenticação e autorização existentes. Para entender melhor como essas estruturas se encaixam, é útil examinar os padrões comuns de implantação de agentes de IA e como esses padrões são mapeados para a ID de Agente do Microsoft Entra.
Este artigo descreve padrões comuns de implantação de agentes de IA e como eles se correlacionam com o ID do Agente do Microsoft Entra. O artigo começa com uma revisão dos principais conceitos de identidade, descreve permissões e limites de confiança e, em seguida, percorre padrões comuns de implantação.
Para obter diretrizes de decisão passo a passo sobre quantos blueprints e identidades de agente criar, consulte Planejar a arquitetura de identidade do agente.
Conceitos principais
Os componentes a seguir são a base da ID do Agente do Microsoft Entra. Se você for novo neles, comece com os principais conceitos de chave do ID do agente Microsoft Entra antes de continuar com este artigo.
Constructos de identidade
Os seguintes constructos de identidade são usados em todos os padrões descritos neste artigo:
- Plano de identidade do agente: modelo e base de autenticação para uma ou mais identidades de agente. Ele contém credenciais e políticas que se aplicam a todas as identidades de agente criadas a partir dela.
- Entidade de blueprint de identidade do agente: o objeto do Microsoft Entra criado quando um blueprint é adicionado a um locatário. É o que realmente adquire tokens, cria identidades de agente e aparece em logs de auditoria em nome do blueprint.
- Identidade do agente: a identidade de runtime de um agente de IA específico, com suas próprias permissões em recursos downstream.
- Conta de usuário do agente: uma conta opcional 1:1 emparelhada com uma identidade de agente, necessária somente quando o agente deve acessar sistemas que exigem um objeto de usuário.
Modelos de permissões
Permissões no nível do blueprint e permissões no nível de identidade do agente atendem a diferentes finalidades:
- As permissões do blueprint representam as permissões mínimas compartilhadas entre todas as identidades de agente criadas a partir do modelo. Use permissões herdáveis no blueprint quando quiser que todas as identidades do agente comecem com uma linha de base comum.
- As permissões de identidade do agente representam permissões diferenciadas para um agente específico. Use essas permissões quando agentes diferentes no mesmo sistema precisarem de acesso diferente aos recursos downstream.
Para obter mais informações, consulte Configurar permissões herdáveis para blueprints e Autorização na ID do Microsoft Entra Agent.
Limite de confiança
Um limite de confiança refere-se à superfície de risco compartilhada em que um único comprometimento é assumido para afetar todo o perímetro. Agentes em execução em plataformas separadas com contas de serviço separadas, credenciais e segmentos de rede não compartilham um limite de confiança.
Um limite de confiança é uma decisão de modelagem de ameaças de aplicativo, não uma que a ID do Agente do Microsoft Entra define para você.
Padrões de implantação
Os padrões a seguir são baseados em implantações reais de agentes. Cada um descreve a arquitetura do agente, sua estrutura de identidade e considerações de permissão e governança relevantes.
Agente singleton low-code
Um único agente que auxilia em uma tarefa específica, geralmente criada em uma plataforma de baixo código ou sem código, como o Microsoft Copilot Studio. O agente sempre atua em nome de um usuário conectado (interativo) ou sempre atua como ele mesmo (autônomo).
Estrutura: Um projeto → uma identidade de agente
Embora um blueprint com uma única identidade de agente possa parecer redundante, o blueprint fornece ao agente políticas de acesso condicional consistentes, monitoramento, governança e entradas de auditoria , a mesma infraestrutura necessária para sistemas multi-agente, com configuração mínima.
Permissões: Conceda permissões diretamente na identidade do agente. As permissões herdáveis do blueprint normalmente não são necessárias para casos singleton.
Conta de usuário do agente: Não é necessário, a menos que o agente precise de acesso ao Exchange, ao Teams ou a outro sistema que exija um objeto de usuário.
Agente de domínio (multiagente sequencial)
Vários agentes trabalham juntos em um fluxo de trabalho sequencial e firmemente acoplado para atender a uma meta de domínio comum. Normalmente, os agentes compartilham uma base de código, são executados no mesmo ambiente de runtime (por exemplo, o mesmo namespace ou contêiner do Kubernetes) e têm a mesma postura de segurança. Cada agente tem responsabilidades distintas e acesso diferente a recursos downstream. Esse padrão é mapeado para orquestração sequencial no design de vários agentes.
Estrutura: Um blueprint → várias identidades de agente (uma por função de agente)
Usar um único blueprint é apropriado aqui porque todos os agentes compartilham o mesmo limite de confiança. Cada agente obtém sua própria identidade de agente para que as ações possam ser atribuídas a um agente específico nos logs de auditoria e de login, e cada um possa possuir permissões diferentes em recursos downstream.
Exemplo: um sistema de gerenciamento de produtos de varejo tem três agentes : inventário de loja, comparação de produtos e inventário de fornecedores. Todos os três são executados no mesmo namespace do Kubernetes e são criados pela mesma equipe. Eles usam um blueprint com três identidades de agente, cada uma com permissões delimitadas a seus próprios recursos.
Permissões: Defina permissões de linha de base compartilhadas como herdáveis no blueprint. Atribua permissões específicas de função diretamente a cada identidade do agente.
Conta de usuário do agente: Normalmente, não é necessário para agentes de trabalho de domínio.
Orquestrador simultâneo com trabalhadores de domínio
Um agente orquestrador ativa dinamicamente diferentes trabalhadores de domínio com base na tarefa de entrada. Os trabalhadores de domínio podem ser executados em diferentes plataformas, ser operados por equipes diferentes e cruzar limites de confiança. Esse padrão é mapeado para orquestração simultânea no design de vários agentes.
Estrutura:
- Blueprint A → identidade do agente orquestrador
- Blueprint B → identidades de agente de trabalhador de domínio (uma por função, grupo de limites de confiança cruzada)
- Blueprint C → outro grupo de trabalho de domínio, se operado por uma equipe ou plataforma separada
Como os trabalhadores de domínio cruzam os limites de confiança — runtimes, segredos ou equipes separados — eles exigem planos separados. As credenciais do blueprint têm como escopo o respectivo domínio de confiança, portanto, um comprometimento em um domínio não afeta os agentes pares.
Identidades de agente efêmeros: Uma variante desse padrão usa identidades de agente efêmeros. O orquestrador cria uma identidade de agente temporário em runtime para facilitar uma interação específica (por exemplo, coordenando com um subsistema de manutenção), concede a ele permissões herdadas do blueprint e exclui a identidade quando a sessão termina. Isso limita o raio de explosão à duração da tarefa.
Observação
A criação de identidade do agente efêmero ocorre em runtime, o que introduz latência não determinística. Avalie essa compensação para cenários sensíveis à latência.
Permissões: o orquestrador e cada grupo de trabalhadores do domínio têm seus próprios conjuntos de permissões, abrangendo seus respectivos blueprints e identidades de agente.
Conta de usuário do agente: Normalmente, não é necessário no nível do orquestrador ou do trabalhador de domínio, a menos que um trabalhador de domínio específico precise acessar um recurso que dependa do objeto de usuário.
Agentes por usuário (small-n)
Uma identidade de agente separada é criada para cada usuário ou unidade organizacional. Por exemplo, um agente de analista soc pode ter uma instância por ambiente de nuvem ou um agente de auditoria pode ter uma instância por departamento. O número de identidades de agente é moderado – dezenas a algumas centenas – não um para cada usuário de diretório.
Estrutura: um blueprint → uma identidade de agente por usuário, departamento ou ambiente
Esse padrão é apropriado quando cada instância do agente precisa de permissões diferentes, limites de auditoria diferentes ou um ciclo de vida independente (por exemplo, o agente de um departamento pode ser desabilitado sem afetar outras pessoas).
Permissões: Cada identidade do agente contém permissões com escopo para seu usuário ou unidade organizacional. As permissões herdáveis do blueprint definem uma linha de base mínima e cada identidade do agente recebe permissões adicionais, conforme necessário.
Conta de usuário do agente: Considere emparelhar cada identidade de agente com a conta de usuário de um agente quando cada agente atua como um representante nomeado para seu usuário ou departamento , por exemplo, um agente de vendas dedicado que recebe emails em nome de um território.
Trabalhador digital (agente totalmente autônomo)
Um agente totalmente autônomo atua como um funcionário digital, provisionado com recursos normalmente reservados para funcionários humanos: uma caixa de correio do Exchange, compartilhamento do OneDrive e presença do Teams. Esse é o nível mais alto de autonomia do agente.
Estrutura: Um projeto → uma identidade de agente → uma conta de usuário de um agente
Cada trabalhador digital requer a conta de usuário de seu próprio agente. A relação 1:1 entre a identidade do agente e a conta de usuário do agente é fixa – você não pode compartilhar a conta de usuário de um agente entre várias identidades de agente.
Exemplo: um representante de vendas de IA com uma caixa de correio real, listada na Lista de Endereços Global, que responde a emails e recebe um gerente humano no organograma.
Permissões: Conceda à conta de usuário do agente as permissões específicas do Exchange, do Teams e do OneDrive necessárias. Conceda permissões no nível do aplicativo de identidade do agente para sistemas que não exigem um objeto de usuário. Para obter mais informações, consulte Conceder acesso de agente ao Microsoft 365.
Conta de usuário do agente: Necessário. Crie uma conta de usuário de agente para cada identidade de agente de trabalho digital.
Padrões a serem evitados
Réplicas de expansão não precisam de identidades de agente separadas
A execução de várias instâncias do mesmo código de agente (expansão) não requer identidades de agente separadas. A expansão é uma preocupação de runtime: o blueprint obtém tokens como a identidade do agente, e várias instâncias do agente podem ser executadas simultaneamente com a mesma identidade. A criação de uma identidade de agente separada por réplica adiciona objetos de diretório e sobrecarga de gerenciamento sem nenhuma auditoria, controle de acesso ou benefício de responsabilidade.
O gerenciamento de memória e contexto não exige identidades de agente separadas
A memória do agente normalmente é um armazenamento de dados compartilhado (por exemplo, Cache do Azure para Redis ou Pesquisa de IA do Azure ), em que os dados são filtrados pela ID da sessão no momento da recuperação. O acesso a esse armazenamento de dados é controlado pelas permissões da identidade do agente, não por identidades separadas por sessão. Identidades de agente separadas para isolamento de memória adicionam complexidade sem um benefício de segurança.
Não use identidades de agentes por objeto escalonáveis no diretório
A criação de uma identidade de agente por reunião, por documento ou por objeto efêmero em grande escala não é prática com identidades no nível de diretório atualmente. Para cenários de alta fluxo, use identidades de agente compartilhado e dependa de identificadores de sessão ou contexto na camada do aplicativo para distinguir interações.