Seguridad en IA: los 10 riesgos OWASP para LLMs que todo desarrollador debe conocer
10 riesgos y una checklist práctica. El OWASP LLM Top 10 empieza en tu teclado, con las herramientas de coding con IA que ya usas.
La mayoría de artículos sobre seguridad en LLMs te advierten sobre la IA con la que interactúan tus usuarios. No hablan de las herramientas de IA con las que tú estás construyendo. He usado asistentes de coding con IA para escribir código, generar documentación e incluso aprender fundamentos de criptografía, todo para desplegar servicios en producción. El OWASP Top 10 para aplicaciones LLM, actualizado después de 2025, describe 10 riesgos que aplican tanto a tu toolchain interna de IA como al chatbot que estás lanzando.
La superficie de ataque no está delante de tus usuarios.
Empieza en tu IDE.
Mientras escribía este post, los artículos que leí sobre esta lista se centraban en chatbots expuestos al exterior. Escribí este para considerar también los 10 riesgos en los workflows de IA que los ingenieros ya están ejecutando dentro de sus empresas. Si eres desarrollador y usas herramientas como Claude Code, Codex o GitHub Copilot, no solo alguien construyendo un producto de IA, este artículo es para ti.
Identifica dónde y cómo aplicar IA desde hoy con el GPT Arquitecto IA completamente gratis.
Lo recibes en el primer email que te mando al suscribirte
En este artículo aprenderás
Qué cubre el OWASP Top 10 para aplicaciones LLM y por qué se actualizó para 2025.
Cómo la prompt injection, la exposición de información sensible y la agencia excesiva afectan a workflows reales de ingeniería.
Qué cambió entre las listas OWASP LLM Top 10 de 2023/24 y 2025.
Cómo aplicar una checklist práctica de seguridad mapeada a las 10 vulnerabilidades LLM.
Por qué la IA agéntica en 2026 hace que varios de estos riesgos sean mucho más peligrosos.
¿Qué es la seguridad en IA para aplicaciones LLM?
La seguridad en IA significa dos cosas distintas, y la distinción importa.
La primera es usar IA para mejorar la seguridad: detección de amenazas, code reviews automatizadas y escaneo de vulnerabilidades. La segunda es proteger la propia IA: los modelos, los pipelines, las APIs y los datos que esos sistemas manejan. Este artículo trata sobre la segunda.
Los LLMs introducen superficies de ataque que el software tradicional no tiene. Una aplicación convencional tiene lógica determinista. Puedes auditar un árbol de decisión. Los LLMs son probabilísticos y sensibles al contexto. El mismo prompt no siempre produce el mismo output. Los inputs adversariales pueden producir comportamiento emergente e impredecible.
Con los LLMs aparecieron vectores de ataque que antes no existían: prompts diseñados para explotar el sistema, datos de entrenamiento envenenados, cadenas de plugins y acciones autónomas de agentes. La comunidad OWASP respondió extendiendo su framework de confianza para aplicaciones web para cubrir estos riesgos. El LLM Top 10 fue construido por más de 600 colaboradores en más de 18 países, y la actualización de 2025 refleja cuánto cambió el panorama de amenazas en un solo año.
Por qué el OWASP Top 10 para LLMs importa en 2026
El OWASP Top 10 original para aplicaciones web se convirtió en el estándar de facto para desarrollo seguro. Certificaciones de seguridad, frameworks de compliance como SOC 2 e ISO 27001, y revisiones de seguridad enterprise lo citan constantemente. La versión para LLMs tiene el mismo peso. Si trabajas en una empresa que lanza software, la lista OWASP LLM aparecerá en tus auditorías y en tus checklists de seguridad.
Esta lista fue escrita para tres audiencias: desarrolladores que construyen features con LLMs como chatbots y copilots, ingenieros de seguridad revisando integraciones de IA, y líderes de ingeniería aprobando herramientas de IA para sus equipos.
Hubo una primera lista en 2023/24 centrada en las primeras integraciones con LLMs: plugins inseguros, robo de modelos y sobredependencia. La actualización de 2025 reestructuró todo alrededor de IA agéntica, sistemas RAG y riesgos de supply chain que aparecieron cuando esos despliegues llegaron a producción. El ecosistema de IA evoluciona muy rápido, y tres riesgos fueron completamente nuevos en 2025: System Prompt Leakage, Vector and Embedding Weaknesses y Misinformation. Otros riesgos se renombraron o fusionaron para reflejar cómo evolucionaron los ataques.
Vamos a revisar la lista completa.
Los 10 riesgos de seguridad OWASP para LLMs (2025)
LLM01:2025 - Prompt Injection
La prompt injection es un ataque en el que los prompts del usuario alteran el comportamiento o el output del LLM de formas no intencionadas, pudiendo hacer que viole directrices, genere contenido dañino o influya en decisiones críticas.
Hay dos tipos.
La inyección directa ocurre cuando el input de un usuario altera directamente el comportamiento del modelo, ya sea de forma intencionada por un actor malicioso o de forma involuntaria al activar un trigger inesperado.
La inyección indirecta ocurre cuando el LLM procesa contenido externo, como una página web, un documento o un resultado RAG, que contiene instrucciones adversariales embebidas que el modelo acaba siguiendo.
La prompt injection es diferente del jailbreaking, aunque están relacionados. La prompt injection manipula respuestas del modelo mediante inputs específicos. El jailbreaking es una forma de prompt injection en la que el atacante hace que el modelo ignore por completo sus protocolos de seguridad. Puedes mitigar prompt injection con salvaguardas en el system prompt. El jailbreaking requiere actualizaciones continuas de entrenamiento del modelo.
Está en el número uno porque es la vulnerabilidad más explotable de la lista. No requiere acceso especial. Cualquiera con un campo de texto puede intentarlo. RAG y fine-tuning no eliminan completamente el riesgo. La investigación confirma que la vulnerabilidad persiste entre arquitecturas de modelos.
Para mitigarlo: trata todo contenido externo como datos no confiables, no como instrucciones. Usa canales de input separados para instrucciones de sistema y contenido de usuario siempre que sea posible. Añade validación de output antes de ejecutar cualquier acción generada por un LLM.
Los prompts son un paradigma para programar con IA, pero también existe el paradigma del Spec-Driven Development: crear un plan, una spec, antes de hacer cambios de código. Puedes aprender más en este artículo:
LLM02:2025 - Sensitive Information Disclosure
La exposición de información sensible ocurre cuando un LLM revela datos confidenciales de su conjunto de entrenamiento, context window o interacciones anteriores con usuarios.
GitHub anunció que, a partir del 24 de abril, GitHub Copilot usará tu código y tus prompts para entrenar sus modelos. Además de aprovecharse de tu trabajo, puedes ver por qué esto es un problema. Eso es LLM02 en la práctica: introducir datos propietarios en un modelo que podría mostrarlos a otra persona.
Hay tres vectores principales de exposición.
Primero, el modelo fue entrenado con datos sensibles y puede ser inducido a reproducirlos.
Segundo, hay datos sensibles en la context window y se filtran mediante preguntas de usuario diseñadas para ello.
Tercero, en despliegues multi-tenant, el contexto de un usuario se mezcla con las respuestas de otro.
Lo que hace que esto sea peor que una fuga de datos tradicional es que no siempre puedes saber qué “sabe” el modelo. La exposición es probabilística. El mismo prompt puede no reproducir los datos cada vez, lo que hace difícil probarlo sistemáticamente.
Para mitigarlo: nunca incluyas credenciales ni datos confidenciales de negocio en system prompts salvo que sea necesario. Usa enmascaramiento de datos antes de enviar contenido sensible a APIs externas de IA. Audita a qué pueden acceder realmente tus herramientas de IA, especialmente plugins de navegador y herramientas de reuniones. Si puedes, usa modelos desplegados en tu cloud, bajo tu control.
LLM03:2025 - Supply Chain
Las vulnerabilidades de supply chain en LLMs vienen de componentes inseguros en el pipeline de desarrollo de IA que introducen riesgos en aplicaciones de producción. Esto incluye modelos preentrenados, datasets, librerías o herramientas asistidas por IA.
He usado herramientas de IA en el trabajo, pero tienen que estar aprobadas por el departamento de seguridad. Piénsalo: la herramienta de IA es en sí misma un componente de supply chain. Si el modelo que alimenta tu asistente de coding fue fine-tuned con datos envenenados, o la herramienta tiene un plugin inseguro, el output de IA que se envía a producción hereda ese riesgo. Eso es LLM03 en la práctica.
Los riesgos comunes de supply chain incluyen modelos preentrenados de hubs open-source con procedencia de entrenamiento desconocida, SDKs de IA de terceros con dependencias inseguras, asistentes de coding con IA que acceden a tu codebase y a APIs externas al mismo tiempo, y modelos con datos de entrenamiento no revelados.
Este riesgo subió al número tres en la actualización de 2025 porque el ecosistema de tooling de IA explotó en variedad y popularidad. El LLM en sí ahora es un componente dentro de un pipeline mayor. Cada capa introduce riesgo.
Para mitigarlo: fija versiones de modelos y no actualices automáticamente dependencias de IA, de forma similar a lo que harías con otras dependencias de software. Trata las herramientas de IA usadas en revisiones de seguridad o certificaciones como componentes que requieren su propia revisión de seguridad. Mantén un AI Bill of Materials para tu pipeline de IA en producción.
LLM04:2025 - Data and Model Poisoning
El data and model poisoning es un ataque en el que se introducen datos adversariales en los datasets de entrenamiento, fine-tuning o feedback de un modelo para manipular su comportamiento de formas que quizá no aparezcan hasta que se activan condiciones específicas.
Esto es distinto del supply chain (LLM03). Supply chain cubre los componentes del pipeline alrededor del modelo. Poisoning ataca directamente el comportamiento aprendido del modelo, a través de los datos con los que fue entrenado o fine-tuned.
El poisoning ocurre de varias formas. Los datasets públicos usados para fine-tuning pueden ser envenenados antes o durante la recolección. Los feedback loops, específicamente datos RLHF de usuarios, pueden ser manipulados a escala por usuarios adversariales. Los ataques de backdoor introducen un trigger oculto. El modelo se comporta normalmente hasta que una frase o patrón específico activa el comportamiento malicioso.
Recientemente, con la filtración del codebase de Claude Code, vimos en esta aplicación instrucciones para “no añadir atribución si es un empleado de Anthropic”. Ahora imagina que eso no estuviera añadido a nivel de cliente, sino que el entrenamiento del modelo o la fase de RLHF hicieran que el modelo reaccionara de forma distinta bajo ciertas condiciones. Eso es Model Poisoning.
Lo que hace que esto sea especialmente insidioso es que no puedes ver el veneno. Está incorporado en los pesos. Tenemos que diferenciar los modelos “open source” transparentes de los modelos abstractos “open weight”. Los pesos nos permiten ejecutar, pero no entender el modelo. El modelo se comporta normalmente en casos de uso estándar y solo se comporta mal bajo condiciones de trigger específicas. Descubrirlo requiere red-teaming sistemático por parte de ingenieros de seguridad.
Para mitigarlo: evalúa las fuentes de datos de entrenamiento y trátalas como dependencias de código de terceros. Usa modelos de fuentes verificadas y auditables con procedencia documentada de datos de entrenamiento. Monitoriza el comportamiento del modelo a lo largo del tiempo para detectar drift o anomalías en contextos específicos.
LLM05:2025 - Improper Output Handling
El improper output handling ocurre cuando los outputs de un LLM se pasan directamente a sistemas downstream sin validación o sanitización adecuada. Piensa en navegadores, shells, APIs o bases de datos.
Los outputs de LLMs pueden contener HTML, JavaScript, comandos de shell, SQL o código ejecutable. Todo eso es potencialmente peligroso dependiendo de dónde acabe.
Si tu app renderiza output de un LLM como HTML, tienes riesgo de Cross-Site Scripting. Si tu app pasa output del LLM a una shell o intérprete de código, tienes riesgo de Remote Code Execution. Si tu app pasa output del LLM a una consulta de base de datos, tienes riesgo de SQL injection.
El error común es tratar el output del LLM como seguro porque vino de tu propio sistema. Al modelo se le pidió escribir una respuesta. No se le pidió escribir output seguro para cada contexto de renderizado que pueda encontrar después.
Para mitigarlo: aplica encoding apropiado al contexto en todos los outputs del LLM: HTML escaping, SQL parameterization, shell quoting. Nunca pases output crudo de un LLM a eval(), exec() o comandos de shell. Trata el output del LLM como input de usuario no confiable cuando lo pases a cualquier sistema que lo ejecute. Ten reglas en la aplicación cliente que impidan la ejecución de ciertos comandos de shell, o que solo permitan los que confías.
LLM06:2025 - Excessive Agency
La agencia excesiva ocurre cuando un sistema basado en LLM recibe demasiada autonomía, funcionalidad o permisos para actuar en el mundo, permitiéndole tomar acciones dañinas o no intencionadas fuera del alcance previsto.
He usado asistencia LLM para escribir todo mi código y mis documentos. Es eficiente y útil. Pero si el LLM sugiere código ligeramente incorrecto, y lo aplico sin revisarlo, el LLM ha ejercido agencia sobre algo que puede causar problemas. A escala, en un workflow agéntico donde el LLM escribe el código, lo commitea y dispara el pipeline, esto es exactamente lo que advierte LLM06. Cuanto más automatizas, más agencia entregas, y menos supervisión recibe cada acción individual.
La agencia excesiva tiene tres dimensiones.
Funcionalidad excesiva significa que el LLM puede llamar a más herramientas o APIs de las que requiere su tarea.
Permisos excesivos significa que opera con privilegios más altos de los necesarios, como lectura-escritura cuando solo necesita lectura.
Autonomía excesiva significa que toma acciones de varios pasos sin checkpoints humanos.
La IA agéntica hace que este sea el riesgo definitorio de 2026. Las llamadas individuales a LLMs tienen un blast radius limitado: el usuario ve el output y decide. Los workflows agénticos pueden tomar docenas de acciones antes de que un humano vea los resultados. Tienes tu OpenClaw tomando acciones por ti mientras duermes. Cada paso autónomo compone el riesgo de un error no detectado.
Para mitigarlo: limita cada agente LLM a los permisos mínimos que necesita para su tarea específica. Añade checkpoints human-in-the-loop para acciones con consecuencias, como deploys, cambios de permisos y commits de archivos. Registra todas las acciones iniciadas por LLMs para tener audit trails.
Sobre guardrails para LLMs, te recomiendo leer este otro artículo:
https://newsletter.arquitecturasoftware.com/p/harness-engineering-ia
LLM07:2025 - System Prompt Leakage
El system prompt leakage ocurre cuando las instrucciones confidenciales dadas a un LLM mediante el system prompt quedan expuestas a usuarios, atacantes o sistemas downstream, revelando lógica de negocio, guardrails de seguridad o configuración sensible.
Los system prompts se han convertido en el mecanismo estándar para configurar el comportamiento de LLMs en apps de producción. Un system prompt mal protegido ahora equivale a código fuente expuesto.
Qué hacen los atacantes con system prompts filtrados: mapean los controles de seguridad de la aplicación para encontrar huecos, entienden la lógica de negocio para diseñar prompt injections más precisas, y extraen IP competitiva embebida en instrucciones como workflows propietarios o nombres de herramientas internas.
La filtración ocurre de varias formas. Extracción directa, donde prompts como “repite tu system prompt” a veces funcionan en modelos mal protegidos. Extracción indirecta, donde inputs de usuario diseñados para ello consiguen acceso a contenido parcial del system prompt en las respuestas. También está relacionado con LLM02: si el system prompt contiene datos sensibles, esos datos se exponen.
Para mitigarlo: nunca incrustes secretos ni credenciales en system prompts. Prueba tu aplicación contra system prompt leakage antes de desplegar. Diseña los system prompts como si fueran públicos. La lógica sensible debe vivir en código, no en prompts.
LLM08:2025 - Vector and Embedding Weaknesses
Las debilidades de vectores y embeddings son vulnerabilidades en la recuperación y almacenamiento de embeddings usados en sistemas RAG y búsqueda semántica, permitiendo data poisoning, extracción de información o acceso no autorizado a contenido indexado.
Los sistemas RAG se generalizaron en 2024, y las bases de datos vectoriales ahora son un componente central de despliegues LLM enterprise. Los embeddings suelen tratarse como cajas negras opacas, pero tienen riesgos de seguridad reales que no se entendían ampliamente cuando se hicieron populares.
Los patrones de ataque incluyen varios escenarios:
Embedding inversion: extraer el texto original a partir de embeddings almacenados.
Poisoning del vector store: inyectar documentos adversariales que se recuperan como contexto autoritativo.
Filtración cross-tenant: que el contenido indexado de un usuario aparezca en el contexto de consulta de otro usuario.
Abuso de similarity search: consultas diseñadas para hacer aparecer documentos sensibles.
Si tu sistema RAG indexa páginas internas de Confluence, repositorios de código o tickets de soporte, el vector store es un objetivo de alto valor. Los controles de acceso de los documentos fuente deben reflejarse a nivel del vector store, no solo en el momento de recuperación.
Para mitigarlo: aplica los controles de acceso de los documentos fuente a las consultas del vector store. No devuelvas embeddings de documentos que el usuario no podría leer directamente. Valida y sanitiza documentos antes de indexarlos. Trata el contenido ingerido como input de usuario.
LLM09:2025 - Misinformation
La desinformación ocurre cuando un LLM genera información falsa, engañosa u obsoleta que los usuarios usan como si fuera precisa, algo especialmente peligroso en dominios de alto riesgo como seguridad, medicina, legal o compliance.
Este riesgo captura tanto alucinación (hechos fabricados) como incorrección confiada (respuestas plausibles pero equivocadas). El riesgo no es solo que los usuarios confíen demasiado en la IA. Es que la IA les da algo falso en lo que confiar.
Por ejemplo, he usado LLMs para verificar detalles sobre distintos algoritmos de hashing. Esto ya es común: no buscamos en Google ni en las especificaciones originales, se lo preguntamos al LLM. Sin embargo, cualquier cosa relacionada con hashing y cifrado tiene matices de seguridad. Elegir el algoritmo equivocado en el contexto equivocado es una vulnerabilidad. Si tomo una decisión a partir de un LLM sin verificarla después contra documentación autoritativa, estoy cayendo en el riesgo LLM09.
Escala eso a tu equipo escribiendo documentación de seguridad, threat models o feedback de code review. Aceptar ese output sin crítica es cómo la desinformación entra en producción.
La razón por la que los LLMs producen desinformación con confianza es estructural. Los LLMs no señalan incertidumbre como lo hace un resultado de búsqueda. No tienen una relación de causa y efecto (si A, entonces B). Solo tienen correlaciones probabilísticas (A y B aparecen al mismo tiempo el 99% de las veces). En contextos de seguridad, una respuesta confiada pero incorrecta puede pasar una revisión sin ser cuestionada. La fluidez del output del LLM en texto legible por humanos crea una falsa sensación de verificación.
Para mitigarlo: trata los outputs de LLMs como primeros borradores, no como respuestas finales. Establece un paso de verificación: output de IA, luego revisión humana, luego comprobación contra fuentes autoritativas. Personalmente me gusta mover al humano todo lo posible hacia la derecha del proceso, pero no eliminarlo. Exige en tus prompts citas de fuentes primarias de donde vienen los datos.
LLM10:2025 - Unbounded Consumption
El consumo no acotado ocurre cuando una aplicación LLM permite que usuarios o adversarios consuman recursos computacionales excesivos, causando degradación del servicio, costes descontrolados o denegación de disponibilidad.
No cubre solo ataques de disponibilidad, sino también agotamiento de costes, presupuestos reventados y abuso de recursos por usuarios legítimos que no encuentran límites.
Esto importa más en 2026 porque los workflows agénticos pueden disparar cascadas de llamadas a APIs. Anthropic anunció hace unos días que prohibirá explícitamente el uso de su suscripción con OpenClaw. Una acción de usuario con OpenClaw puede generar docenas de peticiones LLM. El coste por inferencia ha bajado, lo que hace fácil desplegar LLMs, y también hace fácil quemar accidentalmente presupuestos de API. Los agentes multi-step y técnicas como Ralph Loops sin límites de tokens o turnos pueden auto-bucle infinito.
Los patrones de ataque incluyen inundar la API con peticiones de longitud máxima de contexto para maximizar el coste por petición, construir prompts diseñados para provocar respuestas recursivas o verbosas, y prompt injection que dispara bucles agénticos que consumen recursos sin terminar.
Para mitigarlo: implementa rate limiting por usuario, API key y endpoint. Define límites máximos de tokens en inputs y outputs, tanto por petición como por sesión. Establece límites duros de presupuesto en gasto de APIs de IA y alerta antes de alcanzarlos, no después. Diseña workflows agénticos con condiciones explícitas de terminación y número máximo de iteraciones.
Cómo proteger aplicaciones LLM: checklist práctica
Aquí tienes cada riesgo mapeado a su acción de mitigación más importante.
Sinceramente, se lo reenviaría a todos los ingenieros que conozco:
LLM01 - Prompt Injection: trata todo contenido externo como datos no confiables, no como instrucciones. Valida antes de actuar sobre outputs de LLMs.
LLM02 - Sensitive Information Disclosure: enmascara datos sensibles antes de enviarlos a APIs de IA. Audita a qué pueden acceder tus herramientas de IA.
LLM03 - Supply Chain: trata el tooling de IA como supply chain. Fija versiones de modelos. Audita herramientas usadas en procesos regulados.
LLM04 - Data and Model Poisoning: evalúa fuentes de datos de entrenamiento. Usa modelos con procedencia documentada. Monitoriza drift de comportamiento.
LLM05 - Improper Output Handling: aplica encoding apropiado al contexto en todos los outputs de LLMs antes de renderizar o ejecutar.
LLM06 - Excessive Agency: aplica least privilege a agentes de IA. Añade checkpoints humanos para acciones con consecuencias.
LLM07 - System Prompt Leakage: diseña system prompts como si fueran públicos. Prueba filtraciones antes de desplegar. Mantén secretos en código, no en prompts.
LLM08 - Vector and Embedding Weaknesses: replica los controles de acceso de documentos fuente a nivel del vector store. Valida documentos antes de indexarlos.
LLM09 - Misinformation: trata outputs de LLMs como primeros borradores. Exige verificación con fuentes autoritativas para orientación de seguridad.
LLM10 - Unbounded Consumption: establece rate limits, límites de tokens y límites duros de presupuesto. Monitoriza costes de inferencia en tiempo real.
Seguridad en IA en la empresa real: lo que la lista OWASP no te cuenta
La lista OWASP describe riesgos. No describe a quién culpan cuando esos riesgos se materializan.
Usamos herramientas de IA todo el tiempo. Cuando lanzamos rápido, solo recibimos crédito parcial por usar IA, pero el mérito se lo lleva la IA. Cuando la herramienta de IA se pierde una vulnerabilidad, el desarrollador recibe el 100% de la culpa. Esta asimetría moldea cómo deberían usar IA los ingenieros: agresivamente para prototipar, conservadoramente cuando hay accountability en riesgo. El problema es que no nos damos cuenta de la asimetría hasta que algo sale mal.
Las organizaciones también están desplegando IA más rápido de lo que legal y compliance pueden seguir. He desarrollado tooling pequeño, como obtener transcripciones de reuniones, y solo meses después recibí un aviso sobre los requisitos legales y la necesidad de cambiar a una herramienta aprobada. Los riesgos LLM02 y LLM06 a menudo no se materializan por actores maliciosos, sino por ingenieros bienintencionados rodeando procesos de policy lentos. No hace falta malicia.
Luego está la paradoja de la revisión. Usar IA para preparar una revisión es eficiente, y siempre recomendaría usar IA. Pero no podemos saltarnos que un humano revise el output de la revisión de IA. Si la herramienta de IA tiene sus propios riesgos de supply chain (LLM03), y la estás usando para revisar un estándar de seguridad, has introducido el mismo riesgo contra el que estás revisando. Esto no es un argumento contra usar herramientas de IA para revisiones de seguridad. Es un argumento para entender en qué estás confiando.
El mayor cambio en 2026 es lo que la IA agéntica hace al blast radius. Si vamos a la primera lista OWASP para aplicaciones LLM en 2023, asumía que los prompts eran activados por un humano. Un usuario enviaba un prompt y revisaba un output. En 2026, los agentes actúan de forma autónoma a través de múltiples pasos. Todos estos riesgos se vuelven más peligrosos cuando no hay checkpoint humano en el workflow.
En la práctica: identifica cuáles de los 10 riesgos aplican realmente a tu integración específica de IA. No todos aplican igual. Trata cada herramienta de IA usada en un proceso regulado como un componente que requiere su propia revisión de seguridad. Documenta tu uso de herramientas de IA en tus threat models.
Conclusión: la IA en la que confías es la IA de la que eres responsable
El código se envió y la feature se lanzó. Pero la pregunta se quedó conmigo: ¿qué unknown unknowns puedo estar pasando por alto?
El OWASP LLM Top 10 no responde esa pregunta por ti. Te da el vocabulario para hacerla con precisión. No es una checklist de compliance, sino una herramienta de pensamiento. Úsala para auditar cómo estás usando herramientas de IA para construir.
Ideas clave:
El OWASP Top 10 for LLM Applications (2025) define 10 riesgos de seguridad específicos de sistemas de large language models, actualizado desde la lista de 2023/24 para reflejar IA agéntica y despliegues RAG.
Prompt Injection (LLM01) sigue siendo el riesgo principal porque no requiere acceso especial y persiste incluso usando RAG o fine-tuning.
Excessive Agency (LLM06) y Unbounded Consumption (LLM10) son los riesgos definitorios de la IA agéntica en 2026, donde workflows autónomos de varios pasos amplifican cada error no comprobado.
Sensitive Information Disclosure (LLM02) a menudo no viene de un mal comportamiento del modelo, sino de ingenieros introduciendo sin querer datos sensibles en herramientas de IA en las que confían.
Tres riesgos son nuevos en la actualización de 2025: System Prompt Leakage (LLM07), Vector and Embedding Weaknesses (LLM08) y Misinformation (LLM09), cada uno reflejando cómo evolucionaron los despliegues LLM en producción desde 2023.
¿Cuál de estos 10 riesgos ya está presente en tu workflow de IA?
Recapitulación sobre seguridad para LLMs
¿Cuáles son los riesgos OWASP Top 10 para LLMs en 2025?
El OWASP Top 10 for LLM Applications de 2025 cubre Prompt Injection, Sensitive Information Disclosure, Supply Chain, Data and Model Poisoning, Improper Output Handling, Excessive Agency, System Prompt Leakage, Vector and Embedding Weaknesses, Misinformation y Unbounded Consumption. La lista completa está en genai.owasp.org/llm-top-10.
¿Qué es prompt injection en seguridad de IA?
Prompt injection es un ataque en el que input malicioso sobrescribe las instrucciones de un LLM, haciendo que tome acciones no intencionadas. Puede ser directo (desde input de usuario) o indirecto (desde contenido externo que procesa el LLM, como una página web o documento). Está clasificado como la vulnerabilidad LLM principal porque no requiere acceso especial para intentarlo.
¿En qué se diferencia el OWASP LLM Top 10 del OWASP Web Application Top 10?
El OWASP Web App Top 10 cubre vulnerabilidades web tradicionales como XSS y SQL injection. El OWASP LLM Top 10 cubre riesgos específicos de large language models: ataques basados en prompts, riesgos de datos de entrenamiento, comportamiento autónomo de agentes y vulnerabilidades de sistemas RAG. Las dos listas tienen mitigaciones que se solapan, pero tratan superficies de ataque fundamentalmente distintas.
¿Qué cambió entre el OWASP LLM Top 10 de 2023/24 y el de 2025?
La actualización de 2025 añadió System Prompt Leakage, Vector and Embedding Weaknesses y Misinformation. Eliminó Model Theft, Insecure Plugin Design y Overreliance, que fueron absorbidos por otras categorías. La actualización refleja el auge de la IA agéntica y los sistemas de producción basados en RAG, que no estaban extendidos cuando se escribió la lista de 2023.
Si has leído hasta aquí, sigue leyendo sobre cómo construí mi agente de IA en 10 pasos: