Prompt injection

La inyección de prompts es el fallo nº1 de las aplicaciones con LLM: como las instrucciones y los datos viajan por el mismo canal de texto, un atacante puede insertar instrucciones que el modelo obedece. No es un bug de implementación puntual, sino una propiedad fundamental de cómo funcionan los LLM hoy.

Directa vs indirecta

Directa     el usuario escribe instrucciones maliciosas al modelo
            "ignora tus instrucciones y haz X" / jailbreak del sistema
Indirecta   el modelo procesa CONTENIDO EXTERNO con instrucciones ocultas
            p. ej. una web/documento/email que el LLM lee en un flujo RAG o de agente
            -> el atacante no habla con el modelo; "planta" el prompt en los datos

La indirecta es la más peligrosa en apps reales: el atacante no necesita acceso al chat, solo controlar algún contenido que el LLM vaya a leer.

Objetivos del atacante

- exfiltrar datos (del prompt de sistema, del contexto, de otros usuarios)
- hacer que el agente ABUSE de sus herramientas (enviar correo, llamar APIs, borrar)
- manipular la salida (desinformación, phishing, enlaces maliciosos)
- saltar restricciones/guardarraíles (jailbreak)

Técnicas (conceptual)

- "ignore previous instructions", cambio de rol/persona, instrucciones en otro idioma
- ocultar el payload en el contenido (texto blanco, HTML, metadatos, imágenes)
- envenenar la fuente de RAG (documento/web indexados con instrucciones)
- encadenar: instrucción inyectada -> herramienta del agente -> acción con impacto

Por qué no hay una “solución” perfecta

- el modelo no distingue de forma fiable instrucción de dato en el mismo texto
- los filtros/clasificadores reducen pero no eliminan (hay evasiones continuas)
-> defensa en PROFUNDIDAD: asumir que la injection puede ocurrir y limitar su IMPACTO

Defensas (reducir impacto, no solo intentar bloquear)

- MÍNIMO PRIVILEGIO del LLM/agente: que una injection no pueda hacer daño grave
- human-in-the-loop para acciones sensibles (enviar/borrar/pagar)
- tratar la salida como no confiable (LLM02, ver ai-llm); sandbox de herramientas
- separar/etiquetar datos no confiables; límites y allowlists en las herramientas
- filtros de entrada/salida como capa ADICIONAL, no como única defensa

Blue Team / AppSec

Asumir que la injection ocurrirá y diseñar para limitar el impacto (mínimo privilegio, aprobación humana).
La indirecta (RAG/agentes) es la clave en apps reales: todo contenido externo es no confiable.
Tratar la salida del LLM como entrada no confiable aguas abajo (evitar XSS/SSRF/RCE encadenados).
Filtros como capa extra, red teaming continuo (Red teaming de IA) y monitorización.

Casos reales

Numerosos asistentes y chatbots con LLM comprometidos por prompt injection indirecta vía web/email.
Filtración de prompts de sistema de productos comerciales mediante injection directa.
Agentes que ejecutaron acciones no deseadas (enviar datos) por instrucciones en contenido recuperado.

Checklist de prueba

Probar injection directa (jailbreak, cambio de rol)
Probar injection indirecta (contenido RAG/web/email con instrucciones)
¿Puede la salida exfiltrar el prompt de sistema o datos?
¿Puede inducir al agente a abusar de sus herramientas?
Verificar mínimo privilegio y human-in-the-loop en acciones sensibles
Tratar la salida como no confiable aguas abajo
Filtros de entrada/salida como capa adicional