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.

O Acesso Condicional para agentes requer Microsoft Entra ID P1 ou P2 e uma licença do Agente Microsoft 365 para cada usuário. A imposição do licenciamento do Agent 365 será em breve. Os controles de rede para agentes requerem Acesso à Internet do Microsoft Entra. Para obter mais informações, consulte O que é ID do agente Microsoft Entra.

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.
• Como direcionar identidades de agentes no Acesso Condicional
• Configurar políticas para acesso a agentes autônomos

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.

Padrões de acesso a agentes

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

Agentes agindo em nome de um usuário

O padrão de acesso mais comum é o fluxo on-behalf-of (OBO). Nesse fluxo, um usuário entra em um aplicativo de agente e o agente acessa recursos downstream usando a identidade do usuário e as permissões delegadas. Por exemplo, quando um agente lê seus emails, ele acessa sua caixa de correio em seu nome. Para obter mais informações sobre como o fluxo OBO funciona para agentes, consulte Fluxos OAuth para agentes: on-behalf-of.

Nesse fluxo, o agente não pode reutilizar o token original do usuário porque ele foi emitido para um público diferente. Em vez disso, o agente usa o fluxo OBO para trocar tokens com o Microsoft Entra ID, obtendo um novo token válido para o recurso de destino. Essa troca de tokens também é avaliada pelo Acesso Condicional, permitindo que os administradores imponham controles granulares sobre os quais os agentes de recursos podem acessar em nome do usuário.

Como o usuário é o assunto nesse fluxo, as políticas de Acesso Condicional são direcionadas a usuários e grupos, não a identidades do agente.

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. Para obter mais informações sobre como os agentes se autenticam com sua própria identidade, consulte os fluxos do Agente OAuth: aplicativos autônomos.

Esse fluxo se aplica nos seguintes cenários comuns:

• Agentes autônomos que operam independentemente são executados em segundo plano, respondem a eventos ou são executados em um 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 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.
• Os agentes publicados na Web para uso público 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. Para obter a configuração de política passo a passo, consulte Acesso Condicional para agentes autônomos.

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 que funciona como um trabalhador digital com sua própria caixa de correio, acesso ao chat e a capacidade de 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.

Os agentes que usam esse fluxo 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. Para obter a configuração de política passo a passo, consulte Acesso Condicional para agentes autônomos. Para obter mais informações sobre o fluxo OAuth do usuário do agente, consulte o fluxo OAuth do usuário do Agente.

Agentes em execução em endpoints gerenciados, como Windows 365 Cloud PCs for Agents, também podem estar sujeitos à conformidade de dispositivo e a controles de rede compatíveis. Use a condição Ambientes de execução do agente (Versão prévia) para restringir essas políticas apenas a sessões baseadas em endpoint. Para obter mais informações, consulte Exigir um dispositivo em conformidade para contas de usuário dos agentes.

Políticas de acesso condicional e modelos de identidade do agente

Além dos padrões de acesso específicos do agente, você também pode selecionar projetos de identidade do agente para aplicar políticas de Acesso Condicional a uma classe de agentes. 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, o gerenciamento individual de cada uma em cada política torna-se insustentável. Os atributos de segurança personalizados permitem categorizar identidades e recursos do agente com rótulos específicos aos negócios e, em seguida, direcionar esses atributos em políticas de Acesso Condicional. As políticas se aplicam automaticamente a cada agente com atributos correspondentes, incluindo os adicionados no futuro.

Para obter um passo a passo completo sobre como criar atributos de segurança personalizados e usá-los em uma política de Acesso Condicional, consulte Acesso Condicional para agentes autônomos.

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 tokens com base na identidade do agente ou na 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.

Próximas Etapas 

• Como direcionar identidades de agentes no Acesso Condicional
• Configurar a política para acesso a agentes autônomos