Acesso Condicional para agentes

O Acesso Condicional para agentes é uma extensão do motor de políticas de Acesso Condicional que controla como os agentes acedem a recursos protegidos pelo Microsoft Entra ID. Reúne sinais em tempo real, como o contexto do utilizador e do agente, dispositivo, localização e informações de risco, para determinar quando permitir, bloquear ou limitar o acesso, ou exigir mais passos de verificação.

Compreender o padrão de acesso do agente ajuda-o a identificar a identidade correta. Um agente pode agir em nome de um utilizador com sessão iniciada, usar a sua própria identidade de agente ou usar a sua própria conta de utilizador do agente.

Saiba mais sobre o Acesso Condicional para agentes:

• Visão geral de alto nível do Acesso Condicional: O que é o Acesso Condicional?
• Guia para gerir identidades de agentes em toda a sua organização: Gere as identidades de agentes na sua organização.
• Como segmentar identidades de agentes no Acesso Condicional
• Agentes autónomos seguros com Acesso Condicional
• Proteja os utilizadores do agente com o Acesso Condicional do Microsoft Entra

Requisitos e licenciamento

O Acesso Condicional do Microsoft Entra ID para agentes requer um dos seguintes planos de licença:

• Microsoft 365 E7, que inclui o Agente 365 e a Microsoft Entra Suite.
• Licença Microsoft Agent 365 associada a pelo menos uma licença Microsoft Entra P1 ou Microsoft 365 E3.

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

Como o Acesso Condicional avalia o acesso ao agente

Para aceder a um recurso como um ficheiro SharePoint, servidor MCP ou serviço Open API, um utilizador ou agente solicita um token de acesso ao Microsoft Entra ID.

Quando se aplica uma política de Acesso Condicional, o Microsoft Entra ID avalia os requisitos da política antes de emitir o token. Se os requisitos forem cumpridos, o Microsoft Entra ID emite o token. O recurso alvo valida o token e usa as suas reivindicações para tomar decisões de autorização.

Cada token de acesso tem um sujeito e um público:

• Sujeito: A identidade que recebe o token.
  • No acesso delegado, o token representa o utilizador ao mesmo tempo que identifica a aplicação ou agente que chama.
  • No acesso apenas por aplicação, a identidade do agente é o sujeito.
  • No acesso entre agente e utilizador, a conta de utilizador do agente é o sujeito.
• Público: O recurso alvo para o qual o token se destina, que deve estar registado no Entra ID. Se um sujeito acede a múltiplos recursos, normalmente necessita de um token separado para cada recurso.

O Acesso Condicional avalia tanto a entidade que solicita acesso como o recurso ao qual se pretende aceder. Avalia políticas quando o Microsoft Entra ID emite ou atualiza um token de acesso. Alguns recursos também suportam a Avaliação Contínua de Acesso, que pode desencadear a aplicação forçada em tempo quase real em resposta a eventos específicos.

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

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

• Se as condições definidas numa política forem cumpridas, os controlos de acesso configurados são aplicados.
• Se os controlos necessários forem cumpridos, o acesso é concedido.
• Se os controlos exigidos não forem cumpridos, o acesso é negado.

Por exemplo, uma organização pode exigir autenticação multifator antes de um utilizador autorizar um agente a aceder ao seu email. De forma semelhante, 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 suportam a Avaliação Contínua de Acesso, que pode desencadear a aplicação forçada em tempo quase real em resposta a eventos específicos.

Padrões de acesso a agentes

Os agentes podem aceder a recursos protegidos pela Microsoft Entra usando um dos seguintes padrões:

Um agente pode usar mais do que um padrão de acesso. Crie políticas separadas para cada objeto de token que o agente utiliza. Uma política que visa a identidade de um agente não se aplica à conta de utilizador do agente, e uma política que visa a conta de utilizador do agente não se aplica à identidade do agente.

Agentes que atuam em nome de um utilizador

O modelo de acesso mais comum é o fluxo On-Behalf-Of (OBO). No fluxo OBO, um utilizador inicia sessão numa aplicação agente. O agente acede a recursos posteriores com a identidade do utilizador e permissões delegadas. Por exemplo, quando um agente lê os seus emails, acede à sua caixa de correio em seu nome. Para mais informações sobre como funciona o fluxo OBO para agentes, consulte Fluxos OAuth para agentes: On-behalf-of.

