Vulnerabilidades de LLM: el OWASP Top 10 y cómo priorizar

Una vulnerabilidad de LLM es cualquier debilidad de una aplicación basada en un gran modelo de lenguaje que un atacante puede explotar para hacer que el modelo filtre datos, ejecute acciones no previstas o produzca salidas dañinas. En ciberseguridad, «LLM» se refiere a los modelos de IA (como GPT-4, Claude o Llama) cada vez más integrados en productos, y a la nueva superficie de ataque que crean. La referencia autorizada es el OWASP Top 10 for LLM Applications, que cataloga los diez riesgos frente a los que más necesitan defenderse los equipos de seguridad. El mayor problema es que los LLM difuminan la línea entre datos e instrucciones, lo que hace que la manipulación de entradas (inyección de prompts) sea difícil de prevenir por completo.

Qué significa realmente «vulnerabilidad de LLM»

El software tradicional separa el código de los datos. Los LLM no. Cada fragmento de texto que lee un modelo (un mensaje del usuario, un documento recuperado, una página web que resume) se procesa igual, así que un texto malicioso escondido en los «datos» puede secuestrar el comportamiento del modelo. Esa única propiedad está detrás de la mayoría de las vulnerabilidades de LLM de cualquier lista creíble.

Esto difiere de la seguridad de aplicaciones clásica en tres aspectos que conviene nombrar:

• No determinismo: la misma entrada puede producir salidas distintas, así que las defensas basadas en firmas y las pruebas de regresión no son fiables.
• Fronteras de decisión opacas: no puedes leer la «lógica» del modelo como lees el código fuente, así que no puedes auditar del todo por qué hizo algo.
• Exposición en el entrenamiento: los datos usados para entrenar o ajustar un modelo pasan a formar parte del modelo y pueden filtrarse después.

El OWASP Top 10 for LLM Applications

OWASP publica la lista de referencia de vulnerabilidades de LLM (disponible en GitHub y en el sitio de OWASP). La versión v1.1 nombra estos diez riesgos:

• LLM01 – Prompt Injection: una entrada elaborada anula el prompt de sistema o el comportamiento previsto. Incluye la inyección indirecta mediante documentos o contenido web envenenados.
• LLM02 – Insecure Output Handling: pasar la salida del modelo a sistemas posteriores (shells, navegadores, SQL) sin validarla, lo que permite XSS, SSRF o RCE.
• LLM03 – Training Data Poisoning: manipular los datos de entrenamiento o de fine-tuning para introducir puertas traseras o sesgos.
• LLM04 – Model Denial of Service: consultas costosas que agotan las ventanas de contexto, el cómputo o el presupuesto.
• LLM05 – Supply Chain Vulnerabilities: modelos, datasets o plugins de terceros comprometidos.
• LLM06 – Sensitive Information Disclosure: según el OWASP Top 10 for LLM Applications v1.1, los LLM pueden memorizar y reproducir datos de entrenamiento, incluida PII, credenciales y código propietario.
• LLM07 – Insecure Plugin Design: plugins con una validación de entradas débil o un acceso excesivo.
• LLM08 – Excessive Agency: dar al modelo demasiada autonomía, permisos o funcionalidad en relación con lo que necesita.
• LLM09 – Overreliance: confiar en la salida del modelo sin verificarla, propagando alucinaciones a decisiones o código.
• LLM10 – Model Theft: acceso no autorizado a los pesos propietarios del modelo o extracción de los mismos.

Cómo priorizar: qué arreglar primero

No arreglas las diez a la vez. Prioriza por explotabilidad y radio de impacto:

• Arregla primero Insecure Output Handling (LLM02) y Excessive Agency (LLM08). Son las que convierten una inyección de prompts en daños reales. Si el modelo no puede lanzar un comando de shell, borrar un registro o enviar un correo sin una comprobación humana, una inyección con éxito queda contenida. Trata cada salida del modelo como una entrada de usuario no fiable: sanéala, codifícala y condiciona las acciones de alto impacto a una confirmación.
• Arregla después Sensitive Information Disclosure (LLM06). Acota a qué puede acceder el modelo. No hagas fine-tuning con secretos, elimina la PII de las fuentes de entrenamiento y RAG, y aplica filtrado de salidas. Como los modelos memorizan los datos de entrenamiento, el control más barato es no darles nunca datos que no deberían poder repetir.
• Mitiga, no «resuelvas»: Prompt Injection (LLM01). No hay una solución completa. Superpón defensas: separa el contexto de sistema y el de usuario, usa listas de permitidos para las llamadas a herramientas y limita el modelo con mínimo privilegio en lugar de intentar bloquear cada frase maliciosa.

Ejemplo práctico: un chatbot de soporte con una herramienta de «consultar pedido del cliente». La combinación peligrosa es LLM01 + LLM08 + LLM06: una instrucción inyectada convence al modelo de llamar a la herramienta de consulta con el ID de otro cliente y leer su dirección. La solución no es un prompt mejor; es imponer en la capa de aplicación que la herramienta solo acepte el ID del propio usuario autenticado, para que el modelo literalmente no pueda consultar los datos de otra persona.

Construir un modelo de amenazas de LLM sobre el que tu equipo pueda actuar

Asocia cada función LLM al Top 10 y asigna un responsable de control. Para cada punto de contacto con el modelo, pregúntate: ¿qué puede leer, qué puede hacer y quién verifica su salida?

Preguntas frecuentes

¿Qué significa «vulnerabilidad de LLM»?

El software tradicional separa el código de los datos. Los LLM no. Cada fragmento de texto que lee un modelo (un mensaje del usuario, un documento recuperado, una página web que resume) se procesa igual, así que un texto malicioso escondido en los «datos» puede secuestrar el comportamiento del modelo.

¿Qué es el OWASP Top 10 for LLM Applications?

OWASP publica la lista de referencia de vulnerabilidades de LLM (disponible en GitHub y en el sitio de OWASP). La versión v1.1 nombra estos diez riesgos: LLM01 – Prompt Injection: una entrada elaborada anula el prompt de sistema o el comportamiento previsto.

¿Cómo se priorizan las vulnerabilidades de LLM?

No arreglas las diez a la vez. Prioriza por explotabilidad y radio de impacto: Arregla primero Insecure Output Handling (LLM02) y Excessive Agency (LLM08). Son las que convierten una inyección de prompts en daños reales. Si el modelo no puede lanzar un comando de shell, borrar un registro o enviar un correo sin una comprobación humana, una inyección con éxito queda contenida.

¿Cómo se construye un modelo de amenazas de LLM sobre el que tu equipo pueda actuar?

Asocia cada función LLM al Top 10 y asigna un responsable de control. Para cada punto de contacto con el modelo, pregúntate: ¿qué puede leer, qué puede hacer y quién verifica su salida?