La vulnerabilidad de Virtual Agent de ServiceNow demuestra por qué la seguridad de la IA necesita los fundamentos tradicionales de AppSec
14 de enero de 2026
0 minutos de lecturaLa reciente divulgación de lo que los investigadores de seguridad llaman «la vulnerabilidad impulsada por IA más grave descubierta hasta la fecha» en la plataforma de ServiceNow es un recordatorio contundente: proteger la IA agéntica no se trata solo de implementar controles específicos para la IA; primero hay que hacer bien lo fundamental.
Anatomía de la vulnerabilidad de Virtual Agent
En octubre de 2025, el equipo de investigación de seguridad de AppOmni descubrió una cadena de vulnerabilidades críticas en Virtual Agent de ServiceNow que permitía a los atacantes tomar el control total de la plataforma con poco más que la dirección de correo electrónico de la víctima.
El exploit combinaba tres fallas en cascada:
Falla de autenticación de API: ServiceNow distribuyó la misma credencial codificada de forma rígida —la cadena
servicenowexternalagent— a todos los servicios de terceros que se autenticaban con la API de Virtual Agent. Este token estático era idéntico en todos los entornos de clientes.Falla en la verificación de identidad: Una vez conectado, el sistema aceptaba las direcciones de correo electrónico como prueba suficiente de identidad. Sin contraseña. Sin MFA. Sin validación de SSO.
Privilegios excesivos del agente:
Record Management AI Agentpodía crear datos nuevos en cualquier lugar de ServiceNow, incluso cuentas de usuario con privilegios de administrador.
Esto es lo que hace que este ataque sea especialmente preocupante: ServiceNow es una plataforma de gestión de servicios de TI que usa el 85 % de las empresas de Fortune 500. Sus tentáculos llegan a RR. HH., atención al cliente, operaciones de seguridad y muchos otros sistemas. Un atacante con acceso de administrador a ServiceNow no solo controla esa plataforma: obtiene una plataforma de lanzamiento hacia Salesforce, Microsoft 365 y cualquier otro sistema conectado.
El problema no era el modelo de IA
Este incidente refleja un patrón más amplio que está surgiendo en toda la industria: los agentes de IA se están convirtiendo rápidamente en los principales consumidores de API, y las fallas en los controles de acceso están apareciendo como el principal vector de riesgo.
Las causas raíz no fueron vulnerabilidades nuevas y específicas de la IA. Fueron problemas clásicos de seguridad de aplicaciones:
Falla de autenticación: credenciales codificadas de forma rígida — una clase de problema que el análisis estático lleva mucho tiempo abordando
Falla de autorización a nivel de función
Falla de autenticación: vinculación de identidad — una clase de problemas que se puede identificar mediante el modelado de amenazas
Lo que hizo el agente de IA fue amplificar estas fallas. Errores tradicionales que podrían haber permitido un acceso limitado a los datos se convirtieron en vulneraciones de toda la plataforma, porque el agente podía encadenar acciones de forma autónoma: crear cuentas, asignar privilegios y establecer persistencia.
Como ha señalado Gartner, los agentes de IA se están convirtiendo en «actores autónomos» que heredan y, a menudo, superan los permisos de los usuarios a quienes asisten. Cuando esos agentes interactúan con API que tienen brechas de seguridad fundamentales, las fallas menores se convierten en fallas sistémicas.
La perspectiva de Snyk: una estrategia de defensa integral
Este incidente demuestra por qué las plataformas de seguridad de IA necesitan incorporar capacidades fundamentales de seguridad de aplicaciones. Proteger la IA significa proteger el software y las API que controla: desde el diseño, durante la ejecución y considerando el impacto. Tratar estos temas como problemas separados es precisamente lo que da lugar a incidentes como esta vulnerabilidad de Virtual Agent.
Empieza con el modelado de amenazas
El modelado de amenazas que considera a los agentes ayuda a los equipos a definir límites de seguridad antes de escribir el código. En el caso de la vulnerabilidad de ServiceNow, un modelo de amenazas adecuado habría señalado:
El riesgo de compartir credenciales entre instancias de distintos clientes
La falta de aplicación de MFA/SSO para las afirmaciones de identidad de la API
El alcance del impacto de un agente con capacidades ilimitadas para crear datos
El enfoque de Snyk para el modelado de amenazas en aplicaciones nativas de IA pone énfasis en definir «qué pueden hacer los agentes, a qué pueden acceder y hasta dónde pueden propagarse sus acciones» antes de la implementación.
Implementa DAST para detectar vulnerabilidades tradicionales
Las dos primeras causas raíz de esta vulnerabilidad de Virtual Agent —las fallas de autenticación y autorización— son problemas clásicos de seguridad web. SAST podría detectar el secreto codificado de forma rígida. DAST podría detectar un problema criptográfico. La vulnerabilidad principal es BFLA, que solo podía activarse al encadenarse con las dos primeras (el secreto codificado de forma rígida y la vinculación de identidad).
Esto resalta la necesidad de realizar pruebas de seguridad de API, especialmente en aplicaciones de agente a agente (A2A).
Las herramientas DAST tradicionales suelen tener dificultades con las pruebas de autorización porque la lógica de autenticación depende del contexto. El enfoque de Snyk usa LLM para comprender la semántica de las API e identificar «fallas de autorización complejas y que antes eran difíciles de detectar», que las reglas estáticas no detectan.
Agrega red teaming de IA para descubrir el impacto
Aquí es donde entran en juego los controles de seguridad específicos para la IA. Mientras DAST detecta las vulnerabilidades de origen, el red teaming de IA revela las rutas de impacto catastrófico que surgen cuando fallan los controles tradicionales y hay agentes de IA en el flujo.
AI Red Teaming de Snyk realiza pruebas ofensivas continuas para aplicaciones nativas de IA. DAST encuentra la falla. El red teaming de IA muestra en qué se convierte esa falla cuando un agente autónomo puede aprovecharla.
En una aplicación como Virtual Agent de ServiceNow, el red teaming de IA investigaría hasta dónde podría llegar un usuario suplantado: comprobaría si se podría engañar al agente para escalar privilegios, exfiltrar datos o moverse lateralmente a sistemas conectados.
El red teaming de IA no reemplaza los controles tradicionales de AppSec. Revela cómo los agentes de IA convierten errores comunes en vulneraciones de toda la plataforma.
Por qué la IA agéntica necesita controles de seguridad por capas
La lección de esta vulnerabilidad de Virtual Agent es clara: proteger la IA agéntica requiere controles por capas que aborden tanto las vulnerabilidades tradicionales como los riesgos específicos de la IA.
Capa de control | Qué detecta | Ejemplo de ServiceNow |
|---|---|---|
Modelado de amenazas | Defectos de diseño, permisos excesivos | Habría señalado de antemano las capacidades ilimitadas del agente |
SAST | Secretos codificados de forma rígida, vulnerabilidades de código | Habría detectado |
DAST/seguridad de API | Omisión de autenticación, BOLA, inyección | Habría detectado la falta de MFA y las brechas en la verificación de identidad |
Red teaming de IA | Amplificación del impacto, cadenas de escalada de privilegios | Habría revelado la ruta para tomar el control total de la plataforma |
Este es el núcleo de la seguridad agéntica: integrar la seguridad directamente en el ciclo de vida del desarrollo de IA, en lugar de tratarla como algo secundario.
Qué deben hacer las organizaciones ahora
Si estás implementando agentes de IA —o tus proveedores lo hacen en tu nombre—, estas son algunas medidas inmediatas que puedes considerar:
1. Audita los permisos de los agentes
Como señaló Aaron Costello, investigador de AppOmni: «Las organizaciones deben asegurarse de que los agentes de IA no puedan realizar acciones poderosas, como crear datos en cualquier lugar de una plataforma. El alcance de lo que pueden hacer los agentes de IA debe ser muy limitado».
Aplica rigurosamente el principio de mínimo privilegio. Si un agente no necesita capacidades de administrador, no debe tenerlas.
2. Exige una identidad sólida en los límites de las API
Las direcciones de correo electrónico no sirven para autenticar. Toda API que acepte solicitudes de agentes de IA debe exigir:
Autenticación sólida (OAuth 2.0, claves de API con rotación)
Validación de MFA o SSO para operaciones sensibles
Límites de frecuencia y detección de anomalías
3. Implementa pruebas continuas
Las evaluaciones de seguridad estáticas suelen quedarse atrás ante el rápido crecimiento de las implementaciones de IA. Las organizaciones necesitan:
DAST automatizado en los pipelines de CI/CD
Red teaming de IA continuo para sistemas en producción
Actualizaciones periódicas del modelo de amenazas a medida que evolucionan las capacidades de los agentes
4. Revisa las implementaciones de agentes de IA como si fueran código
Como dijo Costello: «Antes de que el código se integre en un producto, se revisa. Deberíamos aplicar el mismo criterio a los agentes de IA».
Establece flujos de aprobación para:
Nuevas implementaciones de agentes de IA
Cambios en los permisos o las capacidades de los agentes
Integraciones con sistemas sensibles
Qué nos espera
La vulnerabilidad de Virtual Agent es un anticipo del panorama de seguridad de IA que se avecina. A medida que las organizaciones se apresuran a implementar IA agéntica, la superficie de ataque se amplía de formas para las que las herramientas de seguridad tradicionales no fueron diseñadas.
Pero la solución no es abandonar AppSec tradicional, sino agregar controles específicos para la IA sobre una base sólida. El modelado de amenazas identifica los riesgos antes de escribir el código. DAST detecta vulnerabilidades durante la ejecución. El red teaming de IA revela rutas de impacto que solo surgen cuando intervienen agentes autónomos.
ServiceNow actuó rápidamente para resolver los problemas inmediatos: rotó las credenciales y deshabilitó el agente problemático en la semana posterior a la divulgación. Pero la lección para toda la industria sigue vigente: proteger la IA agéntica empieza por saber qué pueden hacer los agentes, a qué pueden acceder y hasta dónde pueden propagarse sus acciones.
La pregunta no es si tu organización implementará agentes de IA. La pregunta es si los protegerás antes de que una vulnerabilidad similar ocupe los titulares.
Recursos relacionados de Snyk
El nuevo panorama de amenazas: aplicaciones nativas de IA y flujos de trabajo agénticos — Cómo las aplicaciones nativas de IA y los flujos de trabajo agénticos amplían la superficie de ataque
Snyk abre el camino al futuro de DAST: seguridad impulsada por IA para la era de la IA — Presentamos Snyk API & Web con detección de BOLA impulsada por IA
Cómo AI Red Teaming de Snyk incorpora pruebas ofensivas continuas a los sistemas de IA — Un análisis profundo de las pruebas adversariales automatizadas para aplicaciones nativas de IA
Presentamos Evo by Snyk: el primer sistema de orquestación de seguridad agéntica del mundo — Cómo Evo combina el modelado de amenazas, el red teaming y la aplicación de políticas
El ciclo OODA agéntico: cómo la IA y las personas aprenden a defenderse en conjunto — Cómo crear flujos de trabajo colaborativos de seguridad entre personas e IA
Recursos en video

Manoj Nair, Snyk | The AI Security Summit 2025 — El CEO de Snyk explica los fundamentos de Evo y cómo proteger aplicaciones impulsadas por LLM

Liran Tal: cómo proteger tus aplicaciones y agentes de IA — Un análisis profundo de la evolución de las prácticas de seguridad para aplicaciones nativas de IA
¡Compite en Fetch the Flag 2026!
Pon a prueba tus habilidades, resuelve los desafíos y domina la tabla de posiciones. Acompáñanos desde las 12 p. m. ET del 12 de febrero hasta las 12 p. m. ET del 13 de febrero en el evento CTF definitivo.
