Las alertas de AI SOC de Intezer se dispararon, pero casi todas eran ruido

Las alertas de AI SOC de Intezer aumentaron un 685% entre febrero y junio de 2026, a pesar de representar solo el 0,43% de las alertas de seguridad de su estudio. El conflicto ya es evidente. La IA empresarial no ha provocado la oleada de brechas impulsadas por agentes que muchos equipos de seguridad temían. Ha generado un flujo de actividad legítima que crece con rapidez y que a menudo se parece a una intrusión.

Intezer examinó cerca de 16,9 millones de alertas en múltiples entornos empresariales. Aproximadamente 73.000 involucraban herramientas o agentes de IA. Sus investigadores clasificaron el 94,1% como ruido, el 5,8% como riesgos de seguridad reales y solo el 0,02% como ataques reales.

Ese desequilibrio enfrenta, por un lado, la lógica de detección ya establecida y, por otro, el trabajo normal asistido por IA. Claude, Codex, Cursor, ChatGPT y herramientas similares pueden iniciar procesos, gestionar archivos, invocar shells y conectarse a servicios. Estas acciones se parecen al comportamiento de un atacante cuando se observan sin conocer la intención del usuario.

El resultado no es simplemente más trabajo para un centro de operaciones de seguridad, o SOC. Es un problema de contexto. Los equipos deben distinguir la actividad legítima de los agentes del comportamiento inseguro de los agentes antes de que las falsas alarmas oculten las exposiciones importantes.

Las alertas de AI SOC de Intezer crecieron más rápido de lo que su cuota sugiere

La cifra importante no es la cuota actual de la IA en el volumen de alertas. Es la velocidad y la composición de ese crecimiento.

Según el estudio de alertas de IA de Intezer, la actividad relacionada con IA generó cerca de 73.000 de las 16,9 millones de alertas revisadas. Esto convierte a la categoría en una parte pequeña frente a las alertas de endpoints, identidad, correo electrónico, nube y red que ya llegan a los SOC empresariales.

Sin embargo, el volumen mensual relacionado con IA aumentó durante todo el periodo de informes estable. Intezer midió un crecimiento del 685% entre febrero y junio de 2026. La empresa describió el patrón como monotónico, lo que significa que cada mes completo superó al anterior.

Esta trayectoria importa porque la adopción empresarial no requiere un despliegue formal en toda la compañía. Los empleados pueden conectar un chatbot de consumo mediante OAuth, que permite a una aplicación acceder a recursos aprobados de una cuenta. Los desarrolladores pueden instalar agentes de programación que comienzan inmediatamente a interactuar con sistemas locales.

Cada acción añade una nueva fuente de telemetría. También puede activar reglas creadas años antes de que los agentes de propósito general comenzaran a operar en los ordenadores de los empleados.

Intezer dividió las alertas resultantes en tres categorías. El ruido abarcaba actividad legítima que activó una detección existente. El riesgo de seguridad cubría comportamiento inseguro o exposición sin un compromiso confirmado. Los ataques reales requerían evidencia de una operación real de un atacante.

El ruido dominó con un 94,1%. Los riesgos de seguridad representaron el 5,8%, mientras que los ataques confirmados supusieron alrededor del 0,02%. Estas clasificaciones proceden de la plataforma y metodología de Intezer, por lo que estudios independientes podrían producir proporciones distintas.

Los datos internos de gestión mostraron otra capa del mismo patrón. Intezer afirmó que el 79,8% de las alertas relacionadas con IA recibió un veredicto benigno. Su sistema automatizado suprimió el 81,7%, cerrándolas sin presentarlas a un analista humano.

Solo el 5,4% se escaló a un analista. Las alertas restantes se marcaron para seguimiento en lugar de tratarse inmediatamente como incidentes.

Estos resultados respaldan el triaje automatizado, pero también revelan una dependencia. La automatización debe comprender la relación entre un agente, su usuario y la tarea que se está realizando. El nombre de un proceso o un comando por sí solo rara vez aporta ese contexto.

