Prompt injection no se parchea: por qué tu agente de IA siempre será vulnerable

Llevas tiempo esperando el parche del prompt injection. No va a llegar.

No porque los fabricantes sean lentos. Porque no hay nada que parchear. El prompt injection no es un fallo en una línea de código que alguien arregla en la próxima versión. Es cómo funcionan los modelos de lenguaje por dentro. Y eso convierte la pregunta que repites en cada comité de seguridad, "¿cuándo lo solucionan?", en la pregunta equivocada.

OWASP acaba de ponerle números. En su informe State of Agentic AI Security and Governance, la edición de 2026 deja de catalogar amenazas teóricas y pasa a catalogar CVEs, advisories de fabricantes y brechas reales. En ese mapa, el prompt injection aparece en seis de las diez categorías del Top 10 para aplicaciones agénticas. Seis de diez. Es la causa raíz dominante de los fallos de seguridad en IA, no una entrada más de la lista.

OWASP ya no cataloga amenazas: cataloga incidentes

El cambio de tono del informe es la noticia. La edición anterior describía amenazas plausibles; la de 2026 las documenta con casos. Lo resume bien el análisis de Help Net Security sobre el informe: hemos pasado del "esto podría pasar" al "esto ya pasó, aquí está el CVE".

Los números acompañan. Un paquete comprometido de LiteLLM acumuló unas 47.000 descargas en una ventana de tres horas. Los advisories de seguridad se concentran en las herramientas que más usamos para construir agentes: n8n suma 57, Claude Code 22, AutoGPT 15, Dify 13 y Roo-Code 11. De los 53 proyectos agénticos que el informe sigue de cerca, 28 son agentes de codificación, y las cinco categorías de mayor crecimiento son justamente esas: asistentes que escriben y ejecutan código.

Ese detalle importa más de lo que parece. Los agentes de codificación son los que antes llegan a producción y los que más permisos acumulan: leen tu repositorio, tocan tu pipeline, ejecutan comandos. Son la superficie de ataque que crece más rápido, y son los que reúnen las condiciones perfectas para que una inyección haga daño de verdad. Si estás midiendo el riesgo de IA en tu organización solo por los chatbots de cara al usuario, estás mirando la parte tranquila del mapa.

¿Por qué el prompt injection es un fallo de diseño y no un bug?

La raíz del problema es arquitectónica. Un modelo de lenguaje recibe el prompt del sistema, la petición del usuario y cualquier texto externo que entre en su contexto como un único flujo de tokens. No hay un canal separado y de confianza para las instrucciones y otro distinto para los datos. Todo entra por la misma puerta.

Trabajo en el sector nuclear, un entorno determinista y procedimentado, lo opuesto a esto. Allí una orden de operación y un dato de campo viajan por canales distintos, con autenticación distinta, y nadie confunde uno con otro. En un LLM esa separación no existe. Por eso un correo, una página web o el comentario de un ticket pueden contener instrucciones que el modelo obedece como si vinieran de ti. No es que el modelo "se equivoque": hace exactamente lo que su arquitectura permite.

De ahí la tesis incómoda. Mientras el paradigma sea este, no habrá una versión del modelo que cierre el agujero del todo, igual que ningún filtro elimina por completo los riesgos del Top 10 de OWASP para LLM. Hay defensas que reducen la tasa de éxito del ataque, y líneas de investigación prometedoras sobre atribución de procedencia en la capa de herramientas. Pero ninguna convierte el prompt injection en un problema resuelto. El que te venda lo contrario te está vendiendo tranquilidad, no seguridad.

Asumido eso, el trabajo del CISO cambia de naturaleza. Dejas de perseguir la detección perfecta y empiezas a diseñar contención: que cuando la inyección ocurra, y va a ocurrir, no pueda hacer nada grave. Dos heurísticas maduras dan el marco.

La trifecta letal: cuándo un agente se vuelve una herramienta de exfiltración

El concepto es de Simon Willison, el ingeniero que popularizó el propio término prompt injection. Lo llama la trifecta letal, y describe el momento exacto en que un agente se vuelve peligroso: cuando combina tres propiedades a la vez.

