Acesso Condicional para identidades de agentes

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

Para uma visão geral geral do Acesso Condicional, veja O que é o Acesso Condicional?. Para um guia de alto nível sobre a gestão de identidades de agentes em toda a sua organização, consulte Gerir identidades de agentes na sua organização.

Acesso Condicional Orientado por Atributos

À medida que o número de identidades de agentes cresce, adicionar individualmente 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 as identidades dos agentes, permitindo uma aplicação de controlo de acesso consistente e escalável.

Atributos de segurança personalizados no Microsoft Entra ID são uma forma conveniente de organizar as identidades dos agentes em grande escala. Os atributos de segurança personalizados são atributos chave-valor específicos do negócio que possam ser definidos e associados a objetos do Microsoft Entra, incluindo utilizadores, identidades de agentes e aplicações empresariais (principais de serviço). Estes atributos permitem-lhe armazenar informação significativa sobre a identidade de cada agente, como o nível de sensibilidade dos dados que o agente gere.

O diagrama seguinte mostra que as identidades dos agentes com o atributo "Data Sensitivity" definido como "Confidencial" estão bloqueadas; Todos os outros agentes são excluídos e permitidos. Estes valores personalizados de atributos de segurança podem ser usados como filtros durante a avaliação de Acesso Condicional, permitindo a direcionação baseada em atributos. Em vez de manter uma seleção manual de identidades de agentes ou recursos-alvo, pode definir uma regra como: "Se o atributo de Sensibilidade aos Dados for Confidencial", então bloqueie o acesso. A política aplica-se automaticamente a todos os agentes que identificam esses atributos, incluindo os que forem adicionados no futuro.

A tabela seguinte mostra alguns exemplos de como pode categorizar as identidades dos seus agentes:

Atributos de segurança personalizados não são apenas para identidades de agentes. Também pode usá-los para classificar os recursos corporativos a que os agentes acedem, e depois usar ambos nas suas políticas de Acesso Condicional para um sistema de rotulagem consistente em toda a cadeia de acesso. Para mais informações, consulte O que são atributos de segurança personalizados em Microsoft Entra ID.

Esquemas de identidade do agente

Outra forma de aplicar uma política de Acesso Condicional a múltiplas identidades de agentes ao mesmo tempo é direcionando o blueprint de identidade do agente pai deles. 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 todos os agentes derivados dela, incluindo novos adicionados no futuro.

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.

Visão geral dos padrões de acesso a dados

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. No entanto, os tokens de acesso são emitidos apenas depois de cumpridos os controlos de Acesso Condicional necessários. Uma vez emitido o token de acesso, o agente apresenta esse token ao recurso para provar a sua identidade. O recurso valida o token e usa as suas reivindicações para fazer cumprir a autorização.

O diagrama seguinte ilustra os padrões de acesso aos dados.

As políticas de Acesso Condicional são instruções if-then: se um utilizador ou agente quiser aceder a um recurso, algo tem de acontecer primeiro. Por exemplo, se um agente precisar de ler o email de um utilizador em seu nome através do Work IQ MCP, o utilizador deve completar a autenticação multifator antes de o acesso ser concedido. Da mesma forma, se um agente tentar aceder a qualquer recurso que não esteja explicitamente incluído na política, o acesso é bloqueado por defeito.

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

• O "sujeito" identifica a quem o token foi emitido:
  • Quando uma aplicação ou agente solicita um token em nome de um utilizador, o utilizador é o sujeito.
  • Quando uma aplicação ou agente solicita um token para si próprio, a aplicação ou o agente é o sujeito.
• O "público" identifica o recurso alvo para o qual o token se destina:
  • Este recurso deve estar registado no Microsoft Entra ID.
  • Se o sujeito precisar de chamar múltiplos recursos (por exemplo, dois servidores MCP diferentes), normalmente precisa de 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 reavaliadas cada vez que um token de acesso é solicitado, o que normalmente acontece após a expiração do token ou quando um evento crítico é desencadeado, como a Avaliação de Acesso Contínuo.

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

• Em nome de um utilizador
• Apenas aplicação
• Conta do utilizador do agente

Para mais informações sobre os tipos de agentes e os desafios de identidade e gestão de acessos que apresentam, consulte Security for AI.

Fluxo On-Behalf-Of (OBO)

O acesso mais comum é o fluxo em nome do utilizador iniciado (OBO). Neste fluxo, o agente acede a recursos com a identidade e permissões do utilizador para recuperar dados ou realizar ações que o utilizador também pode realizar. Por exemplo, quando um agente lê os seus emails, está a aceder à sua caixa de correio em seu nome.

O diagrama seguinte mostra o fluxo OBO utilizado quando um agente acede a um recurso em nome de um utilizador, incluindo os seguintes componentes:

• Utilizador: Que envia os prompts ao agente
• Aplicação Agente/Cliente: A interface de utilizador onde os utilizadores submetem os seus prompts
• Microsoft Entra ID: O fornecedor de identidade que gere a identidade do agente, a conta de utilizador e onde os recursos estão registados
• Plataforma de IA: O ambiente de execução em que o grande modelo de linguagem (LLM) corre
• Resource: O recurso que o agente recorre para recuperar dados ou realizar uma ação, como Work IQ, SharePoint online ou um servidor MCP personalizado

Os passos seguintes descrevem o fluxo com mais detalhe:

1. O utilizador acede à aplicação agente.

   1. A aplicação agente está registada no Microsoft Entra ID e o seu acesso é regulado pelo Microsoft Entra ID.
   2. Para aceder à aplicação, os utilizadores devem primeiro autenticar-se com a sua conta. Os administradores podem direcionar a aplicação agente na política de Acesso Condicional.

2. Depois de o utilizador iniciar sessão, a aplicação valida o token de acesso do utilizador e concede acesso.

   1. O utilizador envia um prompt para a plataforma de IA (por exemplo, Copilot Studio, Microsoft Foundry ou uma plataforma que não seja da Microsoft).
   2. Para lidar e responder ao pedido, o LLM contacta um recurso corporativo.

3. O recurso corporativo (SharePoint, email, etc.) está protegido pelo Microsoft Entra ID e necessita do seu próprio token de acesso.

   • Não podes passar o token desde o primeiro passo, porque é emitido para um público diferente e com permissões.
   • Em vez disso, use o fluxo OBO para intercambiar tokens com o Microsoft Entra ID e obter um novo token destinado ao recurso.
   • Esta troca de tokens é também avaliada pelas políticas de Acesso Condicional, permitindo aos administradores impor controlos detalhados sobre quais recursos os agentes podem aceder em nome do utilizador.
   • Dependendo da arquitetura do seu agente, a troca de tokens OBO pode acontecer em diferentes camadas: a própria aplicação do agente, uma API middleware personalizada, uma plataforma de IA como o Copilot Studio ou o Azure AI Foundry, ou até 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, devolve a sua resposta e o fluxo é concluído.

Configurar a política de acesso condicional para o fluxo OBO

Para criar uma política de Acesso Condicional para agentes que operam em nome de um utilizador, utilize as seguintes definições:

• Atribuições: Num fluxo OBO, o token de acesso é emitido ao utilizador (o sujeito do token), por isso, atribui-se a política aos utilizadores ou grupos, mas não ao agente ou à conta de utilizador do agente.
• Recursos-alvo: Selecione o que o utilizador ou agente em nome do utilizador está a tentar aceder:
  • Para qualquer recurso-alvo, escolhe direcionar "todos os recursos", "todos os agentes", ou seleciona cada recurso individual que queres direcionar com essa política.
• Atribuição de rede: Os administradores podem criar políticas que visem localizações específicas da rede como sinal, juntamente com outras condições no seu processo de tomada de decisão. Neste contexto, rede refere-se aos locais onde o utilizador inicia sessão, não onde o agente corre.
• Condições: Configure os sinais que o Acesso Condicional avalia, como risco do utilizador, risco de início de sessão ou outros fatores.
• Controlo de acesso: Fazer cumprir se o acesso a um recurso alvo é concedido, negado, limita o acesso ou exige mais passos de verificação por parte do utilizador.

Fluxo de acesso apenas à 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. O diagrama seguinte ilustra como o agente acede aos recursos 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.

O diagrama seguinte mostra o fluxo de autorização de acesso apenas à aplicação.

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

• Agentes autónomos que operam de forma independente:
  • Estes agentes operam 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
  • Estes agentes nem sempre acedem aos 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:
  • Estes agentes ou não autenticam o utilizador ou não suportam a delegação do contexto do utilizador aos 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.

Configurar a política de Acesso Condicional para o fluxo de acesso à aplicação

Para criar uma política de Acesso Condicional para agentes que operam com a sua própria identidade, use as seguintes definições:

• Atribuições: Num fluxo de acesso de agente, o token de acesso é emitido para a identidade do agente (o sujeito do token), portanto, deve-se atribuir a política às identidades dos agentes ou à sua blueprint de identidade de agente.
• Recursos de destino: Selecione os recursos que a identidade do agente precisa de acessar.
• Condições: Configurar se a identidade do agente está em risco. Para mais informações, consulte Proteção de Identificação para agentes.
• Controlo de acesso: Como este agente acede a recursos com a sua própria identidade, não há remediação e a única opção disponível é bloquear o acesso.

Conta de utilizador do agente

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 é, na verdade, um utilizador. Por exemplo, trabalhadores digitais que funcionam como membros da equipa com as suas próprias caixas de correio, acesso ao chat e podem participar em fluxos de trabalho colaborativos como membros 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. As licenças podem ser atribuídas para aceder a recursos do Microsoft 365, como caixas de correio e calendários. A conta pode ser adicionada a unidades administrativas e grupos de segurança tal como uma conta de utilizador humano.