Un cliente generó el 55% de todas las alertas relacionadas con IA etiquetadas como críticas en el conjunto de datos mediante una única detección. Esa regla identificó el binario de Windows Expand.exe como una posible herramienta de transferencia lateral.

Una inspección más detallada encontró a un agente de programación preparando un entorno de shell. La actividad era normal para ese flujo de trabajo, aunque sus señales técnicas individuales se parecían al comportamiento de un atacante.

Una etiqueta de gravedad tradicional habría colocado estas alertas cerca del inicio de la cola de un analista. El contexto las desplazó hacia el cierre automático. Esa diferencia se vuelve costosa cuando el mismo patrón se repite en miles de endpoints.

El estudio no demuestra que todas las alertas de IA de alta gravedad sean inofensivas. Demuestra que la gravedad pierde significado cuando la lógica de detección no puede reconocer el comportamiento normal de los agentes.

Este es el primer cambio operativo para los responsables de SOC. La actividad de IA necesita su propia línea base, incluidas las herramientas aprobadas, los procesos padre esperados, los destinos habituales y las acciones permitidas. Sin esa línea base, el crecimiento de la adopción se convierte en crecimiento de la urgencia falsa.

La adopción de IA en toda la empresa cambia la forma del flujo de alertas

La IA empresarial crea dos flujos de seguridad a la vez: ejecución ruidosa de agentes y movimiento silencioso de datos corporativos.

El flujo ruidoso procede principalmente de usuarios técnicos. Los agentes de programación pueden crear scripts, iniciar intérpretes, instalar paquetes, inspeccionar repositorios, abrir puertos o ejecutar herramientas de desarrollo. Cada acción puede parecerse a una etapa de una intrusión.

Un desarrollador podría pedir a un agente que inicie un servidor de pruebas local. El agente podría iniciar PowerShell, localizar un puerto sin usar, ejecutar Python y redirigir la salida a registros del proyecto. Un producto de endpoint ve una cadena de procesos inusual antes de ver un objetivo de desarrollo benigno.

Intezer descubrió que un binario sandbox firmado de OpenAI Codex producía este patrón. PowerShell iniciaba después cmd.exe, python.exe y conhost.exe mientras preparaba un entorno de proyecto local.

Una regla convencional interpretó la secuencia como una posible shell inversa. El texto del comando mostraba, en cambio, orquestación local en 127.0.0.1, la dirección de bucle invertido utilizada para llegar al mismo ordenador.

Los instaladores generan colisiones similares. Intezer informó de que el instalador legítimo de Claude Desktop activó detecciones asociadas con comportamiento de ransomware y ejecución codificada de PowerShell. Su firma de código confirmó la identidad del paquete, pero las reglas de comportamiento siguieron tratando la secuencia de instalación como sospechosa.

Esto no vuelve obsoleta la detección basada en comportamiento. El software firmado puede volverse malicioso y las aplicaciones de confianza pueden ser objeto de abuso. Significa que la detección requiere contexto de respaldo antes de que un analista pueda asignar una intención.

El flujo silencioso procede de la adopción no técnica. Los empleados pueden conceder a un servicio de IA acceso a cuentas corporativas, cargar documentos o pegar material sensible en prompts. Estas acciones quizá nunca generen un proceso inusual en el endpoint.

Intezer observó consentimiento OAuth concedido a ChatGPT en varios tenants. También detectó los primeros inicios de sesión en una aplicación de OpenAI y un grupo de alertas de protección de datos relacionadas con cargas de IA generativa en un cliente.

La mayoría de los eventos eran benignos. Aun así, representaban información corporativa que se trasladaba a servicios fuera del control inmediato del endpoint.

Esta distinción explica por qué bloquear unos pocos ejecutables no puede resolver la seguridad de la IA empresarial. Una parte del riesgo reside en los procesos. Otra reside en sesiones del navegador, permisos de identidad, integraciones de software y flujos de datos.

Por tanto, un inventario útil necesita más que una lista de aplicaciones aprobadas. Debe conectar usuarios, identidades, agentes, extensiones, autorizaciones OAuth, destinos de datos y los recursos a los que cada herramienta puede acceder.

