La inyección de prompts no es un bug que vayas a parchear

Cada pocos meses una nueva defensa contra la inyección de prompts se hace popular — un mejor system prompt, un clasificador que marca "ignora las instrucciones anteriores", un fine-tune que se supone que es más obediente. Y cada pocos meses alguien lo esquiva con un ataque ligeramente reformulado. Seguimos tratando esto como un bug de camino a un parche. No lo es.

El informe de 2026 de OWASP pone la inyección de prompts en el centro del riesgo de la IA agéntica, y los investigadores de seguridad ahora dicen la parte callada sin rodeos: puede ser un fallo permanente, no un bug parcheable.

Por qué no se "arregla"

Una vulnerabilidad clásica es un error en el código — la inyección SQL vive en una mala consulta, y una sentencia preparada la cierra para siempre, porque la base de datos puede distinguir la estructura de los datos. Un LLM no tiene tal línea. Instrucciones y datos llegan como la misma cosa: texto en la ventana de contexto. Cuando tu agente lee una página web, un email, un informe de error o la salida de una herramienta, cada token ahí dentro es una instrucción candidata, y el modelo no tiene forma fiable de saber que esta frase es tu orden y esa es la de un atacante. Eso no es un defecto de un modelo en particular. Es el mecanismo. Que tu agente confíe en la descripción de la herramienta es el mismo agujero; también lo es una página web que puede darle órdenes. Misma raíz, distinta puerta.

Deja de preguntar "¿cómo evito que engañen al modelo?". Asume que lo engañarán, cada vez, y pregunta "¿qué puede alcanzar el engaño en realidad?".

Diseña para que una victoria no le cueste nada al atacante

El marco útil es la trifecta letal de Simon Willison: una inyección se convierte en una brecha solo cuando un solo agente tiene los tres a la vez —

1. acceso a datos privados (tus emails, tu base de datos, tus archivos),
2. exposición a contenido no confiable (cualquier cosa que un atacante pueda influenciar — una página, un documento, un ticket),
3. una forma de enviar datos hacia fuera (una llamada HTTP, un email, incluso renderizar una imagen desde una URL manipulada).

Ten dos cualesquiera y una inyección exitosa se apaga. Concede los tres en una misma sesión y una sola frase envenenada se convierte en un pipeline de exfiltración que funciona — sin necesidad de código de exploit. Así que todo el trabajo de seguridad se convierte en: nunca dejar que esos tres se junten.

• Mínimo privilegio en las herramientas, por tarea. El agente que lee contenido no confiable no tiene también las llaves de la base de datos de clientes. Acota las credenciales al trabajo que tiene delante, no a toda la organización.
• Rompe la pata de exfiltración. Un agente que ingiere texto de fuera no debería tener un canal de salida abierto. Nada de HTTP arbitrario, solo dominios en lista blanca, nada de descargas silenciosas de imágenes desde URLs suministradas por el atacante.
• Divide el pipeline. Deja que un componente resuma el documento no confiable sin acceso a datos y sin red; entrega solo el resultado verificado al paso privilegiado. Dos agentes seguros le ganan a uno letal.
• Puerta humana en lo irreversible. Enviar dinero, borrar registros, escribir emails a clientes — una persona aprueba. El diseño aburrido y acotado es el que sobrevive.

Esto no es fontanería hipotética. Una dependencia envenenada — un gateway de LLM con puerta trasera que estuvo en PyPI durante tres horas, decenas de miles de instalaciones — te da contenido no confiable y privilegio en un solo movimiento. La trifecta es cómo un pequeño compromiso se convierte en uno grande.

En resumen

Esperar a que el proveedor "resuelva" la inyección de prompts es una estrategia de seguridad construida sobre un arreglo que no va a llegar. Los equipos que se mantienen seguros no son los del filtro más ingenioso — son los que asumieron que el filtro falla y se aseguraron de que no importara.

Trata cada entrada que tu agente lee como hostil, y diseña la arquitectura de modo que ningún agente individual tenga nunca a la vez datos privados, contenido no confiable y un canal de salida. No puedes parchear el modelo. Puedes asegurarte de que, cuando lo engañen, no haya nada al otro lado de la puerta.