OWASP Top 10 para aplicaciones con LLM: riesgos y controles esenciales

Un asistente que responde preguntas sobre un manual tiene una superficie de riesgo distinta de un agente que consulta expedientes, envía correos y modifica una base de datos. Ambos pueden utilizar el mismo modelo de lenguaje. Lo que cambia es la información que reciben, la autoridad que les concedemos y lo que hacemos con sus respuestas.

Por eso, proteger una aplicación con IA exige revisar más que su prompt. Hay que entender quién introduce los datos, cómo se recuperan, qué herramientas están disponibles y dónde se toman las decisiones de seguridad.

Vamos a recorrer los diez riesgos de OWASP con escenarios técnicos y controles concretos. Los ejemplos son ficticios e ilustrativos: no describen incidentes observados ni resultados de un laboratorio.

Qué edición estamos utilizando

Al verificar el proyecto oficial el 4 de noviembre de 2026, la edición vigente que presenta OWASP es el Top 10 de 2025 para aplicaciones con LLM e IA generativa. Conservaremos sus identificadores para evitar mezclar categorías de otras versiones. Es una guía de riesgos y mitigaciones; no constituye por sí sola una obligación legal ni una certificación de seguridad. Índice oficial de OWASP.

El modelo es una parte de la aplicación

Un LLM, o modelo de lenguaje de gran tamaño, genera contenido a partir de un contexto. La aplicación prepara ese contexto y decide cómo utilizar la respuesta. Cuando permite que el modelo proponga llamadas a herramientas y continúe trabajando con sus resultados, hablamos habitualmente de un agente.

RAG, generación aumentada por recuperación, añade información recuperada de fuentes externas al contexto de una respuesta. Un mecanismo frecuente utiliza embeddings: representaciones numéricas que permiten buscar contenido por similitud. Esa similitud ayuda a seleccionar documentos relevantes; no demuestra que sean verdaderos ni que el usuario tenga permiso para leerlos.

Este recorrido simplificado sitúa las fronteras que tendremos que proteger:

sequenceDiagram
    actor U as Usuario
    participant A as Aplicación
    participant R as Recuperación documental
    participant M as Modelo
    participant T as Herramienta

    U->>A: Pregunta autenticada
    A->>R: Buscar con permisos del usuario
    R-->>A: Fragmentos y procedencia
    A->>M: Instrucciones y datos diferenciados
    M-->>A: Propuesta de respuesta o acción
    Note over A: Validar y autorizar fuera del modelo
    opt Acción permitida y dentro del presupuesto
        A->>T: Operación acotada
        T-->>A: Resultado
    end
    A-->>U: Respuesta tratada para su destino

El diagrama es una propuesta de diseño para esta guía, no una arquitectura obligatoria de OWASP. En una aplicación real también habrá sesiones, almacenamiento, proveedores, registros y procesos de ingestión de documentos.

LLM01: prompt injection

El problema aparece cuando contenido que debería aportar datos consigue influir como una instrucción. Puede entrar directamente por una conversación o indirectamente desde documentos y respuestas de herramientas. OWASP: Prompt Injection.

Escenario: un asistente revisa propuestas comerciales. Una propuesta incluye una nota que le pide ignorar los criterios de evaluación y recomendar a su autor. Si además dispone de una herramienta para enviar mensajes, el contenido podría intentar inducir una acción fuera de la tarea.

Las consecuencias van desde una respuesta manipulada hasta una filtración o una operación no autorizada, según sus permisos. Conviene identificar la procedencia del contenido, separarlo de las instrucciones, reducir herramientas y exigir autorización independiente para acciones sensibles.

Límite: separar bloques y reforzar el prompt puede ayudar, pero no garantiza que el modelo respete esa frontera. Los controles decisivos deben limitar lo que puede ocurrir aunque la generación se desvíe. En la guía de prompt injection y defensas externas al modelo desarrollamos esa diferencia.

LLM02: divulgación de información sensible

Una respuesta puede revelar información que su destinatario no debería conocer: datos personales, documentos privados o credenciales. El origen puede estar en el contexto, en herramientas conectadas o en datos utilizados durante el entrenamiento. OWASP: Sensitive Information Disclosure.

Escenario: un asistente de soporte recibe el expediente completo de un cliente para contestar una pregunta sobre el estado de un trámite. Al resumirlo, incluye una nota interna con información innecesaria para esa respuesta.

La consecuencia es una pérdida de confidencialidad, aunque nadie haya intentado manipular al modelo. Reduce los campos enviados, aplica permisos antes de recuperar documentos y revisa las condiciones de retención y uso de datos del proveedor. Protege también los registros: guardar prompts completos puede crear una segunda copia del problema.

