Pentesting de modelos IA y LLM: metodología y herramientas 2026

El pentesting de modelos de lenguaje grandes (LLM) es la evaluación estructurada de aplicaciones construidas sobre modelos de IA generativa (chatbots de atención al cliente, copilots internos, sistemas RAG sobre documentación corporativa, agentes autónomos con acceso a herramientas) cuyo objetivo es identificar vulnerabilidades específicas del paradigma de IA antes de que un atacante las descubra en producción. A diferencia del pentesting web tradicional, el foco no está únicamente en la capa de aplicación o infraestructura, sino en el comportamiento del propio modelo, en cómo gestiona instrucciones, datos externos y herramientas conectadas.

Esta guía explica cuándo conviene contratar un pentesting LLM en lugar de uno web genérico, las fases de un engagement estructurado, qué tests son obligatorios en cualquier evaluación seria, las herramientas que utiliza el equipo ofensivo, las modalidades white-box, black-box y gray-box, los entregables esperados, el encaje regulatorio con la EU AI Act, NIS2 y DORA, y la diferencia con el AI red teaming y los programas de bug bounty.

Lo esencial sobre pentesting LLM

• El pentesting LLM evalúa aplicaciones que integran modelos de lenguaje y no se limita a la capa web o de API.
• Cubre como mínimo el OWASP LLM Top 10: prompt injection, fugas de system prompt, exfiltración de PII vía RAG, abuso de herramientas, envenenamiento de embeddings, jailbreaks y abuso de cuota.
• Se ejecuta en dos a cuatro semanas dependiendo del alcance, con modalidad white-box, gray-box o black-box.
• El entregable incluye informe ejecutivo, matriz OWASP LLM Top 10, prompts adversariales documentados, recomendaciones por capa y un plan de retest.
• Encaja con el artículo 15 de la EU AI Act para sistemas de alto riesgo, el artículo 21 de NIS2 y los ejercicios TLPT extendidos en entornos DORA.

Cuándo necesitas un pentesting LLM (no un pentesting web genérico)

Un pentesting web tradicional cubre vulnerabilidades de aplicación clásicas: inyección SQL, control de acceso roto, deserialización, XSS, configuraciones de servidor. Es necesario en cualquier producto expuesto a internet, pero deja sin cubrir toda la superficie de ataque introducida por un modelo de lenguaje. Si tu aplicación encaja en alguno de los siguientes escenarios, necesitas un pentesting LLM dedicado además del web habitual.

Un chatbot de atención al cliente que responde en lenguaje natural, accede a información de cuenta y puede ejecutar acciones (cambiar dirección de envío, generar un reembolso, gestionar una incidencia). Aquí el riesgo no es solo que un atacante explote un endpoint, sino que manipule al modelo para que tome decisiones fuera de su política.

Un copilot interno que asiste a empleados de finanzas, soporte o ingeniería y tiene acceso a herramientas (consultas a bases de datos, ejecución de código, integración con sistemas internos). Cualquier herramienta que el modelo pueda invocar es un vector de abuso potencial si un atacante consigue redirigir su comportamiento.

Un sistema RAG (retrieval augmented generation) que indexa documentación confidencial, contratos, manuales técnicos o historial de tickets para responder preguntas internas. El riesgo principal es la exfiltración de información a la que el usuario que pregunta no debería tener acceso.

Agentes autónomos en producción que reciben un objetivo y ejecutan secuencias de acciones (búsqueda web, llamada a APIs, escritura en sistemas de gestión, envío de correos). El daño potencial de un agente comprometido es proporcional al alcance de las herramientas que controla.

Si tu aplicación reúne dos o más de estas condiciones, el pentesting tradicional no es suficiente y deberías incluir un alcance LLM dedicado.

Fases del pentesting LLM

Un pentesting LLM serio sigue cuatro fases bien diferenciadas, equivalentes al modelo OSSTMM o PTES adaptado al paradigma de IA.

