Los agentes de IA integrados en plataformas empresariales han dejado de ser simples herramientas de productividad para convertirse en un riesgo crítico dentro de la capa de identidad de las organizaciones. Investigaciones recientes indican que, al actuar en nombre de usuarios reales, estos agentes pueden ejecutar comportamientos sospechosos, los cuales están siendo detectados a través de los registros de Microsoft Entra Agent ID.

Los agentes de IA integrados en las plataformas empresariales ya no son solo herramientas de productividad. Investigadores de seguridad han descubierto que estos agentes, cuando se configuran para actuar en nombre de usuarios reales, pueden convertirse en un riesgo silencioso pero grave en lo más profundo de la capa de identidad de una organización.

Una nueva investigación revela cómo los registros de Microsoft Entra Agent ID capturan comportamientos sospechosos vinculados a lo que se denomina agentes asistivos, también conocidos como agentes interactivos.

Estos agentes operan a través de un flujo de acceso delegado, lo que significa que llevan a cabo acciones utilizando los permisos de un usuario real en lugar de sus propias credenciales independientes.

Los agentes asistivos están diseñados para ayudarte realizando tareas bajo demanda a través de una interfaz de chat. Esto puede incluir leer correos electrónicos, extraer datos del calendario o responder preguntas de soporte con una intervención humana mínima.

El problema es que, bajo las circunstancias equivocadas, estos agentes pueden ser manipulados o comprometidos y luego utilizados para llevar a cabo acciones dañinas mientras aparentan actuar como un empleado de confianza.

Investigadores de Red Canary identificaron este comportamiento y publicaron un informe detallado sobre cómo se desarrolla un ataque de este tipo dentro de un entorno real de Microsoft 365.

Según el informe de Red Canary compartido con Cyber Security News (CSN), la investigación analiza un escenario en el que un agente de IA envió un correo electrónico sospechoso en nombre de un usuario legítimo, y toda la operación pasó desapercibida para las herramientas estándar de monitoreo de identidad.

El caso se centra en cómo un usuario concede acceso a un agente a través de algo llamado flujo "On Behalf of" (en nombre de). Cuando se otorga ese consentimiento, el agente recibe un token vinculado a los permisos del usuario y puede entonces realizar solicitudes a servicios de Microsoft como Exchange o la API de Graph.

Los permisos que recibe el agente representan la intersección entre lo que el agente tiene permitido hacer y los roles que el usuario ya posee.

El correo electrónico en cuestión estaba dirigido a un contacto externo de nivel CFO y llevaba el asunto "Aquí tienes tu factura". A simple vista, parecía un mensaje normal de un empleado regular.

Sin embargo, un análisis más profundo de los registros reveló que la identidad del agente Agent001, ejecutándose a través de la API de Microsoft Graph, era el remitente real que operaba silenciosamente en nombre de la cuenta del usuario.

Registros de Microsoft Entra Agent ID

Rastrear el correo electrónico sospechoso requirió correlacionar tres fuentes de registros distintas: el registro de Purview Exchange, el registro de actividad de Microsoft Graph y el registro de inicio de sesión de usuarios no interactivos.

El registro de Purview mostró inicialmente una dirección IP propiedad de Microsoft como la fuente, un detalle que podría confundir fácilmente a un analista.

Al extraer el registro correspondiente de la API de Graph utilizando el campo AppAccessContext.UniqueTokenId, salió a la luz la verdadera dirección IP de origen, 51.3.97.221, junto con la llamada exacta a la API que activó el correo electrónico.

El registro de inicio de sesión confirmó que el agente estaba operando a través de un flujo "On Behalf of". Los indicadores clave fueron dos campos específicos del registro: Agent.agentType establecido como agenticAppInstance y Agent.agentSubjectType establecido como notAgentic.

Microsoft no etiqueta estos flujos explícitamente en los registros, por lo que reconocer este patrón requiere un conocimiento previo de cómo aparece cada tipo de autenticación. El equipo de investigación señaló que tú, como defensor, debes replicar estos escenarios en entornos de prueba para comprender las diferencias de comportamiento.

Detectar flujos agénticos antes de que se cause el daño

Una de las conclusiones más importantes es que los defensores no pueden confiar en una sola fuente de registros para entender qué hizo un agente de IA. La correlación entre Purview, los registros de actividad de Graph y los registros de inicio de sesión es esencial para construir una imagen completa y precisa.

Los equipos de seguridad deben buscar la operación Add delegated permission grant en la tabla AuditLogs para detectar cuándo un usuario consiente dar acceso a un agente a través del alcance access_agent. Ese evento de auditoría es la señal más temprana disponible.

También se aconseja rastrear el campo Agent.parentAppId en los registros de inicio de sesión, que vincula una instancia de agente con su origen de diseño (blueprint). Cuando ocurre algo sospechoso, ese campo es el que vincula una acción específica con la identidad original del agente.

Ten en cuenta que incluso los permisos de nivel inferior, como Mail.Send, pueden causar daños graves si se utilizan mal. Crear detecciones basadas en correos electrónicos salientes inesperados enviados a través de la API de Graph sigue siendo un punto de partida práctico para capturar el comportamiento malicioso de los agentes a tiempo.

Indicadores de Compromiso (IoCs):-

Nota: Las direcciones IP y los dominios han sido deshabilitados intencionalmente (por ejemplo, [.]) para evitar la resolución accidental o el hipervínculo. Reactívalos solo dentro de plataformas de inteligencia de amenazas controladas como MISP, VirusTotal o tu SIEM.