Inyección de prompt: OWASP dice que quizá no exista una defensa infalible. Esto es lo que sí ayuda

Casi todos los textos de fabricantes sobre inyección de prompt terminan en un producto. La página de OWASP termina en una admisión, y esa admisión es la frase más útil publicada sobre el tema: dada la influencia estocástica en el corazón del funcionamiento de los modelos, no está claro que existan métodos infalibles de prevención de la inyección de prompt. Es la primera entrada del top diez de seguridad para modelos de lenguaje diciendo, con sus propias palabras, que esto quizá no tenga solución. Todo lo práctico se deduce de tomarse esa frase en serio.

Qué es, y por qué el nombre se queda corto

La inyección de prompt es el riesgo LLM01 del Top 10 de OWASP para aplicaciones LLM: la primera entrada, por delante de las fugas de datos y de los problemas de cadena de suministro. OWASP distingue dos formas. La inyección directa: la entrada del usuario «altera directamente el comportamiento del modelo de forma inesperada». La inyección indirecta: el modelo «acepta entradas de fuentes externas, como sitios web o archivos», y ese contenido cambia su comportamiento. En ambos casos OWASP precisa que la manipulación puede ser deliberada o del todo accidental.

La palabra «inyección» invita a compararla con la inyección SQL, y ahí es justo donde los equipos se equivocan. La inyección SQL tiene solución: separar la consulta de los datos con sentencias parametrizadas, y la clase de fallo desaparece. Aquí no existe una separación equivalente. Su prompt de sistema y el párrafo de un atacante llegan al modelo con la misma forma —texto— y nada en el formato señala cuál tiene autoridad. No es una carencia de implementación a la espera de un parche: es una propiedad del funcionamiento de los modelos.

El caso indirecto es el que sorprende

La inyección directa se ve. Alguien escribe en su ventana de chat, usted ve el tráfico, puede limitarlo y registrarlo. La indirecta es más silenciosa: su agente descarga una página web, abre un PDF que subió un cliente o resume un ticket de soporte, y unas instrucciones presentes en ese contenido se leen como si las hubiera escrito usted. El atacante nunca toca su interfaz, y nada en sus registros parece un ataque.

Esto importa porque se deriva de la arquitectura, no de un error. Cualquier agente que navegue por la web, abra archivos o ingiera datos de terceros arrastra esta exposición por construcción. Es también la razón por la que Cloudflare citó el aislamiento frente a la inyección de prompt entre sus objetivos de diseño al construir un navegador pensado para agentes y no para personas: en cuanto un agente lee la web abierta, la web abierta se convierte en un canal de entrada.

Una cinta de balizamiento a rayas blancas y negras con la palabra DANGER, tendida en una escena oscura — Una cinta de balizamiento con la palabra DANGER. Marca un límite sin imponerlo físicamente, que es exactamente lo que hace «separar e identificar el contenido externo» con un agente: etiquetar una entrada no fiable ayuda, pero la etiqueta no es un muro.

Las siete defensas que nombra OWASP

OWASP enumera siete estrategias, y merece la pena notar que ninguna es un producto que se compre:

Restringir el comportamiento del modelo mediante el prompt del sistema
Definir y validar los formatos de salida esperados
Filtrar entradas y salidas
Aplicar control de privilegios y mínimo privilegio
Exigir aprobación humana para las acciones de riesgo
Separar e identificar el contenido externo
Realizar pruebas adversarias y simulaciones de ataque

Leídas como lista, parecen siete casillas que marcar. Leídas como conjunto, describen algo más preciso: una arquitectura levantada sobre el supuesto de que al modelo se le convencerá alguna vez, y cuyo trabajo consiste en que aquello de lo que se le convenza salga barato.

Dos de las siete aguantan aunque el ataque funcione

Los tres primeros puntos —prompt de sistema, formatos de salida, filtrado de entradas y salidas— elevan el coste de un ataque. Merecen hacerse, y todos acaban cediendo, porque operan sobre el mismo canal que emplea el atacante.

El control de privilegios y el mínimo privilegio, junto con la aprobación humana de las acciones de riesgo, son de otra naturaleza. No intentan impedir que se convenza al modelo. Limitan lo que un modelo convencido puede hacer. Si su agente solo tiene credenciales de lectura, una inyección exitosa lee algo que no debería: molesto, acotado, recuperable. Si tiene un token de pagos, esa misma inyección exitosa es una conversación completamente distinta.

Por eso la pregunta útil antes de desplegar un agente no es «qué tal es nuestro prompt». Es: ¿qué es lo peor que este agente puede hacer sin una persona en el circuito, y estamos dispuestos a que ocurra por accidente? Un agente que redacta una respuesta para que alguien la envíe es un riesgo realmente distinto de uno que reembolsa sin supervisión, y la diferencia no tiene nada que ver con el modelo.

Probar es intentar romper el propio agente

El séptimo punto, pruebas adversarias y simulaciones de ataque, es el que más se salta porque no tiene una línea de meta evidente. Una versión practicable es más estrecha de lo que parece: para cada fuente que consume su agente —páginas web, documentos subidos, tickets, correos—, darle contenidos que contengan instrucciones y mirar qué hizo el agente, no qué dijo.

