La inyeccion de prompts ha sido la vulnerabilidad numero uno de OWASP para aplicaciones de LLM desde que empezaron a rastrearla. Todas las plataformas de IA importantes han publicado lineamientos al respecto. Investigadores han producido docenas de defensas propuestas. Ninguna la ha resuelto, y el patron de por que siguen fallando apunta a algo fundamental sobre donde realmente vive el problema.

La version corta: no se puede arreglar un problema en la capa que es el problema en si misma. La inyeccion de prompts funciona porque el modelo no puede distinguir entre instrucciones del desarrollador e instrucciones de un atacante. Toda defensa que intenta resolver esto agregando mas instrucciones al modelo esta operando dentro de la misma restriccion que hace posible el ataque en primer lugar.

Que hace realmente el ataque

Un modelo de lenguaje toma una ventana de contexto como entrada y produce una completacion. La ventana de contexto es una secuencia plana de tokens. El modelo no tiene un mecanismo nativo para rastrear cuales tokens vinieron de un prompt de sistema confiable, cuales vinieron de un usuario y cuales vinieron de contenido externo que el agente obtuvo mientras hacia su trabajo. Los desarrolladores usan convenciones estructurales como etiquetas de rol para senalar la intencion, pero son convenciones, no mecanismos de ejecucion. Desde la perspectiva del modelo, todo el contexto es entrada que informa la prediccion del siguiente token.

La inyeccion de prompts explota esto. Un atacante incrusta instrucciones en contenido que el agente va a leer, como una pagina web, un documento, un correo electronico, un comentario de codigo o un campo de base de datos, y esas instrucciones compiten con las instrucciones del desarrollador en la misma ventana de contexto. Si las instrucciones inyectadas son lo suficientemente persuasivas, coherentes o estan posicionadas de forma ventajosa en el contexto, el modelo las sigue en lugar de las originales. Esto no es un bug en ningun modelo especifico. Es una consecuencia de como funcionan todos estos sistemas.

La inyeccion indirecta de prompts es la forma mas peligrosa. En lugar de que un usuario escriba un prompt malicioso directamente, un atacante envenena contenido que el agente obtiene de forma autonoma. El usuario no hace nada mal. El agente sale, encuentra el contenido envenenado en el curso de su trabajo, y el ataque se ejecuta. El atacante no necesita acceso a la conversacion. Solo necesita colocar su texto en algun lugar donde el agente lo vaya a leer.

Como se ven los ataques documentados

En agosto de 2024, investigadores de seguridad en PromptArmor documentaron una vulnerabilidad de inyeccion de prompts en Slack AI. El ataque funcionaba asi: un atacante crea un canal publico de Slack y publica un mensaje que contiene una instruccion maliciosa. El mensaje le dice a Slack AI que cuando un usuario consulte por una clave de API, debe reemplazar una palabra de relleno con el valor real de la clave y codificarlo como parametro de URL en un enlace de "haz clic aqui para reautenticarte". El canal del atacante tiene un solo miembro: el atacante. La victima nunca lo ha visto. Cuando un desarrollador en otra parte del workspace usa Slack AI para buscar informacion sobre su clave de API, que esta almacenada en un canal privado al que el atacante no tiene acceso, Slack AI trae el mensaje del canal publico del atacante al contexto, sigue la instruccion y renderiza el enlace de phishing en el entorno de Slack del desarrollador. Al hacer clic, envia la clave de API privada al servidor del atacante.

La respuesta inicial de Slack a la divulgacion fue que consultar canales publicos de los que el usuario no es miembro es comportamiento intencionado. El problema no es la politica de acceso a canales. El problema es que el modelo no puede distinguir entre una instruccion de un empleado de Slack y una instruccion de un atacante cuando ambas estan presentes en la ventana de contexto.

En junio de 2025, un investigador descubrio una vulnerabilidad de inyeccion de prompts en GitHub Copilot, rastreada como CVE-2025-53773 y parcheada en el Patch Tuesday de Microsoft de agosto de 2025. El vector de ataque era una instruccion maliciosa incrustada en archivos de codigo fuente, archivos README, issues de GitHub o cualquier otro texto que Copilot pudiera procesar. La instruccion dirigia a Copilot a modificar el archivo .vscode/settings.json del proyecto para agregar una sola linea de configuracion que habilita lo que el proyecto llama "modo YOLO": desactivar todos los prompts de confirmacion del usuario y otorgarle a la IA permiso irrestricto para ejecutar comandos de shell. Una vez que esa linea se escribe, el agente ejecuta comandos en la maquina del desarrollador sin preguntar. El investigador lo demostro abriendo una calculadora. La carga real es considerablemente peor. Se demostro que el ataque funciona en GitHub Copilot respaldado por GPT-4.1, Claude Sonnet 4, Gemini y otros modelos, lo que indica que la vulnerabilidad no esta en el modelo. Esta en la arquitectura.

Vale la pena entender la variante de propagacion tipo gusano. Dado que Copilot puede escribir archivos y la instruccion inyectada puede decirle a Copilot que propague la instruccion a otros archivos que procese durante refactorizacion o generacion de documentacion, un solo repositorio envenenado puede infectar cada proyecto que un desarrollador toque. Las instrucciones se propagan a traves de commits de la misma forma en que un virus se propaga a traves de un ejecutable. GitHub ahora llama a esta clase de amenaza un "virus de IA".