Discovery. El equipo ofensivo necesita entender el sistema antes de atacarlo. Esto incluye identificar qué modelo se utiliza (GPT-4, Claude, modelos open source desplegados localmente), qué proveedor (OpenAI, Anthropic, Azure OpenAI, Bedrock, autoalojado), qué herramientas tiene conectadas el modelo (tools, function calling, plugins), qué fuentes de datos consulta (vector store, bases de datos, APIs externas) y qué controles de seguridad están en el medio (LLM Guard, filtros propios, sistemas de moderación). En modalidad white-box se accede a system prompts, configuración y código; en black-box se infiere todo desde el comportamiento observable.

Threat modeling. Aquí se aplica el OWASP LLM Top 10 como matriz base, complementado con STRIDE adaptado al contexto de IA y el marco MITRE ATLAS. Cada función de la aplicación se mapea contra las amenazas relevantes: si el sistema tiene RAG, hay riesgo de exfiltración cruzada y envenenamiento de índices; si invoca herramientas con privilegios, hay riesgo de abuso de funciones; si hay multi-tenant, hay riesgo de fuga entre clientes. El resultado de esta fase es un plan de pruebas priorizado.

Test execution. La fase de ejecución es donde se aplican los prompts adversariales, jailbreaks específicos del modelo, técnicas de inyección indirecta vía documentos cargados, ataques de exfiltración de embeddings, abuso de herramientas mediante encadenamiento y pruebas de carga maliciosa. Cada hallazgo se documenta con evidencia reproducible: prompt exacto, respuesta del modelo, impacto demostrado.

Reporting. Cierre del engagement con informe ejecutivo, hallazgos técnicos, severidades calculadas con CVSS adaptado a LLM (o el sistema interno del proveedor), recomendaciones por capa y plan de retest. La duración total típica es de dos a cuatro semanas dependiendo del alcance.

Tests obligatorios en cada engagement

Cualquier pentesting LLM serio debe cubrir, como mínimo, los siguientes tests. La lista coincide en gran medida con el OWASP LLM Top 10 publicado en 2025 y con los vectores documentados en MITRE ATLAS.

Prompt injection directa. El atacante envía instrucciones que sobrescriben las del sistema. Se prueban variantes en español, inglés, codificadas en base64, fragmentadas, en lenguaje ofuscado y mediante caracteres invisibles.

Prompt injection indirecta. La instrucción maliciosa llega al modelo dentro de un documento cargado por el usuario, una página web consultada por la herramienta de búsqueda o un correo recibido por un asistente con acceso al buzón. Es el vector más peligroso porque no requiere acceso directo al modelo.

System prompt leakage. Se intenta recuperar el prompt del sistema mediante técnicas de extracción (resumir lo anterior, repetir la primera línea, traducir las instrucciones al alemán). La fuga del system prompt expone lógica de negocio y facilita ataques posteriores.

PII exfiltration vía RAG. En sistemas con recuperación aumentada, se intenta que el modelo recupere y revele datos de otros usuarios o de documentos confidenciales fuera del alcance del rol que pregunta. Incluye pruebas con consultas oblicuas y manipulación de embeddings.

Tool abuse. Si el modelo tiene herramientas conectadas (envío de correos, lectura de bases de datos, ejecución de scripts), se prueba inducirlo a ejecutar comandos no autorizados o a encadenar herramientas en formas no previstas. Es el riesgo más alto en agentes autónomos.

Embedding poisoning. En sistemas con ingesta de documentos por parte del usuario o de proveedores externos, se prueba contaminar el índice vectorial con contenido que altere respuestas futuras. Es un ataque persistente y difícil de detectar.

Output validation bypass. El modelo puede devolver respuestas que, al renderizarse en el frontend, ejecuten código (XSS clásico vía HTML inyectado, markdown malicioso, URLs fraudulentas). Se prueba si la capa de presentación valida correctamente la salida del modelo.

Rate limit y abuso de coste. Los modelos comerciales se facturan por token. Un atacante puede generar consultas costosas (prompts largos, salidas máximas, llamadas a herramientas caras) para agotar la cuota o disparar la factura. Se prueba el comportamiento bajo carga adversarial.

