El proyecto nació en 2023 como una iniciativa comunitaria para dar visibilidad a los riesgos específicos de seguridad en aplicaciones basadas en LLM. La edición 2025, publicada en marzo de ese mismo año, amplía y refina ese trabajo inicial con nuevas categorías y un enfoque mucho más alineado con los casos de uso actuales: asistentes corporativos, copilots, agentes, arquitecturas RAG y automatizaciones conectadas a terceros.
La utilidad del Top 10 es doble. Por un lado, ofrece a equipos técnicos una taxonomía clara para modelar amenazas, priorizar controles y diseñar pruebas de seguridad. Por otro, permite a responsables de negocio y de riesgo entender que una aplicación con IA no introduce un único problema nuevo, sino una combinación de amenazas clásicas y amenazas emergentes que se potencian entre sí.
OWASP destaca varios cambios de fondo en la edición 2025. El primero es la evolución de la antigua lógica de denegación de servicio hacia una categoría más amplia: consumo ilimitado. En entornos LLM, una mala gestión del contexto, de los tokens, de las llamadas a herramientas o del acceso al modelo no solo afecta a la disponibilidad; también puede disparar costes y degradar el servicio de forma silenciosa.
El segundo gran cambio es la incorporación explícita de debilidades de vector y representaciones vectoriales, una respuesta directa al auge de arquitecturas RAG. Cuando la seguridad de una aplicación depende de cómo genera, almacena y recupera embeddings, la base vectorial deja de ser un componente neutro y pasa a ser un activo crítico.
El tercer cambio importante es la entrada sobre filtración de prompts de sistema. Muchas aplicaciones asumían que estas instrucciones internas eran opacas para el usuario. OWASP deja claro que esa suposición no es segura. Si el prompt de sistema puede revelarse, también puede exponer lógica interna, credenciales, restricciones de seguridad y detalles operativos que faciliten nuevos ataques.
Por último, la categoría de agencia excesiva gana peso por el uso creciente de agentes y plugins. Cuando el modelo dispone de autonomía para actuar sobre otros sistemas, cualquier fallo de control deja de ser un simple error de respuesta y se convierte en una acción insegura con impacto operativo.
| ID | Riesgo |
| LLM01 | Inyección de prompt |
| LLM02 | Divulgación de información sensible |
| LLM03 | Cadena de suministro |
| LLM04 | Envenenamiento de datos y modelo |
| LLM05 | Manejo inadecuado de la salida |
| LLM06 | Agencia excesiva |
| LLM07 | Filtración de prompts de sistema |
| LLM08 | Debilidades de vector y representaciones vectoriales |
| LLM09 | Desinformación |
| LLM10 | Consumo ilimitado |
1. Inyección de prompt
La inyección de prompt sigue ocupando el primer lugar por una razón sencilla: el contenido externo no es solo contexto, también puede ser un vector de ataque. Un correo, una página web, un PDF, un ticket o un documento en una base RAG pueden incluir instrucciones ocultas capaces de alterar el comportamiento del modelo. La amenaza ya no reside únicamente en lo que un usuario escribe de forma directa, sino en cualquier fuente que el modelo procese e interprete.
| Objetivos ➡️ Toda entrada de usuarios se trata como no confiable. ➡️ Utilice validación estricta de entradas, separación de privilegios entre el modelo y los sistemas backend, y revisión humana para operaciones sensibles. ➡️ No permita que el contenido generado por LLMs active directamente acciones privilegiadas sin verificación. |
2. Divulgación de información sensible
La divulgación de información sensible recuerda que una aplicación con IA puede filtrar secretos sin necesidad de una intrusión clásica. Basta con entrenar mal, orquestar mal, recuperar mal o conceder acceso de más. Cuando un LLM se conecta a repositorios, bases documentales, CRM, tickets o código fuente, la superficie de exposición crece de forma inmediata.
| Objetivos ➡️ Exponga sólo los datos que un LLM realmente necesita. ➡️ Aplique filtrado de salidas para detectar y ocultar patrones sensibles antes de que las respuestas lleguen al usuario. ➡️ Audite periódicamente los flujos de datos de entrenamiento y recuperación. |
3. Cadena de suministro
En entornos de IA, la cadena de suministro incluye dependencias, datasets, modelos base, adaptadores LoRA, repositorios de terceros, procesos de conversión y condiciones de uso del proveedor.
| Objetivos ➡️ Analice detenidamente todos los modelos, plugins y fuentes de datos de terceros. ➡️ Prefiera modelos de proveedores de buena reputación con prácticas de seguridad documentadas. |
4. Envenenamiento de datos y modelo
Casos como PoisonGPT, los ataques sobre conversiones de modelos o el abuso de componentes externos demuestran que el problema puede estar en cualquier punto del pipeline.
| Objetivos ➡️ Valide cuidadosamente todos los datos de entrenamiento. ➡️ Utilice detección de anomalías durante el entrenamiento. ➡️ Prefiera el ajuste fino sobre el reentrenamiento completo siempre que sea posible, y monitorice las salidas del modelo en producción. |
5. Manejo inadecuado de la salida
En paralelo, el manejo inadecuado de la salida recuerda que nunca debe encadenarse ciegamente la respuesta de un LLM con otra acción automática sin validación determinista.
| Objetivos ➡️ Utilice consultas parametrizadas para interacciones con bases de datos, entornos de ejecución de código en sandbox e implemente validación estricta de salidas. |
6. Agencia excesiva
OWASP llama agencia excesiva a uno de los problemas más importantes del momento. El riesgo no es sólo que el modelo se equivoque; el verdadero problema es que ese error tenga permiso para crear, borrar, enviar, aprobar, comprar o modificar algo.
| Objetivos ➡️ Aplique el principio de mínimo privilegio de forma rigurosa. ➡️ Otorgue a los agentes LLM sólo los permisos mínimos necesarios para cada tarea específica. ➡️ Implemente puertas de aprobación humana para acciones de alto impacto. |
7. Filtración del Prompt de Sistema
Los prompts de sistema incluyen información sobre propiedad intelectual, configuraciones de seguridad, definiciones de personalidad e instrucciones operativas que los desarrolladores consideran confidenciales. Los atacantes a menudo pueden extraer el contenido parcial o completo del prompt de sistema.
| Objetivos ➡️ Utilice controles de acceso robustos, evite incrustar credenciales o lógica empresarial sensible en los prompts y monitorice los intentos de extracción. |
8. Debilidades en Vectores y Embeddings
Las debilidades en cómo se generan, almacenan o recuperan los embeddings pueden permitir a los atacantes manipular los resultados de recuperación, inyectar contenido malicioso en la base de conocimiento o explotar algoritmos de búsqueda por similitud para extraer documentos almacenados sensibles.
| Objetivos ➡️ Valide todo el contenido antes de que ingrese a la base de conocimiento. ➡️ Implemente filtrado de consultas para prevenir la recuperación no autorizada de documentos y monitorice los patrones de búsqueda vectorial en busca de indicios extraños. |
9 y 10. Desinformación y Consumo Ilimitado de Recursos
La desinformación y el consumo ilimitado introducen una idea importante: una aplicación con IA también puede generar daño cuando responde con falsedades convincentes o cuando consume recursos sin control. Eso afecta a reputación, operación, toma de decisiones y coste. En muchos entornos corporativos, una salida errónea o una arquitectura ineficiente pueden ser tan dañinas como una vulnerabilidad técnica tradicional.
| Objetivos ➡️ Implemente las respuestas del modelo basándose en fuentes de datos verificadas y autorizadas. ➡️ Muestre indicadores de confianza claros y citas de fuentes. ➡️ Implemente revisión humana para decisiones críticas y eduque a los usuarios sobre las limitaciones del contenido generado por IA. |
Aplique límites por usuario y límites máximos de tokens de salida. Monitorice los patrones de uso inusuales e implemente disyuntores para detener procesos descontrolados.
Antes de desplegar un asistente, un copilot o un agente conectado a sistemas internos, conviene revisar al menos seis aspectos. Primero, separar con claridad el contenido confiable del no confiable y etiquetar las fuentes externas. Segundo, limitar privilegios y accesos siguiendo el principio de mínimo privilegio. Tercero, introducir validaciones deterministas sobre las salidas del modelo antes de usarlas en otros componentes. Cuarto, exigir aprobación humana en acciones sensibles. Quinto, auditar la cadena de suministro de modelos, datasets, librerías y proveedores. Y sexto, monitorizar consumo, costes, uso de contexto y llamadas a herramientas para detectar abuso o descontrol operativo.
En otras palabras: menos fascinación por la demo y más disciplina de arquitectura, gobierno y seguridad. El OWASP Top 10 para LLM no es una lista para memorizar; es una guía para hacerse las preguntas correctas antes de poner una IA a leer, decidir o actuar dentro del negocio.
▪️Separar contenido confiable y no confiable en prompts y flujos RAG.
▪️Aplicar mínimo privilegio a herramientas, conectores, APIs y agentes.
▪️Validar de forma determinista la salida del modelo antes de reutilizarla.
▪️Mantener aprobación humana en acciones críticas o irreversibles.
▪️Auditar proveedores, modelos, datasets y dependencias de la cadena de suministro.
▪️ Controlar consumo, costes, contexto, cuotas y llamadas a herramientas.
Referencias
OWASP GenAI Security Project - LLM Top 10
OWASP Top 10 para Aplicaciones de LLM - Versión 2025 (traducción al español)
|
José Antonio Linio
OSCP |
|
Ismael de Frutos
CRTP |