Este trabajo va más allá del SOC. Los equipos de identidad gestionan el consentimiento y el acceso. Los equipos de gobernanza de datos definen la información sensible. Los responsables de ingeniería deciden qué configuraciones de agentes son aceptables.

Los equipos de compras y legales evalúan las condiciones de tratamiento de terceros. Los responsables de negocio determinan si los empleados cuentan con alternativas aprobadas y funcionales.

El SOC sigue siendo el punto donde convergen estas señales. Recibe las alertas cuando una herramienta inicia un comando sospechoso, abre un túnel o accede a información protegida.

La adopción en toda la empresa también cambia el significado de la atribución. Antes de los agentes de propósito general, un comando ejecutado bajo la cuenta de un usuario normalmente reflejaba al usuario o a un atacante que controlaba esa cuenta.

Un agente introduce un tercer actor. Opera con la autoridad del usuario, pero puede seleccionar comandos que el usuario nunca revisó. La actividad pertenece a la cuenta sin reflejar por completo la acción directa del titular de la cuenta.

Esa brecha es especialmente importante para las líneas temporales de incidentes. Los analistas necesitan saber si una persona escribió un comando, si lo generó un agente aprobado o si contenido malicioso manipuló al agente.

Los equipos de seguridad también necesitan contexto organizativo duradero. Una base de conocimientos de ingeniería con capacidad de búsqueda puede conservar flujos de trabajo aprobados y decisiones técnicas locales. Sin embargo, la documentación debe conectarse con evidencia actual de identidad y endpoints para respaldar el triaje.

El objetivo operativo no es lograr visibilidad perfecta sobre cada prompt. Es contar con suficiente contexto verificado para separar el trabajo aprobado, el comportamiento inseguro y la actividad adversaria sin supervisar a los empleados de forma más amplia de lo necesario.

La lógica de detección heredada choca con el comportamiento normal de los agentes

La principal disputa es entre la lógica de detección heredada y el contexto de los agentes de IA, no entre analistas humanos y automatización.

Los productos de seguridad suelen detectar técnicas en lugar de intención. El acceso a credenciales, la ejecución de comandos, la persistencia, los túneles y la recopilación de datos siguen siendo peligrosos independientemente de qué aplicación los inicie.

Los agentes de IA complican ese modelo porque las herramientas legítimas ahora realizan combinaciones que antes se asociaban principalmente con administradores, testers de penetración y atacantes. La superposición es estructural, no accidental.

Intezer detectó tasas de actividad benigna de entre el 77% y el 99% entre los grupos de detección relacionados con IA más ruidosos. Varias reglas se equivocaron con el comportamiento generado por IA más de cuatro de cada cinco veces.

Un ejemplo involucraba OpenAI Codex iniciado mediante Node.js con flags como --yolo o --dangerously-skip-permissions. La actividad resultante activó detecciones relacionadas con ClickFix, herramientas deshabilitadas e inyección de DLL.

Los flags de omisión de permisos eliminan las solicitudes de aprobación antes de que un agente ejecute acciones. Los desarrolladores los utilizan para reducir interrupciones, pero esa misma comodidad debilita un límite de control importante.

El grupo de ClickFix fue una excepción dentro de los hallazgos de ruido de Intezer. Solo el 37% de esas alertas eran benignas. Ese resultado no convierte cada alerta en un ataque, pero aporta más valor investigativo al grupo.

Aquí es donde las listas de permitidos simples fallan. Declarar que Codex, Claude o Cursor son de confianza reduciría el ruido, pero también podría ocultar acciones inseguras iniciadas mediante esas herramientas.

El enfoque más seguro evalúa la cadena completa. El SOC debe considerar la aplicación firmada, el usuario iniciador, la configuración del agente, la tarea solicitada, los procesos hijo, los recursos a los que se accede, el destino de red y el movimiento de datos resultante.

La matriz de amenazas de IA de MITRE refleja esta visión más amplia. Incluye invocación de herramientas por agentes, recolección de credenciales, inyección de prompts, shells inversas y exfiltración mediante mecanismos relacionados con IA.