Hallucination en contextos críticos. En aplicaciones donde el modelo asesora sobre temas regulados (médico, financiero, legal), se documentan casos donde el modelo inventa información con apariencia de autoridad. No es una vulnerabilidad clásica pero es un riesgo operativo crítico.

Jailbreaks específicos del modelo. Cada familia de modelo tiene jailbreaks conocidos que evolucionan en el tiempo. Se ejecuta una batería actualizada contra el modelo desplegado para verificar qué filtros están activos y cuáles se pueden saltar.

Herramientas y testbed

El pentesting LLM combina herramientas automatizadas con trabajo manual del especialista. Las herramientas aceleran la cobertura, pero los hallazgos relevantes suelen requerir prompts adversariales construidos a medida para el caso de uso concreto.

Garak (NVIDIA). Es el escáner de vulnerabilidades LLM más extendido. Funciona como un nmap para modelos: ejecuta probes preconfigurados contra el endpoint del modelo y reporta resultados. Cubre prompt injection, jailbreaks, fugas de datos de entrenamiento, toxicidad y desinformación. Útil en la fase de barrido inicial para identificar problemas obvios antes de pasar al trabajo manual.

PyRIT (Microsoft). Es un framework de red teaming pensado para automatizar campañas de adversarial prompting. Permite encadenar prompts, mantener estado entre turnos y orquestar ataques multiturno. Es la herramienta de referencia cuando el target es un agente o un chatbot con memoria conversacional.

Promptfoo. Plataforma de testing que ejecuta casos de prueba estructurados contra uno o varios modelos y compara resultados. Útil para mantener una suite de regresión que se ejecute periódicamente contra el sistema en producción y detecte degradaciones de seguridad tras actualizaciones del modelo o del system prompt.

LLM Guard. Aunque su propósito principal es la mitigación en producción (filtros de entrada y salida), también se usa en pentesting para evaluar qué filtros del cliente están activos y cuáles puede saltar el equipo ofensivo. La auditoría de un despliegue con LLM Guard incluye probar la propia herramienta defensiva.

Otras herramientas relevantes. NeMo Guardrails de NVIDIA para evaluar barandillas conversacionales, Rebuff como capa de detección de prompt injection que también se audita, y conjuntos de jailbreaks comunitarios mantenidos en repositorios públicos como referencia de prompts adversariales conocidos.

El testbed típico combina Garak para cobertura amplia, PyRIT para escenarios multiturno y trabajo manual con prompts a medida para los casos de uso específicos del cliente.

Pentesting white-box vs black-box vs gray-box en LLM

La modalidad determina el alcance, el coste y el realismo del ejercicio.

Black-box. El equipo ofensivo solo dispone de acceso al producto como un usuario externo. No conoce el modelo subyacente, el system prompt, las herramientas conectadas ni la arquitectura interna. Simula a un atacante real. La ventaja es el realismo; la desventaja es que parte del tiempo se invierte en descubrimiento y algunos vectores quedan sin cubrir si no se encuentran en el plazo del engagement.

Gray-box. El cliente comparte información parcial: documentación de arquitectura, listado de herramientas conectadas, modelo y versión, política general de filtros. No se entrega el system prompt ni acceso a logs. Es la modalidad recomendada para la mayoría de engagements porque equilibra realismo y cobertura.

White-box. Acceso completo: system prompts, configuración de tools, código de los pipelines RAG, logs de inferencia y entorno de pruebas idéntico a producción. Permite la máxima cobertura y es la modalidad obligatoria cuando el sistema es de alto riesgo según la EU AI Act o cuando el cliente necesita evidencia exhaustiva para auditoría regulatoria.

La elección depende del objetivo. Si se busca validar la postura de seguridad frente a un atacante externo, black-box. Si se busca cobertura máxima para certificación o cumplimiento, white-box. Si se busca el equilibrio en un engagement típico de producto en producción, gray-box.

Entregables esperados

