Seguridad en LLMs (OWASP LLM Top 10)

Integrar un modelo de lenguaje (LLM) en una aplicación añade una superficie de ataque nueva: la entrada es lenguaje natural no estructurado, el modelo tiene acceso a datos y herramientas, y las instrucciones y los datos se mezclan en el mismo canal. El OWASP LLM Top 10 cataloga los riesgos clave.

Por qué los LLM son distintos

- la frontera instrucción/dato se DIFUMINA: el prompt y el contenido externo comparten canal
- salida no determinista y difícil de validar; el modelo "quiere" obedecer
- a menudo con acceso a herramientas/datos (RAG, plugins, agentes) -> impacto real
- confianza excesiva del usuario en la salida ("lo dijo la IA")

OWASP Top 10 for LLM Applications (resumen)

LLM01 Prompt injection      inyectar instrucciones (directa/indirecta) -> ver ai-prompt
LLM02 Insecure output handling  confiar en la salida sin validar -> XSS/SSRF/RCE aguas abajo
LLM03 Training data poisoning   envenenar los datos de entrenamiento -> ver ai-poisoning
LLM04 Model DoS             entradas que disparan coste/recursos
LLM05 Supply chain          modelos/datasets/plugins de terceros comprometidos
LLM06 Sensitive info disclosure  fuga de datos del prompt/entrenamiento
LLM07 Insecure plugin design  plugins con exceso de permisos/sin validación
LLM08 Excessive agency      el agente puede hacer DEMASIADO (permisos/autonomía)
LLM09 Overreliance          confiar ciegamente en salidas erróneas/alucinadas
LLM10 Model theft           robo del modelo/pesos

Riesgos de aplicaciones con LLM (RAG, agentes)

RAG         contenido recuperado no confiable -> prompt injection INDIRECTA (ai-prompt)
Agentes     el LLM llama a herramientas/APIs -> "excessive agency": limitar qué puede hacer
Plugins     tratar la salida del LLM como entrada no confiable a sistemas (LLM02)
Datos       no meter secretos en el prompt de sistema esperando que "no los revele"

Controles clave

- tratar TODA salida del LLM como entrada no confiable (validar/encodear aguas abajo)
- mínimo privilegio para herramientas/plugins; human-in-the-loop para acciones sensibles
- separar instrucciones de datos cuando sea posible; defensas contra injection (ai-prompt)
- límites de tasa/coste (DoS); no exponer datos sensibles en el contexto

Blue Team / AppSec

Aplicar el OWASP LLM Top 10 como checklist de diseño; tratar la salida como no confiable (LLM02).
Mínimo privilegio y menos agencia en agentes/plugins; aprobación humana para acciones con impacto.
Defensas contra prompt injection (Prompt injection), especialmente la indirecta en RAG.
Red teaming específico de IA (Red teaming de IA) y monitorización de entradas/salidas; gobernanza del modelo (grc).

Casos reales

Múltiples apps con LLM vulnerables a prompt injection indirecta vía contenido web/documentos en RAG.
Fugas de prompts de sistema y datos por salidas no filtradas (LLM06).
Agentes con excessive agency que ejecutaron acciones no deseadas por instrucciones inyectadas.

Checklist de prueba

Revisar contra OWASP LLM Top 10
Tratar la salida del LLM como entrada no confiable (validar aguas abajo)
Probar prompt injection directa e indirecta (Prompt injection)
Mínimo privilegio en herramientas/plugins; aprobación humana en acciones sensibles
Verificar que no hay secretos en el contexto/prompt de sistema
Límites de tasa/coste (DoS) y monitorización
Red teaming de IA (Red teaming de IA) y gobernanza del modelo