Un asistente de correo electrónico recibe un mensaje solicitando un resumen, recupera documentos corporativos relacionados, invoca una herramienta de calendario y genera una respuesta concisa en HTML. Un único correo electrónico no confiable puede introducirse en ese flujo como contenido; sin embargo, el modelo procesa dicho texto junto con las instrucciones de la tarea. Si ese contenido modifica el resultado —pasando de resumir el mensaje a ejecutar una acción no prevista—, nos encontramos ante una inyección de prompts: una entrada que altera el comportamiento del modelo más allá de la tarea para la que fue diseñada la aplicación.
Nuestro asistente operativo presenta cinco puntos donde el contenido se incorpora a una solicitud para el modelo. El usuario proporciona el texto del correo, el sistema de recuperación devuelve fragmentos indexados, las herramientas conectadas suministran datos, el modelo emite texto o argumentos para herramientas, y el componente de renderizado convierte esa salida en HTML. Cada etapa conlleva un nivel de confianza distinto, pero el modelo recibe un flujo de tokens combinado en lugar de una secuencia protegida por un límite de seguridad impuesto por la aplicación.
Antes de evaluar los controles, examinemos en qué puntos de este flujo los datos pueden transformarse en instrucciones.
El flujo demuestra por qué filtrar únicamente el cuadro de chat resulta insuficiente. Un correo electrónico externo puede transportar la instrucción inyectada, un proceso de recuperación puede situarla en el contexto y el resultado de una herramienta puede repetirla en una etapa posterior. El renderizado HTML añade otra frontera, ya que una salida que para el modelo es simplemente texto puede convertirse en un enlace activo, código de marcado o una solicitud en el navegador. Etiquete cada fuente como confiable, de confianza parcial o no confiable antes de que llegue al contexto y conserve dicha etiqueta en los registros.
Ese flujo mixto constituye el ámbito de aplicación de OWASP LLM01:2026. Abarca tanto la inyección directa derivada de la entrada del usuario como la inyección indirecta proveniente de documentos recuperados, correos electrónicos, páginas web, resultados de herramientas, memoria persistente, imágenes, audio y vídeo. Un caso directo comienza con un mensaje del usuario. Un caso indirecto se inicia cuando el cuerpo de un correo electrónico, contenido en el índice de recuperación de nuestro asistente, aporta texto que el usuario nunca escribió ni vio.
Podemos clasificar cada caso según tres ejes. La superficie de entrega es el punto donde se introduce el contenido, como un correo electrónico o la respuesta de una herramienta. La propagación es el destino al que se desplaza a continuación, por ejemplo, desde un resultado de recuperación hacia la memoria persistente. La codificación es la forma en que se representa, incluyendo texto sin formato, caracteres Unicode ocultos o instrucciones incrustadas en una imagen. Esta clasificación nos ayuda a probar la ruta real, y no simplemente un patrón de frase.
La parametrización tradicional impide que los datos alteren la sintaxis de la consulta, ya que la base de datos trata los parámetros por separado. Las aplicaciones actuales de LLM no cuentan con una separación clara equivalente cuando las instrucciones y los datos llegan como tokens en el mismo contexto. Los delimitadores y las etiquetas pueden aclarar la intención, pero no garantizan el control de acceso ni la autoridad. En su lugar, el límite de seguridad debe situarse fuera del modelo; allí, el código verifica los permisos, valida los argumentos y restringe el alcance de la salida generada.
Premisa de trabajo Considere que cualquier entrada del modelo puede influir en la salida, incluso si proviene de un sistema de recuperación interno.
Una vez que un correo electrónico inyectado afecta a la salida, el resultado depende de lo que permita la aplicación circundante. Si el asistente revela contenido oculto del sistema o un fragmento privado recuperado, la situación deriva en el riesgo OWASP LLM08:2026 (Exposición de contexto oculto). Si genera código HTML que el motor de renderizado acepta sin saneamiento, o argumentos para herramientas que el código posterior ejecuta sin validación, se incurre en el riesgo OWASP LLM10:2026 (Gestión inadecuada de la salida). El riesgo LLM01 representa la vulnerabilidad en la entrada que desencadena estas consecuencias.
La misma inyección también puede intentar realizar una acción insegura en el calendario o lograr persistencia en el corpus de recuperación. Estas consecuencias se agravan cuando el modelo tiene capacidad para invocar herramientas de amplio alcance; sin embargo, la solicitud del modelo nunca debe constituir su propia autorización. El servicio de calendario debe verificar la autoridad del usuario, limitar los campos de escritura y exigir aprobación para cambios de relevancia. El motor de renderizado debe permitir únicamente formatos de salida seguros. Cada capa restringe una vía diferente una vez que se modifica la salida del modelo.
Compare los resultados para identificar qué límite debe detener cada uno.