Acesso Condicional para agentes

O Acesso Condicional é um motor de políticas inteligente que ajuda as organizações a controlar como os utilizadores e agentes acedem aos recursos corporativos. Reúne sinais em tempo real, como o contexto do utilizador e do agente, o dispositivo, a localização e a informação de risco da sessão, para determinar quando permitir, bloquear ou limitar o acesso, ou exigir mais passos de verificação.

O Acesso Condicional para agentes requer o Microsoft Entra ID P1 ou P2 e uma licença Microsoft Agent 365 para cada utilizador. A aplicação da licença do Agente 365 está a chegar em breve. Os controlos de rede para agentes requerem o Acesso à Internet do Microsoft Entra. Para 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 é 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
• Configurar políticas para acesso a agentes autónomos

Como o Acesso Condicional avalia pedidos de acesso a agentes

Para aceder a um recurso corporativo, como ficheiros SharePoint, servidores MCP ou serviços Open API, um utilizador ou agente solicita primeiro 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 configurada antes de emitir o token. Se os requisitos forem cumpridos, é emitido um token de acesso. O token é então apresentado ao recurso alvo, que valida o token e usa as suas reivindicações para tomar decisões de autorização.

O diagrama a seguir ilustra esse processo.

Como os temas e o público são usados

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

Assunto: A identidade que recebe o token.

• Em cenários de acesso delegado, o token representa o utilizador ao mesmo tempo que identifica a aplicação ou agente que chama.
• Em cenários apenas de aplicação, a aplicação ou agente autónomo é o sujeito.
• Nos cenários da conta de utilizador do agente, a conta de utilizador do agente é o assunto.

Público: O recurso alvo para o qual o token se destina.

• O recurso deve estar registado no Microsoft Entra ID.
• Se um sujeito precisar de aceder a múltiplos recursos (por exemplo, múltiplos servidores MCP ou APIs), normalmente requer um token de acesso separado para cada recurso, cada um com a sua própria audiência e permissões.

As políticas de Acesso Condicional são avaliadas com base tanto no sujeito que solicita acesso como no público acedido.

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:

Agentes a agir em nome de um utilizador

O modelo de acesso mais comum é o fluxo On-Behalf-Of (OBO). Neste fluxo, o utilizador inicia sessão numa aplicação agente, e o agente acede a recursos posteriores usando 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 é o sujeito neste fluxo, as políticas de Acesso Condicional direcionam-se a utilizadores e grupos, não às identidades dos agentes.

Agentes que atuam como uma aplicação

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 Acesso Condicional para agentes autónomos.

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. Cada identidade de agente é derivada de um blueprint de identidade de agente, que define a sua configuração e modelo de governação. Aplicar uma política ao nível do blueprint cobre automaticamente todas as identidades dos agentes derivadas dela, incluindo quaisquer novas adicionadas no futuro. Aplicar o modelo de identidade do agente não abrange as contas de utilizador dos agentes.

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 guia completo sobre como criar atributos de segurança personalizados e utilizá-los numa política de Acesso Condicional, consulte Acesso Condicional para agentes autónomos.

Limites e limitações do Acesso Condicional

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 direcionadas a todos os utilizadores não incluem as contas de utilizador dos agentes.
• Definição de uma política de Acesso Condicional para incluir ou excluir a conta de utilizador do agente com base na 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.

Próximos passos

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