Acesso condicional para identidades de agente

O Acesso Condicional é um mecanismo de política inteligente que ajuda as organizações a controlar como usuários e identidades de agente acessam recursos corporativos. Ele reúne sinais em tempo real, como o contexto, o dispositivo, o local e as informações de risco de sessão do usuário para determinar quando permitir, bloquear ou limitar o acesso ou exigir mais etapas de verificação.

Para obter uma visão geral de alto nível do Acesso Condicional, consulte o que é acesso condicional?. Para obter um guia de alto nível para gerenciar identidades de agente em toda a sua organização, consulte Gerenciar identidades de agente em sua organização.

Acesso condicional controlado por atributo

À medida que o número de identidades de agente aumenta, a adição individual de cada identidade de agente em cada política de Acesso Condicional torna-se operacionalmente insustentável. Antes de começar a criar políticas de Acesso Condicional, é importante organizar as identidades do agente, permitindo a imposição de controle de acesso consistente e escalonável.

Atributos de segurança personalizados em Microsoft Entra ID são uma maneira conveniente de organizar identidades de agente em escala. Atributos de segurança personalizados são atributos chave-valor específicos do negócio que você pode definir e atribuir a objetos Microsoft Entra, incluindo usuários, identidades de agente e aplicativos empresariais (entidades de serviço). Esses atributos permitem armazenar informações significativas sobre cada identidade de agente, como o nível de confidencialidade dos dados que o agente manipula.

O diagrama a seguir mostra que as identidades do agente com o atributo "Confidencialidade de Dados" definido como "Confidencial" estão bloqueadas; todos os outros agentes são excluídos e permitidos. Esses valores de atributo de segurança personalizados podem ser usados como filtros durante a avaliação do Acesso Condicional, habilitando o direcionamento baseado em atributo. Em vez de manter uma seleção manual de identidades de agente ou recursos de destino, você pode definir uma regra como: "Se o atributo de Confidencialidade de Dados for Confidencial", bloqueie o acesso. Em seguida, a política se aplica automaticamente a cada identidade de agente com esses atributos, incluindo os adicionados no futuro.

A tabela a seguir mostra alguns exemplos de como você pode categorizar suas identidades de agente:

Atributos de segurança personalizados não são apenas para identidades de agente. Você também pode usá-los para classificar os recursos corporativos que os agentes acessam e, em seguida, usar ambos em suas políticas de Acesso Condicional para um sistema de rotulagem consistente em toda a cadeia de acesso. Para obter mais informações, consulte O que são atributos de segurança personalizados em Microsoft Entra ID.

Planos de identidade do agente

Outra maneira de aplicar uma política de Acesso Condicional a várias identidades de agente ao mesmo tempo é visando o modelo de identidade do agente pai. Cada identidade de agente é derivada de um blueprint de identidade do agente, que define seu modelo de configuração e governança. A aplicação de uma política no nível do blueprint abrange automaticamente todos os agentes derivados dela, incluindo os novos adicionados no futuro.

O diagrama a seguir mostra que somente as identidades do agente associadas ao blueprint "A" recebem acesso; todos os outros agentes são excluídos e bloqueados.

Por exemplo, imagine um projeto em que você tenha vários agentes, cada um com sua própria finalidade. Alguns operam de forma independente, enquanto outros colaboram com outros agentes (A2A) para concluir tarefas. Se todos eles forem criados no mesmo blueprint, uma única política aplicada a esse blueprint imporá controles de acesso consistentes em toda a coleção.

Visão geral dos padrões de acesso a dados

Para acessar um recurso corporativo, como arquivo do SharePoint, servidores MCP ou serviços de Open API, um usuário ou agente primeiro solicita um token de acesso do Microsoft Entra ID. No entanto, os tokens de acesso são emitidos somente depois que os controles de Acesso Condicional necessários são atendidos. Depois que o token de acesso é emitido, o agente apresenta esse token para o recurso para provar sua identidade. O recurso valida o token e usa suas declarações para impor a autorização.

O diagrama a seguir ilustra os padrões de acesso a dados.

As políticas de Acesso Condicional são instruções if-then: se um usuário ou agente quiser acessar um recurso, algo deverá acontecer primeiro. Por exemplo, se um agente precisar ler o email de um usuário em seu nome por meio do MCP do IQ de Trabalho, o usuário deverá concluir a autenticação multifator antes que o acesso seja concedido. Da mesma forma, se um agente tentar acessar qualquer recurso não incluído explicitamente na política, o acesso será bloqueado por padrão.

Microsoft Entra ID emite um token de acesso a um assunto para um público específico (recurso). Cada token tem exatamente um assunto e um público-alvo.

• O "assunto" identifica para quem o token foi emitido:
  • Quando um aplicativo ou agente solicita um token em nome de um usuário, o usuário é o assunto.
  • Quando um aplicativo ou agente solicita um token para si mesmo, o aplicativo ou o agente é o assunto.
