Pentesting de Inteligencia Artificial y LLMs: qué vulnerabilidades busca

Por el equipo de QuantumSec

Un LLM integrado en un producto no es solo "más software que auditar": introduce vectores de ataque que no existían antes, como el prompt injection o la exfiltración del system prompt, que las herramientas de pentesting tradicionales no están diseñadas para detectar. Esta guía explica en qué consiste un pentesting de sistemas de IA y por qué requiere metodología específica.

Por qué un LLM necesita una evaluación de seguridad distinta

Un escáner de vulnerabilidades tradicional busca CVEs conocidos y configuraciones incorrectas en software determinista: dado el mismo input, el mismo output. Un LLM es probabilístico y su "vulnerabilidad" muchas veces no es un fallo de código sino un fallo de diseño: instrucciones del sistema que pueden sobrescribirse con el input del usuario, salidas que se ejecutan sin validar, o un modelo que revela información que nunca debería compartir. Herramientas como Burp Suite o Nessus no están diseñadas para detectar esto: se necesita metodología específica, alineada con OWASP Top 10 for LLMs y MITRE ATLAS.

Prompt injection: el vector de ataque más característico de los LLMs

El prompt injection directo ocurre cuando el propio usuario introduce instrucciones diseñadas para hacer que el modelo ignore sus reglas ("olvida las instrucciones anteriores y..."). El indirecto es más peligroso: las instrucciones maliciosas llegan a través de un documento, una página web o un email que el LLM procesa como parte de su contexto, sin que el usuario lo sepa. Un pentesting de IA prueba ambos, además de variantes multi-step que encadenan varias interacciones para eludir los controles del modelo de forma acumulativa.

Jailbreaking, exfiltración y otros vectores del OWASP Top 10 for LLMs

Jailbreaking: técnicas para hacer que el modelo ignore sus restricciones de seguridad (role-play, encoding de instrucciones, manipulación de contexto). Exfiltración de system prompt o de datos de entrenamiento: hacer que el modelo revele instrucciones confidenciales o información que memorizó durante el entrenamiento. Insecure output handling: cuando la salida del modelo se ejecuta o renderiza sin validación (inyección de código, XSS a través de una respuesta del LLM). Y model denial-of-service: inputs diseñados para agotar recursos de cómputo y encarecer o tumbar el servicio.

Pipelines RAG, function calling y plugins: la superficie que nadie audita

Cuando un LLM tiene acceso a herramientas (function calling) o a una base de datos corporativa (RAG, Retrieval Augmented Generation), la superficie de ataque se dispara: un prompt injection ya no solo manipula texto, puede ejecutar funciones con permisos reales o filtrar datos de la base de conocimiento a la que el modelo tiene acceso. Auditar esta capa —qué puede hacer el modelo, no solo qué puede decir— es la parte que con más frecuencia se queda fuera de una revisión de seguridad convencional.

FAQ

¿Un escáner de vulnerabilidades automático detecta estos problemas?

No. Los escáneres tradicionales buscan CVEs y configuraciones incorrectas en software determinista. El prompt injection, el jailbreaking o la exfiltración de contexto requieren un experto que interactúe activamente con el modelo probando variantes, igual que un pentesting manual frente a un simple análisis de vulnerabilidades.

¿Esto aplica solo a chatbots o también a copilots y agentes de IA?

Aplica a cualquier sistema que use un LLM: chatbots orientados al cliente, copilots de código, agentes con function calling, o pipelines RAG con acceso a datos corporativos. Cada tipo tiene vectores propios que se adaptan durante el alcance del proyecto.

¿Cuánto dura una evaluación de seguridad de un sistema de IA?

Depende de la complejidad del pipeline: entre 5 y 10 días hábiles para un chatbot o asistente estándar, más si incluye function calling, múltiples integraciones o un pipeline RAG complejo.