Acceso condicional para agentes

El acceso condicional es un motor de directivas inteligente que ayuda a las organizaciones a controlar cómo los usuarios y los agentes acceden a los recursos corporativos. Reúne señales en tiempo real, como el contexto del usuario y el agente, la información de riesgo de dispositivo, ubicación y sesión para determinar cuándo permitir, bloquear o limitar el acceso, o requerir más pasos de comprobación.

El acceso condicional para agentes requiere Microsoft Entra ID P1 o P2 y una licencia del Agente 365 de Microsoft para cada usuario. La aplicación de licencias de Agent 365 llegará pronto. Los controles de red para agentes requieren Acceso a Internet de Microsoft Entra. Para obtener más información, vea ¿Qué es Agente de Microsoft Entra ID.

Obtenga información sobre el acceso condicional para agentes:

• Información general de alto nivel del acceso condicional: ¿Qué es el acceso condicional?
• Guía para administrar identidades de agente en toda la organización: administración de identidades de agente en su organización.
• Cómo seleccionar como destino las identidades de agente en Acceso condicional
• Configuración de directivas para el acceso de agentes autónomos

Cómo evalúa el acceso condicional las solicitudes de acceso del agente

Para acceder a un recurso corporativo, como SharePoint archivo, servidores MCP o servicios de Open API, un usuario o agente solicita primero un token de acceso desde Microsoft Entra ID.

Cuando se aplica una directiva de acceso condicional, Microsoft Entra ID evalúa los requisitos de directiva configurados antes de emitir el token. Si se cumplen los requisitos, se emite un token de acceso. A continuación, el token se presenta al recurso de destino, que valida el token y usa sus declaraciones para tomar decisiones de autorización.

En el diagrama siguiente se muestra este proceso.

Cómo se usan los temas y audiencias

Microsoft Entra ID emite un token de acceso a un sujeto para un público específico (recurso). Cada token de acceso tiene exactamente un asunto y una audiencia.

Asunto: la identidad que recibe el token.

• En escenarios de acceso delegado, el token representa al usuario al mismo tiempo que identifica la aplicación o el agente que realiza la llamada.
• En escenarios de solo aplicación, la aplicación o el agente autónomo es el sujeto.
• En los escenarios de cuentas de usuario del agente, la cuenta de usuario del agente es el sujeto.

Audiencia: el recurso de destino para el que está pensado el token.

• El recurso debe registrarse en Microsoft Entra ID.
• Si un sujeto necesita acceder a varios recursos (por ejemplo, varios servidores o API de MCP), normalmente requiere un token de acceso independiente para cada recurso, cada uno con su propia audiencia y permisos.

Las directivas de acceso condicional se evalúan en función del sujeto que solicita acceso y de la audiencia a la que se accede.

Cómo se toman las decisiones de acceso condicional

Las directivas de acceso condicional funcionan como instrucciones if-then:

• Si se cumplen las condiciones definidas en una directiva, se aplican los controles de acceso configurados.
• Si se cumplen los controles necesarios, se concede acceso.
• Si no se cumplen los controles necesarios, se deniega el acceso.

Por ejemplo, una organización puede requerir autenticación multifactor para que un usuario pueda autorizar a un agente a acceder a su correo electrónico. De forma similar, una organización puede configurar una directiva para bloquear el acceso de los agentes identificados como de alto riesgo.

Cuando se evalúa el acceso condicional

El Acceso condicional se evalúa siempre que Microsoft Entra ID emite o actualiza un token de acceso. Algunos recursos también admiten la evaluación continua del acceso, que puede desencadenar la aplicación casi en tiempo real para eventos específicos.

Patrones de acceso del agente

Los agentes pueden acceder a los recursos protegidos Microsoft Entra mediante uno de los siguientes patrones:

Agentes que actúan en nombre de un usuario

El patrón de acceso más común es el flujo en nombre de (OBO). En este flujo, un usuario inicia sesión en una aplicación de agente y el agente accede a los recursos de bajada mediante la identidad del usuario y los permisos delegados. Por ejemplo, cuando un agente lee los correos electrónicos, accede a su buzón en su nombre. Para obtener más información sobre cómo funciona el flujo OBO para los agentes, consulte Flujos de OAuth del agente: en nombre de.

