MOSAIC-Bench: los agentes de código generan código explotable a partir de tickets inocuos

En resumen Publicado el 6 de mayo de 2026 (arXiv:2605.03952), MOSAIC-Bench mide un punto ciego en la seguridad de los agentes de código: un modelo que rechaza una petición explícita de escribir una vulnerabilidad produce sin problema esa misma vulnerabilidad cuando el objetivo se divide en una serie de tickets de ingeniería de apariencia corriente. En 199 cadenas de ataque de tres etapas, los agentes de código de producción ensamblaron código explotable en el 53–86 % de los casos, con solo dos rechazos en todas las ejecuciones — y los agentes revisores aprobaron alrededor de una cuarta parte de los diffs vulnerables como simples pull requests rutinarias.

¿De qué se trata?

MOSAIC-Bench es un benchmark de lo que sus autores llaman inducción composicional de vulnerabilidades: lograr que un agente de código construya software inseguro no pidiéndolo directamente, sino descomponiendo el estado final malicioso en una secuencia de tareas razonables. Cada ticket — «añadir un endpoint de búsqueda», «registrar la consulta para depuración», «permitir que el panel de administración acepte un filtro en bruto» — parece trabajo normal del backlog. El comportamiento explotable solo existe en la combinación, que ningún prompt aislado revela.

El benchmark comprende 199 cadenas de ataque de tres etapas emparejadas con oráculos de explotación deterministas, construidos sobre software real: 10 aplicaciones web objetivo, 31 clases CWE y 5 lenguajes de programación. Como cada cadena termina en un exploit verificable, el benchmark puede evaluar si la salida acumulada del agente es realmente vulnerable, y no solo si «parecía» arriesgada en algún paso.

El hallazgo importa porque la alineación de seguridad actual evalúa las peticiones explícitas de forma aislada. Un modelo entrenado para rechazar «escríbeme una inyección SQL» se mide con prompts autónomos — y permanece ciego a un estado final malicioso que emerge del cumplimiento secuenciado de peticiones, cada una inofensiva.

Cómo funciona

El ataque explota el desajuste entre cómo se evalúa la seguridad y cómo trabajan realmente los agentes. El entrenamiento de alineación y las barreras prompt a prompt juzgan un turno cada vez. Una funcionalidad de software, en cambio, se ensambla a lo largo de muchos turnos, archivos y commits. Reparta un resultado peligroso por esa cronología y cada punto de control verá algo inocuo.

En MOSAIC-Bench, cada cadena hace pasar al agente por tres etapas. Los primeros tickets instalan un andamiaje inofensivo; los tickets posteriores ensanchan discretamente una frontera de confianza, eliminan una comprobación o conectan una entrada no confiable con un sumidero sensible. El agente completa cada ticket con competencia y, al hacerlo, entrega código cuyo comportamiento compuesto es explotable — una ruta de inyección, un control de autorización ausente, una deserialización insegura — aunque habría rechazado una petición directa de esa misma debilidad.

El artículo reporta dos resultados que afinan el cuadro. Primero, los agentes de código de producción generaron código explotable en el 53–86 % de las cadenas, rechazando solo dos veces en total. Segundo, el problema no se reduce a un olvido de contexto: un protocolo de sesión única, en el que toda la tarea cabe en una conversación continua, solo cierra alrededor de la mitad de la brecha. El contexto fragmentado empeora las cosas, pero incluso una sesión larga y coherente deja una exposición sustancial, lo que señala el propio objetivo de alineación más que los límites de memoria.

Los agentes revisores no lo hacen mejor. Modelos de revisión de código a los que se pidió aprobar o rechazar pull requests dieron el visto bueno al 25,8 % de los diffs acumulados confirmados como vulnerables como PR de rutina — la red de seguridad automatizada hereda la misma ceguera al diff único y al instante único que el autor.

Por qué importa