Estas técnicas muestran por qué un agente aprobado no puede recibir confianza permanente y absoluta. La herramienta puede ser legítima mientras que una invocación concreta sigue siendo insegura.

Por lo tanto, la ingeniería de detección debe volverse más condicional. Un servidor local iniciado dentro de un repositorio de desarrollo conocido puede ser rutinario. El mismo intérprete que crea un túnel externo desde una estación de trabajo de finanzas merece un tratamiento distinto.

Puede ser esperable que un agente de programación lea su propio token de configuración. Volcar todo el llavero de macOS en un archivo temporal no es proporcional a esa tarea.

Intezer observó ese patrón exacto. Un agente utilizó security dump-keychain y redirigió la salida a una ubicación temporal mientras intentaba recuperar credenciales almacenadas.

La tarea prevista no requería una intención maliciosa. Sin embargo, el método elegido expuso más información de la necesaria y creó un objetivo valioso en el disco.

Otro caso involucró a un editor de código con IA que inició PowerShell y luego ngrok, un servicio que crea túneles accesibles desde internet. Abrió un túnel inverso con nombre utilizando el token de autenticación del empleado.

El propósito del usuario podría haber sido una resolución legítima de problemas o desarrollo. Sin embargo, la acción creó una vía real desde la internet pública hacia un entorno empresarial.

Un tercer ejemplo involucró a Cursor iniciando una cadena de procesos que utilizó un método conocido de volcado de memoria. Cursor inició PowerShell, que llamó a rundll32.exe y a la funcionalidad MiniDump en comsvcs.dll.

Esa técnica puede extraer secretos de la memoria de un proceso. Incluso cuando un agente la selecciona para depuración, el comportamiento crea un riesgo de acceso a credenciales que merece investigación.

Estos ejemplos respaldan una política basada en acciones y límites, no solo en nombres de productos. Los agentes aprobados deben seguir teniendo restricciones sobre almacenes de credenciales, sistemas de producción, túneles públicos y repositorios sensibles.

El aislamiento puede ayudar. Intezer recomienda ejecutar herramientas de IA dentro de entornos restringidos, incluidos contenedores o máquinas virtuales, cuando el flujo de trabajo lo permita.

Un contenedor empaqueta un proceso con recursos y límites de acceso definidos. Una máquina virtual proporciona un entorno operativo independiente con un aislamiento más sólido en muchas configuraciones.

Ninguno de estos controles es absoluto. Los contenedores pueden configurarse incorrectamente, mientras que las máquinas virtuales aún necesitan controles de identidad, red, almacenamiento y actualizaciones. Ambos pueden reducir la cantidad de recursos a los que un agente accede de forma predeterminada.

También mejoran la atribución. La actividad originada dentro de un entorno de agente asignado es más fácil de distinguir de la actividad habitual de escritorio de un usuario.

El cambio requiere una medición cuidadosa. Los equipos deben realizar un seguimiento de las tasas de falsos positivos por detección, agente, configuración y unidad de negocio. También deben registrar qué supresiones posteriormente requirieron corrección.

Una reducción generalizada del volumen de alertas no equivale al éxito. La medida útil es si el ajuste elimina ruido predecible sin ocultar el acceso a credenciales, la exposición externa o el movimiento de datos sensibles.

Los riesgos silenciosos de seguridad de la IA importan más que las alertas ruidosas

Los riesgos de IA con mayores consecuencias en los datos de Intezer a menudo eran exposiciones, no compromisos confirmados ni alertas de máxima gravedad.

Intezer clasificó el 5,8 % de la población relacionada con IA como riesgos de seguridad genuinos. Estos eventos no demostraban que un atacante hubiera obtenido acceso. Mostraban condiciones que podrían hacer que un compromiso posterior fuera más perjudicial.

La omisión de permisos fue un ejemplo central. Un agente que opera sin solicitudes de aprobación puede ejecutar una larga secuencia antes de que un usuario vea los detalles.

Ese diseño se vuelve más peligroso cuando el agente lee código, sitios web, tickets, correos electrónicos o documentos no confiables. Las instrucciones maliciosas ocultas en esas fuentes pueden influir en las decisiones de un agente.

