Auditoría de seguridad LLM con OWASP Top 10

Cuando tu código llama a un modelo de lenguaje, el input del usuario puede secuestrar las instrucciones del sistema. Este es el riesgo central al auditar vulnerabilidades en aplicaciones con LLM, un tema clave para desarrolladores que integran endpoints de IA en productos reales como sistemas de soporte.

Imagina que Payments USC tiene un endpoint moderno, llmsupport.py, que toma la consulta del usuario y la pasa a un LLM para responder preguntas de soporte. Es la clase de funcionalidad que todos estamos agregando hoy. Y aquí viene lo interesante: introduce un tipo de vulnerabilidad completamente nuevo.

Por qué un LLM no distingue entre instrucciones y ataques

Un modelo de lenguaje no puede diferenciar de forma confiable lo que le dijo el desarrollador de lo que le está diciendo el usuario. Todo es texto en la misma ventana. Ese es el problema de raíz.

Si el LLM tiene privilegios altos, por ejemplo acceso a datos de cuentas, un usuario con privilegios bajos puede convertirlo en lo que conocemos como confused deputy. En otras palabras, un intermediario confundido que ejecuta acciones que no debería.

¿Qué es un confused deputy en seguridad LLM? Es cuando un componente con privilegios altos, como un LLM con acceso a cuentas, es manipulado por un usuario de bajos privilegios para ejecutar acciones no autorizadas en su nombre.

El mapa que usamos aquí no es el clásico OWASP Web Top 10, sino el OWASP Top 10 for LLM Applications, diseñado específicamente para estos escenarios.

Cuáles son las tres vulnerabilidades que debes auditar

La auditoría se centra en tres riesgos concretos que aparecen cuando conectas un modelo a datos sensibles [00:38].

1. El injection vector: determinar si el input del usuario se está concatenando directamente junto al prompt.
2. El system prompt leak: generar payloads para comprobar si el usuario puede engañar al LLM para que revele sus instrucciones internas completas.
3. La excessive agency o exceso de agencia: verificar si el LLM tiene más permisos o más herramientas de las que esa función de soporte realmente necesita.

El archivo preparado para la clase, LLM_supports, tiene un problema deliberado: en algún punto del código concatena la consulta directa del usuario con el system prompt. Y ese LLM tiene acceso a una herramienta de lectura de cuentas. Una fuente de confusión servida en bandeja.

Cómo funciona el script que detecta los riesgos

Se creó un script que resalta los tres riesgos dentro del archivo [01:35]. Sirve para dos cosas: que seamos conscientes de que el problema existe y que la IA que lo analizará después lo tenga como evidencia.

Al ejecutarlo, cada una de las tres categorías recibe un score. La lógica es simple pero potente: una vez arreglado el problema, si corres el script de nuevo, esperarías que ya no aparezca.

¿Para qué sirve un score de vulnerabilidad antes de arreglar el código? Funciona como línea base verificable. Si el score desaparece tras aplicar la mitigación, confirmas que el fix realmente resolvió el problema y no solo lo ocultó.

Cómo usar la IA como revisor de seguridad de aplicaciones

La idea es pasar toda esta evidencia a la IA para que actúe como revisor de seguridad de aplicaciones usando un LLM [02:10]. No se trata de delegar a ciegas, sino de darle contexto muy preciso.

El contexto que se le entrega incluye reglas claras:

• El repositorio y la branch actual, tratada como si fuera un pull request a develop.
• La ruta específica a revisar.
• El sistema usa un cliente falso determinista, así que no debe asumir llamadas a proveedores externos.
• No debe fabricar información de GitHub, CI, revisores o historiales remotos.

Con ese marco, la tarea es concreta. Se le pide proponer payloads de prompt injection directos contra el endpoint del LLM y payloads indirectos que simulen instrucciones maliciosas embebidas en el contenido del usuario.

Qué payloads debe generar el auditor con IA

Entre los escenarios adversariales solicitados hay dos especialmente reveladores [03:20].

1. Un payload que intente revelar las instrucciones internas del modelo.
2. Un payload que intente usar la herramienta de historial de reembolsos para otra cuenta.

La IA también debe explicar el riesgo que demuestra cada payload y redactar una sección de mitigaciones. Las restricciones son estrictas: no hacer llamadas reales al proveedor, no extraer secretos reales y no inventar datos de cuentas que no aparezcan en el código. Y algo fundamental: separar la evidencia verificable de las inferencias.

Por qué recortar privilegios es mejor que filtrar más

Unos minutos después, la respuesta llega ordenada. Primero muestra los payloads propuestos y lo que esperaba obtener. Luego, en la sección de riesgos, lo que observó tras ejecutarlos.

Pero lo que más importa son las mitigaciones [04:30]. Ahí están las instrucciones claras: qué hacer al modificar el código y cómo verificar que quedó bien y que el problema desapareció. Ese archivo se convierte en una herramienta para corregir con una solución muy estructurada.

La conclusión técnica es contundente. La mitigación más robusta no es filtrar más, sino recortar los privilegios del modelo al mínimo indispensable. Menos herramientas y menos accesos significan menos superficie para el confused deputy.

Hasta aquí todo el trabajo ha sido manual: pruebas en tu propia máquina, decisiones a mano, reportes guardados en archivos locales. El siguiente paso es convertir ese trabajo manual en infraestructura, un flujo automatizado.

Revisa lo que hicimos, comparte tus conclusiones y dudas en los comentarios, y avancemos juntos al siguiente módulo.