La mayoría de los programas de seguridad de IA se detiene en la primera etapa. Un equipo ejecuta una batería de prompts adversariales, el modelo escapa del guardrail una vez cada cincuenta intentos, el hallazgo se convierte en un ticket de severidad media y el asunto se cierra. El informe dice "el modelo es vulnerable a prompt injection". No dice qué haría un adversario con eso.
Esa es la brecha que la Promptware Kill Chain existe para cerrar. Adaptamos el framework de la investigación de Schneier et al. (2025) y lo convertimos en una metodología ofensiva de siete etapas — del acceso inicial al compromiso total. La premisa es simple: el prompt injection no es el ataque. Es la puerta de entrada.
Por qué la kill chain tradicional no sirve
Los frameworks clásicos asumen una frontera nítida entre código y datos. Un binario ejecuta instrucciones; un archivo de configuración aporta parámetros. La explotación ocurre cuando el atacante logra mover datos al lado del código.
En un LLM, esa frontera no existe. El system prompt, el input del usuario, el documento recuperado del vector store y la salida de una herramienta llegan al modelo por el mismo canal — texto. El modelo no tiene un mecanismo estructural para distinguir la instrucción legítima del operador de la instrucción plantada dentro de un PDF que el pipeline RAG acaba de indexar.
El resultado práctico: todo dato que entra en el contexto es potencialmente ejecutable. Un framework de ataque para sistemas de IA debe partir de esa realidad, no adaptarla.
Las siete etapas
1. Acceso inicial
El adversario obtiene entrada en el sistema de IA. Los vectores que probamos con más frecuencia:
- Prompt injection directo — el usuario es el atacante, interactuando directamente con la interfaz.
- Prompt injection indirecto — la instrucción llega vía contenido que el sistema consume: un correo, una página web, un ticket de soporte, un documento en el vector store.
- Envenenamiento de datos — manipulación del corpus de fine-tuning o de los embeddings.
- Plugins y endpoints comprometidos — la integración de terceros como punto de entrada.
El vector indirecto es el más subestimado y el más explotado en incidentes reales. No exige que el atacante tenga acceso al sistema — exige solo que logre colocar texto donde el sistema va a leer.
2. Escalación de privilegios
Dentro del contexto del modelo, el atacante amplía lo que puede hacer: evade guardrails, extrae el system prompt o desbloquea llamadas de herramienta que deberían estar restringidas al operador.
Extraer el system prompt suele tratarse como hallazgo de baja severidad. No lo es. El system prompt describe las herramientas conectadas, los límites de autorización y con frecuencia la estructura de los datos accesibles. Es el mapa de la red — solo que en lenguaje natural.
3. Reconocimiento
El adversario enumera capacidades: qué herramientas puede invocar el agente, qué fuentes de datos alcanza, qué otros agentes existen en el pipeline, qué credenciales están en el alcance de la sesión.
Aquí la asimetría queda evidente. Un agente con acceso a correo, calendario y una base vectorial corporativa responde preguntas sobre su propia configuración con la misma diligencia con que responde preguntas sobre el negocio.
4. Persistencia
La etapa que separa una prueba de escritorio de un ejercicio realista. El atacante graba instrucciones en un lugar que sobrevive al fin de la sesión:
- memoria de largo plazo del agente;
- documentos en el vector store que serán recuperados en conversaciones futuras;
- archivos de configuración o reglas de proyecto que el asistente lee en cada inicialización.
En los incidentes que catalogamos entre 2025 y 2026, el 57% de los casos mantuvo persistencia activa después de la detección inicial. La organización remedió el síntoma — bloqueó el prompt, ajustó el filtro — y dejó el payload en su lugar.
5. Comando y control
Se establecen canales de salida. Un agente con acceso a la web tiene un canal C2 incorporado: basta con codificar datos en el path de una petición. Un agente con acceso a correo tiene otro. La memoria de conversación de un asistente compartido puede servir como dead drop entre operaciones — fue exactamente el patrón observado en el caso ZombAI.
6. Movimiento lateral
El agente comprometido alcanza otros sistemas. En arquitecturas multiagente, un agente confía en la salida de otro por el mismo motivo por el que confía en el input del usuario: todo es texto. Una instrucción plantada en el agente A es ejecutada por el agente B como si fuera legítima.
El incidente GeminiJack demostró movimiento lateral por un entorno Workspace entero, zero-click, sin que el usuario interactuara con nada.
7. Acciones sobre el objetivo
Exfiltración de datos, manipulación de sistemas, fraude o uso del acceso como puente hacia el entorno tradicional. CVE-2025-53773 (GitHub Copilot) y CurXecute (Cursor IDE) cierran el ciclo de forma inequívoca: sugerencia de código malicioso que lleva a ejecución arbitraria de comandos en la máquina del desarrollador. El ataque empieza en lenguaje natural y termina en shell.
Lo que muestran los datos
Catalogamos 21 incidentes de promptware entre 2025 y 2026. Dos números importan más que los demás:
- 15 de los 21 presentaron cuatro o más etapas de la kill chain. Los ataques a sistemas de IA no son one-shot. Son campañas.
- El 57% mantuvo persistencia después de la detección inicial. El tiempo de permanencia es largo porque la superficie de detección — memoria, embeddings, contexto — no está monitoreada por los controles existentes.
Si su prueba de seguridad de IA produce una lista de prompts que rompieron el guardrail, usted midió la etapa 1 y extrapoló el resto.
Cómo cambia esto la prueba
Aplicar la kill chain reorganiza el ejercicio en torno a tres preguntas:
- Alcance. Comprometido el modelo, ¿qué alcanza efectivamente? No lo que dice la documentación — lo que permiten las credenciales de la sesión.
- Persistencia. ¿Existe algún lugar escribible que el modelo relea? Si es así, es un mecanismo de persistencia, independientemente de que se haya diseñado como tal.
- Detección. ¿Las etapas 4 a 6 generan alguna señal observable? En la mayoría de los entornos que evaluamos, la respuesta es no — los logs registran la interacción, no la intención.
La salida deja de ser una lista de jailbreaks y pasa a ser un camino de ataque con evidencia reproducible en cada etapa, clasificación de severidad por impacto al negocio y un orden de corrección justificado.
Por dónde empezar
Si usted opera sistemas de IA en producción, tres controles tienen el mejor retorno inmediato:
- Reduzca la agencia. La mayor parte de la severidad viene de la etapa 7, y la etapa 7 está limitada por lo que el agente puede hacer. Permisos de lectura en lugar de escritura eliminan clases enteras de impacto.
- Trate la memoria como superficie de ataque. Si el agente escribe en un almacenamiento que después relee, ese almacenamiento necesita revisión, expiración y log.
- Instrumente la etapa 5. Las llamadas de salida iniciadas por agentes — HTTP, correo, invocación de herramienta — deben registrarse y ser correlacionables con el input que las originó.
Ninguno de estos controles depende de que el modelo "resista" al prompt injection. Esa es la intención: la kill chain asume que la etapa 1 va a funcionar y diseña la defensa para las seis etapas siguientes.
La Promptware Kill Chain es el framework detrás de nuestros ejercicios de Red Team para IA y del pentest de LLM. Para discutir su aplicación en su entorno, hable con el equipo.