OWASP Top 10 para LLM (2025) y para agentes de IA: qué son y cómo se prueban

por | Oct 14, 2026 | Inteligencia artificial

Resumen en 40 palabras: el OWASP Top 10 para aplicaciones LLM (edición 2025) es la referencia de riesgos de seguridad para chatbots, asistentes y sistemas RAG. En diciembre de 2025 OWASP publicó otra lista para agentes de IA. Esta guía explica ambas con ejemplos y pruebas concretas.

Cuando una empresa pone un modelo de lenguaje en contacto con sus datos, sus clientes o sus herramientas, aparecen fallos que un pentest web tradicional no detecta. El OWASP GenAI Security Project ha ordenado esos fallos en dos listas que hoy son el punto de partida de cualquier auditoría seria. Aquí las tienes explicadas desde el lado del que las pone a prueba: qué es cada riesgo, cómo se manifiesta en una empresa y cómo se comprueba.

Las dos listas de OWASP que debes conocer

  • OWASP Top 10 for LLM Applications 2025: riesgos de cualquier aplicación que use un modelo de lenguaje, desde un chatbot de atención al cliente hasta un buscador interno con RAG.
  • OWASP Top 10 for Agentic Applications 2026 (publicada el 9 de diciembre de 2025): riesgos propios de los agentes, es decir, sistemas de IA que planifican, usan herramientas, guardan memoria y actúan con cierta autonomía.

No se sustituyen: un agente sigue teniendo todos los riesgos de un LLM y, además, los de actuar sobre el mundo. Si tu empresa usa agentes conectados al correo, al CRM o a la facturación, necesitas las dos.

OWASP Top 10 para LLM 2025, riesgo a riesgo

Mapa de los riesgos del OWASP Top 10 para LLM según dónde aparecen: entrada, modelo, datos, salida y acciones
Dónde aparece cada riesgo en una aplicación con LLM. Las pruebas se diseñan siguiendo ese recorrido.

LLM01: Inyección de instrucciones (prompt injection)

Qué es: alguien consigue que el modelo siga sus instrucciones en lugar de las del sistema. Puede ser directa (el usuario escribe la orden) o indirecta (la orden va escondida en un correo, una web o un documento que el modelo lee).

Caso real: en 2025 se conoció EchoLeak (CVE-2025-32711), una vulnerabilidad de Microsoft 365 Copilot en la que un único correo con instrucciones ocultas permitía extraer datos internos sin que la víctima hiciera clic. Microsoft lo corrigió en el servidor.

Cómo se prueba: instrucciones directas, codificadas y en varios turnos, y sobre todo contenido envenenado en las fuentes que el sistema consume (correos, tickets, PDF, páginas web). Lo explicamos a fondo en nuestra guía sobre prompt injection.

LLM02: Revelación de información sensible

Qué es: el modelo devuelve datos que el usuario no debería ver: datos personales, secretos comerciales, credenciales o información de otros clientes.

Cómo se manifiesta: un asistente RAG que indexa todo SharePoint sin respetar permisos responde a un comercial con nóminas o contratos de otro departamento.

Cómo se prueba: con usuarios de distintos perfiles, preguntamos por información que no deberían alcanzar y comprobamos si el control de acceso se aplica antes de recuperar los documentos, no solo en la interfaz.

LLM03: Cadena de suministro

Qué es: riesgos que llegan de terceros: modelos descargados de repositorios públicos, librerías, plugins, conjuntos de datos o proveedores de API.

Cómo se manifiesta: se han encontrado en repositorios públicos modelos con código malicioso que se ejecuta al cargarlos, por el uso de formatos de serialización inseguros.

Cómo se prueba: inventario de modelos y componentes (un AI-BOM), procedencia, formatos de carga seguros y revisión de los permisos de cada plugin o conector.

LLM04: Envenenamiento de datos y modelos

Qué es: manipular los datos de entrenamiento, ajuste fino o contexto para introducir sesgos, errores o puertas traseras.

Cómo se manifiesta: un atacante consigue colar documentos manipulados en la base de conocimiento que alimenta el RAG y el asistente empieza a dar respuestas falsas sobre un producto o un procedimiento.