Neste fluxo, o agente não pode reutilizar o token original do utilizador porque foi emitido para um público diferente. Em vez disso, o agente utiliza o fluxo OBO para trocar tokens com o Microsoft Entra ID, obtendo um novo token com âmbito definido para o recurso de destino. Esta troca de tokens é também avaliada pelo Acesso Condicional, permitindo aos administradores impor controlos granulares sobre quais recursos os agentes podem aceder em nome do utilizador.

Como o utilizador iniciado é o sujeito do token neste fluxo, o Acesso Condicional avalia as políticas atribuídas a esse utilizador, quer o utilizador seja direcionado diretamente, através de um grupo ou através de outro mecanismo suportado de segmentação de utilizadores. Selecionar uma identidade de agente como sujeito da política não cobre pedidos do agente feitos em nome do utilizador.

Agentes que atuam como aplicações

Os agentes podem aceder a recursos sem um utilizador com sessão iniciada. Neste caso, o agente acede ao recurso com a sua própria identidade. Este fluxo é também conhecido como fluxo de credenciais do cliente, ou acesso apenas a aplicações. Todos os tipos de agentes podem usar este fluxo. Para mais informações sobre como os agentes se autenticam com a sua própria identidade, consulte Fluxos OAuth do agente: aplicações autónomas.

Este fluxo aplica-se nos seguintes cenários comuns:

• Agentes autónomos que operam de forma independente funcionam em segundo plano, respondem a eventos ou seguem um calendário.
  • Por exemplo, um agente que gera um relatório diário e envia o resultado a um grupo de colaboradores.
  • Neste cenário, não há utilizador presente e o agente opera sozinho.
• Agentes interativos que usam a sua própria identidade nem sempre acedem a recursos em nome do utilizador; por vezes usam a sua própria identidade.
  • Por exemplo, se um agente chama um serviço SMS backend ao qual os utilizadores não têm acesso, o fluxo OBO não se aplica, e o agente autentica-se diretamente como ele próprio.
• Agentes publicados na web para uso público não autenticam o utilizador nem apoiam a delegação do contexto do utilizador a recursos corporativos.

Nestes cenários, o agente solicita um token de acesso usando a sua própria identidade de agente e credenciais, geridas através do modelo de identidade do agente. O token é emitido para a identidade do agente (não para o utilizador). Portanto, as políticas de Acesso Condicional são aplicadas à identidade do agente em vez de ao utilizador. Para a configuração passo a passo da política, veja Agentes autónomos seguros com Acesso Condicional.

Agentes que atuam como utilizadores

Por vezes, não basta um agente realizar tarefas em nome de um utilizador ou operar com a sua própria identidade. Em certos cenários, um agente tem a sua própria conta de utilizador que funciona como um trabalhador digital, com a sua própria caixa de correio, acesso ao chat e a possibilidade de participar em fluxos de trabalho colaborativos como membro da equipa.

Neste modelo, um administrador cria uma conta de utilizador no diretório e liga-a à identidade do agente. A partir daí, é como qualquer outra conta de utilizador. Licenças podem ser atribuídas para aceder a recursos do Microsoft 365, como uma caixa de correio e calendário. A conta pode ser adicionada a unidades administrativas e grupos de segurança tal como uma conta de utilizador humano.

Agentes que utilizam este fluxo também são considerados agentes autónomos, pois não envolvem uma interface de utilizador para interação humana. Neste modelo, o token de acesso é emitido para a conta de utilizador do agente (o sujeito do token), e a política é avaliada com base na conta de utilizador do agente, não na identidade do agente. Para a configuração passo a passo da política, veja Acesso Condicional para agentes autónomos. Para mais informações sobre o fluxo OAuth do utilizador agente, consulte fluxo OAuth do utilizador agente.

Agentes em execução em endpoints geridos, como Windows 365 Cloud PCs para Agentes, também podem estar sujeitos à conformidade do dispositivo e a controlos de rede em conformidade. Use a condição de ambientes de execução do Agente (Preview) para definir estas políticas apenas para sessões baseadas em endpoints. Para mais informações, consulte Exigir um dispositivo compatível para contas de utilizador dos agentes.