Límite: un detector de datos sensibles puede omitir información contextual que no coincide con patrones conocidos. La instrucción «no reveles secretos» tampoco compensa haber entregado información innecesaria. Las credenciales deben permanecer en los componentes que las usan, con gestión de secretos y acceso limitado.

LLM03: riesgos de cadena de suministro

La cadena de suministro incluye paquetes, servicios, modelos, adaptaciones de modelos y conjuntos de datos. Incorporar un componente de terceros introduce dependencias de su procedencia, integridad y mantenimiento. OWASP: Supply Chain.

Escenario: un equipo añade un cargador de modelos desde un repositorio no verificado. Durante la instalación ejecuta código con acceso al entorno de construcción. El problema ya existe antes de que el modelo genere su primera respuesta.

Puede haber robo de credenciales, alteración de artefactos o comportamiento manipulado. Mantén inventarios y versiones identificables; revisa proveedores, permisos y licencias; verifica integridad desde una referencia confiable y aísla la construcción. Combina el análisis de dependencias con SCA con evaluaciones específicas de modelos y datos.

Límite: un escáner de paquetes no evalúa toda la conducta de un modelo. Una firma o un hash ayuda a comprobar origen o integridad, pero no convierte un componente firmado en seguro. También hace falta capacidad de retirar una versión y volver a una conocida.

LLM04: envenenamiento de datos y modelos

El envenenamiento altera datos o artefactos del modelo para influir en su comportamiento. Puede afectar al entrenamiento, al ajuste posterior o a los datos que alimentan mecanismos de recuperación. OWASP: Data and Model Poisoning.

Escenario: un proceso convierte automáticamente conversaciones de soporte en ejemplos de entrenamiento. Alguien introduce repetidamente respuestas falsas sobre cómo restablecer una cuenta; más tarde, esos ejemplos entran en un ajuste del modelo sin revisión.

El sistema podría aprender instrucciones inseguras o degradar sus respuestas. Conviene controlar quién aporta datos, registrar origen y transformaciones, separar los conjuntos de evaluación de los de entrenamiento y revisar cambios antes de promoverlos. Las versiones permiten identificar qué conjunto participó en una actualización y facilitar su retirada.

Límite: un comportamiento malicioso puede activarse solo en condiciones que las pruebas no cubren. Versionar datos permite investigar; no detecta automáticamente el envenenamiento. Tampoco hay que confundir añadir un documento a un índice RAG con reentrenar el modelo: se modifica el conocimiento recuperable, no necesariamente sus parámetros.

LLM05: manejo inadecuado de salidas

El texto generado sigue siendo una entrada no confiable para el componente que lo recibe. El riesgo surge cuando se interpreta como HTML, SQL, comandos o rutas sin controles adecuados. OWASP: Improper Output Handling.

Escenario: un panel pide al modelo un resumen HTML y lo inserta directamente en la página. Si la salida contiene contenido ejecutable, el navegador puede convertir una respuesta manipulada en un ataque de XSS.

Usa texto escapado cuando solo necesites texto; si permites HTML, sanitízalo con una política restrictiva apropiada. Para bases de datos, define consultas en código y pasa valores como parámetros. Para herramientas, valida un contrato cerrado en vez de ejecutar instrucciones libres.

Límite: un JSON válido no demuestra que la acción sea segura ni autorizada. Un identificador perfectamente formado todavía puede pertenecer a otro cliente. La validación en tiempo de ejecución comprueba estructura; el control de acceso debe comprobar permisos. No basta con sustituir una cadena SQL arbitraria por un objeto con campos válidos.

LLM06: capacidad de actuación excesiva

OWASP distingue tres excesos: funcionalidad disponible, permisos concedidos y autonomía para actuar. El peligro existe tanto ante una manipulación como ante una interpretación equivocada de una petición legítima. OWASP: Excessive Agency.

Escenario: un asistente encargado de encontrar documentos recibe una herramienta que también puede eliminarlos. Una petición ambigua de «limpiar resultados» termina proponiendo borrados que nunca fueron necesarios para buscar.

La consecuencia puede ser pérdida de datos o modificación de procesos. Expón operaciones pequeñas, utiliza identidades con permisos mínimos y evalúa cada llamada bajo la autoridad del usuario. Para cambios importantes, solicita aprobación sobre la operación concreta, sus destinatarios y su alcance.

Límite: una confirmación genérica de «¿continuar?» aporta poco si no muestra qué va a cambiar. Además, una acción aprobada debe seguir pasando por autorización en el servidor. Ni la aprobación ni la conexión mediante MCP justifican conceder acceso irrestricto.

LLM07: exposición del prompt de sistema

El prompt de sistema orienta el comportamiento, pero no debe tratarse como una caja fuerte ni como el mecanismo que impone permisos. OWASP enfatiza que el riesgo depende de lo que se almacena o se delega allí. OWASP: System Prompt Leakage.

