OWASP dice que la prompt injection sigue sin resolverse. Configurar no te salvará.
La industria de la seguridad ha pasado dos años tratando la prompt injection como un bug: algo que un buen filtro, un system prompt más estricto o la siguiente versión del modelo acabarían limpiando. Ese enfoque es reconfortante porque implica que el problema tiene dueño y fecha de parche. También resulta estar equivocado, y quienes están más cerca del problema han empezado a decirlo en voz alta.
Solo que la historia que llega de Infosecurity Europe, según informa Infosecurity Magazine, no es "hemos encontrado un filtro mejor". Es lo contrario. OWASP clasifica la prompt injection como el riesgo número uno para las aplicaciones con LLM, y un investigador de OWASP usó un escenario público para advertir de que sigue sin resolverse. No difícil. No parcialmente mitigado. Sin resolver. Ese es un tipo de afirmación distinto del que la industria está acostumbrada a oír sobre una vulnerabilidad en cabeza de la lista, y debería cambiar cómo construyes arquitectura, no solo cómo te preocupas.
Porque si la propia autoridad del campo en riesgo de LLM te está diciendo que el problema no tiene arreglo en la capa del modelo, entonces toda defensa que asuma que el arreglo viene está construida sobre arena.
"Sin resolver" es una entrada de diseño, no un aviso legal
La mayoría de la gente oye "sin resolver" y lo archiva como mala noticia a gestionar. Ese es el archivo equivocado. Sin resolver es un hecho arquitectónico, y dicta lo que un diseño responsable puede asumir.
La prompt injection está sin resolver por una razón estructural, no de madurez. Un modelo de lenguaje lee un flujo de tokens y no puede separar con fiabilidad las instrucciones que le diste del contenido que le pediste procesar. Cuando lee un documento, el texto del documento y tus órdenes llegan por el mismo canal, y el modelo no tiene forma privilegiada de saber cuál es cuál. Por eso el problema resiste a los parches: es una propiedad de cómo lee el modelo, no un defecto de un modelo concreto.
La cobertura del mismo material de OWASP por parte de Help Net Security enmarca los fallos de alrededor sin rodeos, y la línea es consistente. La superficie de ataque no encoge a medida que mejoran los modelos. Crece a medida que se conectan a más herramientas. Informes citados junto al aviso de OWASP apuntan a un fuerte aumento interanual de estos ataques, que es exactamente lo que esperarías si la debilidad subyacente es estructural y el número de agentes desplegados está subiendo.
Así que el supuesto honesto de planificación no es "la inyección se reducirá a una tasa aceptable". Es "la inyección tendrá éxito a veces, y mi arquitectura tiene que seguir siendo segura cuando lo tenga". Todo lo demás se sigue de aceptar esa frase en lugar de discutir con ella.
La configuración no es una frontera
Aquí es donde falla en silencio la mayoría de las defensas empresariales. Ante un problema sin resolver, los equipos echan mano de la configuración: un system prompt mejor, un delimitador alrededor del texto no confiable, un clasificador afinado para marcar entradas sospechosas. Ayudan, y deberías usarlos. Pero ninguno es una frontera. Todos son reductores de probabilidad, y un reductor de probabilidad aplicado a un problema estructuralmente sin resolver baja la tasa de fallo sin llegar nunca a cero.
La razón por la que configurar no basta se volvió concreta en 2026. La CVE-2025-6514, con una puntuación CVSS de 9,6, se divulgó en la infraestructura central de MCP: ejecución remota de código en la fontanería que conecta agentes con herramientas. Y Microsoft documentó, en su investigación "when prompts become shells", cómo la prompt injection deja de ser un problema de texto y se convierte en una primitiva de ejecución de código en el momento en que un agente se conecta a herramientas reales. Esa es la escalada que importa. En un chatbot, una inyección exitosa produce una frase mala. En un agente con herramientas, la misma inyección produce una acción, y si la fontanería tiene una RCE, produce código arbitrario corriendo en tu entorno.
Ningún ajuste de system prompt aborda eso. La distancia entre "el modelo dijo algo equivocado" y "el agente hizo algo equivocado" no la cierra la configuración, porque el peligro no es lo que el modelo cree. Es lo que se le permite hacer al modelo una vez lo cree. Un clasificador que deja pasar una entrada bien construida no se ha degradado con elegancia. Le ha entregado a un atacante las herramientas que hay detrás.
Un problema estructural necesita una respuesta estructural
Si el problema no se puede resolver en la capa del modelo, la única jugada responsable es dejar de intentar que el modelo sea fiable y empezar a hacer inocuos los errores del modelo. Eso es un cambio de la probabilidad a la estructura, y tiene una forma concreta.
Una frontera de contaminación. Los datos no confiables, todo lo que el agente leyó en lugar de escribir, se marcan y nunca pueden convertirse en privilegio ejecutable. No es un filtro por el que el contenido no confiable podría colarse. Es una regla sobre en qué puede convertirse estructuralmente el contenido no confiable, aplicada por el sistema en lugar de esperada del modelo.
El patrón dual-LLM CaMeL. Reparte el trabajo entre dos modelos. Un planificador privilegiado planifica e invoca herramientas pero nunca lee contenido no confiable. Un lector en cuarentena lee el documento envenenado y extrae lo necesario pero no tiene herramientas y no puede actuar. Ante cualquier duda, el patrón falla cerrado. El componente que ve el ataque no tiene manos, y el componente con manos nunca ve el ataque. Donde un clasificador baja la probabilidad de confusión, esto elimina la capacidad de actuar sobre ella.
Identidad no humana de privilegio mínimo. Cada agente corre bajo su propia identidad acotada y de corta duración, con una allow-list de salida explícita, así que una inyección exitosa manda sobre un actor que solo puede ejecutar un puñado de acciones con nombre hacia un puñado de destinos permitidos. Un agente robado o secuestrado no vale casi nada porque no hay poder permanente del que abusar.
Defensa en profundidad. Ninguno de estos se considera suficiente por sí solo. Se disponen en capas para que eludir uno caiga en el siguiente, precisamente porque "sin resolver" significa que cualquier control aislado acabará siendo batido por algo novedoso.
Fíjate en lo que une a los cuatro. Ninguno intenta que el modelo resista la inyección. Cada uno asume que la inyección tiene éxito y garantiza que ese éxito no hace nada con consecuencia. Así es como se ve una respuesta estructural a un problema estructural.
El replanteamiento
La pregunta que la industria insiste en hacer, la que lleva directamente a otro clasificador, es "¿cómo detenemos la prompt injection?". OWASP acaba de responderla: no la detienes, no en la capa del modelo, no todavía, quizá nunca. Organizar tu defensa alrededor de resolverla es organizarse alrededor de una solución que no existe.
La pregunta mejor es esta. Cuando una inyección tenga éxito, y OWASP nos está diciendo que lo tendrá, ¿qué le impide hacer estructuralmente nuestra arquitectura? Si la respuesta es "depende de que el clasificador la atrape", no tienes una frontera, tienes una apuesta. Si la respuesta es "el componente que leyó el ataque no puede actuar, y el actor que sí puede actuar corre bajo una identidad acotada a casi nada", has contenido un problema sin resolver en lugar de fingir que está resuelto.
La capa del modelo no te va a salvar. La configuración no te va a salvar. La estructura es lo único que aguanta cuando aquello contra lo que te defiendes no tiene arreglo.
Si quieres pasar tus agentes en producción por los cuatro controles estructurales y descubrir hasta dónde llegaría de verdad una inyección exitosa, reserva una reunión y tráenos el que está conectado a más herramientas.