Los agent harnesses son el nuevo CI: lo que Firefox, Google y otros estan demostrando

En abril de 2026, Mozilla lanzo Firefox 150 con correcciones para 271 bugs de seguridad (180 de ellos clasificados como sec-high), encontrados por un unico pipeline agente construido sobre Claude Mythos Preview. No es un error de tipeo. Doscientos setenta y un bugs, en un solo release, de un sistema que no existia seis meses antes. Cuando leimos el desglose tecnico, dejamos lo que estabamos haciendo y metimos a todo el equipo de ingenieria en un hilo.

Este post analiza que es realmente un agent harness, por que el caso de Firefox importa mas alla del numero titular, y que estan haciendo otros equipos, incluyendo Google Project Zero, en el mismo espacio. Si escribes software que llega a produccion, vale la pena entender estos patrones ahora.

---

El concepto detras de los agent harnesses

Un agent harness es la estructura alrededor de un LLM que lo convierte de una herramienta conversacional en un pipeline estructurado y repetible. El modelo es la pieza central; el harness es lo que lo hace util a escala.

En terminos concretos, un harness define:

• Que puede ver el agente. Archivos fuente, diffs, historial de commits, resultados de tests, logs de crashes.
• Que puede hacer el agente. Compilar codigo, ejecutar casos de prueba, activar sanitizers, escribir parches, reportar bugs.
• Como recibe retroalimentacion. Senales de runtime: el test se cayo? AddressSanitizer reporto algo? El proof-of-concept se reprodujo?
• Como se manejan los fallos. Estrategias de reintento, deduplicacion contra issues conocidos, escalamiento a revision humana.

La idea clave es que un agente con acceso a un entorno de build y un ciclo de retroalimentacion es categoricamente diferente de un agente que solo lee codigo y produce texto. Cuando un modelo puede formular la hipotesis de que un bug existe, escribir un caso de prueba, compilarlo, ejecutarlo, observar el resultado e iterar — deja de ser un motor de sugerencias y se convierte en un sistema de descubrimiento.

---

Como Mozilla construyo su pipeline de deteccion de bugs

El articulo tecnico de Mozilla ofrece un nivel de detalle inusual sobre un agent harness en produccion. Asi funciona el sistema, capa por capa.

El ciclo interno

En el nucleo, el harness le da al modelo una region especifica del codigo fuente de Firefox con una directiva: hay un bug en esta parte del codigo, encontralo y construye un caso de prueba. El modelo puede:

1. Leer el codigo objetivo y el contexto circundante
2. Escribir un caso de prueba en C++/JavaScript disenado para disparar una vulnerabilidad sospechada
3. Compilar y ejecutar el test dentro de la infraestructura de pruebas de Firefox
4. Observar si AddressSanitizer, el crash reporter u otras senales confirman el bug
5. Iterar: refinar el caso de prueba o pasar a una nueva hipotesis

Este ciclo de compilar-ejecutar-observar es lo que separa al harness de una revision de codigo estatica. El modelo no solo afirma que un bug existe; lo prueba con un caso de prueba reproducible, o sigue adelante.

El ciclo externo

El descubrimiento solo no es suficiente. Mozilla construyo un pipeline completo alrededor del ciclo interno:

• Seleccion de objetivos. Una mezcla de juicio humano y senales automatizadas determina que archivos y funciones escanear. Areas de alto riesgo como el compilador JIT, los limites de IPC y el motor XSLT tienen prioridad.
• Paralelizacion. Los trabajos se distribuyen en multiples VMs efimeras, cada una asignada a un archivo objetivo especifico. Los resultados se envian a un bucket central.
• Deduplicacion. Los hallazgos entrantes se verifican contra issues conocidos para evitar reportes duplicados.
• Triaje y seguimiento. Los bugs entran al ciclo de vida estandar de seguridad de Mozilla: clasificacion de severidad, asignacion de parche, revision de codigo, gestion de release.
• Actualizacion de modelos. Como el pipeline es agnostico al modelo, intercambiar uno mas nuevo (como pasar de Claude Opus 4.6 a Claude Mythos Preview) mejora cada etapa simultaneamente: mejores hipotesis, mejores casos de prueba, mejores explicaciones.

Como lucian los bugs

Los bugs que Mozilla hizo publicos no son triviales. Algunos ejemplos de la muestra publicada:

• Bug 2024918: Una verificacion de igualdad incorrecta hizo que el JIT omitiera la inicializacion de un struct WebAssembly GC activo, creando un primitivo de objeto falso con potencial lectura/escritura arbitraria. Esto en codigo que habia sido extensivamente fuzzeado.
• Bug 2024437: Un bug de 15 anos en el elemento <legend>, disparado solo por una orquestacion precisa de limites de profundidad de recursion, propiedades expando y recoleccion de ciclos.
• Bug 2021894: Una condicion de carrera sobre IPC que permitia a un proceso de contenido comprometido manipular refcounts de IndexedDB, disparando un use-after-free para un potencial escape de sandbox.
• Bug 2025977: Un bug de 20 anos en XSLT donde llamadas reentrantes a key() causaban un rehash de tabla que liberaba su almacenamiento mientras un puntero sin procesar seguia activo.

Varios de estos son escapes de sandbox, la clase mas dificil de vulnerabilidad de navegador. Al modelo se le permitio parchear el proceso de contenido aislado de Firefox para simular un renderer comprometido, y luego buscar formas de escalar al proceso padre privilegiado. Este tipo de razonamiento sobre limites de confianza a traves de aislamiento de procesos es algo con lo que los fuzzers luchan fundamentalmente.

---

Google Big Sleep y el patron entre proyectos

Mozilla no esta solo. Google Project Zero y DeepMind han estado ejecutando un esfuerzo paralelo llamado Big Sleep, que evoluciono del proyecto anterior Naptime.

El descubrimiento en SQLite

A finales de 2024, Big Sleep encontro un stack buffer underflow en SQLite, el motor de base de datos integrado en miles de millones de dispositivos. La vulnerabilidad existia en una rama de desarrollo y fue detectada antes de cualquier release oficial. La infraestructura de fuzz testing existente, incluyendo OSS-Fuzz de Google, no la habia detectado.

A mediados de 2025, las apuestas subieron. Big Sleep descubrio CVE-2025-6965, una vulnerabilidad critica de corrupcion de memoria en SQLite que, segun Google, “solo era conocida por actores de amenazas y estaba en riesgo de ser explotada.” Google afirma que fue la primera vez que un agente de IA previno directamente la explotacion de una vulnerabilidad. El parche se envio en SQLite 3.50.2 antes de que los adversarios pudieran escalar su uso de la falla.

AgentFlow y los zero-days de Chrome

Una linea de investigacion separada, documentada en el paper Synthesizing Multi-Agent Harnesses for Vulnerability Discovery, introdujo AgentFlow, un sistema que sintetiza automaticamente harnesses multi-agente usando un DSL de grafos tipado. En lugar de construir manualmente un solo ciclo de agente, AgentFlow define roles de agentes, topologia de comunicacion, acceso a herramientas y coordinacion de reintentos como un grafo que puede optimizarse.

Los resultados: AgentFlow obtuvo 84.3% en TerminalBench-2 (el puntaje publico mas alto al momento de publicacion) y descubrio diez vulnerabilidades zero-day en Google Chrome, incluyendo dos escapes de sandbox criticos (CVE-2026-5280 y CVE-2026-6297). Tambien encontro una vulnerabilidad de denegacion de servicio de 27 anos en la implementacion de TCP SACK de OpenBSD.

El patron compartido

En todos estos esfuerzos, el patron de ingenieria es el mismo:

1. Un modelo como nucleo de razonamiento. Lee codigo, forma hipotesis, genera casos de prueba.
2. Un entorno de build/test que el modelo puede controlar. Compilacion, ejecucion, sanitizers, analisis de crashes.
3. Un ciclo de retroalimentacion que filtra senal del ruido. Solo los bugs que se reproducen sobreviven.
4. Una capa de orquestacion que maneja la escala. VMs paralelas, priorizacion de objetivos, deduplicacion, triaje.
5. Un pipeline que se conecta a flujos de trabajo existentes. La salida es un bug registrado con un reproductor, no un informe PDF.

---

Por que los fuzzers no encontraron lo que los agentes si

La pregunta natural es: por que estos bugs sobrevivieron anos de fuzzing? Mozilla, Google y equipos academicos han ejecutado fuzzers de ultima generacion contra estos codebases por mas de una decada.

La respuesta se reduce a razonamiento versus fuerza bruta. Los fuzzers generan entradas a alta velocidad y miden cobertura, pero no tienen un modelo de la semantica del programa. Un agente, por el contrario, puede:

• Leer y razonar sobre limites de confianza. Un escape de sandbox requiere entender que proceso tiene que privilegios, como fluyen los mensajes IPC y donde un proceso comprometido podria inyectar datos maliciosos. Los fuzzers no modelan estas relaciones.
• Encadenar disparadores de multiples pasos. El Bug 2024437 en Firefox requeria una secuencia precisa: manipular limites de profundidad de recursion, configurar propiedades expando, disparar recoleccion de ciclos. Un fuzzer necesitaria tropezar con esta secuencia exacta; un agente puede razonar sobre ella.
• Aprovechar conocimiento del dominio. El bug de NaN-boxing (Bug 2022034) requeria entender como Firefox serializa valores JavaScript a traves de IPC, y que un NaN crudo puede hacerse pasar por un puntero etiquetado. Eso es conocimiento arquitectonico, no algo que la generacion de entradas aleatorias descubre.

Dicho esto, agentes y fuzzers son complementarios. Los fuzzers sobresalen cubriendo espacios de entrada masivos de forma economica. Los agentes sobresalen en analisis profundo y dirigido de rutas de codigo complejas. La postura de seguridad mas fuerte usa ambos.

---

Que hace un buen harness

Basandonos en los patrones de estos proyectos, algunos principios de ingenieria se destacan para cualquiera que construya un agent harness, ya sea para seguridad, testing u otros flujos de trabajo en produccion.

Empezar simple, luego iterar. Los prompts iniciales de Mozilla no eran dramaticamente diferentes de lo que cualquier ingeniero intentaria en un primer intento. La sofisticacion vino de observar el comportamiento del agente, ajustar los prompts y construir orquestacion alrededor del ciclo central. El harness crecio de sesiones de terminal a flotas de VMs paralelizadas a traves de iteracion gradual.

El ciclo de retroalimentacion es el producto. Un agente que solo puede leer y escribir texto siempre tendra una alta tasa de falsos positivos. En el momento en que le das la capacidad de compilar, ejecutar y observar, la relacion senal-ruido cambia fundamentalmente. Invierte en el entorno antes que en el prompt.

Hacer que las actualizaciones de modelo sean un cambio de una linea. Mozilla diseno su pipeline para ser agnostico al modelo. Cuando Claude Mythos Preview estuvo disponible, lo intercambiaron e inmediatamente obtuvieron mejores resultados. Si tu harness esta fuertemente acoplado a las particularidades de un modelo especifico, pierdes la capacidad de beneficiarte de la parte del stack que mas rapido avanza.

Conectar a flujos de trabajo existentes. La salida de un agent harness deberia ser un ticket de bug con un reproductor, un test que falla o un PR. No un reporte aislado que requiere triaje aparte. El pipeline de Mozilla alimenta directamente su ciclo de vida de bugs de seguridad. Los hallazgos de Google pasan por procesos estandar de CVE. El harness es un productor; los sistemas existentes son el consumidor.

Planificar para el volumen. Mozilla corrigio 423 bugs de seguridad en los releases de abril de 2026. Eso es un orden de magnitud por encima de su linea base historica de 20-30 por mes. El cuello de botella paso del descubrimiento a la revision de parches y gestion de releases. Si despliegas un harness efectivo, asegurate de que el pipeline aguas abajo pueda manejar el volumen.

---

Que significa esto para el resto de nosotros

Los ejemplos de Mozilla y Google son proyectos a escala de navegador con equipos de seguridad dedicados. Pero los patrones subyacentes son accesibles para cualquier equipo que mantenga un codebase con un suite de tests.

El minimo viable de un agent harness es mas simple de lo que parece: un prompt, acceso a git, un compilador o test runner, y un ciclo que verifique si la salida se reproduce. No necesitas una flota de VMs para comenzar. Necesitas un ciclo de retroalimentacion.

El propio consejo de Mozilla: “Cualquiera que construya software puede empezar a usar un harness con un modelo moderno para encontrar bugs y fortalecer su codigo hoy. Recomendamos empezar ahora.”

Los equipos que construyen esta infraestructura ahora, incluso a pequena escala, estaran posicionados para aprovechar cada actualizacion de modelo que venga despues. El harness es la inversion duradera; el modelo es la parte que mejora sola.

Para equipos que coordinan agentes de IA junto a desarrolladores humanos, el desafio mas amplio no es solo ejecutar agentes sino rastrear lo que encuentran, enrutar su salida a procesos existentes y mantener a los humanos involucrados en las decisiones de triaje. Esa capa de coordinacion es donde vive la complejidad operativa.

El momento de empezar a construir es ahora. No porque los modelos actuales sean perfectos, sino porque la infraestructura que construyes hoy se potencia con cada modelo que viene despues.