El OWASP LLM Top 10 se convirtió en la referencia estándar para la seguridad de aplicaciones con IA — y, como todo Top 10, se convirtió también en un checklist que los equipos completan sin probar. "Cubrimos las diez categorías" suele significar que alguien leyó las diez descripciones.
Esta guía es lo contrario: lo que cada categoría significa cuando usted tiene las manos en el sistema, qué evidencia prueba la explotación y dónde se concentra la severidad real.
El punto de partida: mapear antes de probar
Ninguna de las diez categorías puede evaluarse sin un mapa de la superficie. Antes del primer payload, documente:
- Endpoints — quién llama al modelo, con qué autenticación, con qué límites de tasa.
- System prompts — el texto completo, incluyendo instrucciones inyectadas dinámicamente.
- Herramientas y plugins — cada función que el modelo puede invocar y lo que ella puede hacer.
- Pipeline RAG — de dónde vienen los documentos, quién puede escribir en ellos, cómo se indexan.
- Flujo de datos — lo que entra en el contexto, lo que sale, lo que se persiste.
Sin ese mapa, una prueba de LLM es una sesión de ensayo y error contra una caja negra. Con él, cada categoría a continuación tiene objetivos concretos.
LLM01 — Prompt Injection
Qué es. Entradas manipuladas que alteran el comportamiento del modelo, evaden guardrails o disparan acciones no intencionadas.
Qué probar. Separe directo de indirecto. El injection directo (el usuario es el atacante) es el caso fácil y el menos interesante. El injection indirecto — la instrucción llega dentro de un documento recuperado, de un correo procesado, de una página que el agente navegó — es donde ocurren los incidentes reales, porque no exige acceso del atacante al sistema.
Evidencia que vale. No es el modelo diciendo algo que no debería. Es el modelo ejecutando algo que no debería: una llamada de herramienta no autorizada, un dato que atravesó un límite de tenant, una acción de escritura disparada por texto de un tercero.
LLM02 — Tratamiento inseguro de la salida
Qué es. La salida del modelo se consume aguas abajo sin validación — y se convierte en XSS, SSRF, inyección de comando o de SQL.
Qué probar. Siga la salida. ¿Se renderiza en HTML? ¿Se pasa a un shell? ¿Se interpola en una query? ¿Se usa como URL? Cada uno de esos destinos es una vulnerabilidad tradicional con un nuevo punto de entrada.
Por qué importa. Esta es la categoría que convierte un problema de IA en RCE. Trate la salida del modelo exactamente como trata el input de usuario no confiable — porque es eso lo que es.
LLM03 — Envenenamiento de datos de entrenamiento
Qué es. Manipulación de datos de preentrenamiento, fine-tuning o embedding para introducir sesgos o backdoors.
Qué probar. En evaluaciones de aplicación, el objetivo práctico rara vez es el preentrenamiento — es el corpus de embeddings. ¿Quién puede escribir en el vector store? ¿Un ticket de soporte enviado por un cliente termina indexado? Si es así, el control de acceso de escritura al índice es un control de seguridad de primer orden.
LLM04 — Denegación de servicio del modelo
Qué es. Operaciones que degradan el rendimiento, inflan el costo o tumban el servicio.
Qué probar. Agotamiento de la ventana de contexto, prompts recursivos, expansión descontrolada de llamadas de herramienta. Mida el costo, no solo la latencia: en arquitecturas con agentes, un único input puede disparar una cascada de llamadas pagas.
LLM05 — Supply chain
Qué es. Modelos preentrenados, datasets, plugins y extensiones de terceros que arrastran vulnerabilidades.
Qué probar. Procedencia de los pesos, verificación de integridad, formato de serialización, permisos de los plugins instalados. La pregunta de auditoría es directa: si el repositorio de origen del modelo fuera comprometido hoy, ¿usted lo sabría?
LLM06 — Divulgación de información sensible
Qué es. Exposición de PII, secretos o system prompts vía respuestas o canales laterales.
Qué probar. Fuga de system prompt (subestimada — es el mapa de las herramientas y los límites), fuga entre tenants en contexto compartido, PII recuperada de documentos que el usuario no debería alcanzar. Verifique el control de acceso en la recuperación, no solo en la interfaz.
LLM07 — Diseño inseguro de plugins
Qué es. Integraciones de herramientas que permiten acciones no autorizadas o ejecución de código.
Qué probar. Cada plugin como una API sin autenticación, porque en la práctica es eso: quien autoriza la llamada es el modelo, y el modelo es influenciable por texto. ¿Parámetros validados? ¿Alcance verificado por usuario o heredado del servicio? Un plugin que se ejecuta con credencial de servicio convierte cualquier injection en escalación.
LLM08 — Agencia excesiva
Qué es. Permisos o autonomía más allá de lo necesario — explotables para acciones arbitrarias.
Qué probar. Enumere las capacidades reales y compárelas con el caso de uso declarado. Un asistente de lectura con permiso de escritura, un agente de triaje con acceso a producción, una integración con token de administrador porque "era más simple".
Por qué importa. Esta categoría es el multiplicador de severidad de todas las demás. Reducir la agencia es la mitigación con mejor relación costo-beneficio en seguridad de IA — y no depende de que el modelo resista a nada.
LLM09 — Dependencia excesiva
Qué es. Confiar en la salida del modelo sin validación — decisiones erradas, código vulnerable, desinformación.
Qué probar. Es tanto control de proceso como técnico. ¿Existe revisión humana donde la decisión tiene consecuencia? ¿El código generado pasa por el mismo gate de seguridad que el código escrito a mano? En flujos financieros o clínicos, ¿el modelo decide o recomienda?
LLM10 — Robo de modelo
Qué es. Extracción, replicación o exfiltración no autorizada de modelos y pesos propietarios.
Qué probar. Extracción por consulta masiva, acceso directo al artefacto de pesos, exposición del endpoint de model serving. Para la mayoría de las empresas que consumen modelos de terceros, esta es la categoría de menor prioridad — lo que no significa que los controles de almacenamiento y acceso puedan ignorarse.
Dónde se concentra realmente la severidad
En las evaluaciones que conducimos, los hallazgos críticos se agrupan en tres categorías: LLM02 (tratamiento de la salida), LLM07 (diseño de plugins) y LLM08 (agencia excesiva). Las tres comparten una característica: no son fallas del modelo. Son fallas de la aplicación alrededor del modelo.
Esto tiene una consecuencia práctica incómoda. Cambiar el modelo por uno más alineado no resuelve ninguna de ellas. Lo que resuelve es la arquitectura — validación de salida, alcance de autorización por usuario, principio de menor privilegio en las herramientas.
LLM01 sigue siendo la categoría con mayor volumen de hallazgos. Pero volumen no es severidad: el prompt injection aislado, en un sistema sin agencia y con salida validada, es una molestia. El prompt injection en un agente con permiso de escritura y herramientas con credencial de servicio es compromiso.
Del informe a la decisión
Una prueba OWASP LLM Top 10 que entrega diez secciones y una lista de hallazgos no resuelve el problema del CISO, que es el orden de corrección. Lo que cierra esa brecha:
- Evidencia reproducible por hallazgo — el payload, la respuesta, el efecto observable. Si no se reproduce, no es hallazgo.
- Clasificación por impacto al negocio, no por categoría OWASP. LLM08 en un chatbot público y LLM08 en un agente con acceso al ERP no son el mismo riesgo.
- Vínculo con la kill chain. Un hallazgo que solo permite la etapa 1 es distinto de uno que encadena hasta la exfiltración.
El Top 10 es un buen mapa de cobertura. No es, por sí solo, un programa de seguridad.
Nuestro pentest de IA/LLM cubre las diez categorías con PoC reproducible y clasificación AI-VRM. Vea también el Promptware Kill Chain para el modelo de encadenamiento de hallazgos.