El cierre de un pentesting LLM debe incluir, como mínimo, los siguientes entregables. Si el proveedor no los detalla en la propuesta, es señal de que el alcance está mal definido.

Un informe ejecutivo de cinco a diez páginas dirigido a dirección y comité de seguridad. Incluye resumen de hallazgos, severidades, recomendaciones priorizadas y conclusión global sobre la postura del sistema. No contiene prompts adversariales en bruto, sino el resumen narrativo.

Un informe técnico detallado con cada hallazgo documentado: descripción, prompts utilizados, respuestas del modelo, evidencia reproducible, impacto demostrado, severidad calculada y recomendación específica. Es el documento que utiliza el equipo de desarrollo para remediar.

Una matriz OWASP LLM Top 10 que mapea cada vulnerabilidad del catálogo contra el sistema auditado, indicando si se ha probado, si se ha encontrado evidencia y qué severidad tiene. Es el documento de referencia para informes a auditores externos.

Un repositorio de prompts adversariales documentados que el cliente puede integrar en su pipeline de testing continuo. Incluye los prompts que funcionaron, los que se filtraron correctamente y notas sobre el comportamiento observado.

Recomendaciones por capa: modelo (cambios de configuración, system prompt reforzado, ajuste de parámetros), aplicación (validación de entrada, sanitización de salida, segregación de privilegios entre herramientas) e infraestructura (cuotas, monitorización, alertas, segmentación).

Un plan de retest que define qué hallazgos se reverifican, en qué plazo y bajo qué condiciones. Sin retest, el pentesting es un diagnóstico aislado; con retest, es un proceso de mejora verificable.

Encaje regulatorio

El pentesting LLM no es una buena práctica opcional para muchos sectores: es parte del cumplimiento exigido por marcos europeos vigentes en 2026.

EU AI Act, artículo 15. Los sistemas de IA clasificados como de alto riesgo (uso en infraestructuras críticas, educación, empleo, servicios esenciales, justicia, gestión migratoria) deben someterse a pruebas de robustez, exactitud y ciberseguridad antes de su puesta en mercado y de forma continua. El pentesting LLM es el mecanismo principal para demostrar este cumplimiento técnico. El plazo de aplicación plena para sistemas de alto riesgo se extiende durante 2026 y 2027 según el calendario del reglamento.

NIS2, artículo 21. Las entidades esenciales e importantes deben adoptar medidas de gestión de riesgos de ciberseguridad proporcionales a los riesgos planteados, incluyendo pruebas de seguridad. Si la entidad opera sistemas críticos basados en IA (autenticación, detección de fraude, decisiones automatizadas), el pentesting LLM forma parte de las medidas exigibles.

DORA y TLPT extensions. El reglamento DORA exige pruebas avanzadas de penetración basadas en amenazas (TLPT) para entidades financieras significativas. Si la entidad utiliza sistemas LLM en funciones críticas (asesoría automatizada, scoring, atención al cliente con acceso a cuentas), el ejercicio TLPT debe incluir vectores específicos del paradigma IA. Algunos supervisores nacionales ya han publicado guías que extienden TIBER-EU para incluir capacidades de IA en el alcance.

Diferencia con AI red teaming y bug bounty

Tres prácticas relacionadas pero con propósitos distintos.

Pentesting LLM. Engagement estructurado, alcance cerrado, ventana temporal definida (dos a cuatro semanas), entregables formales, severidades documentadas. Es la práctica adecuada cuando el objetivo es validar la postura del sistema en un momento concreto, generar evidencia para auditoría o cumplir un mandato regulatorio.

AI red teaming. Ejercicio adversarial abierto, sin alcance cerrado a priori, orientado a descubrir comportamientos emergentes y vectores no documentados. Suele ejecutarse durante el desarrollo del modelo (los laboratorios como OpenAI o Anthropic mantienen equipos internos de red teaming continuo) o como ejercicio puntual contra sistemas críticos. Es más exploratorio que el pentesting y los entregables son más narrativos.