Esa distinción es toda la prueba. Un modelo que se niega educadamente y luego llama igualmente a la herramienta ha fallado. Un modelo que produce una respuesta alarmante sin tocar nada, no. Registrar las llamadas a herramientas, y no solo las respuestas, es lo que hace visible la diferencia, y es la instrumentación más barata que puede añadir antes de que un agente se acerque a producción.

Qué llevarse de la admisión de OWASP

Si la inyección de prompt tuviera un arreglo limpio, el plan sensato sería aplicarlo y pasar a otra cosa. No lo tiene, así que el plan sensato es otro: suponer éxitos ocasionales, diseñar para que esos éxitos sean aburridos, e instrumentar para poder saberlo. Es una respuesta menos satisfactoria que un filtro, y es la que sostienen los hechos.

Da la casualidad, además, de que es buena ingeniería en cualquier caso. El mínimo privilegio, los formatos de salida validados, la revisión humana de las acciones irreversibles y las pruebas adversarias eran práctica sensata antes de que existieran los modelos de lenguaje. La novedad no está en los controles. Está en que un sistema que lee texto ahora puede ser persuadido, y en que la persuasión entra por la misma puerta que los datos.

Preguntas frecuentes

¿Qué es la inyección de prompt, en una frase?

Es cuando un texto que llega al modelo cambia su comportamiento de una manera que usted no había previsto. OWASP la clasifica como LLM01 en su Top 10 para aplicaciones LLM y la divide en dos: la inyección directa, en la que la entrada del usuario altera directamente el comportamiento del modelo de forma inesperada, y la inyección indirecta, en la que el modelo acepta entradas de fuentes externas como sitios web o archivos, y ese contenido cambia su comportamiento. En ambos casos la manipulación puede ser deliberada o completamente accidental.

¿Por qué no basta con decirle al modelo que ignore las instrucciones maliciosas?

Porque la instrucción que usted escribe y la que escribe un atacante llegan con la misma forma: texto. Ningún canal transporta autoridad. Restringir el comportamiento mediante el prompt del sistema es una defensa real, y OWASP la cita en primer lugar, pero eleva el coste de un ataque en vez de cerrar la puerta. OWASP es explícito sobre el límite: dada la influencia estocástica en el corazón del funcionamiento de los modelos, no está claro que existan métodos infalibles de prevención de la inyección de prompt.

¿Qué diferencia práctica hay entre inyección directa e indirecta?

La inyección directa es alguien escribiendo en su ventana de chat. Ese tráfico se ve y se puede limitar. La indirecta es la que sorprende a los equipos: su agente descarga una página web, lee un PDF que subió un cliente o resume un ticket de soporte, y unas instrucciones escondidas en ese contenido se leen como si vinieran de usted. El atacante nunca toca su interfaz. Cualquier agente que navegue, abra archivos o ingiera datos de terceros tiene esta exposición por construcción.

¿Qué recomienda realmente OWASP?

Siete estrategias, y ninguna es un producto que se compre. Restringir el comportamiento del modelo mediante el prompt del sistema. Definir y validar los formatos de salida esperados. Filtrar entradas y salidas. Aplicar control de privilegios y mínimo privilegio. Exigir aprobación humana para las acciones de riesgo. Separar e identificar el contenido externo. Realizar pruebas adversarias y simulaciones de ataque. Leídas como conjunto describen una arquitectura, no un filtro: asuma que al modelo se le puede convencer, y procure que aquello de lo que se le puede convencer no salga caro.

¿Significa esto que no deberíamos desplegar agentes de IA?

No, y leerlo así sería un contrasentido. Significa que el radio de acción importa más que el prompt. Un agente que redacta una respuesta para que la envíe una persona no es la misma propuesta que uno que emite reembolsos sin supervisión. Los dos puntos de OWASP que más cambian son el control de privilegios y la aprobación humana de las acciones de riesgo, porque siguen en pie incluso cuando la inyección tiene éxito. Despliegue el agente; decida antes qué se le permite hacer solo.

¿Cómo se prueba esto?

OWASP nombra las pruebas adversarias y las simulaciones de ataque entre sus siete estrategias, lo que es una manera educada de decir que hay que intentar romper el propio agente antes de que lo haga otro. En la práctica: alimentarlo, desde cada fuente que consume, con contenidos que contengan instrucciones, y comprobar no si se niega, sino si ocurrió algo irreversible. Una prueba que solo mira la respuesta del modelo pierde de vista lo esencial: lo que importa es lo que el agente HIZO.

La designación LLM01:2025, las definiciones de inyección directa e indirecta, las siete estrategias de mitigación y la frase que indica que se desconoce si existe una prevención infalible proceden todas de la página sobre inyección de prompt del OWASP Gen AI Security Project, consultada en el momento de la redacción. No hemos llevado a cabo nuestro propio programa de pruebas adversarias y no reclamamos aquí ninguna medición propia.

El acompañamiento de ZAX en agentes de IA

Construimos agentes de IA para empresas, lo que significa que la mayor parte del tiempo de diseño se va exactamente en esta pregunta: qué puede hacer el agente solo y qué necesita una persona. El alcance de los privilegios, el registro de llamadas a herramientas y los puntos de aprobación humana forman parte de la construcción, no de un parche posterior.

Auditoría y encuadre. Una auditoría de IA gratuita de 30 minutos revisa a qué puede llegar hoy su agente, y qué pasaría si se le convenciera de usarlo.

Contáctenos para hablar de la arquitectura de sus agentes.