• O "público-alvo" identifica o recurso de destino para o qual o token destina-se:
  • Esse recurso deve ser registrado no Microsoft Entra ID.
  • Se o assunto precisar chamar vários recursos (por exemplo, dois servidores MCP diferentes), ele normalmente precisará de um token de acesso separado para cada recurso, cada um com seu próprio público e permissões.

As políticas de Acesso Condicional são reavaliadas sempre que um token de acesso é solicitado, o que normalmente ocorre após a expiração do token ou quando um evento crítico é disparado, como a Avaliação contínua de acesso.

Os agentes podem acessar recursos corporativos protegidos por Microsoft Entra ID usando um dos seguintes padrões:

• Em nome de um usuário
• Somente aplicativo
• Conta do usuário do agente

Para obter mais informações sobre os tipos de agentes e os desafios de gerenciamento de identidade e acesso que eles apresentam, consulte Segurança para IA.

O fluxo On-Behalf-Of (OBO)

O acesso mais comum é o fluxo 'usuário conectado em nome de', conhecido como fluxo OBO. Nesse fluxo, o agente acessa recursos com a identidade do usuário e permissões para recuperar dados ou executar ações que o usuário também pode fazer. Por exemplo, quando um agente lê seus emails, o agente está acessando sua caixa de correio em seu nome.

O diagrama a seguir mostra o fluxo OBO usado quando um agente acessa um recurso em nome de um usuário, incluindo os seguintes componentes:

• Usuário: Quem envia prompts para o agente
• Aplicativo agente/cliente: a interface do usuário em que os usuários enviam seus prompts
• Microsoft Entra ID: o provedor de identidade que gerencia a identidade do agente, a conta de usuário e onde os recursos estão registrados
• Plataforma de IA: o ambiente de runtime no qual o LLM (modelo de linguagem grande) é executado
• Resource: o recurso que o agente chama para recuperar dados ou executar uma ação, como Work IQ, SharePoint online ou um servidor MCP personalizado

As etapas a seguir descrevem o fluxo com mais detalhes:

1. O usuário acessa o aplicativo do agente.

   1. O aplicativo do agente é registrado em Microsoft Entra ID e seu acesso é regido por Microsoft Entra ID.
   2. Para acessar o aplicativo, os usuários primeiro devem se autenticar com sua conta. Os administradores podem direcionar o aplicativo do agente na política de Acesso Condicional.

2. Depois que o usuário entra, o aplicativo valida o token de acesso do usuário e concede acesso.

   1. O usuário envia um prompt para a plataforma de IA (por exemplo, Copilot Studio, Microsoft Foundry ou uma plataforma não Microsoft).
   2. Para processar e responder à solicitação, a LLM chama um recurso corporativo.

3. O recurso corporativo (SharePoint, email etc.) é protegido por Microsoft Entra ID e requer seu próprio token de acesso.

   • Você não pode passar o token da etapa um, pois ele é emitido para um público diferente e com permissões distintas.
   • Em vez disso, use o fluxo OBO para trocar tokens com o Microsoft Entra ID e obter um novo token com escopo para o recurso.
   • Essa troca de tokens também é avaliada pelas políticas de Acesso Condicional, permitindo que os administradores imponham controles granulares sobre os quais os agentes de recursos podem acessar em nome do usuário.
   • Dependendo da arquitetura do agente, a troca de tokens OBO pode ocorrer em camadas diferentes: o próprio aplicativo do agente, uma API de middleware personalizada, uma plataforma de IA como Copilot Studio ou Fábrica de IA do Azure ou até mesmo o servidor MCP.

4. Com o novo token de acesso obtido, o agente invoca o recurso, apresentando o token para autenticação.

   • O recurso valida o token de entrada, retorna sua resposta e o fluxo é concluído.

Configurar a política de acesso condicional para o fluxo OBO

Para criar uma política de Acesso Condicional para agentes que operam em nome de um usuário, use as seguintes configurações:

• Atribuições: em um fluxo OBO, o token de acesso é emitido para o usuário (o sujeito do token), portanto, você atribui a política a usuários ou grupos, mas não ao agente ou à conta de usuário do agente.
• Recursos de destino: selecione o que o usuário ou o agente em nome do usuário está tentando acessar:
  • Para qualquer recurso de destino, escolha direcionar "todos os recursos", "todos os agentes" ou selecione cada recurso individual que você deseja direcionar com essa política.
• Atribuição de rede: os administradores podem criar políticas direcionadas a locais de rede específicos como um sinal, juntamente com outras condições em seu processo de tomada de decisão. Nesse contexto, a rede refere-se aos locais em que o usuário entra, não onde o agente é executado.
• Condições: configurar os sinais que o Acesso Condicional avalia, como risco do usuário, risco de entrada ou outros fatores.
• Controle de acesso: imponha se o acesso a um recurso de destino é concedido, negado, limita o acesso ou exige mais etapas de verificação do usuário.