Cómo se prueba: revisando quién puede escribir en las fuentes de datos, cómo se validan antes de indexarse y si hay trazabilidad de qué documento originó cada respuesta.

LLM05: Gestión inadecuada de las salidas

Qué es: la respuesta del modelo se pasa a otro sistema sin validarla: un navegador, una base de datos, una shell o una API.

Cómo se manifiesta: el modelo genera HTML o Markdown que el chat renderiza y que carga una imagen externa con datos en la URL, o una consulta SQL que se ejecuta tal cual.

Cómo se prueba: forzando salidas con cargas de XSS, enlaces y consultas, y verificando que se escapan, se validan contra una lista permitida o se ejecutan con mínimos privilegios. Es el puente entre el pentest de IA y la auditoría de seguridad web clásica.

LLM06: Agencia excesiva

Qué es: el modelo tiene más funciones, permisos o autonomía de los que necesita.

Cómo se manifiesta: un asistente que solo debía leer el correo también puede enviarlo y borrarlo, porque el conector se configuró con todos los permisos.

Cómo se prueba: listando cada herramienta y permiso del sistema, e intentando que el modelo los use fuera de su propósito. Las acciones con impacto (pagos, envíos, borrados) deben pedir confirmación humana.

LLM07: Filtración del prompt del sistema

Qué es: se extraen las instrucciones internas del sistema, que a veces incluyen reglas de negocio, nombres de herramientas o, peor, credenciales.

Cómo se prueba: intentando extraer el prompt por varias vías. Pero la conclusión importante es otra: el prompt del sistema no es un control de seguridad. Nada que sea secreto debe estar ahí.

LLM08: Debilidades en vectores y embeddings

Qué es: fallos en la capa de recuperación de los sistemas RAG: bases vectoriales sin separación entre clientes, embeddings que permiten reconstruir texto o documentos manipulados para colarse en los resultados.

Cómo se prueba: comprobando el aislamiento entre usuarios e inquilinos, los permisos de la base vectorial y si un documento malicioso puede ganar prioridad en la recuperación.

LLM09: Desinformación

Qué es: el modelo genera información falsa con apariencia de verdad (alucinaciones) y alguien actúa sobre ella.

Caso real: en febrero de 2024 un tribunal de Canadá obligó a Air Canada a cumplir una política de reembolso que su chatbot se había inventado. La empresa respondía de lo que decía su asistente.

Cómo se prueba: con baterías de preguntas sobre políticas, precios y condiciones con respuesta conocida, midiendo cuántas respuestas son incorrectas y si el sistema cita la fuente.

LLM10: Consumo sin límites

Qué es: peticiones que disparan el coste o tumban el servicio: prompts enormes, bucles de herramientas o extracción masiva del modelo por API.

Cómo se prueba: verificando límites de peticiones y de tokens por usuario, tiempos máximos, alertas de gasto y detección de patrones de extracción.

OWASP Top 10 para agentes de IA (2026)

Los agentes añaden un problema nuevo: ya no solo responden, actúan. Estos son los diez riesgos de la lista para aplicaciones agénticas y la pregunta que hay que hacerse en cada uno:

Riesgo Pregunta clave para tu empresa
ASI01 Secuestro del objetivo del agente ¿Puede un contenido externo cambiar lo que el agente intenta conseguir?
ASI02 Uso indebido de herramientas ¿Puede usar una herramienta legítima para un fin no previsto?
ASI03 Abuso de identidad y privilegios ¿Con qué identidad actúa el agente y qué permisos hereda?
ASI04 Cadena de suministro agéntica ¿De dónde vienen sus herramientas, plugins y servidores MCP?
ASI05 Ejecución inesperada de código ¿Puede acabar ejecutando código generado por él mismo o por un tercero?
ASI06 Envenenamiento de memoria y contexto ¿Qué pasa si alguien escribe algo falso en su memoria persistente?
ASI07 Comunicación insegura entre agentes ¿Se autentican y validan los mensajes entre agentes?
ASI08 Fallos en cascada ¿Un error de un agente se propaga a toda la cadena?
ASI09 Explotación de la confianza humano-agente ¿Aprueban las personas lo que el agente propone sin revisarlo?
ASI10 Agentes que se desvían ¿Detectarías un agente que actúa fuera de su comportamiento esperado?