Os agentes que utilizam este fluxo são por vezes chamados de "trabalhador digital" ou "colega de equipa de IA". 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. Hoje em dia, pode direcionar a conta de utilizador de um agente com um único âmbito: "todos os agentes a atuar como utilizadores."

Configurar a política de Acesso Condicional para a conta de utilizador de um agente

Para criar uma política de Acesso Condicional para a conta de utilizador de um agente, use as seguintes definições:

• Atribuições: No fluxo de contas de utilizador de um agente, escolha "Selecionar agentes ativos como utilizadores" e depois selecione "Todos os utilizadores agentes"
• Recursos-alvo: Todos os recursos
• Condições: Configurar se a identidade do agente está em risco. Para mais informações, consulte Proteção de Identificação para agentes
• Controlo de acesso: Como esta política cobre a conta de utilizador do agente, não há solução para os desafios de autenticação, pelo que a única opção disponível é bloquear o acesso

Selecione o recurso alvo

Para selecionar um recurso alvo numa política de Acesso Condicional, o recurso deve ter uma aplicação empresarial (principal de serviço) com o seu conjunto de permissões no seu tenant do Microsoft Entra ID. Esta política aplica-se a todos os tipos de recursos, incluindo SharePoint Online, Exchange Online, servidores MCP do Work IQ, o Azure MCP Server, o Microsoft 365 MCP Server, Microsoft Graph, Open API, servidores MCP, ferramentas não-Microsoft e ferramentas personalizadas constrói.

A aplicação empresarial é necessária independentemente do padrão de acesso aos dados, quer os agentes acedam em nome de um utilizador, acesso apenas por aplicação ou conta de utilizador de um agente. O tipo de permissões concedidas irá variar entre acesso delegado pelo utilizador e acesso à aplicação, mas o requisito do principal do serviço aplica-se em todos os casos.

Alguns serviços da Microsoft exigem uma etapa explícita de provisionamento antes de aparecerem no seu diretório. Por exemplo, ativar a licença necessária ou executar um comando PowerShell. Para mais informações, consulte a documentação relevante do produto para mais detalhes.

Para servidores MCP personalizados, ferramentas baseadas em Open API ou qualquer outro tipo de ferramenta personalizada, regista a ferramenta como uma aplicação no Microsoft Entra ID e expõe o seu conjunto de permissões (delegadas ou funções de aplicação). Para mais informações, veja Como configurar uma aplicação para expor uma API web.

Planejar a implantação de Acesso Condicional

Planear a sua implementação de Acesso Condicional é fundamental para alcançar a estratégia de acesso da sua organização para agentes, utilizadores 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 cobertura em todos os padrões de acesso dos agentes, elabore as suas políticas para cobrir os três padrões de acesso descritos neste artigo: em nome de utilizadores autenticados, agentes que acedem com a própria identidade, e agentes que operam como utilizadores (contas de utilizador dos agentes).

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 agenciais são sempre realizadas pela identidade do agente em questão.
• 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 agentivos são protegidos porque o acesso condicional protege a aquisição de tokens a partir da identidade do agente ou da conta de usuário 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:

• 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 e Atributos de Segurança Personalizados.
• Uma política de Acesso Condicional que direciona identidades de agentes num cenário agente-para-agente usando Atributos de Segurança Personalizados não se aplica à conta de utilizador do agente.
• Uma política de Acesso Condicional direcionada a identidades de agentes num cenário agente-para-agente, utilizando o esquema de identidade do agente, cobre apenas a identidade do agente, e não a conta de utilizador do agente.

Avaliação de políticas utilizando registos de acesso

Os administradores podem usar os registos de início de sessão para investigar porque é que uma política de Acesso Condicional se aplicou ou não. Para entradas específicas de agente, filtre por agentType. Alguns destes eventos aparecem nos inícios de sessão do utilizador (não interativos) enquanto outros aparecem em inícios de sessão do principal de serviço. Para mais informações, consulte os registos de início de sessão e auditoria do ID do Agente Microsoft Entra.

• Identidades de agentes (ator) a aceder a quaisquer recursos → Registos de início de sessão do principal do serviço → agente Tipo: identidade do agente
• Conta de utilizador do agente a aceder a quaisquer recursos → Iniciações de sessão de utilizadores não interativas → tipo de agente: conta de utilizador do agente
• Utilizadores acedendo a agentes → Inícios de sessão de utilizadores

Próximos passos

Aprenda a configurar políticas de Acesso Condicional para identidades de agentes:

• Os agentes operam em nome de um utilizador iniciado
• Os agentes operam com a sua própria identidade
• O agente atua como utilizador