Acesso Condicional para agentes

O Acesso Condicional é um mecanismo de política inteligente que ajuda as organizações a controlar como usuários e agentes 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 e do agente para determinar quando permitir, bloquear ou limitar o acesso ou exigir mais etapas de verificação.

Saiba mais sobre o Acesso Condicional para agentes:

• Visão geral de alto nível do Acesso Condicional: O que é acesso condicional?
• Guia para gerenciar identidades de agente em toda a sua organização: gerenciar identidades de agente em sua organização.
• Proteção de fluxos de agente com o Acesso Condicional:
  • Configurar políticas para acesso a agentes autônomos
  • Configurar políticas para acesso ao agente em nome

Como o Acesso Condicional avalia as solicitações de acesso do agente

Para acessar um recurso corporativo, como um arquivo do SharePoint, servidores MCP ou serviços da Open API, um usuário ou agente primeiro solicita um token de acesso do Microsoft Entra ID.

Quando uma política de Acesso Condicional se aplica, Microsoft Entra ID avalia os requisitos de política configurados antes de emitir o token. Se os requisitos forem atendidos, um token de acesso será emitido. Em seguida, o token é apresentado ao recurso de destino, que valida o token e usa suas declarações para tomar decisões de autorização.

O diagrama a seguir ilustra esse processo.

Como assuntos e públicos são usados

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

Assunto: a identidade que recebe o token.

• Em cenários de acesso delegado, o token representa o usuário e, ao mesmo tempo, identifica o aplicativo ou o agente de chamada.
• Em cenários somente de aplicativo, o aplicativo ou agente autônomo é o assunto.
• Nos cenários de conta de usuário do agente, a conta de usuário do agente é o assunto.

Público-alvo: o recurso de destino para o qual o token se destina.

• O recurso deve ser registrado no Microsoft Entra ID.
• Se um assunto precisar acessar vários recursos (por exemplo, vários servidores MCP ou APIs), ele normalmente exigirá um token de acesso separado para cada recurso, cada um com seu próprio público-alvo e permissões.

As políticas de Acesso Condicional são avaliadas com base no assunto que solicita acesso e no público que está sendo acessado.

Como as decisões de Acesso Condicional são tomadas

As políticas de Acesso Condicional operam como instruções if-then:

• Se as condições definidas em uma política forem atendidas, os controles de acesso configurados serão aplicados.
• Se os controles necessários forem atendidos, o acesso será concedido.
• Se os controles necessários não forem atendidos, o acesso será negado.

Por exemplo, uma organização pode exigir autenticação multifator antes que um usuário possa autorizar um agente a acessar seus emails. Da mesma forma, uma organização pode configurar uma política para bloquear o acesso de agentes identificados como de alto risco.

Quando o Acesso Condicional é avaliado

O Acesso Condicional é avaliado sempre que o Microsoft Entra ID emite ou atualiza um token de acesso. Alguns recursos também dão suporte à Avaliação contínua de Acesso, que pode disparar a imposição quase em tempo real para eventos específicos.

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

• Em nome de um usuário (acesso delegado)
• Como um aplicativo (acesso autônomo usando a identidade do agente)
• Como usuário (acesso autônomo usando a conta de usuário do agente)

Esse modelo de acesso fornece uma estrutura consistente para proteger o acesso humano e de agente aos recursos organizacionais.

Padrões de acesso a agentes

Há três padrões de acesso para agentes no Acesso Condicional. O fluxo em nome de um usuário, o fluxo de agentes atuando como uma aplicação (acesso autônomo) e o fluxo de agentes atuando como um usuário.

Fluxo em nome de

O fluxo de acesso mais comum é o fluxo on-behalf-of signed-in (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 restrito ao 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.

Agentes que funcionam como um aplicativo

Os agentes podem acessar recursos sem um usuário conectado. Nesse caso, o agente acessa o recurso 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 de acordo com uma programação.
  • 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 acessar 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 em seu próprio nome.
• 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. Você pode direcionar agentes que atuam como aplicativos no Acesso Condicional usando as seguintes opções:

• Todas as identidades de agente: tem como alvo todas as identidades de agente no seu diretório.
• Selecione identidades de agente: Direcione identidades de agente específicas individualmente.

Agentes atuando como um usuário

À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 tem a conta de usuário de seu próprio agente. 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 uma caixa de correio e um calendário. 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. Você pode direcionar contas de usuário do agente no Acesso Condicional usando as seguintes opções:

• Todos os usuários do agente (versão prévia): direciona todas as contas de usuário do agente em seu diretório.
• Selecionar usuários do agente (versão prévia): direcionar contas de usuário de agente específicas individualmente.

Maneiras de selecionar agentes para aplicar políticas de Acesso Condicional

Além dos padrões de acesso específicos do agente, você também pode selecionar blueprints de identidade do agente para aplicar políticas de Acesso Condicional a uma classe de agentes. Atributos de segurança personalizados também podem ser usados para categorizar e direcionar agentes para acesso condicional.

Planos de identidade do agente

Outra maneira de aplicar uma política de acesso condicional a várias identidades de agente de uma só vez é direcionando-a ao 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 todas as identidades de agente derivadas dela, incluindo as novas adicionadas no futuro. O direcionamento do blueprint de identidade do agente não abrange as contas de usuário dos agentes.

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.

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 suas identidades de agente para habilitar 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 lista 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 aqueles 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.

Considerações sobre o recurso de destino

Para selecionar um recurso de destino em uma política de Acesso Condicional, o recurso deve ter um aplicativo corporativo (entidade de serviço) com seu conjunto de permissões em seu locatário do 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. Para obter mais informações, consulte Direcionamento de recursos com acesso condicional.

O aplicativo empresarial é necessário independentemente do padrão de acesso a dados. 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 do agente são sempre executadas pela identidade do agente.
• Um blueprint de identidade de agente ou identidade de agente realiza uma troca intermediária de tokens no ponto de extremidade 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 de agente são protegidos porque o Acesso Condicional protege a obtenção de token pela identidade do agente ou pela conta de usuário do 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:

• As políticas direcionadas a todos os usuários não incluem contas de usuário do agente.
• Definir o escopo de uma política de Acesso Condicional para incluir ou excluir a conta de usuário do agente com base na participação dele em um grupo
• Uma política de Acesso Condicional direcionada às identidades do agente não se aplicará à conta de usuário do agente.
• Uma política de Acesso Condicional voltada para identidades de agente que usa o modelo de identidade de agente se aplica apenas à identidade do agente, não à conta de usuário do agente.

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 da entidade de serviço → agentType: ID de 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 agentes:

• Bloquear agentes de alto risco
• Configurar a política para acesso a agentes autônomos
• Configurar a política para acesso do agente em nome de outro usuário