En la práctica, la mayoría de hallazgos en agentes se reducen a tres cosas: permisos demasiado amplios, contenido externo tratado como instrucción y falta de registro de lo que el agente hizo y por qué.

Cómo encaja OWASP con el AI Act y la ISO/IEC 42001

OWASP no es una norma obligatoria, pero sirve para demostrar diligencia frente a requisitos que sí lo son:

  • AI Act, artículo 15: exige que los sistemas de alto riesgo sean precisos, robustos y ciberseguros, y nombra expresamente ataques como el envenenamiento de datos o de modelos, los ejemplos adversarios y los ataques a la confidencialidad. Tras el Reglamento Ómnibus Digital sobre IA (Reglamento (UE) 2026/1744, en vigor desde el 27 de julio de 2026), las obligaciones de los sistemas de alto riesgo del anexo III se aplican desde el 2 de diciembre de 2027. Hay tiempo, pero no tanto.
  • ISO/IEC 42001: el sistema de gestión de IA pide identificar y tratar riesgos de los sistemas de IA. Un pentest basado en OWASP es una evidencia directa de ese tratamiento. Ver implantación de ISO/IEC 42001.
  • MITRE ATLAS y NIST: ATLAS describe las tácticas de los atacantes contra sistemas de IA, y el informe NIST AI 100-2 (2025) clasifica los ataques y reconoce que las defensas actuales son empíricas e incompletas.

Checklist rápida antes de poner un LLM en producción

  1. Inventario de modelos, fuentes de datos, herramientas y permisos.
  2. Control de acceso aplicado antes de recuperar documentos, no después.
  3. Contenido externo marcado como no confiable y nunca tratado como instrucción.
  4. Salidas validadas antes de llegar a navegadores, bases de datos o APIs.
  5. Confirmación humana para acciones con impacto.
  6. Nada secreto en el prompt del sistema.
  7. Límites de uso, de coste y de tiempo.
  8. Registro de entradas, salidas y llamadas a herramientas.
  9. Pentest de IA antes del lanzamiento y después de cada cambio relevante.

Si quieres comprobarlo en tu propio sistema, en BCNSoluciona hacemos pentesting de IA y LLM basado en OWASP, MITRE ATLAS y el NIST AI RMF, con independencia de fabricantes.

Preguntas frecuentes sobre el OWASP Top 10 para LLM

¿Cuál es la versión actual del OWASP Top 10 para LLM?

La edición 2025. Sus diez riesgos son inyección de instrucciones, revelación de información sensible, cadena de suministro, envenenamiento de datos y modelos, gestión inadecuada de salidas, agencia excesiva, filtración del prompt del sistema, debilidades en vectores y embeddings, desinformación y consumo sin límites.

¿Qué diferencia hay entre el Top 10 para LLM y el de agentes?

El de LLM cubre los riesgos de cualquier aplicación con un modelo de lenguaje. El de agentes, publicado en diciembre de 2025, añade los riesgos de sistemas que planifican, usan herramientas, guardan memoria y actúan con autonomía.

¿Es obligatorio cumplir el OWASP Top 10?

No es una norma legal, pero es la referencia técnica más usada para demostrar que se han tratado los riesgos de seguridad que exigen el AI Act o la ISO/IEC 42001.

¿Un pentest web normal cubre estos riesgos?

Solo en parte. Cubre la aplicación y la infraestructura, pero no la manipulación del modelo, la inyección indirecta ni el abuso de herramientas por parte de un agente. Lo habitual es combinar ambos.

¿Cada cuánto conviene auditar una aplicación con IA?

Antes de ponerla en producción y después de cada cambio relevante: un modelo nuevo, una nueva fuente de datos, una herramienta o un permiso adicional.

Contenido revisado por el equipo de consultoría de BCNSoluciona · octubre de 2026. Fuentes: OWASP GenAI Security Project, NIST AI 100-2 E2025, Reglamento (UE) 2026/1744 y publicaciones técnicas sobre EchoLeak.

¿Necesitas ayuda con la seguridad de tu empresa?
Analizamos tu situación y te ayudamos a identificar las medidas adecuadas para mejorar la seguridad de la información y avanzar con criterio.

Ir al contenido