Fluxo de acesso exclusivo do aplicativo

Os agentes podem acessar recursos sem um usuário conectado. Nesse caso, o agente acessa o recurso com sua própria identidade. O diagrama a seguir ilustra como o agente acessa recursos com sua própria identidade.

Esse fluxo também é conhecido como fluxo de credenciais do cliente ou acesso somente ao aplicativo. Todos os tipos de agentes podem usar esse fluxo.

O diagrama a seguir mostra o fluxo de autorização de acesso somente do aplicativo.

Esse fluxo se aplica nos seguintes cenários comuns:

• Agentes autônomos que operam de forma independente:
  • Esses agentes são executados em segundo plano, respondem a eventos ou são executados conforme agendamento.
  • Por exemplo, um agente que gera um relatório diário e envia o resultado para um grupo de funcionários. Nesse cenário, não há nenhum usuário presente e o agente opera por conta própria.
• Agentes interativos que usam sua própria identidade:
  • Esses agentes nem sempre acessam recursos em nome de um usuário; às vezes eles usam sua própria identidade.
  • Por exemplo, se um agente chamar um serviço de SMS de back-end ao qual os usuários não têm acesso, o fluxo OBO não se aplica, e o agente se autentica diretamente por conta própria.
• Agentes publicados na Web para uso público:
  • Esses agentes não autenticam o usuário ou não dão suporte à delegação do contexto do usuário para recursos corporativos.

Nesses cenários, o agente solicita um token de acesso usando sua própria identidade de agente e credenciais gerenciadas por meio do blueprint de identidade do agente. O token é emitido para a identidade do agente (não para o usuário). Portanto, as políticas de Acesso Condicional têm como escopo a identidade do agente em vez do usuário.

Configurar a política de Acesso Condicional para o fluxo de acesso do aplicativo

Para criar uma política de Acesso Condicional para agentes que operam com sua própria identidade, use as seguintes configurações:

• Atribuições: Em um fluxo de acesso do agente, o token de acesso é emitido para a identidade do agente (o sujeito do token), de forma que você atribua a política às identidades do agente ou ao modelo de identidade do agente.
• Recursos de destino: selecione os recursos que a identidade do agente precisa acessar.
• Condições: configure se a identidade do agente está em risco. Para obter mais informações, consulte ID Protection para agentes.
• Controle de acesso: como esse agente acessa recursos com sua própria identidade, não há correção e a única opção disponível é bloquear o acesso.

Conta de usuário do agente

Às vezes, não é suficiente para um agente executar tarefas em nome de um usuário ou operar com sua própria identidade. Em determinados cenários, um agente é, na verdade, um usuário. Por exemplo, os trabalhadores digitais que funcionam como membros da equipe com suas próprias caixas de correio, acessam o chat e podem participar de fluxos de trabalho colaborativos como membro da equipe.

Nesse modelo, um administrador cria uma conta de usuário no diretório e a vincula à identidade do agente. A partir daí, é como qualquer outra conta de usuário. As licenças podem ser atribuídas para acessar Microsoft 365 recursos, como caixa de correio e calendários. A conta pode ser adicionada a unidades administrativas e grupos de segurança, assim como uma conta de usuário humano.

Agentes que usam esse fluxo às vezes são chamados de "trabalhador digital" ou "companheiro de equipe de IA". Eles também são considerados agentes autônomos, pois não envolvem uma interface do usuário para interação humana.

Nesse modelo, o token de acesso é emitido para a conta de usuário do agente (o assunto do token) e a política é avaliada em relação à conta de usuário do agente, não à identidade do agente. Hoje, você pode direcionar a conta de usuário de um agente com um único escopo: "todos os agentes atuando na função de usuário".

Configurar a política de Acesso Condicional para a conta de usuário de um agente

Para criar uma política de Acesso Condicional para a conta de usuário de um agente, use as seguintes configurações:

• Atribuições: no fluxo de conta de usuário de um agente, escolha "Selecionar agentes ativos como usuários" e selecione "Todos os usuários do agente"
• Recursos de destino: todos os recursos
• Condições: configure se a identidade do agente está em risco. Para obter mais informações, consulte Proteção de ID para agentes
• Controle de acesso: como essa política abrange a conta de usuário de um agente, não há correção para desafios de autenticação, portanto, a única opção disponível é bloquear o acesso

Selecione o recurso de destino

Para selecionar um recurso de destino em uma política de Acesso Condicional, o recurso deve ter um aplicativo empresarial (entidade de serviço) com seu conjunto de permissões em seu locatário Microsoft Entra ID. Essa política se aplica a todos os tipos de recursos, incluindo SharePoint Online, Exchange Online, servidores MCP do Work IQ, o servidor MCP do Azure, o servidor MCP do Microsoft 365, Microsoft Graph, Open API, servidores MCP, ferramentas não-Microsoft e ferramentas personalizadas que você construir.