Bug bounty. Programa continuo de incentivos a investigadores externos para reportar vulnerabilidades. No tiene ventana temporal cerrada, no tiene alcance fijo más allá de las reglas del programa y los entregables son los reportes individuales que llegan. Es complementario al pentesting, no sustitutivo: el bug bounty cubre el largo plazo, el pentesting cubre el momento de la auditoría.

La recomendación operativa para una organización con LLM en producción es combinar pentesting periódico (anual o tras cambios significativos), red teaming antes de lanzamientos críticos y bug bounty como capa continua una vez el producto está estabilizado.

Preguntas frecuentes

¿Se necesita acceso al modelo para hacer pentesting LLM?

Depende de la modalidad. En black-box solo se necesita acceso al producto como usuario; en gray-box se comparte documentación de arquitectura sin entregar credenciales privilegiadas; en white-box se entregan system prompts, configuración de herramientas y logs. La elección depende del objetivo del ejercicio y del nivel de evidencia requerido.

¿Cuál es el coste aproximado de un pentesting LLM?

El coste varía según el alcance, la modalidad y la complejidad del sistema. Un engagement típico para un chatbot empresarial con tres a cinco herramientas conectadas y una base RAG mediana se sitúa en el rango de un pentesting web complejo. Los sistemas con agentes autónomos o múltiples integraciones requieren más esfuerzo. La propuesta debe detallar horas, perfiles asignados y entregables incluidos.

¿Cuánto dura un pentesting LLM?

Entre dos y cuatro semanas para un engagement de alcance medio. Una semana para discovery y threat modeling, una o dos semanas de ejecución y una semana de reporting. Engagements más cortos suelen significar cobertura reducida; engagements significativamente más largos suelen reflejar sistemas con alcance muy amplio o necesidades de auditoría detallada.

¿Se hace pentesting LLM sobre producción o sobre staging?

La práctica habitual es ejecutar la mayor parte del trabajo en un entorno de staging idéntico a producción y reservar una verificación controlada en producción para validar que el comportamiento es equivalente. Atacar directamente producción sin coordinación previa puede agotar cuotas, generar costes y disparar alertas reales del SOC.

¿Qué pasa si encontramos un jailbreak funcional durante el engagement?

Se documenta con evidencia reproducible, se comunica al cliente con la severidad correspondiente y se incluyen recomendaciones de mitigación. Si el jailbreak afecta a un modelo de un proveedor externo (OpenAI, Anthropic) y no es un fallo de la integración del cliente, se sugiere reportarlo también al proveedor a través de su canal de divulgación responsable.

¿El retesting está incluido en el coste original?

Debería estarlo. Un pentesting sin retest es un diagnóstico estático. La práctica habitual es incluir una ronda de retest dentro del plazo de tres a seis meses tras el cierre del informe original, durante la cual se verifican los hallazgos críticos y altos. Si el proveedor no lo incluye por defecto, conviene solicitarlo en la propuesta.

Recursos relacionados

• OWASP LLM Top 10 explicado
• AI red teaming: evaluación de modelos IA
• Qué es prompt injection: ataques a LLM
• Qué es pentesting: guía para empresas
• Pentesting de aplicaciones web

Pentesting LLM con Secra

En Secra realizamos pentesting de aplicaciones LLM con cobertura completa del OWASP LLM Top 10 y un threat model adaptado a tu caso de uso concreto. El engagement tiene una duración estándar de dos a cuatro semanas, incluye modalidades white-box, gray-box y black-box, y entrega informe ejecutivo, matriz de vulnerabilidades, prompts adversariales documentados, recomendaciones por capa y plan de retest. Trabajamos con chatbots, copilots internos, sistemas RAG y agentes autónomos en producción.

Si tu organización va a desplegar o ya tiene una aplicación basada en LLM y necesita validar su postura de seguridad antes de exposición pública, antes de una auditoría regulatoria o tras un cambio significativo en el modelo o las herramientas, contacta con nuestro equipo para definir el alcance.

Solicita propuesta de pentesting LLM