Cómo los agentes de IA siguen poniendo en riesgo la seguridad aunque nada esté roto

Los agentes de IA están pasando rápidamente de la fase experimental a producción. Clasifican alertas, revisan pull requests, resumen registros, asignan tickets y actúan en distintos sistemas con credenciales reales.

Desde una perspectiva de seguridad, muchos de estos sistemas parecen limpios. No tienen código vulnerable a problemas de memoria. No presentan fallas de inyección evidentes. No tienen problemas de autenticación. Y, aun así, pueden fallar, a veces de forma catastrófica, simplemente por seguir una sola oración.

Esta brecha no se debe a parches faltantes ni a dependencias sin analizar, sino a cómo los sistemas no deterministas, como los LLM, cambian el significado de los límites de confianza.

Una investigación reciente de Snyk Labs explora por qué los modelos tradicionales de AppSec tienen dificultades para razonar sobre el comportamiento de los agentes y por qué el modelado de amenazas se perfila como una de las defensas más eficaces para las aplicaciones nativas de IA.

La seguridad determinista no se adapta bien a los sistemas agénticos

La seguridad tradicional de las aplicaciones se basa en comportamientos predecibles. Las entradas se consideran datos, el código restringe las instrucciones y los controles establecen límites claros. Sin embargo, los agentes de IA funcionan de otra manera. Interpretan significados, razonan según el contexto y deciden cuándo actuar. Esto crea una nueva clase de riesgo en la que el sistema se comporta exactamente según lo diseñado, pero el resultado sigue siendo perjudicial.

Por ejemplo:

• Un agente de IA lee texto no confiable de un problema, correo electrónico o documento.

• Ese texto cambia sutilmente la forma en que el agente interpreta su tarea.

• El agente usa herramientas y permisos legítimos para realizar una acción.

• Los datos confidenciales terminan donde nunca deberían haber estado.

Desde la perspectiva de un escáner de seguridad, nada está «roto» y, desde la perspectiva de un atacante, todo salió según lo previsto. Por eso la inyección de prompts ocupa el primer lugar en el OWASP Top 10 para LLM, y por eso el análisis estático por sí solo no puede detectar estos fallos.

El verdadero riesgo de los sistemas agénticos es conductual, no técnico

Uno de los cambios más importantes que destaca la investigación es dónde ocurren los fallos. Los sistemas agénticos suelen fallar en la capa de comportamiento, no en la de código. Los equipos de seguridad se ven cada vez más obligados a plantearse preguntas como:

• ¿Esta entrada funciona como contexto o como instrucción?

• ¿Se debería permitir que este agente actúe en función de lo que acaba de leer?

• ¿Qué ocurre si otro agente recibe este resultado como entrada?

Estas son decisiones semánticas y, por naturaleza, son probabilísticas. Ni siquiera las barreras de protección bien diseñadas pueden garantizar resultados perfectos a gran escala. Aquí es donde muchas herramientas actuales dejan de ser eficaces, no porque estén mal construidas, sino porque nunca se diseñaron para razonar sobre la intención, la autonomía y el flujo de información.

Los incidentes recientes de la industria dejan este cambio muy claro.

A principios de 2025, investigadores revelaron fallos en implementaciones empresariales de agentes en ServiceNow y Salesforce, donde no había ninguna vulnerabilidad tradicional.

En el caso de ServiceNow, un agente interno procesó correctamente una solicitud que parecía provenir de un proveedor confiable. Sin embargo, como la identidad se trató como metadatos proporcionados por el usuario en lugar de como una afirmación verificada, el agente creó una sesión con privilegios elevados en nombre de un atacante: un caso clásico de diputado confundido, provocado por completo por la lógica del agente.

En Salesforce, el contenido de un campo de un formulario público pasó sin modificaciones a la ventana de contexto de un agente interno «resumidor». Esto permitió que una entrada no confiable alterara la intención del agente y convirtiera un flujo de trabajo rutinario en una vía para exfiltrar datos. En ambos casos, los análisis de código no detectaron problemas, los permisos eran técnicamente válidos y los sistemas se comportaron según lo diseñado. El fallo ocurrió en la capa de comportamiento, donde los agentes dedujeron significados, autoridad e intención a partir de un contexto que las herramientas de seguridad trataban como datos inertes.

Por qué la composición importa más que los agentes individuales

Muchos de los fallos más graves en los sistemas agénticos no se originan en un solo agente. Surgen cuando se combinan agentes en flujos de trabajo, pipelines o sistemas orquestados. Por separado, cada agente puede parecer bien diseñado: los permisos están delimitados, se aplican las políticas y los comportamientos coinciden con las expectativas. Las revisiones de seguridad se aprueban porque nada parece claramente inseguro de forma aislada.