En este flujo, el agente no puede reutilizar el token original del usuario porque se emitió para una audiencia diferente. En su lugar, el agente utiliza el flujo OBO para intercambiar tokens con Microsoft Entra ID y obtiene un nuevo token con ámbito en el recurso de destino. El acceso condicional también evalúa este intercambio de tokens, lo que permite a los administradores aplicar controles granulares sobre los que los agentes de recursos pueden acceder en nombre del usuario.

Dado que el usuario es el sujeto de este flujo, las directivas de acceso condicional tienen como destino usuarios y grupos, no identidades de agente.

Agentes que actúan como una aplicación

Los agentes pueden acceder a los recursos sin un usuario que haya iniciado sesión. En este caso, el agente accede al recurso con su propia identidad. Este flujo también se conoce como flujo de credenciales de cliente o acceso solo a la aplicación. Todos los tipos de agentes pueden usar este flujo. Para obtener más información sobre cómo los agentes se autentican con su propia identidad, consulte Flujos de OAuth del agente: Aplicaciones autónomas.

Este flujo se aplica en los siguientes escenarios comunes:

• Los agentes autónomos que operan de forma independiente se ejecutan en segundo plano, responden a eventos o se ejecutan según una programación.
  • Por ejemplo, un agente que genera un informe diario y envía el resultado a un grupo de empleados.
  • En este escenario, no hay ningún usuario presente y el agente funciona por sí mismo.
• Los agentes interactivos que usan su propia identidad no siempre acceden a los recursos en nombre de un usuario; a veces usan su propia identidad.
  • Por ejemplo, si un agente llama a un servicio SMS de back-end al que los usuarios no tienen acceso, el flujo de OBO no se aplica y el agente se autentica directamente como sí mismo.
• Los agentes publicados en la web para uso público no autentican al usuario ni admiten la delegación del contexto del usuario a los recursos corporativos.

En estos escenarios, el agente solicita un token de acceso mediante su propia identidad de agente y credenciales administradas a través del plano técnico de identidad del agente. El token se emite a la identidad del agente (no al usuario). Por lo tanto, las directivas de acceso condicional se limitan a la identidad del agente en lugar del usuario. Para obtener una configuración de directiva paso a paso, consulte Acceso condicional para agentes autónomos.

Agentes que actúan como usuario

A veces no es suficiente para que un agente realice tareas en nombre de un usuario o funcione con su propia identidad. En determinados escenarios, un agente tiene su propia cuenta de usuario del agente. Por ejemplo, los trabajadores digitales que funcionan como miembros del equipo con sus propios buzones, el acceso al chat y pueden participar en flujos de trabajo de colaboración como miembro del equipo.

En este modelo, un administrador crea una cuenta de usuario en el directorio y la vincula a la identidad del agente. Desde allí, es como cualquier otra cuenta de usuario. Las licencias se pueden asignar para acceder a Microsoft 365 recursos, como un buzón y un calendario. La cuenta se puede agregar a unidades administrativas y grupos de seguridad como una cuenta de usuario humano.

A veces, los agentes que usan este flujo se denominan "trabajador digital" o "compañero de equipo de IA". También se consideran agentes autónomos, ya que no implican una interfaz de usuario para la interacción humana. En este modelo, el token de acceso se emite a la cuenta de usuario del agente (el sujeto del token) y la directiva se evalúa contra la cuenta de usuario del agente, no contra la identidad del agente. Para obtener una configuración de directiva paso a paso, consulte Acceso condicional para agentes autónomos. Para obtener más información sobre el flujo de OAuth del usuario del agente, consulte Flujo de OAuth de usuario del agente.

Los agentes que se ejecutan en dispositivos administrados, como Windows 365 Cloud PC para agentes, también pueden estar sujetos a la conformidad del dispositivo y a controles de red de cumplimiento. Use la condición Entornos de ejecución del agente (versión preliminar) para limitar estas directivas solo a sesiones basadas en puntos de conexión. Para obtener más información, consulte Requerir un dispositivo compatible para las cuentas de usuario de los agentes.

