Por qué los sistemas con componentes de IA exigen otro enfoque, otro modelo de amenazas y otro equipo.
El pentest tradicional sigue siendo necesario cuando hay sistemas con componentes de IA de por medio, pero ya no es suficiente. Estos sistemas introducen categorías de ataque que no aparecen en el catálogo clásico, y cuanto más autónomo y agéntico es el sistema, mayor es la brecha entre lo que una auditoría convencional cubre y lo que un atacante real puede aprovechar. Este artículo explica por qué realizar un pentest sobre estos sistemas exige otro enfoque, otro modelo de amenazas y un equipo con competencias específicas.
Durante dos décadas el pentesting ha girado en torno a primitivas bien conocidas como inyecciones en intérpretes deterministas, fallos de control de acceso, manejo de datos, fallos de configuración o lógica de negocio. Son problemas complejos, pero están bien caracterizados. Para una entrada de datos determinada, obtenemos una salida bien definida, y podemos construir patrones fiables para decidir si una prueba tuvo éxito. Las aplicaciones con IA rompen casi todas esas asunciones.
En un pentest clásico trabajas contra código, y una misma entrada produce la misma salida. En una aplicación con un LLM en su flujo de ejecución, el modelo es probabilístico por naturaleza. Aunque le hagas exactamente la misma pregunta dos veces, su respuesta puede variar. Hay muchas razones por las que eso ocurre. Influye la aleatoriedad interna del modelo, pero también cambios en el orden del contexto, una nueva versión silenciosa publicada por el proveedor, ajustes en el system prompt o incluso diferencias sutiles en cómo se dividen los tokens del texto antes de entrar al modelo. Cualquiera de esos factores puede alterar el comportamiento.
Tres implicaciones incómodas:
Un pentest serio no se queda en “hay tres hallazgos altos”. Caracteriza cada hallazgo con métricas: “este ataque tiene un 38 % de éxito sobre 500 ejecuciones, y con este ajuste baja al 12 %”. Esa información es la que permite priorizar y tomar decisiones, algo que una severidad cualitativa por sí sola no ofrece.
Un LLM en producción rara vez está solo. Lo habitual es encontrarlo rodeado de varias piezas que colaboran con él. Una base documental que le aporta contexto en cada consulta (RAG), capas de filtrado y moderación tanto a la entrada como a la salida, un conjunto de herramientas que el modelo puede invocar para ejecutar acciones reales (consultar una API interna, leer un correo, lanzar una consulta contra una base de datos, invocar una herramienta MCP, navegar por la web), orquestadores que coordinan varios modelos o agentes trabajando juntos, memorias que recuerdan interacciones previas y, por todas partes, fuentes de datos externas sobre las que no es fácil mantener un control estable.
Cada una de esas uniones, en las que converge algo no determinista (el modelo) con algo determinista y con privilegios (una API, una base de datos, un cliente de correo), es donde ocurren los accidentes graves. En un pentest clásico la línea entre datos e instrucciones está bien definida: las consultas van por un canal y los datos por otro, y el intérprete sabe distinguirlos. En un sistema con LLM esa línea desaparece. Todo lo que entra en el contexto del modelo puede ser interpretado como instrucción, y esa sola propiedad es el origen de la mitad de las clases de ataque nuevas.
Una diferencia práctica que condiciona todo el trabajo: cuánto del sistema controlas realmente.
Confundir estos tres casos es uno de los errores más caros que vemos al definir el alcance de un trabajo. Se paga un pentest creyendo que se está probando “la IA” cuando en realidad sólo se está probando la caja de alrededor, o al revés. Por eso el kickoff con el cliente arranca de un sitio distinto al de un pentest tradicional. No basta con definir alcances de red, dominios y credenciales. Hay que mapear desde el principio qué partes del modelo se controlan, si ha habido fine-tuning y con qué datos, dónde y cómo se despliega el modelo, qué herramientas puede invocar el agente, qué fuentes alimentan el RAG y qué privilegios tienen las identidades que el agente usa para actuar. Esa conversación inicial determina lo que un pentest de IA puede mirar y lo que tiene que dejar fuera por estar fuera de alcance del cliente.
El prompt injection encabeza el OWASP Top 10 para LLM (2025) [1] por una razón. No es un bug, es una propiedad emergente de cómo funcionan estos sistemas, y esa es la diferencia esencial con las inyecciones tradicionales.
En una inyección SQL clásica disponemos de defensas deterministas y auditables. Los prepared statements separan datos e instrucciones de manera estricta, el motor de base de datos sabe qué es consulta y qué es dato, y podemos leer el código para verificar que la separación se cumple. Con un LLM no existe ese equivalente. El modelo procesa todo el contexto como un único flujo de lenguaje natural, y no hay ninguna forma determinista de decirle “esto es dato, no instrucción”. Cualquier texto que acabe en su ventana de contexto puede actuar como instrucción, da igual de dónde venga.
Eso tiene dos consecuencias prácticas para un pentest. La primera: las vías de entrada se multiplican. Están las evidentes (el input directo del usuario) y las indirectas, donde el atacante nunca habla con el sistema sino que planta instrucciones en contenido que el sistema acabará leyendo. Una web que el agente visita, un documento en el RAG, un correo que un asistente resume, los metadatos de una imagen, un campo libre en un ticket. Cuando el LLM procesa ese contenido, ejecuta las instrucciones del atacante con los privilegios del sistema.
La segunda: los payloads se esconden de formas que un pentest tradicional no rastrea. Caracteres Unicode invisibles que el modelo lee pero el ojo humano no ve. Texto oculto en una web con trucos visuales (tamaño cero, color idéntico al fondo), de modo que el usuario ve una página normal mientras el agente que la resume lee otra cosa. Payloads repartidos en varios fragmentos que sólo cobran sentido al juntarse dentro del contexto. En sistemas multimodales, instrucciones dentro de una imagen o modificaciones imperceptibles en un audio.
Por último, los ataques multi-turno aprovechan que muchos filtros miran los mensajes uno a uno. Técnicas como Crescendo [2] o Deceptive Delight [3] conducen la conversación por caminos aparentemente benignos hasta el objetivo prohibido. La investigación pública reporta tasas de éxito muy altas contra modelos frontera cuando las defensas evalúan turno a turno [2][4].
Y hay otro patrón que el pentester clásico reconocerá enseguida: muchas clases de ataque tradicionales tienen su versión adaptada al mundo de la IA, donde la idea de fondo se mantiene pero se ramifica al chocar con las particularidades del nuevo contexto, abriendo además vías que no existían en el original. Lo hemos analizado en detalle en Blind Prompt Injection: el nuevo Blind SQL Injection en automatizaciones con IA [5], donde tomamos un ataque clásico bien conocido y mostramos cómo se traslada al ámbito de la IA.
No existe un WAF equivalente para esto. Pueden aplicarse filtros de entrada, clasificadores o guardrails que detecten palabras, patrones o estructuras sospechosas, y son útiles como capa adicional. Pero todas estas defensas son probabilísticas y ninguna cierra el problema de raíz: siempre quedará una formulación equivalente que no han visto. La defensa principal tiene que ser arquitectónica: separar privilegios, dar a cada herramienta sólo lo mínimo que necesite, validar la estructura de las salidas del modelo antes de actuar sobre ellas, y exigir confirmación humana en acciones especialmente sensibles que no se pueden deshacer. Evaluar si esas defensas existen y si funcionan en la arquitectura real es justo el tipo de trabajo que un pentest tradicional no está diseñado para hacer.
Los guardrails son las defensas específicas que se colocan alrededor del modelo. Clasificadores que intentan detectar contenido peligroso en la entrada, filtros que buscan datos personales en la salida, o incluso otro modelo actuando como “juez” que decide si la respuesta principal es aceptable.
Aquí aparece otra diferencia clave respecto al pentest clásico. Las defensas tradicionales (un WAF, un sanitizador de entrada, una regla de validación) son deterministas. Se pueden auditar leyendo su configuración, sus reglas o su código fuente. Si el WAF bloquea un patrón, lo bloquea siempre, y basta con comprobar su regex para saberlo. Los guardrails de IA son probabilísticos, y eso cambia cómo hay que probarlos.
Fallan a veces: dejan pasar ataques que deberían bloquear y bloquean cosas legítimas que deberían dejar pasar. Esa tasa de falsos negativos no se lee de un fichero de configuración, se mide experimentalmente. Pueden ser evadidos con técnicas diseñadas específicamente contra ellos (reescribir el ataque con otras palabras, traducirlo a un idioma menos cubierto por las defensas, ofuscarlo), y si se usa un modelo como juez, ese juez hereda todos los problemas de cualquier LLM. Técnicas como Bad Likert Judge [4] han demostrado que se puede convencer al juez para etiquetar como “seguro” material claramente peligroso.
La diferencia para el pentester es directa. A un WAF se le audita inspeccionando su configuración y revisando sus reglas. A un guardrail se le audita sometiéndolo a muchos intentos y midiendo su comportamiento estadístico, con metodología propia y métricas específicas.
Simon Willison la bautizó así [6]. Un agente es explotable por diseño cuando combina tres características al mismo tiempo:
La clave está en que el punto 1 describe qué puede ver el agente dentro del perímetro, el punto 2 describe qué entra al agente desde fuera del perímetro, y el punto 3 describe qué puede salir. Los agentes útiles tienden a tener las tres capacidades a la vez, porque su utilidad viene precisamente de ahí. El OWASP Top 10 para Aplicaciones Agénticas (2025) [7] sistematiza los riesgos derivados, entre ellos el exceso de autonomía del agente, el abuso de la identidad del usuario al que representa, el envenenamiento de la memoria de un agente por otro, los fallos que se propagan en cadena cuando varios agentes se llaman entre sí, y algo más sutil: la explotación de la confianza del operador humano, cuando el agente genera justificaciones tan pulidas que el humano acaba aprobando acciones que no debería.
Frente al pentest tradicional, el cambio conceptual es importante. Hay que pensar en cadenas de compromiso, no en vulnerabilidades aisladas:
Un comentario en un ticket (controlado por un cliente externo) → un agente de soporte lo lee al resumir la cola → la instrucción oculta le hace consultar el CRM → extrae correos de otros clientes → los envía a una URL externa vía su herramienta de HTTP.
Ninguna pieza es “una vulnerabilidad” clásica. Todas juntas son un compromiso total. Un pentest tradicional, que evalúa cada componente por separado, no lo ve. Un pentest de IA tiene que modelar precisamente estas cadenas y probarlas de extremo a extremo.
El Model Context Protocol (MCP) y el uso de herramientas en general son el puente entre un modelo que razona en lenguaje natural y sistemas reales con privilegios. Aquí conviven los bugs clásicos y los nuevos, y la diferencia con un pentest tradicional está en ese cruce.
Por un lado, los servidores MCP son código normal. Tienen inyecciones SQL, ejecución de comandos del sistema, accesos a ficheros fuera de ruta y peticiones salientes no controladas, igual que cualquier otro componente. El caso público del servidor de referencia SQLite de Anthropic (Trend Micro, 2025) [8] mostró cómo una inyección SQL permitía dejar instrucciones maliciosas guardadas en la base de datos, listas para ser ejecutadas la próxima vez que un agente las leyera. Vulnerabilidades como CVE-2025-49596 (inspector de MCP) [9] o CVE-2025-59528 (Flowise, severidad 10.0) [10] refuerzan el patrón: los constructores y gateways agénticos heredan toda la deuda de AppSec.
Por otro lado aparecen vectores específicamente agénticos. El envenenamiento de herramientas consiste en que un servidor MCP malicioso describe la herramienta que ofrece con metadatos que contienen instrucciones ocultas dirigidas al LLM (“cuando te pidan X, ejecuta primero Y y no se lo cuentes al usuario”). Esa descripción, en la práctica, es parte del prompt. También está el patrón clásico del confused deputy, un componente con privilegios legítimos que es manipulado para usarlos en favor de un tercero. Aplicado a agentes: el usuario autoriza algo general, el agente lo interpreta de forma demasiado amplia, y acaba usando los privilegios del usuario para algo que éste nunca habría aprobado si se le hubiera explicado.
La diferencia esencial con un pentest tradicional es que ahora una vulnerabilidad clásica puede ser activada por una frase en lenguaje natural. Un SQLi que antes requería un atacante con acceso directo al endpoint ahora puede dispararlo un agente inocente que lee un documento envenenado. Auditar un entorno con MCPs exige, por tanto, combinar análisis de código y fuzzing tradicional con razonamiento adversario sobre cómo el LLM puede sacar al servidor fuera de su comportamiento esperado. Por separado, ni un pentester clásico ni un especialista en LLM cubren las dos caras, pero sí un pentester que tenga experiencia en los dos mundos.
El RAG (Retrieval-Augmented Generation), la técnica que recupera documentos relevantes de una base propia y los inyecta en el contexto del modelo antes de responder, convierte tu base de conocimiento en superficie de ataque.
La diferencia con un pentest de base de datos tradicional es doble. Primero, los permisos en un RAG no los aplica un motor determinista que entiende usuarios y roles, sino un paso de búsqueda por similitud vectorial que decide qué documentos se parecen más a la pregunta. Si ese paso no aplica correctamente los permisos del usuario, la “filtrada” no es una consulta con un WHERE mal puesto, es un documento que aparece en un resultado donde no debería. Segundo, antes una base de datos no razonaba sobre su contenido: devolvía registros. Ahora el modelo actúa sobre lo que se recupera.
Algunos vectores específicos:
El pentest clásico no evalúa nada de esto porque las defensas clásicas (control de acceso a la base, cifrado en reposo, aislamiento por tenant) se aplican en capas que aquí pueden ser sorteadas por completo sin tocar el motor de base de datos.
Más allá del prompt existe una familia de ataques heredada del mundo del adversarial machine learning que sigue aplicando y que el pentest tradicional ignora por completo, porque simplemente no hay equivalente conceptual en una aplicación sin IA.
Estas pruebas requieren otro perfil, otra instrumentación y otras métricas. Rara vez las cubre un pentest tradicional con “una capa de LLM” añadida.
Los LLM introducen una clase de ataque económico que el pentest tradicional no contempla, y la diferencia con las defensas clásicas es muy concreta.
La variante más llamativa es el Denial of Wallet. El atacante no busca tirar el servicio: quiere que siga funcionando, pero que arruine la factura. Se envían prompts que ocupan casi toda la ventana de contexto del modelo para maximizar el coste de cada petición. Se construyen entradas que hacen al modelo alimentarse a sí mismo en bucle. Se explota el modo de razonamiento de los modelos más nuevos, esos que “piensan” por escrito antes de responder, para que gasten miles de tokens internos aunque la respuesta final sea corta. Hay casos públicos de facturas de decenas de miles de dólares generadas en horas a partir de una sola clave filtrada [14].
También existe el LLMjacking: robo de credenciales de proveedores (AWS Bedrock, Azure OpenAI, Gemini) para usar el cómputo ajeno. Investigación pública ha rastreado operaciones con coste para la víctima superior a 40 000 $ al día [15].
La diferencia con un pentest clásico es directa. Los límites de tasa tradicionales cuentan peticiones por unidad de tiempo, y con esa métrica un atacante puede quedarse muy por debajo del umbral mientras dispara sistemáticamente las peticiones más caras disponibles. Hace falta un control que mida coste por usuario y por unidad de tiempo, cuotas de tokens y alertas sobre gasto, no sólo sobre volumen de tráfico. Esto sale del catálogo de controles que un pentest web tradicional sabe evaluar.
Hay una frontera que muchos equipos siguen tratando como si fuera ética y no seguridad: la generación de contenido dañino, los sesgos sistemáticos, la desinformación, la manipulación emocional o un rechazo que se rompe con facilidad. Son problemas de alignment, pero también son riesgos legales, reputacionales y regulatorios directos, desde RGPD y EU AI Act hasta regulación sectorial en salud o finanzas.
Hay además otra dimensión que el pentest tradicional no tiene que resolver. En una aplicación clásica el impacto de un fallo es objetivo. Si una identidad sin permiso ha leído una base de datos, ha accedido al sistema de archivos o ha ejecutado una acción privilegiada, hay un problema y no hace falta interpretarlo. Esa categoría de fallos sigue existiendo en una aplicación con IA y se evalúa con los criterios de siempre. Pero a la vez aparece otra capa: las respuestas que el modelo da en lenguaje natural pueden ser técnicamente correctas y aun así ir en contra del cometido del sistema o de los intereses de la organización que lo ofrece. Un asistente bancario que entra a especular sobre criptomonedas, un agente de soporte que recomienda productos de la competencia, un chatbot de un servicio médico que da consejos fuera del marco clínico autorizado. Saber dónde está esa línea no es algo que el equipo de pentest pueda decidir por su cuenta. Para evitar que la valoración dependa de la subjetividad del evaluador, hay que entender con precisión el cometido del sistema, las preocupaciones específicas de la organización y los criterios concretos que el cliente considera aceptables o no en las salidas del modelo. Sin ese contexto de negocio, esta capa de riesgo no se puede evaluar bien.
Un pentest IA completo evalúa también esta capa: intentos de saltarse las restricciones para obtener contenido prohibido, sesgos diferenciales entre grupos demográficos, capacidad del modelo de persuadir o manipular, robustez del rechazo frente a role-play y a presión multi-turno. Que algo no salga en un CVE no significa que no vaya a salir en los tribunales o en la prensa.
Cada arquitectura abre frentes propios y el panorama de ataques evoluciona constantemente, pero cualquier pentest de IA serio debería contemplar, como mínimo, un listado similar al siguiente:
Si un proveedor no puede explicarte cómo aborda la mayoría de estos puntos, probablemente te esté vendiendo un pentest tradicional con maquillaje.
El pentester de IA no es un pentester tradicional al que le han regalado un curso de OpenAI. Tampoco es un científico de datos que ha leído el OWASP Top 10. Es el punto donde esos dos perfiles se cruzan. Alguien que entiende de inyecciones, deserialización insegura, evasión de autorización y movimiento lateral, y que a la vez entiende por qué un modelo es más susceptible a un ataque reescrito en un idioma poco representado en su entrenamiento, qué pasa al subir la temperatura del modelo de 0,1 a 0,9, o por qué un embedding almacenado es prácticamente el documento original.
Esa doble profundidad es lo que hace que el equipo detecte cosas que ningún escáner va a ver. El correo con un carácter invisible que dirige al agente a hacer algo que no debería, el campo libre de un ticket que termina ejecutándose como instrucción, el bucle que convierte un modelo de razonamiento en un grifo abierto de tokens, o el servidor MCP tomado de la comunidad con una inyección SQL que ni siquiera hay que explotar directamente, basta con que el agente lo consulte.
El recientemente publicado ETSI EN 304 223 [16], primera norma europea de aplicación global que establece requisitos de ciberseguridad específicos para modelos y sistemas de IA, lo recoge de forma explícita en su provisión 5.2.5-2.1:
“For security testing, System Operators and Developers should use independent security testers with technical skills relevant to their AI systems.”
La dirección que marca el estándar es clara: cuando lo que se prueba es un sistema con IA, las capacidades técnicas del equipo importan, y no cualquier equipo de pentest sirve.
En Kaptor Security nos dedicamos exactamente a esto: pentest sobre aplicaciones, agentes e infraestructuras basadas en IA. Combinamos años de experiencia en pentest tradicional con especialización profunda en inteligencia artificial, y eso nos permite abordar este tipo de auditorías sin renunciar a ninguna de las dos miradas. No somos una consultora que ha añadido la IA a su catálogo; es nuestro foco. Si estás desarrollando o desplegando sistemas con componentes de IA y quieres saber cómo resistirían frente a un atacante real, hablemos.