Skip to main content

La vulnerabilidad de Virtual Agent de ServiceNow demuestra por qué la seguridad de la IA necesita los fundamentos tradicionales de AppSec

Escrito por

14 de enero de 2026

0 minutos de lectura

La 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:

  1. 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.

  2. 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.

  3. Privilegios excesivos del agente: Record Management AI Agent podí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 servicenowexternalagent en el código fuente

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

Recursos en video

Manoj Nair, Snyk | The AI Security Summit 2025

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: How to Secure your Apps and AI Agents

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.