La IA empresarial está inundando los SOC con alertas benignas y ocultando riesgos reales

Las alertas relacionadas con la IA aumentaron un 685 % en cuatro meses

La adopción empresarial de la IA generativa está creando un nuevo problema para las operaciones de seguridad: las herramientas legítimas se comportan cada vez más como el software que las reglas de detección de los SOC estaban diseñadas para identificar.

Una revisión de aproximadamente 16,9 millones de alertas de los SOC identificó unas 73.000 relacionadas con actividad de IA, equivalentes al 0,43 % del total. Aunque la proporción sigue siendo pequeña, el volumen subyacente aumentó en cada uno de los meses analizados.

Durante el periodo estable de elaboración de informes, entre febrero y junio de 2026, las alertas relacionadas con la IA aumentaron un 685 %. La aceleración fue especialmente marcada en mayo de 2026, lo que sugiere que el 0,43 % es un punto de partida, no una proporción estable de la carga de trabajo de los SOC.

Las alertas se dividieron en tres categorías muy desiguales:

• El 94,1 % era ruido de detección, normalmente acciones legítimas de agentes de IA clasificadas erróneamente por los controles de seguridad existentes.
• El 5,8 % representaba un riesgo de seguridad real, incluidas configuraciones inseguras o automatizaciones potencialmente peligrosas sin indicios de compromiso.
• El 0,02 % eran ataques confirmados, principalmente phishing y fraude que aprovechaban el interés por los productos de IA.

Por tanto, el problema inmediato no es una epidemia de atacantes que hayan comprometido agentes de programación empresariales. Es la colisión entre el software autónomo y una lógica de detección diseñada para un mundo en el que una persona, un script o un proceso de malware iniciaba cada comando sensible.

Esa colisión consume capacidad de investigación. También puede ocultar el grupo más pequeño de incidentes relacionados con credenciales expuestas, ejecución sin restricciones, permisos OAuth de riesgo y verdadera ingeniería social.

Los agentes de programación se parecen extraordinariamente a los intrusos

Los agentes de programación modernos hacen mucho más que generar texto. Según su configuración y la tarea asignada, pueden iniciar shells de comandos, instalar paquetes, inspeccionar credenciales, ejecutar utilidades de seguridad, manipular archivos y exponer servicios de desarrollo a redes externas.

Cada acción puede ser legítima. Sin embargo, en conjunto pueden parecerse a las fases de descubrimiento, acceso a credenciales y command and control de una intrusión.

Un cliente experimentó este problema con el binario de Windows Expand.exe. Una detección de transferencia lateral de herramientas relacionada con el ejecutable generó el 55 % de todas las alertas a las que se asignó un veredicto de «crítica» en el conjunto de población analizado. La investigación determinó que el agente de programación de un desarrollador estaba configurando un entorno shell, no trasladando herramientas de un atacante.

Las propias aplicaciones de los proveedores de IA también activaron detecciones graves. Un instalador auténtico y correctamente firmado de Anthropic Claude Desktop activó en varias organizaciones reglas de EDR etiquetadas como «Ransomware Operations detected» y «Encoded PowerShell Download and Run».

No se revelaron las versiones de producto de Claude Desktop, Cursor ni de las demás aplicaciones de IA observadas. Por consiguiente, los hallazgos no deben interpretarse como la identificación de una vulnerabilidad limitada a una versión concreta. Se refieren al comportamiento de las aplicaciones, a la configuración de los usuarios y a los controles de seguridad que rodean la ejecución de la IA.

La gravedad era un indicador poco fiable de la intención. Una clasificación crítica puede indicar que un comando es técnicamente peligroso, pero no establece quién lo solicitó, por qué se ejecutó ni si había un atacante presente.

Los investigadores de los SOC necesitan ahora un contexto de ejecución del que a menudo carecen las detecciones convencionales de endpoints. Esto incluye el proceso padre del agente, la tarea del usuario, el repositorio afectado, el historial de comandos, el modo de permisos y cualquier contenido no fiable procesado antes de que comenzara la actividad.

La automatización insegura genera exposición sin necesidad de una brecha

