Cómo bloquear agentes de IA de alto riesgo en Microsoft Entra

por

Última actualización:
Tiempo de lectura: 5 minutos
Cómo bloquear agentes de IA de alto riesgo en Microsoft Entra

Puntos clave

  • Microsoft Entra puede bloquear automáticamente a los agentes de IA que se hayan marcado como de alto riesgo antes de que accedan a los recursos.
  • Una política de acceso condicional basada en las identidades de los agentes garantiza el cumplimiento en la capa de autenticación, impidiendo que los agentes de riesgo obtengan tokens.
  • Aplicar primero la política en modo «Solo informe» ayuda a identificar los falsos positivos y a evitar interrumpir los flujos de trabajo legítimos impulsados por la IA.
  • Las evaluaciones de riesgo de los agentes se basan en Microsoft Entra ID Protection, que evalúa continuamente las identidades de los agentes y puede activar medidas de control inmediatas cuando aumentan los niveles de riesgo.
  • Esta protección se aplica únicamente a las identidades de los agentes; los agentes que operan mediante permisos de usuario «en nombre de» (OBO) requieren controles de acceso condicional independientes centrados en el usuario.

Los agentes de IA autónomos se autentican con su propia identidad en tu entorno de Microsoft Entra, independientemente de cualquier usuario, y uno que haya sido comprometido o que se comporte de forma anómala es, en la práctica, un atacante que posee credenciales válidas y actúa a la velocidad de una máquina.

Microsoft Entra ID Protection evalúa el riesgo de las identidades de los agentes del mismo modo que evalúa el de los usuarios, y permite bloquear a los agentes de alto riesgo en la capa de autenticación antes de que lleguen a un recurso.

Este blog es una guía paso a paso sobre cómo configurar la política de seguridad adecuada para los agentes de IA, lo que te ayudará a impedir que los agentes de alto riesgo accedan a Microsoft Entra.

Bloquea los agentes de alto riesgo con una política de acceso condicional

Este es el bloque técnico adecuado. Una política de acceso condicional tiene como objetivo controlar el acceso en la capa de autenticación y no solo en la interfaz de usuario.

Nota: Los agentes que actúan en nombre de otros no están cubiertos por esta política. Si un usuario inicia sesión en un agente, este puede acceder a los recursos utilizando los permisos delegados de dicho usuario. En este flujo, el ámbito de aplicación de la política de acceso condicional es el usuario, no la identidad del agente, por lo que no se activa el riesgo asociado al agente.

Pasos:

1. Inicia sesión en entra.microsoft.com como administrador global.

2. Ve a Entra ID > Acceso condicional > Políticas.

3. Haz clic en «Nueva política».

4. Asigna un nombre a la política (por ejemplo: CA-Block-Entra-Admin-Center-Non-Admins)

5. Haz clic en «Usuarios y agentes». En «¿A qué se aplica esta política?», selecciona «Agentes»:

  • Incluir: todas las identidades de agente

6. En «Recursos de destino», selecciona «Recursos» (antes «Aplicaciones en la nube»).

7. Selecciona «Incluir» > «Todos los recursos» (antes «Todas las aplicaciones en la nube»).

8. Haz clic en «Condiciones».

9. Haz clic en «Riesgo del agente» (Vista previa) y selecciona «Configurar» > «Sí» > «Alto».

10. Haz clic en «Hecho».

11. En «Conceder», selecciona «Bloquear el acceso».

12. Establezca la opción «Habilitar política» en «Activada» (o en «Solo informe» para las pruebas iniciales).

13. Haz clic en «Crear».

Buenas prácticas: aplicación de políticas

Ejecuta la política en modo «Solo informes» durante al menos una semana antes de activarla. Durante ese periodo, supervisa Entra ID > Supervisión > Registros de inicio de sesión y filtra por identidades de agente para ver qué se habría bloqueado.

Busca específicamente los agentes legítimos que estén siendo marcados, ya que se trata de falsos positivos, y es importante que los resuelvas antes de que se aplique la política. Activa la opción solo cuando estés seguro de que la política detecta las identidades correctas y no interrumpe los flujos de trabajo reales.

Por qué es importante

A medida que los agentes de IA obtienen acceso a los sistemas de la empresa, se convierten, en la práctica, en identidades no humanas dentro de su entorno. Un agente comprometido puede utilizar credenciales válidas para acceder a recursos, automatizar acciones y aumentar el riesgo a un ritmo que los humanos apenas pueden imaginar. Limitar el acceso de los agentes de alto riesgo proporciona una importante capa de defensa por varias razones:

  • Detiene la amenaza antes de que llegue a tus datos: la aplicación de las medidas de seguridad se lleva a cabo en la capa de autenticación, por lo que un agente marcado nunca llega a obtener el token, y no tienes que ocuparte de limpiar el sistema después de que ya haya accedido a un recurso.
  • Es automático e inmediato: el bloqueo se activa a partir de la señal de riesgo de Identity Protection, por lo que, en el momento en que se asigna una puntuación alta a un agente —incluso cuando se confirma que está comprometido—, la medida se aplica sin intervención humana.
  • Funciona a una escala que la revisión manual no puede alcanzar: los agentes aparecen más rápido de lo que se tarda en identificarlos. Al bloquear a los de alto riesgo, el motor de riesgo se encarga de la clasificación, en lugar de que tengas que examinar a cada agente manualmente.
  • Es preciso: una política bien orientada bloquea únicamente a los agentes de alto riesgo, sin afectar a tus usuarios ni a los agentes sanos, lo que ofrece una protección sólida sin mermar la productividad.

Preguntas frecuentes

¿Qué significa «riesgo del agente» y cómo se puntúa?

El riesgo de los agentes proviene de Microsoft Entra ID Protection, que evalúa las identidades de los agentes del mismo modo que evalúa a los usuarios y los inicios de sesión de riesgo. Puede revisar los agentes marcados en el informe «Agentes de riesgo» del Centro de administración de Entra, donde las detecciones de riesgo permanecen visibles hasta 90 días, con detalles sobre el nombre para mostrar del agente, el estado de riesgo, el nivel de riesgo, el tipo y los patrocinadores. También se puede marcar manualmente a un agente como de alto riesgo cuando se confirme que ha sido comprometido.

¿Qué le ocurre a un agente legítimo al que se le califica como de alto riesgo?

Se le impide solicitar tokens como a cualquier otro agente de alto riesgo, lo cual es un falso positivo y puede interrumpir un flujo de trabajo real. Por eso es recomendable ejecutar primero la política en modo «solo informe»: actívala en este modo durante al menos una semana antes de su aplicación y revisa los registros de inicio de sesión para ver qué casos se habrían detectado.

¿Afecta esta política a los agentes que actúan en nombre de un usuario?

No. En el flujo «en nombre de» (OBO), un usuario inicia sesión en la aplicación del agente y este accede a los recursos utilizando los permisos delegados del usuario. El sujeto del Acceso condicional en ese flujo es el usuario, no la identidad del agente, por lo que no se evalúa el riesgo del agente y esta directiva no tiene ningún efecto. Para controlar a qué pueden acceder los agentes OBO, se necesita una directiva de Acceso condicional dirigida al usuario y limitada a los recursos pertinentes.

CTA