La IA generativa dejó de ser un experimento: hoy hay LLMs en producción resolviendo tickets, escribiendo código y moviendo datos sensibles. El OWASP Top 10 for LLM Applications es el marco de referencia para pensar su seguridad, y en 2026 llegó una revisión que reordena prioridades según lo que realmente está fallando en el mundo real. Este artículo resume la edición 2026 y cómo convertirla en pruebas concretas.
Contexto. Esta es una guía práctica basada en la edición 2026 del proyecto OWASP GenAI Security. Para el texto normativo y las fichas detalladas de cada riesgo, consulta siempre la fuente oficial en genai.owasp.org.
1. Qué es (y qué no es) este Top 10
Es una lista priorizada de los diez riesgos más críticos en aplicaciones que integran modelos de lenguaje. No es un estándar de certificación ni un checklist exhaustivo: es un mapa de dónde mirar primero. Su valor está en darte un vocabulario común y una priorización defendible ante negocio y clientes.
La edición 2026 mantiene las mismas diez categorías que 2025 —no hay riesgos nuevos ni eliminados—, pero reordena la lista y reencuadra varias entradas para reflejar la explosión de sistemas agénticos y multimodales.
2. Cómo se construyó la edición 2026
Lo interesante del método 2026 es que cruza percepción con evidencia:
- Voto de la comunidad de practicantes → pesa 75%.
- Datos de incidentes reales → pesan 25%, sobre un corpus de 7.714 incidentes relacionados con LLM extraídos de bases públicas de vulnerabilidades (de los cuales ~6.639 tenían detalle suficiente para clasificarse).
El resultado es una lista que no solo refleja lo que preocupa, sino lo que de verdad está pasando. La publicación es de agosto de 2026.
3. Los diez riesgos (2026)
| Código | Riesgo | 2025 → 2026 |
|---|---|---|
| LLM01:2026 | Prompt Injection | 1 → 1 |
| LLM02:2026 | Sensitive Information Disclosure | 2 → 2 |
| LLM03:2026 | Excessive Agency | 6 → 3 ▲ |
| LLM04:2026 | Supply Chain | 3 → 4 |
| LLM05:2026 | Data and Model Poisoning | 4 → 5 |
| LLM06:2026 | Unbounded Consumption | 10 → 6 ▲ |
| LLM07:2026 | Misinformation | 9 → 7 ▲ |
| LLM08:2026 | Hidden Context Exposure | 7 → 8 (renombrado) |
| LLM09:2026 | Vector and Embedding Weaknesses | 8 → 9 |
| LLM10:2026 | Improper Output Handling | 5 → 10 ▼ |
LLM01 — Prompt Injection
Sigue en el número uno. El problema de raíz no cambió: el modelo procesa instrucciones confiables y datos no confiables en el mismo contexto, y una instrucción maliciosa puede llegar por un documento, una imagen, la salida de una herramienta o la memoria persistente. En 2026 su alcance se amplía explícitamente a ataques cross-modal, memoria persistente y el blast radius de los agentes. OWASP es claro: prompting y filtros no eliminan el riesgo por sí solos.
LLM02 — Sensitive Information Disclosure
Fuga de datos sensibles (PII, secretos, propiedad intelectual) a través de las respuestas del modelo. Se mantiene en el #2.
LLM03 — Excessive Agency
El gran ascenso (6 → 3). A medida que los LLM obtienen herramientas, permisos y autonomía, el daño de una acción indebida crece. Mitigación central: mínimo privilegio por petición y aprobación humana para acciones de alto impacto o difíciles de revertir.
LLM04 — Supply Chain
Riesgos en modelos, datasets, plugins y dependencias de terceros. Baja un puesto, pero sigue siendo crítico.
LLM05 — Data and Model Poisoning
Envenenamiento de datos de entrenamiento, fine-tuning o embeddings para introducir backdoors o sesgos.
LLM06 — Unbounded Consumption
Otro salto notable (10 → 6). Abarca denegación de servicio, costos descontrolados y extracción de modelo por consumo sin límites. Su subida refleja el impacto económico real de dejar un endpoint LLM sin cuotas.
LLM07 — Misinformation
Alucinaciones y contenido incorrecto en el que los usuarios confían. Sube por los incidentes documentados de decisiones tomadas sobre salidas erróneas.
LLM08 — Hidden Context Exposure
El cambio con nombre propio: antes “System Prompt Leakage”, ahora renombrado y ampliado. Ya no cubre solo la fuga del system prompt, sino de cualquier contexto operativo oculto (instrucciones, configuración, datos de herramientas) que no debería ser observable.
LLM09 — Vector and Embedding Weaknesses
Debilidades en los sistemas RAG: embeddings y bases vectoriales como superficie de ataque (inyección vía documentos indexados, fuga entre tenants).
LLM10 — Improper Output Handling
La mayor caída (5 → 10). Tratar la salida del modelo como confiable y pasarla sin validar a otro sistema (XSS, SQLi, ejecución de comandos aguas abajo). Baja en el ranking, pero el patrón de “validar la salida como si viniera de un usuario” sigue vigente.
4. De la lista a las pruebas
El Top 10 rinde cuando lo conviertes en casos de prueba. Un extracto de cómo lo abordamos en un assessment de una app con LLM:
| Riesgo | Prueba concreta |
|---|---|
| LLM01 | Inyección directa e indirecta (documento/imagen/tool); intentar override del system prompt |
| LLM03 | ¿El agente ejecuta acciones sin confirmación? Probar escalada vía encadenado de herramientas |
| LLM06 | Enviar entradas que inflen tokens/costos; medir si hay rate limiting y cuotas |
| LLM08 | Intentar extraer instrucciones y configuración ocultas vía prompts de sonda |
| LLM10 | Inyectar payloads (<script>, '; DROP…) en entradas que el modelo reenvía a otro sistema |
Cruza marcos. El LLM Top 10 convive con el resto de tu metodología: una salida mal manejada (LLM10) termina siendo un XSS del OWASP Top 10 web, y un agente con exceso de permisos (LLM03) es, al final, un problema de autorización. Mapea cada hallazgo a ambos marcos para que el informe hable el idioma de desarrollo.
5. Defensa: tres principios que se repiten
Más allá de cada ficha, la edición 2026 insiste en tres ideas transversales:
- No confíes en el prompt como control de seguridad. Filtrar y pedir “por favor no hagas X” no es una barrera; la barrera va en la arquitectura (permisos, validación de salida, aislamiento).
- Mínimo privilegio y confirmación humana. Sobre todo para agentes: limita cada acción a la petición en curso y reserva aprobación humana para lo irreversible.
- Valida entrada y salida como no confiables. Tanto lo que entra al contexto (datos, documentos, memoria) como lo que sale hacia otros sistemas.
6. Conclusión
La edición 2026 no reinventa la rueda: mantiene los diez riesgos, pero su reordenamiento cuenta una historia clara —los sistemas agénticos (LLM03) y los costos sin límite (LLM06) suben porque es donde más se está rompiendo, mientras el manejo de salida (LLM10) baja sin dejar de importar. Para quien hace pentesting o diseña defensa, el mensaje es práctico: trata al LLM como un componente no confiable más, con sus controles en la arquitectura y no en el prompt.
Este análisis se apoya en el material de IA y seguridad de la biblioteca interna de TitanSec y complementa los artículos sobre pentesting asistido por IA y construcción de herramientas con MCP.