El 5,8 % clasificado como riesgo real es posiblemente el grupo más importante desde el punto de vista operativo. No eran compromisos confirmados, pero creaban condiciones capaces de exponer sistemas o credenciales.

La principal fuente fueron los agentes de programación iniciados con las salvaguardas de permisos desactivadas. En este modo, el agente puede ejecutar comandos sin pedir al usuario que apruebe cada acción sensible.

Todas las invocaciones revisadas que utilizaban el bypass de permisos estaban asociadas con actividades legítimas de desarrollo. Eso no hace segura la configuración. Significa que las organizaciones están eliminando de forma rutinaria un control que, de otro modo, podría interrumpir comandos destructivos o destinados a robar credenciales.

Un agente que funciona sin solicitar confirmaciones puede seguir siendo inofensivo mientras trabaja con código de confianza. El riesgo cambia cuando procesa un repositorio malicioso, instrucciones manipuladas, documentación controlada por un atacante u otros datos de entrada no fiables. Un incidente de cadena de suministro documentado públicamente ya había demostrado cómo podía ejecutarse código malicioso sin restricciones bajo esta condición previa.

Cuando sea necesaria la ejecución desatendida, las organizaciones deberían añadir guardas programáticas —a menudo denominadas harnesses— que apliquen las políticas de forma independiente del modelo. Estos controles pueden bloquear la extracción de credenciales, restringir los túneles salientes, limitar las rutas con permisos de escritura y exigir aprobación para los comandos de alto riesgo.

Varios comportamientos observados muestran por qué esto es importante.

En un entorno, un editor de código basado en IA inició PowerShell, que a su vez ejecutó ngrok y creó un túnel inverso con nombre utilizando el token de autenticación del desarrollador. La intención aparente era benigna, pero el resultado fue una conectividad accesible desde el exterior hacia un sistema de desarrollo.

En otro caso, un agente intentó recuperar su propio token y las credenciales de cloud ejecutando:

security dump-keychain > /tmp/

En lugar de extraer un único secreto necesario, el comando escribió el contenido del keychain de macOS en una ubicación temporal. Esto convirtió una tarea de autenticación concreta en una exposición generalizada de credenciales.

También se observó que Cursor iniciaba una cadena de procesos más grave:

Cursor.exe → powershell.exe → rundll32.exe

La secuencia utilizaba la funcionalidad MiniDump de comsvcs.dll, scripts temporales de PowerShell y comandos de volcado de memoria. Es posible que se hubiera generado durante una tarea de depuración, pero la técnica puede exponer credenciales y otros secretos almacenados en la memoria de los procesos.

Estos casos no pueden descartarse con seguridad como falsos positivos. Se trata de actividad legítima con consecuencias propias de un atacante.

La exposición de datos es más silenciosa que la ejecución en el endpoint

No todos los riesgos de la IA empresarial generan un árbol de procesos sospechoso. Los empleados también conectan aplicaciones de IA de terceros mediante OAuth, se autentican con identidades corporativas y cargan información empresarial en servicios de IA generativa.

La actividad revisada incluía consentimientos OAuth concedidos a ChatGPT en varios tenants, junto con eventos de «Primer inicio de sesión en una aplicación nueva: OpenAI». Un cliente también generó un grupo considerable de alertas de protección de datos relacionadas con cargas en plataformas de IA generativa.

La mayoría de los eventos eran benignos, pero la autorización no elimina la exposición. Las concesiones OAuth pueden permitir que un proveedor externo lea datos corporativos, mientras que una cuenta de IA comprometida o una vía de prompt injection podría abusar de los permisos existentes.

Las cargas plantean un problema de visibilidad diferente. Una plataforma de EDR puede observar cómo un agente de programación inicia rundll32.exe, pero quizá no identifique el texto sensible pegado en un servicio de IA basado en navegador. Por tanto, las organizaciones necesitan telemetría de identidad, SaaS y protección de datos, además de la supervisión de endpoints.