El riesgo aparece en las conexiones. Cuando el resultado de un agente se convierte en la entrada de otro, se crean nuevas rutas de datos, a menudo sin verificaciones explícitas de sensibilidad, intención o destino. La información puede cruzar límites de confianza simplemente porque el sistema supone que los agentes posteriores «harán lo correcto». Esto refleja patrones de seguridad conocidos, como los diputados confundidos y las brechas entre la verificación y el uso, pero con una diferencia importante: en los sistemas agénticos, estos fallos pueden activarse dinámicamente mediante el razonamiento del modelo, en lugar de por una lógica fija.

A medida que los flujos de trabajo agénticos se vuelven más complejos, el riesgo pasa a ser una propiedad emergente del sistema, en lugar de un defecto en un componente individual. Por eso, la composición, y no los agentes por separado, debe ser la unidad principal del análisis de seguridad.

El modelado de amenazas da herramientas de acción a los equipos de seguridad

Las herramientas de seguridad tradicionales tienen dificultades para razonar sobre el comportamiento agéntico porque no hay nada técnicamente roto. El modelado de amenazas vuelve a aportar estructura al centrar la atención en el comportamiento del sistema en lugar de la corrección del código. En vez de preguntarse si una función es vulnerable, los equipos analizan cómo fluyen los datos, la autoridad y las decisiones a través de un sistema agéntico.

Este enfoque plantea preguntas que los escáneres no pueden responder. ¿Dónde entra la información no confiable al flujo de trabajo? ¿Qué agentes pueden leer datos confidenciales? ¿Qué acciones cambian el estado externo? ¿Cómo limitan o habilitan las decisiones tomadas antes las acciones posteriores del flujo de trabajo?

Al mapear estas relaciones, el modelado de amenazas revela rutas de fallo que solo surgen cuando interactúan los componentes y que permanecen ocultas al revisar los agentes de forma aislada. Para los equipos de seguridad que trabajan con sistemas no deterministas, esto representa una ventaja fundamental. El modelado de amenazas no intenta predecir todos los resultados. En cambio, ayuda a los equipos a entender dónde podrían ocurrir fallos y a diseñar controles que limiten su impacto cuando sucedan.

De la prevención a la contención

Los sistemas agénticos obligan a replantearse qué significa «seguro». Cuando el comportamiento es probabilístico, rara vez es posible reducir a cero la probabilidad de que ocurra algo. Incluso las medidas de protección más sólidas dejan margen para fallos y, a gran escala, las probabilidades pequeñas se convierten en realidades operativas. En este entorno, las estrategias de seguridad que se basan únicamente en la prevención no son suficientes.

La contención es tan importante como la detección. El objetivo pasa a ser limitar a qué puede acceder cada agente, qué combinaciones de capacidades son posibles y hasta dónde pueden llegar los datos confidenciales. En lugar de asumir que los límites siempre se mantendrán, los sistemas se diseñan para seguir siendo seguros cuando no sea así. Esta mentalidad prioriza la reducción del alcance del impacto, la separación de capacidades y los controles explícitos sobre el flujo de datos.

El modelado de amenazas facilita esta transición al ayudar a los equipos a identificar dónde es más importante la contención. Proporciona un marco para diseñar sistemas resilientes que sigan protegiendo a los usuarios y sus datos incluso cuando los modelos se comporten de maneras inesperadas.

Por qué la seguridad de la IA agéntica empieza con el modelado de amenazas

Los agentes de IA están cambiando el comportamiento del software y, con ello, la forma en que ocurren los fallos de seguridad. Los riesgos más importantes ya no se encuentran en vulnerabilidades aisladas ni en configuraciones incorrectas, sino en cómo los sistemas autónomos interpretan el contexto, combinan capacidades y actúan a través de límites de confianza. Para proteger estos sistemas, hay que dejar atrás los supuestos deterministas y adoptar enfoques que tengan en cuenta el comportamiento, la interacción y el impacto.

El modelado de amenazas ofrece una forma práctica de avanzar. Al considerar el comportamiento de los agentes y la composición del sistema como preocupaciones fundamentales de seguridad, los equipos obtienen la claridad necesaria para diseñar controles que se adapten al desarrollo impulsado por IA. A medida que los sistemas agénticos se vuelvan esenciales para las aplicaciones modernas, este cambio definirá cómo las organizaciones construyen una seguridad capaz de mantenerse al ritmo de lo que viene.

¿Te interesa profundizar y leer la investigación completa? Adéntrate hoy en el laboratorio.

O, si ya eres cliente de Snyk y te interesa esta investigación, solicita unirte al Programa de socios de diseño de Evo para obtener una vista previa de nuestra solución Secure Agent Design (modelado de amenazas de IA).