La inyección de prompts es un intento de hacer que un modelo siga instrucciones hostiles incorporadas en su entrada. Se vuelve más grave cuando un agente puede utilizar herramientas o acceder a datos empresariales.

Una inyección indirecta puede llegar a través de contenido que el usuario nunca considera una instrucción. Una página web o un archivo de repositorio puede contener texto destinado al agente en lugar de al lector humano.

El perfil de IA generativa de NIST recomienda gobernar, mapear, medir y gestionar los riesgos de IA durante todo el ciclo de vida del sistema. Ese modelo encaja con los agentes empresariales porque el riesgo atraviesa límites tecnológicos y organizativos.

Una alerta de endpoint podría revelar el comando final sin mostrar el contenido que influyó en el modelo. Un registro de identidad podría revelar una concesión de OAuth sin mostrar qué documentos ingresaron posteriormente al servicio.

Un producto de prevención de pérdida de datos podría detectar una carga, pero carecer del propósito empresarial. Cada herramienta observa un fragmento del evento.

El SOC necesita correlación entre esos fragmentos. Debe conectar al usuario, el agente, la fuente del prompt, los permisos, la actividad de procesos, el destino y la clasificación de datos cuando la telemetría disponible lo permita.

Eso no requiere recopilar todas las conversaciones de los empleados. La privacidad y la proporcionalidad siguen siendo importantes. Las organizaciones deben capturar la evidencia mínima necesaria para aplicar las políticas establecidas e investigar riesgos significativos.

Una política clara también importa porque la misma acción puede tener consecuencias diferentes entre departamentos. Subir textos públicos de marketing no es lo mismo que subir registros de clientes, información financiera no publicada o código fuente que contiene secretos.

Las herramientas aprobadas no eliminan esta diferencia. Las licencias empresariales pueden mejorar los controles administrativos, pero no pueden decidir si cada dato pertenece a cada prompt.

El consentimiento de OAuth merece una atención similar. OAuth permite a un usuario autorizar una aplicación sin entregar una contraseña. El token resultante aún puede proporcionar acceso considerable al correo, archivos, calendarios u otros servicios.

Los ámbitos solicitados por una aplicación de IA legítima pueden superar la tarea inmediata. Una cuenta comprometida o un agente manipulado puede entonces utilizar esos permisos de formas que el empleado nunca pretendió.

Los equipos de SOC deben examinar las concesiones de consentimiento de alto riesgo, las aplicaciones inusuales utilizadas por primera vez y los permisos que atraviesan sistemas sensibles. También deben ofrecer una vía rápida para que los usuarios soliciten integraciones aprobadas.

Si la gobernanza avanza demasiado lentamente, los empleados la sortearán. Eso crea IA en la sombra, es decir, herramientas o usos que operan fuera de la aprobación y supervisión organizativas establecidas.

La respuesta no es una prohibición indiscriminada. Una prohibición puede reducir la actividad visible mientras desplaza el trabajo útil hacia cuentas personales y sesiones de navegador no gestionadas.

Los equipos de seguridad necesitan una vía práctica y autorizada con controles adecuados. Los empleados deben comprender qué herramientas pueden utilizar, qué información pueden compartir y cuándo un agente necesita un entorno aislado.

CISA y socios internacionales pusieron un énfasis similar en la propiedad, la transparencia y el diseño seguro en sus directrices de seguridad de IA. Esos principios se aplican a los proveedores, pero los compradores empresariales también deben evaluarlos.

Las preguntas de adquisición deben cubrir el registro, la retención, el entrenamiento de modelos, los ámbitos de acceso, los controles administrativos, la notificación de incidentes y la eliminación de datos. Las pruebas técnicas deben verificar las afirmaciones importantes siempre que sea posible.

Los manuales de SOC deben traducir la política en pasos de investigación. Un analista que detecte un túnel desconocido debe poder identificar rápidamente al agente, usuario, tarea y destino responsables.

El manual no debe cerrar automáticamente el evento porque una herramienta aprobada lo haya iniciado. Debe determinar si la acción se mantuvo dentro de un límite aprobado.

