La edición 2026 del OWASP Top 10 para aplicaciones con LLM no es solo para actualizar una lista de riesgos. Refuerza un cambio que ya afecta a quienes diseñan productos con inteligencia artificial: cuanto más contexto recibe el modelo, accede a datos, llama a herramientas y realiza acciones, menos seguridad puede restringirse a la capa técnica.
OWASP publicó la nueva edición el 3 de agosto de 2026. La página oficial destaca clasificaciones actualizadas, cobertura ampliada de amenazas e investigaciones respaldadas por miles de incidentes de seguridad relacionados con la IA del mundo real. El documento también conecta los riesgos de las solicitudes con LLM con referencias como NIST, MITRE ATLAS, CWE y el propio Top 10 de OWASP para aplicaciones agentes.
Para los equipos de producto, la lectura principal es práctica: no basta con preguntar si el modelo responde bien. Es necesario definir qué puede leer, qué puede revelar, qué puede decidir y qué puede hacer cuando se equivoca o se manipula.
La metodología ganó un componente que ayuda a explicar el nuevo orden. Además de la evaluación de la comunidad de expertos, la edición de 2026 comparó estas percepciones con incidentes observados en el mundo real. El análisis del informe registra un conjunto de 7.714 incidentes, de los cuales 6.639 contenían información suficiente para su clasificación. Los votos de los practicantes siguieron representando el 75%, mientras que los incidentes representaron el otro 25%.
El resultado no fue una ruptura total con 2025. Los dos primeros riesgos se mantuvieron en las mismas posiciones, pero hubo movimientos relevantes en el resto de la lista y una ampliación en el significado de algunas categorías.
| Posición en 2026 |
Riesgo |
Posición en 2025 |
Cambio principal |
| 1 |
Inyección inmediata |
1 |
Se mantiene en la cima y comienza a considerar más claramente las entradas multimodales, la memoria y los sistemas agentes |
| 2 |
Divulgación de información confidencial |
2 |
Mantiene su posición y continúa lidiando con la exposición indebida de información confidencial |
| 3 |
Agencia excesiva |
6 |
Ascender tres posiciones con el avance de agentes, herramientas y acciones autónomas |
| 4 |
Cadena de suministro |
3 |
Bajar una posición, prestando también atención a la confianza en los modelos, artefactos y componentes |
| 5 |
Envenenamiento de datos y modelos |
4 |
Baja una posición y amplía la perspectiva sobre la manipulación de datos y el propio proceso de adaptación del modelo |
| 6 |
Consumo ilimitado |
10 |
Asciende cuatro posiciones, acercando la disponibilidad al control de costes y al consumo computacional |
| 7 |
Desinformación |
9 |
Gana prioridad a medida que los resultados incorrectos influyen en las decisiones y la automatización |
| 8 |
Exposición al contexto oculto |
7 |
Amplía y cambia el nombre de la antigua fuga de aviso del sistema |
| 9 |
Debilidades de los vectores y la incrustación |
8 |
Continúa cubriendo riesgos en vectores, incrustaciones y arquitecturas de recuperación |
| 10 |
Manejo inadecuado de la salida |
5 | Cae en el ranking, a pesar de mantener y aumentar los riesgos relacionados con el uso inseguro de los resultados del modelo |
La migración de posiciones y el cambio de alcance se reproducen consistentemente mediante análisis del documento de 2026. En particular, la agencia excesiva sube del sexto al tercer lugar, el consumo ilimitado pasa del décimo al sexto y la antigua fuga rápida del sistema ahora se trata como exposición de contexto oculto.
La clasificación no debe interpretarse como un orden automático de implementación. Un riesgo que aparece décimo puede ser crítico en un producto determinado. La utilidad de la lista es ofrecer un lenguaje común para identificar superficies que, en las aplicaciones de IA, escapan a la revisión del software convencional.
La autonomía ya no es sólo una decisión de ingeniería
El ascenso de Excessive Agency al tercer lugar es probablemente el cambio más directo para quienes trabajan en el producto.
Un chatbot que solo sugiere una respuesta tiene un radio de impacto. Un agente capaz de cambiar archivos, llamar a API, consultar sistemas corporativos, enviar mensajes o ejecutar un flujo completo tiene otro. El riesgo ya no está solo en la calidad de la respuesta y ahora depende de los permisos otorgados al sistema.
Steve Wilson, copresidente del Proyecto de Seguridad GenAI de OWASP, relacionó el aumento de la Agencia Excesiva precisamente con el hecho de que los agentes actuales navegan, utilizan herramientas, acceden a los sistemas y actúan en nombre de los usuarios. La recomendación asociada es limitar los permisos y monitorear el comportamiento de estas aplicaciones de forma continua.
Esto convierte decisiones aparentemente funcionales en decisiones de seguridad.
Si un asistente necesita consultar un calendario, por ejemplo, el producto debe decidir si realmente necesita editar citas. Si puede editar, debe definir en qué situaciones, en nombre de quién y cuándo la acción requiere confirmación. Una función de "aprobación automática" no es solo una conveniencia experiencial: modifica el posible impacto de una falla.
Para el PRD, la pregunta ya no es simplemente “¿qué herramienta necesita usar el agente?” y continúa incluyendo "¿cuál es el permiso mínimo requerido para realizar esta función?".
El contexto oculto no debería funcionar como mecanismo de protección
Otro cambio significativo es la sustitución de la fuga de aviso del sistema por exposición de contexto oculto.
El nuevo nombre magnifica el problema. El contexto invisible para el usuario puede contener mucho más que un mensaje del sistema: instrucciones del desarrollador, esquemas de herramientas, políticas recuperadas por RAG, información operativa y otros datos recopilados antes de la llamada del modelo.
La lectura recomendada para la edición 2026 es asumir que este contexto se puede descubrir. Por lo tanto, mantener la información fuera de la interfaz no es suficiente para tratarla como un secreto.
Para el producto y la arquitectura, esto tiene una consecuencia simple: las credenciales, claves, permisos o información cuya exposición desencadenaría un incidente no deben depender de que el modelo permanezca oculto.
También cambia la forma en que pensamos sobre las reglas comerciales.. Una instrucción interna puede guiar el comportamiento del sistema, pero no debe ser la única barrera que impida una operación que el usuario no está autorizado a realizar. La autorización debe existir en una capa confiable de la aplicación.
El coste también es una superficie de abuso
El consumo ilimitado pasó de la décima a la sexta posición.
El riesgo va más allá de la clásica indisponibilidad. Las aplicaciones modernas pueden combinar grandes ventanas de contexto, modelos de razonamiento más costosos, entradas multimodales, llamadas repetidas a herramientas y flujos de varios pasos. Esto crea situaciones en las que una solicitud barata para quienes inician el proceso produce un costo mucho mayor para quienes operan el servicio.
Una política que solo limite el número de solicitudes puede ser insuficiente cuando dos solicitudes tienen costos radicalmente diferentes.
Esto coloca el presupuesto computacional dentro del diseño del producto. Límites por usuario, sesión o flujo de trabajo; número máximo de llamadas a herramientas; presupuesto simbólico; los límites de ejecución y los mecanismos capaces de interrumpir ciclos anormales ya no son sólo optimizaciones financieras.
También reducen la capacidad de que entradas maliciosas o automatizaciones defectuosas consuman recursos de forma indefinida.
Una respuesta incorrecta puede convertirse en una acción incorrecta
La desinformación también aumentó, del noveno al séptimo lugar.
Si bien un LLM funciona únicamente como una interfaz conversacional, la información incorrecta generalmente llega primero a la persona. Cuando el resultado se incorpora al software, los agentes o las decisiones automatizadas, este error puede atravesar el sistema antes de que alguien lo note.
El análisis de la edición 2026 llama la atención exactamente sobre este cambio de contexto: la salida incorrecta puede guiar las llamadas a herramientas, la generación de código y otras acciones posteriores.
Existe una diferencia importante entre “calidad de la IA” y “seguridad del producto”.
Un producto que resume documentos puede tolerar ciertos tipos de errores de manera diferente que una aplicación que transforma la finalización del modelo en un cambio de registro, cambio de permiso o ejecución de código. El requisito de validación debe acompañar a la consecuencia.
En funciones de mayor impacto, la salida probabilística no debe tratarse automáticamente como autorización para actuar. Es posible que se requiera confirmación humana, validaciones deterministas, reglas comerciales y fuentes verificables antes del siguiente paso.
RAG no elimina la necesidad de control de acceso
Las debilidades de vectores e incrustaciones siguen estando entre los diez principales riesgos, ahora en la novena posición.
Para productos que utilizan RAG, búsqueda semántica o memoria vectorial, lo importante es no confundir la recuperación técnicamente correcta con la autorización.
Encontrar el fragmento más similar a una pregunta no significa que ese contenido se pueda mostrar a la persona que hace la pregunta.. La autorización debe acompañar a los documentos, fragmentos o datos recuperados antes de que ingresen al contexto del modelo.
Del mismo modo, las fuentes agregadas al índice necesitan controles de procedencia e integridad. El contenido recuperado por un LLM continúa siendo ingresado y puede cambiar el comportamiento del sistema, incluso en escenarios relacionados con la inyección rápida. La edición de 2026 amplía la mirada a los insumos no confiables consumidos por el modelo.
Los 10 mejores pueden entrar en el ciclo del producto antes de la prueba de penetración
La lista gana más valor cuando deja de aparecer cuando se acerca el lanzamiento.
Una forma práctica de incorporarlo a tu trabajo es recorrer cinco momentos del ciclo:
- Descubrimiento: mapea qué datos entran en el modelo, de dónde provienen y qué consecuencias puede generar una respuesta incorrecta.
- Definición de producto: registro de herramientas, permisos, nivel de autonomía, acciones irreversibles y momentos que requieren confirmación.
- Arquitectura: separe la autorización de la decisión de LLM, limite los privilegios, proteja los datos confidenciales y controle los resultados antes de que lleguen a otros sistemas.
- Validación: inyección de avisos de prueba, fugas de información, entradas recuperadas o manipuladas, abuso de herramientas, consumo excesivo y fallas en integraciones relevantes para esa aplicación.
- Operación: realice un seguimiento del comportamiento, los costos, los errores, las acciones tomadas y los cambios en los modelos, herramientas, fuentes de datos y permisos.
La secuencia es más útil que convertir el Top 10 en diez cuadros de cumplimiento genéricos. El objetivo es descubrir cómo se manifiesta cada categoría en ese producto y cuál es el impacto cuando falla la protección.
Las aplicaciones agentes necesitan una segunda lente
OWASP mantiene un Top 10 específico de aplicaciones agentes. El documento, publicado originalmente en diciembre de 2025 para la edición de 2026, trata sobre sistemas capaces de planificar, actuar y tomar decisiones en flujos de trabajo complejos.
Esta separación ayuda a evitar una falsa sensación de cobertura.
El Top 10 para LLM sigue siendo relevante cuando el modelo es un componente de la aplicación. Cuando aparecen la memoria persistente, la planificación de múltiples pasos, las herramientas y las acciones autónomas, el análisis debe complementarse con la perspectiva agencial. La documentación y los análisis de la edición de 2026 presentan estas dos referencias como complementarias.
En la práctica, un producto puede comenzar como un asistente y cruzar esta frontera durante su evolución. Añadir una herramienta de escritura, memoria compartida o autorización para realizar una acción cambia el modelo de amenaza aunque la interfaz siga siendo prácticamente la misma.
Es por eso que una revisión de seguridad de la IA no debería realizarse simplemente cuando cambia el modelo. Una nueva herramienta, fuente de datos, permiso o flujo de trabajo también pueden cambiar materialmente el riesgo.
El mejor criterio es el radio de impacto de la falla
La edición 2026 apunta a una idea que puede guiar las decisiones de producto incluso sin memorizar todas las categorías: suponer que el modelo puede cometer errores o ser manipulado y examinar qué sucede a continuación.
Si la consecuencia final es una sugerencia inapropiada que será revisada antes de tomar cualquier acción, existe un tipo de exposición. Si el mismo fallo puede revelar datos privados, gastar recursos ilimitados, alterar un sistema o realizar una operación irreversible, el diseño necesita barreras adicionales.
Este razonamiento acerca la seguridad a conceptos que el producto ya utiliza: permisos, estados, confirmación, reversibilidad, observabilidad y recuperación.
El paso más útil para los equipos que ya tienen aplicaciones de IA es revisar el PRD y el modelo de amenazas junto con la edición 2026. Para cada recurso, vale la pena identificar de dónde entran los datos no confiables, qué información llega al contexto, qué herramientas están disponibles y cuál es el mayor impacto que puede tener una respuesta incorrecta.
Si el sistema también actúa de forma autónoma, la revisión debería incorporar el OWASP Top 10 para Aplicaciones Agenticas. El cambio de 2026 pretende precisamente dejar más claro que construir un modelo “difícil de engañar” no es suficiente: es el producto que lo rodea el que debe limitar las consecuencias cuando algo sale mal.
Temas de este articuloAgentes de IAIA generativaLLMsRAGsegurança de aplicaçõessegurança de IAthreat modeling
