MMPIBench: los agentes intentan diez veces más inyecciones multimodales de las que completan

¿De qué se trata?

El 8 de septiembre de 2026, Viet K. Nguyen y Mohammad I. Husain, de California State Polytechnic University, Pomona, publicaron en arXiv An Experimental Evaluation of Multimodal Prompt Injection Attacks on Agentic AI Frameworks (2609.09404, cs.CR/cs.AI). El trabajo presenta MMPIBench, un banco de pruebas que ejecuta un conjunto fijo de ataques — mismas cargas, mismas herramientas simuladas, mismo prompt de sistema — sobre seis frameworks de agentes y cinco modelos fundacionales, y registra hasta dónde llega cada instrucción inyectada en lugar de limitarse a si triunfó.

El dato central es una brecha. En 720 ejecuciones, los ataques se completan en torno al 1 % de los casos pero se intentan en el 12,8 %: unos diez intentos por cada ataque completado. Los autores son explícitos sobre el alcance de su trabajo: «We do not propose a defense; MMPIBench is a measurement tool».

Cómo funciona

El benchmark cruza cuatro dimensiones: seis frameworks (LangGraph, CrewAI, AutoGen, OpenAI Agents SDK, Semantic Kernel, LlamaIndex Workflows), cinco modelos (Claude Opus 4.8, GPT-5.4, Gemini 3.1 Pro, Grok 4.3, Llama 4 Maverick), seis portadores visuales y cuatro objetivos del atacante: uso indebido de herramientas, exfiltración de datos, envenenamiento de memoria y propagación entre agentes. Las herramientas son simuladas, de modo que «completar» significa que el agente emitió la llamada dañina, no que un sistema real resultara afectado.

La aportación está en la instrumentación. Cada ejecución se etiqueta según la etapa más avanzada que alcanza:

Stage             Meaning                                        Share of 720 runs
----------------  ---------------------------------------------  -----------------
None              Payload never perceived                        32.9%
Perception        Payload read, flagged suspicious, agent stopped 23.6%
Planning          Payload read and reasoned about, not acted on   42.1%
Tool invocation   Malicious tool actually called                   0.3%
Execution         Deterministic judge confirms objective met       1.11%

De esa tabla se desprenden tres hallazgos.

El modelo pesa más que el framework. Las tasas de intento por modelo van del 0,0 % (Claude Opus 4.8, que además rechaza en el 59,7 % de sus 144 ejecuciones) al 23,6 % (Grok 4.3 y Llama 4 Maverick, cada uno). Las tasas por framework son mucho más homogéneas, del 10,0 % al 21,7 %, y el artículo advierte de dos factores de confusión que no puede separar en esa comparación.

Los portadores son muy desiguales. El texto renderizado en imagen (OCR) se intenta en el 27,5 % de sus ejecuciones y concentra 7 de los 8 ataques completados. Los metadatos EXIF y los códigos QR se intentan en el 0,0 %: en aproximadamente el 88 % de esas ejecuciones la carga no llega siquiera a la percepción, porque los modelos no leen campos EXIF ni decodifican códigos QR a partir de píxeles sin una herramienta de decodificación explícita.

La detención ocurre en la planificación, no ante una barrera. La mayoría de las ejecuciones muere en la banda de planificación (42,1 %), donde el modelo leyó la instrucción y decidió no llevarla adelante. Solo 170 de los 217 rechazos se detectan en la percepción; el resto contiene lenguaje de rechazo pero aun así alcanza la planificación.

Por qué importa

La tasa de finalización de alrededor del 1 % es la cifra menos interesante del artículo, y los autores lo dicen. Nada arquitectónico detuvo al 11,8 % restante: lo hizo el modelo. Como señala la sección VIII-A, «a behavioral guardrail holds only as long as the model keeps making that judgment».

La extensión al audio lo hace concreto. Solo dos de los modelos tokenizan audio de forma nativa, y solo tres de los seis frameworks lo entregan realmente: CrewAI acepta audio pero nunca lo adjunta y AutoGen carece de tipo de mensaje de audio. Pero allí donde la señal llega, el ataque se completa en el 49 % de las celdas (35 de 72) y en el 75 % con gpt-audio. Un framework que descarta una modalidad no le está protegiendo: simplemente no la transmite, y esa brecha se cierra en cuanto la función se publica.

Como contraste, VPI-Bench (NUS, junio de 2025) reportó tasas de engaño de hasta el 51 % en agentes que controlan un ordenador y del 100 % en agentes de navegador sobre plataformas reales. Ambas cifras no se contradicen: miden modelos de amenaza, encuadres de tarea y formulaciones de prompt distintos. Por eso una única «tasa de éxito» viaja mal de un artículo a otro.

Defensas

El artículo no evalúa ninguna mitigación. Los puntos siguientes separan sus recomendaciones de la práctica habitual.

Del artículo:

1. Reportar las tasas de intento y de reconocimiento, no solo la de finalización. La finalización «solo mide con qué frecuencia la generación actual de modelos ha declinado».
2. Distinguir el rechazo del descuido. «Only recognition is a guardrail. A model that overlooks a payload offers no assurance that it will keep overlooking it as carriers improve».
3. Vigilar la banda de planificación. Las ejecuciones que leen una carga y la ignoran en silencio ofrecen «una garantía más débil que un rechazo».
4. Tratar una modalidad ausente como un accidente. El modelo de tres compuertas — el modelo debe tokenizar el canal, el framework debe entregarlo y el modelo debe entonces rechazar — implica que un ataque necesita las tres abiertas. Dos de ellas son decisiones de producto, no controles de seguridad.
5. Extender el entrenamiento y la evaluación de seguridad a los canales perceptivos. El audio es hoy más estrecho que la visión y está mucho menos defendido.

Práctica habitual, ajena al artículo:

6. Restringir la superficie de acción, no la entrada. Aquí ningún filtro interceptó nada. Todas las finalizaciones fueron uso indebido de herramientas: exija confirmación para llamadas destructivas y salientes, sea cual sea el origen de la instrucción.
7. Registrar el artefacto junto a la acción. Conserve la imagen o el audio junto a cualquier llamada sensible para que la revisión posterior identifique el portador.
8. Volver a probar en cada cambio de versión. Los autores describen sus resultados como «una instantánea de versiones concretas más que una propiedad duradera de los sistemas».

Estado

Elemento	Referencia	Fecha	Notas
Artículo	arXiv:2609.09404 v1	2026-09-08	cs.CR / cs.AI, CC BY-NC-ND 4.0
Autores	Nguyen y Husain	—	California State Polytechnic University, Pomona
Escala	720 ejecuciones de imagen + 72 celdas de audio	—	6 frameworks × 5 modelos × 6 portadores × 4 objetivos
Intentos / finalizaciones	12,8 % / ~1,11 %	—	Intervalos de Wilson al 95 %: 10,5–15,4 % y 0,6–2,2 %
Finalización en audio	49 % de las celdas; 75 % con gpt-audio	—	2 modelos ingieren audio, 3 de 6 frameworks lo entregan
Publicación del benchmark	Prometida con la publicación	—	Sin URL de repositorio en el preprint
Explotación real	No reportada	—	Herramientas simuladas, entorno de investigación controlado

Lo incómodo no es que uno de cada cien ataques funcionara. Es que los otros once llegaran lo bastante lejos como para que el criterio del modelo fuera lo único entre una instrucción renderizada y una llamada a herramienta — y que en el único canal donde menos modelos están entrenados para ejercer ese criterio, la mitad de los ataques llegara hasta el final.