La inyección de prompts no está resuelta: conténgala a velocidad de máquina

¿De qué se trata?

El 8 de junio de 2026, Infosecurity Magazine recogió las declaraciones realizadas en Infosecurity Europe 2026 por Ariel Fogel, investigador de seguridad de IA en la oficina del CTO de Pillar Security y colaborador del proyecto GenAI Security de OWASP. Su mensaje fue directo: la inyección de prompts «sigue siendo un problema sin resolver» a nivel arquitectónico, y la brecha se ensancha a medida que los agentes ganan herramientas y la capacidad de actuar.

No es una nueva divulgación de vulnerabilidad, sino una evaluación del estado del arte procedente del organismo que redacta el Top 10 de OWASP para aplicaciones LLM y agénticas — en la misma semana en que OWASP presentó su Agentic Research Council (anunciado el 4 de junio) para acercar la investigación a mitigaciones desplegables. Lo cubrimos porque la conclusión práctica ha cambiado: hay que dejar de esperar una solución y diseñar para la contención.

Cómo funciona

La causa de fondo es estructural, no un fallo que parchear. Un LLM procesa su entrada como una única secuencia de tokens, y no existe ningún mecanismo fiable, dentro del modelo, que imponga una frontera de privilegio entre el prompt del sistema, la consulta del usuario y el contenido que un agente recupera del mundo exterior. Las instrucciones de confianza y los datos no confiables llegan por el mismo canal: cualquier texto que el modelo lea puede competir por convertirse en instrucción. Es el hecho arquitectónico que hay detrás del Lethal Trifecta de Simon Willison — datos privados, exposición a contenido no confiable y una vía de exfiltración — y detrás de la idea más amplia de que la seguridad de los agentes es un problema de sistemas, no de modelo.

Lo que cambia con los agentes es la consecuencia. El argumento de Fogel: una inyección exitosa ya no solo produce una mala respuesta; cuando el ejecutor es un agente con acceso a herramientas, puede desencadenar una cadena de acciones reales — una escalada de la mala salida a la compromisión activa.

El punto en el que conviene detenerse es cómo fallan los controles de la «era humana» en este contexto. Fogel describió dos patrones observados en ataques reales:

Control (era humana)    Cómo falla frente a un agente
----------------------  ----------------------------------------------------
Allow-list de comandos  Los comandos que el agente necesita ya están
                        aprobados: la allow-list *facilita* el exploit
                        en lugar de bloquearlo.
Frontera de sandbox     La salida del agente redefine la frontera —
                        reescribiendo de hecho la contención que debía
                        detenerlo.
Revisión manual         Los ataques se desarrollan en minutos; los ciclos
                        de revisión humana son demasiado lentos por acción.

Heurísticas como el Lethal Trifecta y la Rule of Two de Meta (un agente no debería satisfacer más de dos de las tres propiedades del trifecta sin aprobación humana) ayudan a reducir el radio de impacto, pero Fogel advirtió que no son defensas completas — ya hay investigaciones publicadas que muestran ataques exitosos con solo dos de las propiedades presentes.

Por qué importa

La mayoría de las organizaciones, señaló Fogel, despliega agentes más rápido de lo que puede gobernarlos. Esa brecha importa porque el modo de fallo ya no es cosmético. La velocidad y la escala que hacen útiles a los agentes también reducen el tiempo hasta el impacto de una inyección, y los controles en los que muchos equipos confían — allow-lists, sandboxes, revisiones periódicas — se diseñaron para operadores humanos y pueden convertirse en aceleradores. Tratar la inyección de prompts como un mero problema de validación de entrada lleva a confiar en exceso en agentes que deberían estar muy restringidos.

Defensas

La postura recomendada pasa de la lógica de prevención pura a limitar lo que un agente comprometido puede hacer, con controles que operen a la velocidad del agente:

• Asuma que la inyección tendrá éxito. Diseñe primero el radio de impacto: limite las herramientas, los datos y el acceso de red saliente de cada agente al mínimo necesario para la tarea.
• Presupueste el trifecta. Aplique la Rule of Two — exija un punto de control humano antes de que una sesión combine datos privados, contenido no confiable y un canal de exfiltración — sabiendo que existen ataques con dos propiedades.
• Monitorice a velocidad de máquina. Use monitorización conductual en vivo de las llamadas a herramientas, con contención en tiempo real y mecanismos de parada forzada, en lugar de análisis de registros a posteriori.
• Ajuste identidad y sesiones. Emita credenciales efímeras y de alcance reducido, y añada atestación criptográfica para que cada acción del agente sea rastreable y limitada en el tiempo.
• Unifique respuesta de seguridad y safety. Construya playbooks de incidentes que cubran escenarios multiagente a velocidad de máquina, con supervisión human-on-the-loop en lugar de una validación human-in-the-loop por acción que no puede seguir el ritmo.

Estado

Elemento	Detalle
Fuente	Ariel Fogel (Pillar Security / OWASP), Infosecurity Europe 2026
Reportado	8 de junio de 2026 (Infosecurity Magazine)
Naturaleza	Limitación arquitectónica — sin parche; la mitigación es la contención
Relacionado	Agentic Research Council de OWASP lanzado el 4 de junio de 2026

Esto es un análisis, no un exploit: no hay payload que publicar ni un único proveedor al que parchear. La lección duradera: mientras los modelos y los runtimes no puedan imponer una separación firme de privilegios entre instrucciones y datos, la inyección de prompts es una propiedad del entorno que los defensores deben contener — no un fallo que puedan esperar a que desaparezca.