Políticas de Acesso Condicional e modelos de identidade do agente

Para além dos padrões de acesso específicos dos agentes, também pode selecionar modelos de identidade de agente para aplicar políticas de Acesso Condicional a uma categoria de agentes. Um modelo de identidade de agente define o modelo de configuração e de governação das identidades de agente criadas a partir dele. Uma política que tem como alvo um modelo aplica-se a todas as identidades de agente criadas a partir desse modelo, incluindo as que forem criadas posteriormente.

O diagrama seguinte mostra que apenas as identidades dos agentes associadas ao projeto "A" têm acesso concedido; Todos os outros agentes são excluídos e bloqueados.

Por exemplo, imagine um projeto onde tem vários agentes, cada um com o seu próprio propósito. Alguns operam de forma independente, enquanto outros colaboram com outros agentes (A2A) para completar tarefas. Se todos forem criados sob o mesmo esquema, uma única política aplicada a esse esquema impõe controlos de acesso consistentes em toda a coleção inteira.

Acesso Condicional Orientado por Atributos

À medida que o número de identidades de agentes cresce, gerir individualmente cada uma em cada apólice torna-se insustentável. Atributos de segurança personalizados permitem-lhe categorizar as identidades e recursos dos agentes com rótulos específicos do negócio, e depois direcionar esses atributos em políticas de Acesso Condicional. As políticas aplicam-se automaticamente a todos os agentes com atributos correspondentes, incluindo os adicionados no futuro.

Para um exemplo de política, veja 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 esquema de identidade de agente adquire um token para o Microsoft Graph a fim de criar uma identidade do agente ou a conta de utilizador do agente.
  • Os blueprints dos agentes têm funcionalidades limitadas. Não conseguem agir de forma independente para aceder a recursos e só estão envolvidos na criação de identidades de agentes e contas de utilizador dos agentes.
  • As tarefas do agente são sempre executadas pela identidade do agente.
• Um blueprint de identidade de agente ou uma identidade de agente realiza uma troca intermédia de token no "endpoint" AAD Token Exchange Endpoint: Public (ID de Recurso: fb60f99c-7a34-4190-8149-302f77469936).
  • Os tokens com escopo no AAD Token Exchange Endpoint: Public não conseguem chamar o Microsoft Graph.
  • Os fluxos de agentes são protegidos porque o Acesso Condicional protege a aquisição de tokens a partir da identidade do agente ou da conta de utilizador do agente.
• Os valores de segurança padrão estão ativados.
• O Acesso Condicional protege apenas os recursos protegidos pelo Microsoft Entra ID. Por exemplo, se um agente aceder a recursos usando uma chave API, ignora completamente o pipeline de autenticação e emissão de tokens do Microsoft Entra ID e as políticas de Acesso Condicional não se aplicam a eles.

As seguintes configurações não são atualmente suportadas:

• As políticas definidas através da atribuição "Utilizadores" não se aplicam às contas de utilizador dos agentes. Esta fronteira aplica-se quer a política tenha como alvo todos os utilizadores, utilizadores selecionados, grupos, funções de diretório ou utilizadores externos. Para proteger as contas dos utilizadores agentes, crie uma política que vise os "Agent Users."
• Definir uma política de Acesso Condicional para incluir ou excluir a conta de utilizador do agente com base na sua pertença ao grupo.
• Uma política de Acesso Condicional dirigida a identidades de agente não se aplica à conta de utilizador associada ao agente.
• Uma política de Acesso Condicional que direciona as identidades dos agentes usando o plano de identidade do agente cobre apenas a identidade do agente, não a conta de utilizador do agente.

Em vez disso, para restringir as políticas aos utilizadores agente, em Atribuições>Utilizadores, agentes ou identidades de carga de trabalho, selecione Agentes e depois aponte todos os utilizadores agente ou utilizadores agente específicos.

Conteúdo relacionado

• Identidades dos agentes-alvo nas políticas de Acesso Condicional
• Agentes autónomos seguros com Acesso Condicional
• Agentes seguros que atuam como utilizadores com Acesso Condicional