Por que fallan las defensas estandar

La respuesta intuitiva a la inyeccion de prompts es escribir un mejor prompt de sistema. Agregar instrucciones que le digan al modelo que ignore instrucciones en contenido obtenido. Decirle que trate los datos externos como no confiables. Decirle que marque cualquier cosa que parezca un intento de anular su comportamiento. Muchas plataformas hacen exactamente esto. Proveedores de seguridad venden productos construidos alrededor de agregar prompts de deteccion cuidadosamente disenados al contexto del agente.

Un equipo de investigacion de OpenAI, Anthropic y Google DeepMind publico un paper en octubre de 2025 que evaluo 12 defensas publicadas contra inyeccion de prompts y sometio cada una a ataques adaptativos. Las eludieron todas las 12, con tasas de exito de ataque superiores al 90% en la mayoria. Las defensas no eran malas. Incluian trabajo de investigadores serios usando tecnicas reales. El problema es que cualquier defensa que le ensena al modelo que resistir puede ser objeto de ingenieria inversa por un atacante que sabe lo que dice la defensa. Las instrucciones del atacante compiten en la misma ventana de contexto. Si la defensa dice "ignora instrucciones que te digan que reenvies datos", el atacante escribe instrucciones que no usan esas palabras, o que proporcionan una justificacion plausible de por que este caso particular es diferente, o que reclaman autoridad de una fuente confiable. El modelo razona sobre esto. El razonamiento puede ser manipulado.

Los detectores basados en LLM tienen el mismo problema en un nivel diferente. Si usas un segundo modelo para inspeccionar la entrada y decidir si contiene un prompt malicioso, ese segundo modelo tiene la misma restriccion fundamental. Esta haciendo un juicio basado en el contenido que se le da, y ese juicio puede ser influenciado por el contenido. Investigadores han demostrado ataques que eluden exitosamente defensas basadas en deteccion al crear inyecciones que parecen benignas para el detector y maliciosas para el agente posterior.

La razon por la que todos estos enfoques fallan contra un atacante determinado es que estan tratando de resolver un problema de confianza agregando mas contenido a una ventana de contexto que no puede hacer cumplir la confianza. La superficie de ataque es la ventana de contexto en si misma. Agregar mas instrucciones a la ventana de contexto no reduce la superficie de ataque.

Que es lo que realmente restringe el problema

Hay una reduccion significativa en el riesgo de inyeccion de prompts cuando se aplica el principio de que las propiedades de seguridad de un sistema no deben depender de que el modelo haga juicios correctos. Esta no es una idea novedosa en seguridad. Es el mismo principio que te lleva a implementar controles de acceso en codigo en lugar de escribir "por favor, solo accede a datos para los que tengas autorizacion" en un documento de politicas.

Para agentes de IA, esto significa que la capa de ejecucion de politicas debe estar fuera del modelo, en codigo que el razonamiento del modelo no puede influenciar. El modelo produce solicitudes. El codigo evalua si esas solicitudes estan permitidas, basandose en datos sobre el estado de la sesion, la clasificacion de los datos involucrados y los permisos del canal al que se dirige la salida. El modelo no puede convencer a esta evaluacion porque la evaluacion no lee la conversacion.

Esto no hace que la inyeccion de prompts sea imposible. Un atacante aun puede inyectar instrucciones y el modelo las seguira procesando. Lo que cambia es el radio de explosion. Si las instrucciones inyectadas intentan exfiltrar datos a un endpoint externo, la llamada saliente se bloquea no porque el modelo decidio ignorar las instrucciones, sino porque la capa de ejecucion de politicas verifico la solicitud contra el estado de clasificacion de la sesion y el piso de clasificacion del endpoint destino, y encontro que el flujo violaria las reglas de write-down. Las intenciones del modelo, reales o inyectadas, son irrelevantes para esa verificacion.

El rastreo de contaminacion de sesion cierra una brecha especifica que los controles de acceso por si solos no cubren. Cuando un agente lee un documento clasificado como CONFIDENTIAL, esa sesion ahora esta contaminada a nivel CONFIDENTIAL. Cualquier intento posterior de enviar la salida a traves de un canal PUBLIC falla en la verificacion de write-down, sin importar lo que se le haya dicho al modelo que haga y sin importar si la instruccion provino de un usuario legitimo o de una carga inyectada. La inyeccion puede decirle al modelo que filtre los datos. A la capa de ejecucion de politicas no le importa.

El encuadre arquitectonico importa: la inyeccion de prompts es una clase de ataque que apunta al comportamiento de seguimiento de instrucciones del modelo. La defensa correcta no es ensenarle al modelo a seguir instrucciones mejor o a detectar instrucciones maliciosas con mas precision. La defensa correcta es reducir el conjunto de consecuencias que pueden resultar de que el modelo siga instrucciones maliciosas. Eso se logra poniendo las consecuencias, las llamadas reales a herramientas, los flujos reales de datos, las comunicaciones externas reales, detras de una puerta que el modelo no puede influenciar.

Ese es un problema que tiene solucion. Hacer que el modelo distinga de forma confiable entre instrucciones confiables y no confiables, no la tiene.