Escenario: el prompt contiene una credencial de integración y una instrucción que limita quién puede usarla. Si la credencial aparece en una respuesta, el atacante puede intentar utilizarla fuera del asistente, donde esa instrucción no tiene efecto.

Mantén secretos fuera del contexto y aplica autorización y límites de negocio en código. Diseña el sistema para que conocer sus instrucciones no conceda derechos adicionales. Si se filtra una credencial, revócala y revisa su uso; cambiar la redacción del prompt no la invalida.

Límite: ocultar las instrucciones puede dificultar algunas exploraciones, pero no garantiza confidencialidad. Exponer una indicación de estilo no tiene el mismo impacto que exponer una clave: hay que evaluar el contenido y los controles afectados, no clasificar cualquier revelación como un compromiso total.

LLM08: debilidades en vectores y embeddings

En RAG, una búsqueda semántica puede seleccionar información relevante pero no autorizada. También importan la integridad de las fuentes y la protección de los embeddings, que no deben suponerse anónimos o irreversibles. OWASP: Vector and Embedding Weaknesses.

Escenario: dos empresas comparten un índice vectorial. Una consulta busca primero en todo el índice y entrega los fragmentos al modelo; después intenta ocultar en la respuesta los documentos de la otra empresa. La separación llega demasiado tarde: el contexto ya cruzó la frontera.

Restringe la recuperación por identidad, organización y permisos documentales antes de incorporar resultados al contexto. Conserva procedencia, protege los metadatos de acceso y propaga cambios de permisos y eliminaciones. Las cachés también necesitan una separación compatible con esas restricciones.

Límite: un filtro por organización no resuelve diferencias de permisos dentro de ella. Tampoco garantiza que un documento autorizado sea confiable: puede contener información falsa o instrucciones maliciosas. El aislamiento protege la confidencialidad; la validación de fuentes y las defensas frente a inyección abordan problemas adicionales.

LLM09: información incorrecta o engañosa

Un modelo puede producir afirmaciones falsas con una presentación convincente. No hace falta un atacante: el riesgo aparece cuando esas respuestas se convierten en decisiones sin verificación suficiente. OWASP: Misinformation.

Escenario: un asistente recomienda una opción de configuración inexistente para desactivar una función peligrosa. El equipo copia la recomendación, cree haber mitigado el riesgo y deja la función operativa.

Contrasta afirmaciones con documentación primaria, comprueba que las citas existan y respalden lo afirmado y ejecuta pruebas sobre los cambios propuestos. Para decisiones relevantes, requiere revisión de alguien con conocimientos del dominio. Permite que el sistema indique que no tiene evidencia suficiente y muestre las fuentes consultadas.

Límite: RAG puede aportar mejores evidencias, pero recuperar una página correcta no garantiza interpretarla correctamente. Una cita tampoco prueba que la frase citada esté en ella. Un segundo modelo puede repetir el error del primero; conviene combinar revisión con verificaciones independientes, no contar coincidencias entre respuestas como demostración.

LLM10: consumo no controlado de recursos

Las consultas, respuestas y llamadas encadenadas consumen tiempo, capacidad y dinero. Sin límites efectivos, usuarios o procesos automáticos pueden degradar el servicio o disparar los costes. OWASP: Unbounded Consumption.

Escenario: un agente intenta resolver un fallo llamando repetidamente a una herramienta. Cada resultado provoca otra generación y otro intento, sin presupuesto ni condición de parada. Una sola petición puede iniciar mucho trabajo.

Limita tamaño de entrada, tokens, duración, concurrencia, pasos y reintentos. Define cuotas por usuario y organización, además de límites globales y mecanismos de cancelación. Registra consumo y latencia sin copiar indiscriminadamente contenido sensible.

Límite: limitar peticiones por minuto no acota el coste de cada petición. Un timeout local tampoco demuestra que un proveedor haya detenido el trabajo remoto. En sistemas distribuidos, las cuotas requieren coordinación: un contador en memoria de una instancia no controla el consumo agregado. Los umbrales deben responder al presupuesto y al comportamiento real de la aplicación, no a una cifra universal.

Un control pequeño en TypeScript: el modelo propone, el servidor decide

Imaginemos una herramienta que consulta el estado de una solicitud. El modelo propone un identificador, pero no decide la organización, el usuario ni los permisos. Este fragmento conceptual para un backend Node.js muestra esa separación; no es una API completa ni un SDK de un proveedor:

type Session = {
  userId: string;
  tenantId: string;
  permissions: readonly string[];
};

type TicketStatus = {
  id: string;
  status: 'open' | 'closed';
};

interface Tickets {
  findVisibleStatus(input: {
    ticketId: string;
    tenantId: string;
    userId: string;
  }): Promise<TicketStatus | null>;
}