• Acceso a datos privados. El agente puede leer lo que no debería salir: tu bandeja de entrada, tu base de clientes, tu código fuente, tu sistema de ficheros.
• Exposición a contenido no confiable. Cualquier vía por la que un texto controlado por un atacante llega al contexto del modelo: un correo, una web, el resultado de una herramienta.
• Capacidad de comunicar al exterior. Cualquier forma de mandar datos fuera, que es lo que el atacante necesita para robarlos.

Cuando un agente tiene las tres, un atacante puede engañarlo para que lea tus datos privados y se los envíe. No hace falta vulnerar nada más: la combinación es, por sí sola, una herramienta de exfiltración esperando una instrucción. Y la clave defensiva está en el reverso de la idea: si rompes una sola de las tres patas, el agente deja de servir para robar. Quitas la salida externa, o aíslas el contenido no confiable, o recortas el acceso a datos, y la inyección se queda sin premio.

La Regla de Dos de Meta: diseña para contener, no para esperar

Meta convirtió esa idea en una regla operativa. Su Regla de Dos para agentes dice que, mientras no exista una forma fiable de detectar y rechazar el prompt injection, un agente debe cumplir como máximo dos de estas tres propiedades dentro de una misma sesión: procesar entradas no confiables, acceder a datos sensibles o cambiar estado, y comunicarse al exterior.

Si el agente necesita las tres para hacer su trabajo, la conclusión de Meta es clara: no debe operar de forma autónoma. Como mínimo, exige un humano en el bucle que apruebe la acción de riesgo. La gracia de la regla es que es accionable sin esperar a nadie. No depende de que el fabricante publique nada; depende de cómo configuras tú el agente. Es ingeniería de permisos, no parcheo.

Willison, al analizar la propuesta, señala el matiz honesto: la Regla de Dos no es una garantía matemática, es una forma de reducir el peor impacto mientras la investigación madura. A mí eso me vale. En seguridad rara vez jugamos con garantías; jugamos con reducir el radio del daño. Y esta regla reduce el radio sin pedirte que confíes en una detección que todavía no funciona.

Mi opinión como CISO

Lo que más me preocupa no es el prompt injection en sí. Es la expectativa equivocada que tiene casi todo el mundo a su alrededor. He visto comités tratar esto como un problema de "esperar a la siguiente versión", y esa mentalidad es la trampa. Si crees que el parche llega, no diseñas contención. Y si no diseñas contención, el día que la inyección ocurra no tienes nada entre el atacante y tus datos.

Hay una segunda cosa que duele. La presión por adoptar IA viene de arriba, del consejo, y viene rápido. El resultado es que muchos agentes con acceso a datos sensibles y capacidad de actuar se están desplegando sin que nadie haya hecho la pregunta de la trifecta. No por mala fe, sino porque el ritmo de adopción va por delante del de gobernanza. Lo mismo que vimos con el Shadow AI y los permisos OAuth, ahora con agentes que además ejecutan acciones.

Y seré honesto en lo que yo tampoco tengo cerrado: el inventario completo de agentes y de lo que cada uno puede tocar es difícil de mantener cuando cualquier desarrollador conecta un nuevo servidor de herramientas en una tarde. No tengo una solución mágica para eso. Tengo un método para acotarlo, que es de lo que va el resto del artículo, pero la honestidad obliga a decir que esto se gobierna a base de disciplina, no de una compra.

Plan de acción: cómo contener el prompt injection sin esperar el parche

Si me preguntase otro CISO por dónde empezar, le pasaría estos cinco puntos. Ninguno depende de que el fabricante publique nada. Todos son decisiones de arquitectura y de permisos que están en tu mano.

1. Inventaria qué agentes cumplen la trifecta letal

Lista cada agente de IA en producción y marca, para cada uno, si combina las tres propiedades a la vez: datos privados, contenido no confiable y salida externa. Los que crucen las tres son tus candidatos a herramienta de exfiltración. Ese inventario es el mapa sobre el que vas a trabajar; sin él, todo lo demás es intuición.

2. Aplica la Regla de Dos

Para cada agente que reúna las tres propiedades, fuerza aprobación humana en la acción de riesgo o recorta una de las patas hasta dejarlo en dos. A veces basta con quitarle la salida externa directa; otras, con aislar el canal por el que entra contenido no confiable. La pregunta de diseño es siempre la misma: ¿necesita de verdad las tres a la vez?

