OWASP Top 10 para Aplicaciones LLM

Definición

El OWASP Top 10 para aplicaciones LLM es una lista mantenida por la comunidad con las clases de vulnerabilidad más críticas en aplicaciones construidas sobre grandes modelos de lenguaje, publicada por el OWASP GenAI Security Project y revisada periódicamente conforme cambia el ecosistema.

Alcance

Cualquier aplicación construida sobre un gran modelo de lenguaje: interfaces de chat, sistemas de recuperación, agentes y las herramientas que invocan. Es voluntaria, no certificable y deliberadamente descriptiva: clasifica riesgos, no prescribe controles ni otorga conformidad.

Requisitos clave

• La inyección de prompts encabeza la lista desde la primera edición y sigue siendo la clase sin solución limpia: solo contención por capas.
• La edición de 2025 cubre inyección de prompts, divulgación de información sensible, cadena de suministro, envenenamiento de datos y modelo, tratamiento indebido de la salida, exceso de agencia, filtración del system prompt, debilidades de vectores y embeddings, desinformación y consumo sin límite. La lista se revisa periódicamente, así que consulta la edición vigente y no una copia en caché.
• Varias entradas son en la práctica específicas de agentes: el exceso de agencia y el tratamiento indebido de la salida solo se vuelven graves cuando el modelo puede actuar.
• Es una taxonomía, no un conjunto de controles. Mapear un hallazgo a LLM06 te dice de qué tipo de problema se trata, no qué construir.
• Es la lengua franca del campo: revisiones de seguridad, cuestionarios de proveedores y reportes de fallos la citan, y esa es buena parte del motivo para conocerla por número.
• Cubrir la lista no es una postura de seguridad. Cada entrada necesita un control en tu arquitectura, y una entrada sin control es un riesgo aceptado lo haya escrito alguien o no.

Controles

Mapea la lista sobre tu propia arquitectura

Recorre cada entrada frente a tus entradas reales, herramientas, almacenes de datos y salidas. El ejercicio vale más que la lista, porque saca a la luz las entradas que no aplican y las superficies que la lista no nombra.

Asigna responsable y control por entrada

Cada clase aplicable necesita un componente concreto que la acote y una persona que lo mantenga. Una entrada mapeada a nada es una brecha con número de referencia.

Trata la inyección de prompts como contención, no como prevención

LLM01 no tiene solución fiable en la capa del modelo. Los controles que importan son herramientas con mínimo privilegio, restricción de salida, tratamiento de la salida y puertas de aprobación para acciones de alto impacto.

Acota la agencia de forma explícita

Para LLM06, escribe qué puede hacer el agente, con qué credenciales y contra qué objetivos, y aplícalo por debajo del modelo en lugar de en el prompt.

Trata la salida del modelo como entrada no confiable

Para LLM05, todo lo que el modelo emita y llegue a un renderizador, un shell, una consulta u otro sistema necesita la misma codificación y validación que aplicarías a la entrada de un desconocido.

Acota el consumo

Para LLM10, los límites de tasa, las cuotas y los timeouts convierten un ataque de disponibilidad y coste en un rechazo registrado. Es la entrada que más se salta la gente porque no parece seguridad hasta que llega la factura.

Rehaz el mapeo cuando cambie la lista o el sistema

La lista se revisa y tu catálogo de herramientas crece. Un mapeo hecho una vez es un documento sobre un sistema que ya no existe.

Lista de verificación

• 01Lee la edición vigente en lugar de un resumen, incluido este.
• 02Produce una tabla de mapeo: entrada → ¿aplica? → control → responsable.
• 03Para cada entrada aplicable sin control, regístrala como riesgo aceptado con motivo y detección compensatoria.
• 04Escribe una prueba por control y ve fallar la prueba antes de confiar en ella.
• 05Revisa las entradas que solo muerden con herramientas: exceso de agencia, tratamiento indebido de la salida, cadena de suministro.
• 06Confirma que existen límites de tasa y cuotas y que devuelven señales correctas a los clientes bien educados.
• 07Rehaz el mapeo siempre que cambie una herramienta, una fuente de datos o un nivel de autonomía.
• 08Usa la numeración de la lista en los hallazgos para que revisores y proveedores hablen de la misma clase.

Errores comunes

• Tratar la lista como objetivo de cumplimiento: cubrir diez titulares mientras la arquitectura real sigue sin examinarse.
• Suponer que el trabajo de seguridad del proveedor del modelo cubre LLM01. Reduce los intentos; las consecuencias siguen siendo enteramente tuyas.
• Mapear contra una edición en caché. La lista se revisa, y un mapeo antiguo deja de cubrir en silencio las clases actuales.
• Saltarse LLM10 porque el consumo sin límite parece un problema de operaciones y no de seguridad.
• Confundir nombrar una clase con controlarla. Una tabla de mapeo impecable sin aplicación es documentación del riesgo, no reducción.

Ejemplos

• Un agente que resume correos de clientes mapea a LLM01 (el cuerpo del correo es entrada de instrucciones no confiable), LLM02 (el resumen puede repetir datos que quien pregunta no debería ver) y LLM06 (la herramienta de CRM convierte el secuestro en acción): tres entradas de una sola funcionalidad, cada una con un control distinto.
• Un sistema RAG sobre una wiki interna mapea a LLM01 por inyección indirecta desde cualquier editor de páginas, a LLM04 si el índice puede envenenarse y a LLM08 por recuperación que devuelve documentos fuera de los permisos de quien pregunta.
• Un endpoint MCP público mapea sobre todo a LLM10: solo lectura y datos públicos, así que el límite de consumo —límites de tasa con cabeceras correctas— es la entrada que hace el trabajo de verdad.

FAQs

¿Se puede ser conforme con el OWASP LLM Top 10?

No. Es un documento de concienciación y clasificación, no una norma certificable. Encaja de forma natural con un sistema de gestión como ISO 42001 o un marco como el NIST AI RMF, que es donde viven de verdad las obligaciones de gobierno.

¿Qué entradas cambian más al dar herramientas al modelo?

El exceso de agencia y el tratamiento indebido de la salida. Sin herramientas producen una respuesta equivocada; con herramientas producen una acción, y la gravedad pasa de bochorno a incidente.

¿Qué relación tiene con MITRE ATLAS?

Responden preguntas distintas. OWASP nombra las clases de vulnerabilidad de tu aplicación; ATLAS cataloga las tácticas y técnicas que un adversario usa contra sistemas de IA. Una es una lista de comprobación sobre tu diseño, la otra un mapa del manual del atacante.

Referencias

• OWASP — Top 10 for LLM Applications
• OWASP — LLM01: Prompt Injection
• MITRE ATLAS — Adversarial Threat Landscape for AI Systems
• NIST — AI Risk Management Framework (AI RMF 1.0)

Gobernanza relacionada