Acceso condicional para agentes

El acceso condicional para agentes es una extensión del motor de directivas de acceso condicional que controla cómo los agentes acceden a los recursos protegidos por Microsoft Entra ID. Reúne señales en tiempo real, como el contexto del usuario y el agente, el dispositivo, la ubicación y la información de riesgo para determinar cuándo permitir, bloquear o limitar el acceso, o requerir más pasos de comprobación.

Comprender el patrón de acceso que sigue el agente le ayuda a identificar la identidad correcta. Un agente puede actuar en nombre de un usuario que ha iniciado sesión, usar su propia identidad de agente o usar su propia cuenta de usuario del agente.

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
• Protección de agentes autónomos con acceso condicional
• Protección de usuarios del agente con Acceso condicional de Microsoft Entra

Requisitos y licencias

Microsoft Entra ID acceso condicional para agentes requiere uno de los siguientes planes de licencia:

• Microsoft 365 E7, que incluye el Agente 365 y Microsoft Entra Suite.
• Licencia de Microsoft Agent 365 combinada con al menos Microsoft Entra P1 o Microsoft 365 E3.

Para obtener más información, consulte Microsoft planes y precios del Agente 365.

Cómo Acceso condicional evalúa el acceso de los agentes

Para acceder a un recurso como un archivo de SharePoint, un servidor MCP o un servicio Open API, un usuario o agente solicita 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 antes de que emite el token. Si se cumplen los requisitos, Microsoft Entra ID emite el token. El recurso de destino valida el token y utiliza sus declaraciones para tomar decisiones de autorización.

Cada token de acceso tiene un asunto y una audiencia:

• Asunto: identidad que recibe el token.
  • En el acceso delegado, el token representa al usuario al mismo tiempo que identifica la aplicación o el agente que realiza la llamada.
  • En el acceso exclusivo a la aplicación, la identidad del agente es el sujeto.
  • En el acceso agente-usuario, la cuenta de usuario del agente constituye el sujeto.
• Audiencia: el recurso de destino para el que está el token, que se debe registrar en Entra ID. Si un sujeto accede a varios recursos, normalmente necesita un token independiente para cada recurso.

El acceso condicional evalúa tanto el asunto que solicita acceso como el público al que se accede. Evalúa las directivas cuando Microsoft Entra ID emite o renueva 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.

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:

Un agente puede usar más de un patrón de acceso. Cree políticas independientes para cada sujeto del token que utilice el agente. Una directiva que tiene como destino una identidad del agente no se aplica a la cuenta de usuario del agente y una directiva que tiene como destino la cuenta de usuario del agente no se aplica a la identidad del agente.

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 el flujo de OBO, un usuario inicia sesión en una aplicación de agente. El agente accede a los recursos de nivel inferior con 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 que ha iniciado sesión es el sujeto del token en este flujo, el acceso condicional evalúa las directivas asignadas a ese usuario, tanto si el usuario es el destinatario directo como si lo es a través de un grupo o de otro mecanismo compatible de asignación de usuarios. Seleccionar una identidad de agente como sujeto de la directiva no cubre las solicitudes del agente realizadas en nombre del usuario.

Agentes que actúan como aplicaciones

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 Protección de agentes autónomos con acceso condicional.

Agentes que actúan como usuarios

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 que funciona como un trabajador digital con su propio buzón de correo, acceso al chat y la capacidad de 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.

Los agentes que usan este flujo 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. Un plano técnico de identidad del agente define la configuración y el modelo de gobernanza para las identidades de agente creadas a partir de él. Una directiva que tiene como destino un plano técnico se aplica a todas las identidades de agente creadas a partir de ese plano técnico, incluidas las identidades de agente creadas más adelante.

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 obtener un ejemplo de directiva, consulte Permitir agentes aprobados mediante atributos de seguridad personalizados.

Límites y limitaciones

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 cuyo ámbito se define mediante la asignación Usuarios no se aplican a las cuentas de usuario de los agentes. Este límite se aplica si la directiva tiene como destino todos los usuarios, usuarios seleccionados, grupos, roles de directorio o usuarios externos. Para proteger las cuentas de usuario del agente, cree una directiva que tenga como destino "Usuarios 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.

En su lugar, para aplicar las directivas a los usuarios de agente, en Asignaciones>, seleccione Agentes y, a continuación, elija todos los usuarios de agente o usuarios de agente específicos.

Contenido relacionado

• Identidades de agente de destino en directivas de acceso condicional
• Protección de agentes autónomos con acceso condicional
• Protección de agentes que actúan como usuarios con acceso condicional