El mismo principio se aplica al acceso a credenciales. Un agente que lee un secreto limitado mediante un intermediario aprobado es distinto de exportar un almacén completo de credenciales.

Este modelo centrado en las acciones preserva detecciones útiles a la vez que reduce el ruido evitable. También alinea las alertas con los riesgos que la organización realmente ha decidido gestionar.

Lo que los datos de Intezer aún no demuestran

Los hallazgos de Intezer son una instantánea operativa útil, pero no una medición universal del riesgo empresarial de IA.

El estudio cubre alertas visibles en entornos conectados a la plataforma de Intezer. No representa a todas las empresas, pilas de seguridad, industrias, geografías ni estilos de implementación de IA.

Intezer no publicó un recuento completo de clientes ni un desglose detallado por sector en el artículo. También anonimizó la información de clientes, hosts, usuarios e identificadores.

Eso protege a las organizaciones, pero limita la reproducción independiente. Los lectores no pueden determinar cuánto influyó un gran entorno en cada categoría más allá de los ejemplos que Intezer divulgó.

La investigación también mide alertas, no toda la actividad de IA. Una acción que nunca activa un control conectado puede estar ausente del conjunto de datos.

Esto importa especialmente para herramientas basadas en navegador, cuentas personales, extensiones no autorizadas e intercambios de datos que los productos de endpoint no pueden observar. El uso silencioso puede estar infrarrepresentado frente a la actividad de agentes ejecutables.

Por tanto, la cifra del 94,1 % de ruido debe orientar el ajuste de detecciones, no convertirse en una tasa universal de falsos positivos. Otra organización puede tener agentes, políticas, usuarios o telemetría diferentes.

La proporción de ataques del 0,02 % también requiere una interpretación cuidadosa. No demuestra que los agentes de IA sean inherentemente seguros ni que los ataques habilitados por agentes sean insignificantes en todas partes.

Muestra que los ataques confirmados fueron extremadamente raros dentro de esta población específica de alertas relacionadas con IA. Intezer indicó que ninguno de esos ataques confirmados fue resultado de que el agente de una organización provocara un compromiso.

Los ataques genuinos que identificó utilizaron marcas conocidas de IA como señuelos de phishing. Los atacantes suplantaron nombres como Anthropic, Gemini y OpenAI porque los empleados los reconocen y confían cada vez más en ellos.

Un correo electrónico hacía referencia a una supuesta colaboración con Anthropic y una solicitud de pago. Otro utilizaba una falsa invitación publicitaria de Gemini con infraestructura no relacionada con Google.

Un tercero suplantaba un evento de socios de OpenAI mientras utilizaba infraestructura legítima de Zoom para que la invitación pareciera creíble. En cada caso, la adopción de IA reforzó el pretexto en lugar de aportar una nueva técnica de ataque.

La distinción es útil, pero puede cambiar. Permisos de agentes más amplios, capacidades autónomas más sólidas e integraciones empresariales más profundas aumentan las consecuencias de la manipulación.

La ausencia de muchos compromisos confirmados causados por agentes en este conjunto de datos no demuestra que las implementaciones futuras seguirán siendo seguras. Es una referencia para observar la transición.

Los incentivos de los proveedores también merecen atención. Intezer vende una plataforma de SOC con IA y servicios automatizados de triaje. Su investigación destaca naturalmente problemas que la investigación contextual y la automatización pueden abordar.

Eso no invalida los datos. Significa que los compradores deben comparar los resultados con su propia telemetría, hallazgos de red team e historial de incidentes antes de cambiar controles.

Los equipos de seguridad deben probar si los veredictos automatizados siguen siendo precisos en su entorno. Deben tomar muestras de alertas suprimidas, revisar clasificaciones inciertas y vigilar evidencias posteriores que contradigan una decisión anterior.

También deben documentar la diferencia entre resultados verificados y afirmaciones de proveedores. Por ejemplo, Intezer afirma que su plataforma más amplia puede investigar alertas a escala, pero este estudio no valida de forma independiente cada afirmación de rendimiento.