O aplicativo empresarial é necessário independentemente do padrão de acesso a dados, se os agentes acessam em nome de um usuário, acesso somente aplicativo ou conta de usuário de um agente. O tipo de permissões concedidas será diferente entre o acesso delegado pelo usuário e o acesso por aplicativo, mas o requisito do principal de serviço se aplica em todos os casos.

Alguns serviços Microsoft exigem uma etapa de provisionamento explícita antes de aparecerem em seu diretório. Por exemplo, habilite a licença necessária ou execute um comando do PowerShell. Para obter mais informações, consulte a documentação relevante do produto para obter detalhes.

Para servidores MCP personalizados, ferramentas baseadas em API abertas ou qualquer outro tipo de ferramenta personalizado, registre a ferramenta como um aplicativo em Microsoft Entra ID e exponha seu conjunto de permissões (funções delegadas ou de aplicativo). Para obter mais informações, consulte Como configurar um aplicativo para expor uma API Web.

Planejar a implantação do Acesso Condicional

Planejar sua implantação de Acesso Condicional é fundamental para alcançar a estratégia de acesso da sua organização para agentes, usuários e recursos. As políticas de Acesso Condicional fornecem flexibilidade de configuração significativa. No entanto, essa flexibilidade significa que você precisa planejar cuidadosamente para evitar resultados indesejáveis. Para obter mais informações, veja Planear uma implementação de Acesso Condicional.

Para garantir a cobertura em todos os padrões de acesso do agente, crie suas políticas para cobrir os três padrões de acesso descritos neste artigo: em nome de usuários conectados, acesso de agente usando a própria identidade do agente e agentes que operam como usuários (contas de usuário dos agentes).

Limites e limitações de acesso condicional

As políticas de Acesso Condicional não se aplicam quando:

• Um modelo de identidade do agente adquire um token para que o Microsoft Graph crie uma identidade de agente ou a conta de usuário do agente.
  • Os blueprints dos agentes têm funcionalidades limitadas. Eles não podem agir de forma independente para acessar recursos e estão envolvidos apenas na criação de identidades de agente e contas de usuário de agentes.
  • As tarefas agênticas são sempre executadas pela identidade do agente.
• Uma planta de identidade de agente ou identidade de agente executa uma troca de token intermediário no endpoint do AAD Token Exchange Endpoint: Public (ID do recurso: fb60f99c-7a34-4190-8149-302f77469936).
  • Tokens com escopo para o AAD Token Exchange Endpoint: Public não podem chamar o Microsoft Graph.
  • Os fluxos agentic são protegidos porque o Acesso Condicional protege a aquisição de token da identidade do agente ou da conta de usuário associada ao agente.
• Os padrões de segurança estão habilitados.
• O Acesso Condicional protege apenas os recursos protegidos por Microsoft Entra ID. Por exemplo, se um agente acessar recursos usando uma chave de API, ele ignorará totalmente o pipeline de autenticação e emissão de token de Microsoft Entra ID e as políticas de Acesso Condicional não se aplicarão a eles.

No momento, não há suporte para as seguintes configurações:

• Definindo o escopo de uma política de Acesso Condicional para incluir ou excluir a conta de usuário do agente com base em sua associação de grupo e nos atributos de segurança personalizados.
• Uma política de Acesso Condicional direcionada a identidades de agente em um cenário de agente para agente usando atributos de segurança personalizados não se aplicará à conta de usuário do agente.
• Uma política de Acesso Condicional destinada a identidades de agente em um cenário de agente para agente, utilizando o modelo de identidade do agente, abrange apenas a identidade do agente, não a conta de usuário do mesmo.

Investigando a avaliação da política usando logs de login

Os administradores podem usar os logs de login para investigar por que uma política de Acesso Condicional foi ou não foi aplicada. Para entradas específicas do agente, filtre por agentType. Alguns desses eventos aparecem nas Entradas de usuário (não interativas), enquanto outros aparecem nas Entradas de entidade de serviço. Para obter mais informações, consulte os Logs de entrada e auditoria do ID do agente Microsoft Entra.

• Identidades do agente (ator) acessando quaisquer recursos → logs de entrada do principal do serviço → agentType: identidade do agente
• Conta de usuário do agente acessando qualquer recurso → logins não interativos de usuário → agentType: conta de usuário do agente
• Usuários acessando agentes → Logins de usuário

Próximas Etapas 

Saiba como configurar políticas de Acesso Condicional para identidades de agente:

• Agentes operam em nome de um usuário conectado
• Os agentes operam com sua própria identidade
• O agente atua como usuário