3. Trata la autorización MCP como dependencia de terceros

Cada servidor de Model Context Protocol que conectas a un agente es una dependencia con permisos sobre tus sistemas. Evalúalo como evaluarías una librería externa en tu cadena de suministro: quién la mantiene, qué accesos pide, qué hace con ellos. Aprobar un MCP no es marcar una casilla de configuración, es admitir un proveedor con llaves.

4. Integra el prompt injection en tu red-teaming

Añade escenarios de inyección indirecta a tus ejercicios: un documento envenenado, una respuesta de herramienta manipulada, una web con instrucciones ocultas. Con agentes de codificación en producción esto deja de ser opcional. Es la categoría que más advisories acumula, y la única forma de saber qué hace tu agente bajo ataque es atacarlo tú primero.

5. Reduce el radio de explosión con mínimo privilegio

Asume que alguna inyección tendrá éxito y diseña para que importe poco. Limita los permisos de cada herramienta que el agente puede invocar, separa credenciales por función y evita los accesos amplios "por comodidad". Cuando el ataque entre, lo único que decide el impacto es cuánto alcance le diste. Ese es el control que sí está bajo tu mando.

Para cerrar

El prompt injection no es un incidente que se cierra: es una condición con la que vas a convivir mientras uses modelos de lenguaje. Aceptar eso no es rendirse, es dejar de gastar energía en el sitio equivocado. La detección perfecta no va a llegar; la contención inteligente ya está disponible.

Coge tu inventario de agentes de IA y pásalo por una sola pregunta, agente a agente: ¿cuáles tienen a la vez acceso a datos privados, entrada de contenido no confiable y salida al exterior? Los que reúnan las tres son tu lista de trabajo. No porque vayan a fallar mañana, sino porque, si fallan, no quieres descubrir entonces que nadie había mirado.

Preguntas frecuentes

¿Se puede parchear el prompt injection?

No de forma fiable. El prompt injection no es un error en una línea de código, sino una consecuencia de cómo funcionan los modelos de lenguaje: tratan las instrucciones del sistema, la petición del usuario y el texto externo como un único flujo de tokens, sin una frontera segura entre comandos y datos. Por eso OWASP lo describe como un fallo de diseño, no como un bug con parche pendiente.

¿Qué es la trifecta letal en agentes de IA?

Es un concepto de Simon Willison. Un agente entra en la trifecta letal cuando combina tres propiedades a la vez: acceso a datos privados, exposición a contenido no confiable y capacidad de comunicar al exterior. Cuando las tres coinciden, un atacante puede usar la inyección para leer datos sensibles y exfiltrarlos. Romper una de las tres propiedades elimina el riesgo de exfiltración.

¿Qué es la Regla de Dos de Meta para agentes?

Es una heurística de diseño publicada por Meta. Mientras no exista forma fiable de detectar y rechazar el prompt injection, un agente debe cumplir como máximo dos de estas tres propiedades en una sesión: procesar entradas no confiables, acceder a datos sensibles o cambiar estado, y comunicarse al exterior. Si necesita las tres, no debe operar de forma autónoma sin supervisión humana.

¿Por qué los agentes de codificación son más peligrosos frente al prompt injection?

Porque concentran las tres propiedades de la trifecta letal por defecto: leen tu código y tus secretos, procesan ficheros y respuestas de herramientas que un atacante puede manipular, y ejecutan comandos o publican cambios. Son la categoría de agentes que más crece y la que acumula más advisories de seguridad, por lo que cualquier despliegue en producción debe asumir que la inyección es posible.

Fuentes

• OWASP GenAI Security Project - State of Agentic AI Security and Governance (v2.01). Informe que mapea el prompt injection a seis de las diez categorías del Top 10 para aplicaciones agénticas.
• Help Net Security - análisis del informe OWASP (11 junio 2026). Cifras de advisories por herramienta y del paquete comprometido de LiteLLM.
• Simon Willison - The lethal trifecta for AI agents. Definición de las tres propiedades que convierten un agente en herramienta de exfiltración.
• Meta AI - Agents Rule of Two: A Practical Approach to AI Agent Security. La heurística de las dos de tres propiedades como contención del prompt injection.
• Simon Willison - análisis de la Regla de Dos y otros papers de prompt injection. Matices y límites de la propuesta de Meta.