Los equipos de los SOC deberían revisar el alcance de las concesiones OAuth relacionadas con la IA, identificar los eventos de primer uso y determinar si el empleado tenía una razón empresarial para autorizar la aplicación. Las políticas de gobierno de datos también deberían definir qué información puede enviarse a modelos externos y cómo se detectan las infracciones.

Los ataques reales utilizaron la IA como señuelo, no como exploit

La actividad maliciosa confirmada representó aproximadamente el 0,02 % de las alertas relacionadas con la IA. Ninguno de los compromisos detectados se atribuyó al propio agente de IA de una organización.

Las alertas que inicialmente parecían indicar que un agente estaba ejecutando Mimikatz, abriendo un shell inverso o robando credenciales acabaron vinculándose a actividades legítimas de desarrollo o a actividad benigna clasificada erróneamente por las reglas de detección.

Los atacantes reales aprovecharon, en cambio, la credibilidad de marcas de IA conocidas.

Un correo electrónico de fraude de pagos utilizó el asunto «RE: Anthropic Engagement approval & payment» para respaldar una historia inventada sobre un contrato o una factura. Anthropic proporcionó el pretexto; no era el remitente ni el origen del ataque.

Otra campaña imitó una invitación al espacio de trabajo de Google/Gemini Ads. La infraestructura del remitente y de respuesta no tenía relación con Google, y el mensaje dirigía a los destinatarios al dominio sospechoso:

gemini-advertisers[.]com

La imagen de marca de OpenAI apareció en una invitación fraudulenta a la «OpenAI Partner Summit 2026», enviada desde [email protected]. La infraestructura legítima de Zoom ayudó a que el proceso de registro pareciera creíble. La marca de OpenAI también se utilizó en un escenario de phishing mediante código de dispositivo.

Estos incidentes requieren una distinción analítica clara. Una alerta que menciona un producto de IA puede describir la ejecución de un agente, una automatización insegura, una aplicación externa que recibe datos o a un atacante ajeno que utiliza una marca reconocible.

Los SOC necesitan supresión basada en el contexto, no excepciones generales

La automatización ya gestionaba la mayor parte del volumen observado. La plataforma de triaje asignó un veredicto benigno al 79,8 % de las alertas relacionadas con la IA y suprimió automáticamente el 81,7 %. Solo el 5,4 % llegó a un analista humano, mientras que el resto se conservó para su seguimiento.

Estas cifras demuestran que el triaje automatizado es necesario, pero permitir de forma generalizada las actividades sería peligroso. El mismo shell, túnel o comando de acceso a credenciales puede representar desarrollo rutinario, comportamiento inseguro de un agente o un compromiso activo.

En su lugar, los equipos de seguridad deberían ajustar los controles en función de un contexto específico:

1. Establecer una línea base de las herramientas de IA aprobadas y de los árboles de procesos esperados. Los instaladores firmados y los flujos de trabajo conocidos de los agentes pueden recibir una prioridad menor sin eximir a todos sus procesos secundarios.
2. Detectar la ejecución con bypass de permisos. Las sesiones de agentes sin restricciones deben inventariarse, limitarse y supervisarse por separado.
3. Preservar la visibilidad de los comandos de alto riesgo. Los volcados de memoria, las exportaciones de keychains, los túneles inversos y el acceso a almacenes de credenciales siguen requiriendo revisión, aunque los haya iniciado un agente de IA.
4. Correlacionar la telemetría de endpoints y de identidad. Los consentimientos OAuth, los nuevos inicios de sesión en aplicaciones de IA y las cargas de datos inusuales pueden revelar riesgos que el EDR no puede observar.
5. Formar a los empleados contra el fraude relacionado con la IA. Las solicitudes de pago, las invitaciones a espacios de trabajo, los registros en conferencias y las solicitudes de códigos de dispositivo deben verificarse fuera del mensaje recibido.
6. Medir el crecimiento, no solo la proporción actual. Una categoría que aumentó un 685 % entre febrero y junio de 2026 no puede dimensionarse según su volumen anterior.

La tarea central no es detectar si intervino la IA. Los SOC deben determinar si la actividad era esperada, si tenía permisos peligrosamente amplios o si era maliciosa, y hacerlo antes de que la automatización benigna entierre la señal.