Directivas de acceso condicional y planos técnicos de identidad del agente

Además de los patrones de acceso de agentes específicos, también puede seleccionar planos técnicos de identidad del agente para aplicar directivas de acceso condicional a una clase de agentes. Cada identidad del agente se deriva de un plano técnico de identidad del agente, que define su modelo de configuración y gobernanza. La aplicación de una directiva en el nivel de plano técnico cubre automáticamente todas las identidades de agente derivadas de ella, incluidas las nuevas agregadas en el futuro. Dirigirse al proyecto de identidad del agente no abarca las cuentas de usuario de los agentes.

En el diagrama siguiente se muestra que solo se concede acceso a las identidades de agente asociadas al plano técnico "A"; todos los demás agentes se excluyen y bloquean.

Por ejemplo, imagine un proyecto en el que tiene varios agentes, cada uno con su propio propósito. Algunas funcionan de forma independiente, mientras que otras colaboran con otros agentes (A2A) para completar tareas. Si todos se crean bajo el mismo esquema, una única directiva aplicada a ese esquema impone controles de acceso coherentes en toda la colección.

Acceso condicional controlado por atributos

A medida que aumenta el número de identidades de los agentes, gestionar cada una individualmente en todas las directivas deja de ser sostenible. Los atributos de seguridad personalizados permiten clasificar las identidades y los recursos del agente con etiquetas específicas de la empresa y, a continuación, dirigirse a esos atributos en las directivas de acceso condicional. Las directivas se aplican automáticamente a todos los agentes con atributos coincidentes, incluidos los agregados en el futuro.

Para ver un tutorial completo sobre cómo crear atributos de seguridad personalizados y usarlos en una directiva de acceso condicional, consulte Acceso condicional para agentes autónomos.

Límites y limitaciones del acceso condicional

Las directivas de acceso condicional no se aplican cuando:

• Un modelo de identidad de agente obtiene un token para Microsoft Graph con el fin de crear una identidad de agente o la cuenta de usuario de un agente.
  • Los planos técnicos del agente tienen una funcionalidad limitada. No pueden actuar de forma independiente para acceder a los recursos y solo están implicados en la creación de identidades de agente y cuentas de usuario de agentes.
  • Las tareas del agente siempre se realizan mediante la identidad del agente.
• Un plano técnico de identidad del agente o una identidad del agente realiza un intercambio de tokens intermedio en el punto de conexión de AAD Token Exchange Endpoint: Public (Identificador del recurso: fb60f99c-7a34-4190-8149-302f77469936).
  • Los tokens con ámbito restringido a AAD Token Exchange Endpoint: Public no pueden llamar a Microsoft Graph.
  • Los flujos del agente están protegidos porque Acceso Condicional protege la adquisición de tokens desde la identidad del agente o la cuenta de usuario del agente.
• Los valores predeterminados de seguridad están habilitados .
• El acceso condicional solo protege los recursos protegidos por Microsoft Entra ID. Por ejemplo, si un agente accede a los recursos mediante una clave de API, omite la Microsoft Entra ID canalización de autenticación y emisión de tokens por completo y las directivas de acceso condicional no se aplicarán a ellos.

Actualmente no se admiten las siguientes configuraciones:

• Las directivas destinadas a todos los usuarios no incluyen las cuentas de usuario del agente.
• Determinar el ámbito de una directiva de acceso condicional para incluir o excluir la cuenta de usuario del agente en función de su pertenencia a grupos
• Una directiva de acceso condicional dirigida a identidades de agente no se aplicará a la cuenta de usuario del agente.
• Una directiva de acceso condicional orientada a identidades de agente que usa el proyecto de identidad del agente solo se aplica a la identidad del agente, no a la cuenta de usuario del agente.

Pasos siguientes

• Cómo seleccionar como destino las identidades de agente en Acceso condicional
• Configuración de la directiva para el acceso de agentes autónomos