Acesso Condicional para agentes

O Acesso Condicional para agentes é uma extensão do mecanismo de política de Acesso Condicional que controla como os agentes acessam recursos protegidos por Microsoft Entra ID. Ele reúne sinais em tempo real, como o contexto, o dispositivo, o local e as informações de risco do usuário e do agente, para determinar quando permitir, bloquear ou limitar o acesso ou exigir mais etapas de verificação.

Entender o padrão de acesso do agente ajuda você a identificar a identidade correta. Um agente pode agir em nome de um usuário conectado, usar sua própria identidade de agente ou usar sua própria conta de usuário do agente.

Saiba mais sobre o Acesso Condicional para agentes:

Requisitos e licenciamento

Microsoft Entra ID acesso condicional para agentes requer um dos seguintes planos de licença:

  • Microsoft 365 E7, que inclui o Agente 365 e Suíte do Microsoft Entra.
  • licença do Microsoft Agent 365 combinada com pelo menos o Microsoft Entra P1 ou o Microsoft 365 E3.

Para obter mais informações, consulte Microsoft planos e preços do Agente 365.

Como o Acesso Condicional avalia o acesso ao agente

Para acessar um recurso como um arquivo SharePoint, um servidor MCP ou um serviço de API Aberta, um usuário ou agente solicita um token de acesso de Microsoft Entra ID.

Quando uma política de Acesso Condicional se aplica, Microsoft Entra ID avalia os requisitos de política antes de emitir o token. Se os requisitos forem atendidos, Microsoft Entra ID emitirá o token. O recurso de destino valida o token e usa suas declarações para tomar decisões de autorização.

Diagrama mostrando os padrões de acesso a dados para identidades de agente.

Cada token de acesso tem um assunto e um público-alvo:

  • Assunto: a identidade que recebe o token.
    • No acesso delegado, o token representa o usuário ao mesmo tempo em que identifica o aplicativo ou o agente de chamada.
    • No acesso somente ao aplicativo, a identidade do agente é o assunto.
    • No acesso agente-usuário, a conta de usuário do agente é o sujeito.
  • Público-alvo: o recurso de destino ao qual o token se destina, que deve estar registrado no Entra ID. Se um assunto acessa vários recursos, normalmente precisa de um token separado para cada recurso.

O Acesso Condicional avalia tanto o assunto que solicita acesso quanto o público que está sendo acessado. Ele avalia as políticas quando 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.

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:

Se o agente Padrão de acesso Destino da política Guidance
Acessa recursos downstream para um usuário conectado Em nome de (OBO), também chamado de acesso delegado Usuários e grupos Fluxos OAuth do agente: em nome do usuário
Acessa recursos com sua própria identidade de agente e sem nenhum usuário conectado Somente aplicativo, também conhecido como credenciais do cliente ou acesso somente ao aplicativo Identidade do agente ou modelo de identidade do agente Proteger agentes autônomos com acesso condicional
Acessa recursos por meio de sua própria conta de usuário Acesso de agente-usuário Conta de usuário do agente Proteger agentes que atuam como usuários com acesso condicional

Um agente pode usar mais de um padrão de acesso. Crie políticas separadas para cada sujeito de token usado pelo agente. Uma política direcionada a uma identidade de agente não se aplica à conta de usuário do agente e uma política direcionada à conta de usuário do agente não se aplica à identidade do agente.

Agentes que atuam em nome de um usuário

O padrão de acesso mais comum é o fluxo on-behalf-of (OBO). No fluxo OBO, um usuário faz login em um aplicativo agente. O agente acessa recursos downstream com a identidade do usuário e 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.

Observação

O fluxo On-Behalf-OF também é conhecido como acesso delegado. "Em nome de" descreve o fluxo de autenticação, não o tipo de agente. Esses agentes interativos envolvem uma interface do usuário para interação humana. Qualquer agente pode usar esse fluxo quando um usuário conectado estiver presente e o agente precisar acessar recursos com a identidade e as permissões desse usuário.

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 atuam como aplicativos

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 Proteger agentes autônomos com acesso condicional.

Agentes que atuam como usuários

À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. Um modelo de identidade de agente define o modelo de configuração e governança para identidades de agente criadas com base nele. Uma política que tem como alvo um blueprint se aplica a todas as identidades de agente criadas a partir desse blueprint, incluindo identidades de agente criadas posteriormente.

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.

Diagrama mostrando uma política de Acesso Condicional aplicada às identidades do agente de um blueprint.

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.

Diagrama mostrando o fluxo de Acesso Condicional para identidades de agente.

Para obter um exemplo de política, consulte Permitir agentes aprovados usando atributos de segurança personalizados.

Limites e limitações

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.

Conteúdo relacionado

  • Last updated on