La cuestión más difícil se refiere a las señales ausentes. Un SOC puede eliminar el ruido visible mediante ajustes y aun así carecer de cobertura para herramientas de navegador no autorizadas o intercambio de datos riesgoso.

Por eso la reducción de alertas no puede ser la única métrica de éxito. Los equipos también necesitan cobertura del inventario de agentes, recuentos de permisos riesgosos, tendencias de cargas sensibles y el tiempo necesario para rastrear una acción hasta su origen.

Una organización con menos alertas pero sin visibilidad de OAuth o de la actividad del navegador no necesariamente ha mejorado su seguridad. Es posible que haya trasladado el riesgo fuera del canal medido.

Tres señales mostrarán si los SOC se están adaptando

La siguiente prueba es si los equipos de seguridad pueden mejorar el contexto más rápido de lo que se expande la actividad de IA.

La primera señal es el rendimiento de falsos positivos en detecciones relacionadas con agentes. Los líderes de SOC deben medir las tasas benignas antes y después de ajustar las reglas más ruidosas.

Un cambio exitoso reducirá las alertas repetidas de instaladores conocidos, servidores de desarrollo locales y cadenas de procesos aprobadas. Mantendrá la revisión de omisiones de permisos, extracción de credenciales, túneles externos y movimientos inusuales de datos.

Si las tasas de eventos benignos disminuyen sin un aumento de incidentes no detectados, el SOC está aprendiendo el comportamiento normal de la IA. Si los analistas siguen cerrando manualmente los mismos patrones, la adopción todavía está superando a la ingeniería de detección.

La segunda señal es la cobertura empresarial en los controles de identidad, navegador, endpoints, nube y datos. Una lista de agentes de programación instalados no constituye un inventario completo de IA.

Los equipos deben buscar nuevas autorizaciones OAuth, inicios de sesión por primera vez en aplicaciones de IA, extensiones no gestionadas, uso de cuentas personales y conexiones entre agentes y repositorios sensibles.

Una cobertura mejorada revelará al principio más exposición silenciosa. Ese aumento temporal no debe confundirse con un empeoramiento de la seguridad. Una mejor medición suele hacer visible el riesgo existente antes de que los controles lo reduzcan.

La tercera señal es si los despliegues de agentes adoptan la ejecución restringida de forma predeterminada. Las solicitudes de permisos, las credenciales restringidas, los entornos aislados y el acceso limitado a la red proporcionan límites medibles.

Las organizaciones deben vigilar la proporción de agentes iniciados con indicadores de omisión. También deben supervisar con qué frecuencia los agentes intentan ejecutar comandos prohibidos, incluso cuando un control bloquea la ejecución.

Una tasa de omisiones a la baja reforzaría la idea de que la gobernanza se está volviendo operativa. Un crecimiento continuado demostraría que la conveniencia sigue primando sobre la contención.

Las pruebas de seguridad deben incluir flujos de trabajo de agentes realistas, no solo prompts de modelos. Una evaluación puede colocar instrucciones no confiables en código, documentos, tickets o contenido web y observar la respuesta del agente.

El objetivo es probar todo el sistema. Eso incluye permisos de identidad, herramientas, memoria, contenido externo, controles de ejecución, registros y aprobación humana.

Las alertas de Intezer AI SOC ofrecen una visión temprana de esta transición. El resultado principal resulta tranquilizador solo a primera vista. Los ataques confirmados fueron poco frecuentes, pero la exposición y el ruido operativo ya crecían rápidamente.

Para los equipos de SOC, la pregunta inmediata es concreta: ¿pueden identificar el comportamiento normal de los agentes sin otorgarles una confianza absoluta?

Empiecen por las detecciones que generan la mayor cantidad de alertas benignas repetidas. Después comparen ese ajuste con las omisiones de permisos, el acceso a credenciales, los túneles, las autorizaciones OAuth y las cargas de datos sensibles. Si esas señales de mayor valor se vuelven más fáciles de detectar, el SOC se está adaptando. Si el número de alertas disminuye mientras la visibilidad sigue fragmentada, la mejora aparente es solo una incertidumbre más silenciosa.