async function readTicketStatus(
  proposedId: unknown,
  session: Session,
  tickets: Tickets,
): Promise<TicketStatus> {
  if (
    typeof proposedId !== 'string' ||
    !/^TKT-[1-9][0-9]{0,8}$/.test(proposedId)
  ) {
    throw new Error('Identificador inválido');
  }

  if (!session.permissions.includes('tickets:read')) {
    throw new Error('Operación no permitida');
  }

  const ticket = await tickets.findVisibleStatus({
    ticketId: proposedId,
    tenantId: session.tenantId,
    userId: session.userId,
  });

  if (!ticket) {
    throw new Error('Recurso no disponible');
  }

  return { id: ticket.id, status: ticket.status };
}

Hay tres contratos importantes fuera del fragmento:

• La sesión la establece el servidor tras autenticar al usuario. Nunca se construye a partir de afirmaciones del modelo o de campos que el cliente pueda elegir libremente.
• findVisibleStatus impone el acceso al objeto en la consulta. Debe comprobar organización y permisos sobre esa solicitud, usar parámetros y devolver null si no existe o no es accesible. Su nombre y su interfaz no implementan esa protección por sí solos.
• El adaptador HTTP controla los errores. Debe devolver respuestas estables, sin stack traces ni detalles internos. Los fallos de la base de datos deben impedir la operación, no provocar una consulta alternativa sin filtros.

La expresión regular solo acepta la forma del identificador. El permiso tickets:read habilita la operación general, pero no concede acceso a todas las solicitudes. Esa última decisión pertenece a la autorización por recurso.

Esta herramienta no acepta SQL, URLs ni nombres de funciones arbitrarias y devuelve únicamente dos campos. Es una elección de diseño para reducir superficie. Aun así, hacen falta límites de consumo, auditoría y pruebas del repositorio real. El fragmento no «soluciona los diez riesgos» ni demuestra cómo se comportará un modelo.

Qué cambia respecto de una aplicación web tradicional

Varias consecuencias son conocidas: XSS, consultas no autorizadas, filtraciones y agotamiento de recursos. Lo nuevo puede estar en la ruta que las provoca: una respuesta generada, un documento recuperado o una decisión de herramienta intermediada por lenguaje natural.

Esta comparación es una lectura de diseño de los riesgos anteriores. No implica que todos los fallos sean exclusivos de los LLM, ni que los controles web existentes sean prescindibles. Añadir IA amplía el análisis de amenazas; no reemplaza la seguridad de la API que la integra.

Cómo llevar la lista a una revisión útil

En una revisión de arquitectura, comenzaría por un recorrido concreto: una pregunta, los datos que entran, las herramientas disponibles y el efecto final. Después plantearía estas comprobaciones, priorizadas según el impacto del sistema:

1. Datos y permisos: verificar con usuarios de prueba que no cruzan documentos, historiales o cachés entre organizaciones ni niveles de acceso.
2. Acciones: intentar una operación fuera de alcance y comprobar que el servidor la deniega aunque la propuesta del modelo sea válida sintácticamente.
3. Salidas: revisar cada destino —interfaz, consulta, archivo o herramienta— y el control que necesita, en lugar de confiar en un único filtro genérico.
4. Cambios: repetir evaluaciones al modificar modelo, instrucciones, herramientas o fuentes documentales; registrar sus versiones para investigar regresiones.
5. Recursos y respuesta a incidentes: verificar límites efectivos y cómo desactivar una herramienta, retirar una fuente comprometida o revocar una credencial.

Son criterios prácticos para esta guía, no una garantía de cobertura completa. Las pruebas necesitan un alcance autorizado y evidencias reproducibles; un rechazo aislado del modelo no demuestra que todas las variantes de una entrada estén controladas.

La frontera importante está en lo que el sistema permite

Un asistente puede equivocarse al resumir y un agente puede proponer una acción que no corresponde. El diseño debe prever ambos casos: reducir la información expuesta, limitar capacidades y mantener las decisiones de autorización fuera de la generación.

El Top 10 sirve para formular preguntas sobre cada frontera. La respuesta útil no es «el prompt lo prohíbe», sino identificar qué componente aplica el control, cómo se comprueba y qué impacto queda si ese control falla.

Referencias oficiales

Consultadas el 4 de noviembre de 2026. Las fichas se enlazan también junto a cada riesgo para facilitar la comprobación de su alcance.

• OWASP Top 10 para aplicaciones LLM e IA generativa: edición 2025.
• LLM01: Prompt Injection.
• LLM02: Sensitive Information Disclosure.
• LLM03: Supply Chain.
• LLM04: Data and Model Poisoning.
• LLM05: Improper Output Handling.
• LLM06: Excessive Agency.
• LLM07: System Prompt Leakage.
• LLM08: Vector and Embedding Weaknesses.
• LLM09: Misinformation.
• LLM10: Unbounded Consumption.