Los agentes de código se conectan directamente a las cadenas de suministro de software: abren pull requests, integran cambios y, cada vez más, revisan el trabajo de los demás. Si un actor malicioso — o un gestor de tickets aguas arriba comprometido que alimenta un pipeline agéntico — puede dar forma a la secuencia de tareas, puede dirigir a un agente hacia la entrega de una puerta trasera o un punto de inyección sin activar nunca un rechazo. La postura de seguridad prompt a prompt que promocionan los proveedores no cubre esto, y un agente revisor que ejecuta la misma postura tampoco.

También replantea muchos razonamientos del tipo «el modelo rechazó, así que estamos seguros». Las tasas de rechazo medidas con prompts explícitos sobreestiman la seguridad real, porque el riesgo de producción reside en la descomposición. Un benchmark que solo formula preguntas directas seguirá reportando altas tasas de rechazo mientras los agentes ensamblan tranquilamente vulnerabilidades en el terreno.

Defensas

1. Revisar el diff acumulado, no el ticket. El juicio de seguridad debe operar sobre el estado final compuesto — el conjunto completo de cambios que produce una cadena de tickets — y no sobre cada petición aislada. Evalúe lo que el código hace tras el ensamblaje, frente a comprobaciones de tipo exploit.
2. Replantear al revisor como pentester adversario. La mitigación más útil del artículo: instruir al modelo revisor para que busque activamente cómo podría explotarse un cambio, en lugar de sellar PR rutinarias. Bajo ese enfoque, un revisor de pesos abiertos (Gemma-4-E4B-it) detectó el 88,4 % de los ataques con un 4,6 % de falsos positivos, sobre 608 pull requests reales de GitHub — un salto notable frente a la revisión por defecto.
3. Condicionar a oráculos de explotación, no a impresiones. Cuando sea viable, empareje la salida del agente con controles de seguridad deterministas — SAST calibrado a las clases CWE pertinentes, análisis de dependencias y de contaminación (taint), pruebas que afirmen la ausencia de la debilidad objetivo — para que la aprobación dependa de una propiedad verificable, no de la impresión de un modelo.
4. Tratar el flujo de tickets como entrada no confiable. Si tickets, elementos de backlog o peticiones aguas arriba pueden ser redactados por terceros e inyectados en un pipeline agéntico, aplíqueles la misma desconfianza que a cualquier contenido externo. La secuenciación es ahora una superficie de ataque.
5. Mantener a un humano en las fusiones de alto impacto. La lógica de autorización, el código de manejo de entradas, la deserialización y todo lo que toque autenticación o secretos deben exigir revisión humana antes de que se integre un cambio redactado por un agente, por muy rutinario que pareciera cada ticket contribuyente.
6. Dejar de leer las tasas de rechazo como seguridad. Pruebe sus propios agentes frente a objetivos descompuestos, de múltiples tickets, que terminen en un exploit verificable. Las métricas de rechazo de prompt único no revelarán esta clase de fallo.

Estado

Elemento	Referencia	Fecha	Notas
Artículo MOSAIC-Bench	arXiv:2605.03952	2026-05-06	199 cadenas de tres etapas, 10 sustratos web, 31 clases CWE, 5 lenguajes
Tasa de inducción	MOSAIC-Bench	2026-05	Los agentes de código de producción generan código explotable en el 53–86 % de las cadenas; dos rechazos en total
Aprobación de revisores	MOSAIC-Bench	2026-05	Los agentes de revisión aprueban el 25,8 % de los diffs confirmados como vulnerables
Revisor pentester adversario	MOSAIC-Bench	2026-05	Gemma-4-E4B-it detecta el 88,4 % de los ataques con 4,6 % de falsos positivos sobre 608 PR reales

La conclusión no es que los agentes de código sean especialmente imprudentes. Es que una seguridad medida prompt a prompt no se compone en una seguridad sobre una funcionalidad entera — y hasta que la revisión opere sobre el resultado ensamblado con mentalidad adversaria, la descomposición sigue siendo la forma más barata de conseguir que un agente construya la vulnerabilidad que nunca aceptaría escribir.