Ejecutar en un sandbox un pipeline de IA que encuentra y corrige fallos de seguridad

## Enviar el trabajo de solo lectura a las habilidades de análisis y la ejecución de código al sandbox Este tipo de sistema tiene dos superficies distintas; dirige al usuario hacia la que corresponde. - Las habilidades de análisis interactivo leen y escriben archivos en el repositorio y se ejecutan en tu sesión actual. Nunca ejecutan el código objetivo. Úsalas para acotar el alcance, modelar amenazas, revisar vulnerabilidades de forma estática, triar una pila de hallazgos existente, redactar parches candidatos y portar el pipeline a otra pila tecnológica. Dirige aquí las preguntas y cualquier trabajo de solo lectura. - El pipeline autónomo sí ejecuta el objetivo para encontrar y verificar fallos (crashes). Como corre código no confiable e influenciado por un atacante, debe ejecutarse dentro de un sandbox contra una build instrumentada. Dirige aquí solo cuando el usuario quiera hallazgos reales, verificados por ejecución, y no una opinión estática. Mantén las dos bien diferenciadas: la superficie de lectura/escritura razona sobre el código, la superficie de ejecución lo corre. Una informa; la otra demuestra. La salida del lado de ejecución es un archivo de entrada que reproduce el fallo, no un texto explicativo. ## Empezar con una ejecución de prueba pequeña y lanzar la completa en segundo plano Opera el pipeline como un panel en vivo, no como un lote de lanzar-y-olvidar. - Primero guía al usuario por el reconocimiento de forma interactiva: muéstrale las áreas de interés descubiertas y déjalo ajustar la partición antes de lanzar nada. - Para una primera corrida contra un objetivo nuevo, lanza una tanda pequeña (pocas corridas en paralelo, un límite de turnos bajo) para que el usuario se haga una idea del consumo de tokens y de la calibración del prompt antes de escalar. Si algo se ve raro, revisen juntos una transcripción. - Después lanza la corrida más grande en segundo plano para poder seguir los logs, ver cómo se acumulan los hallazgos y responder preguntas sin bloquearte. A medida que llega cada resultado verificado, muéstralo con un resumen breve en lugar de esperar a todo el lote. El primer hallazgo verificado suele llegar en minutos, no en horas; una corrida rezagada solo se retrasa a sí misma, no al lote entero. ## Guardar cada transcripción en disco para no perder nada si la ejecución se detiene Dale a cada corrida dos capas de observabilidad siempre activas. - Un latido (heartbeat) impreso cada cierto número de turnos demuestra que el proceso sigue vivo durante tramos largos de silencio. - Una línea de progreso por acción muestra qué está haciendo cada agente, una línea por cada llamada a herramienta o bloque de texto. Transmite cada transcripción de agente a disco a medida que llegan los mensajes, con escritura garantizada (flush durable). Nada importante queda solo en memoria, así que si la corrida se interrumpe a mitad de camino, igual quedan transcripciones completas y legibles para revisar después. Cuando el usuario pida el estado, responde a partir de los artefactos en disco: cuenta las búsquedas que siguen activas, las que ya fueron calificadas y los reportes escritos, y luego muestra los más recientes. Cada resultado se escribe en el momento en que termina su propia corrida, así que las rezagadas nunca bloquean la llegada de las demás. ## Reanudar los agentes tras un límite de tasa en lugar de perder la ejecución Los errores transitorios de capacidad no deben matar una corrida; construye una escalera de recuperación para que los trabajos largos aguanten los picos. - Cada agente es una sesión de larga duración. Un error de límite de tasa o de servidor a mitad de corrida se reintenta primero dentro del propio cliente del agente. - Si eso no funciona, el orquestador aplica un retroceso (exponencial, con un tope) y relanza al agente retomando su sesión, de modo que se restaura todo el contexto de la conversación y continúa desde el turno exacto en que falló. - Limita el número de reanudaciones por agente para que uno realmente atascado termine deteniéndose. Dile al usuario que puede operar cerca de su capacidad contratada y dejar que el retroceso absorba los picos; no necesita autolimitarse para evitar perder trabajo. Una excepción: un error de turnos agotados es terminal y deliberadamente no se reanuda, porque reanudar multiplicaría el límite de turnos — en su lugar, sube el límite y vuelve a correr. Cualquier hallazgo que el agente ya haya enviado antes de tocar ese límite se rescata y se califica igual, no se descarta junto con la corrida. ## Redactar informes de fallos nuevos automáticamente y preguntar antes de usar la red En modo streaming, el reporte es automático. Cuando cada fallo pasa la calificación, un agente juez decide si es un bug nuevo, una versión más limpia de uno ya conocido, o un duplicado que se puede omitir; un bug nuevo dispara de inmediato un agente de reporte, sin esperar al lote. También queda disponible una ruta de reporte por lote independiente, para recuperación o para resultados producidos sin streaming. Cada reporte es un análisis estructurado de explotabilidad — cómo se comporta la primitiva, si es alcanzable desde la superficie de ataque real, la ruta de escalamiento y las restricciones — más una severidad evaluada por el agente. Un agente calificador independiente puntúa el reporte contra una rúbrica semántica, no con un escaneo de palabras clave. Antes de activar cualquier paso que salga a una red externa — por ejemplo, una verificación de novedad que clona el repositorio upstream del objetivo para saber si un bug ya está corregido — pregúntale primero al usuario. Déjalo desactivado por defecto: los entornos aislados (air-gapped) o con salida restringida no van a querer que el pipeline se conecte hacia afuera. Solo el host orquestador toca la red; los contenedores de los agentes se mantienen restringidos al endpoint del modelo en cualquier caso. ## Comprobar que el fallo desapareció y dejar que una persona acepte el parche La fase de parcheo puede correr después del reporte o de forma independiente. Para cada fallo único, un agente de parcheo en un contenedor sandbox recién creado escribe una corrección y emite un diff; un contenedor calificador aparte recorre una escalera de verificación. - Aplica el diff y reconstruye. - Confirma que la entrada original que reproducía el fallo ya no lo provoca. - Confirma que la propia suite de pruebas del objetivo sigue pasando. - Vuelve a atacar el binario parcheado con un agente de búsqueda nuevo y con tiempo limitado. Si un peldaño falla, la evidencia se retroalimenta y el agente de parcheo itera un número acotado de veces; se puede añadir como peldaño final una revisión opcional de estilo consultivo (advisory). Sé explícito con el usuario sobre qué demuestra esto en realidad. La escalera verifica que el fallo desapareció; no verifica que el diff sea seguro para subir al proyecto original (upstream). Muestra el diff para revisión humana y señala la guía de revisión correspondiente. No ofrezcas aplicar el diff a nada fuera de los propios contenedores del pipeline — las correcciones generadas son propuestas para que una persona las acepte, no cambios que se apliquen de forma automática. ## Dejar que los agentes juzguen los fallos duplicados por su causa, no por el texto Deduplica los fallos usando el criterio del agente en dos capas, no comparación de texto literal. - Al momento de enviar un hallazgo, un agente de búsqueda debe adjuntar su propio razonamiento de por qué un fallo es distinto de lo ya registrado en el archivo de hallazgos compartido. El pipeline rechaza cualquier envío que lo omita. El agente toma la decisión porque conoce la causa raíz; el pipeline solo garantiza que ese juicio se haya hecho. Compara de forma semántica contra los extractos crudos del sanitizador, no por coincidencia exacta de texto. - En la puerta de reporte, un agente juez lee cada fallo ya calificado contra el manifiesto de reportes en curso y decide entre nuevo, duplicado-más-limpio, u omitir. La misma causa raíz que aparece en líneas o frames distintos se sigue deduplicando; un duplicado más limpio dispara un nuevo reporte, y luego un paso de comparación elige cuál es el canónico. Cuando registres un bug conocido, indéxalo por el nombre de la función, no por el número de línea: el mismo bug puede fallar en líneas adyacentes, o con distintos tipos de sanitizador, según la entrada. ## Mantener la búsqueda y la calificación en contenedores separados y restringidos El modelo de aislamiento es lo que hace confiables los resultados verificados por ejecución; trátalo como no negociable. - Búsqueda y calificación corren en contenedores separados construidos desde la misma imagen. Solo los bytes de la prueba de concepto pasan de uno a otro. El lado de búsqueda nunca toca el lado de calificación, lo cual anula cualquier intento de manipular la recompensa (reward-hacking) mediante estado pre-posicionado. - Cada agente corre dentro de su propio contenedor, con un runtime reforzado y la salida de red limitada a una lista blanca configurada — dentro del sandbox, no en el host. Sus herramientas de archivos y de shell quedan confinadas a ese contenedor. - Los comandos que generan agentes se niegan a arrancar fuera del sandbox, a menos que se pase explícitamente una anulación marcada como peligrosa. - El conjunto de herramientas del agente es fijo y mínimo: los agentes que actúan solo reciben lectura, escritura y shell; los agentes juez y de comparación no reciben ninguna herramienta y hacen todo en una sola llamada con prompt. Sin herramientas de plugins, sin acceso web. ## Evitar ajustes que rompen el arranque y añadir objetivos sin cambiar el código Hay algunos detalles operativos fáciles de romper y que vale la pena aclarar desde el principio. - Algunas variables de entorno son estructurales: una desactiva la protección contra sesiones anidadas de la herramienta dentro del contenedor, otra le permite aceptar un modo de omisión de permisos (bypass-permissions) dentro del sandbox. Quitar cualquiera de las dos rompe el arranque del agente. - Distingue entre "restringir el conjunto de herramientas disponibles" y "lista blanca de permisos" — una CLI puede aceptar ambas opciones (flags), pero significan cosas distintas; usa la que realmente reduce qué herramientas existen, no solo cuáles están permitidas. - La elección del modelo es un argumento en tiempo de ejecución, no una configuración estática, así que la misma definición de objetivo puede ser manejada por cualquier modelo. - Un parser instrumentado con sanitizador puede necesitar un atributo no-inline para que el inlining del compilador no cambie la firma del fallo. Agregar un objetivo es simplemente añadir un directorio con una definición de build y una configuración de sanitizador; no requiere cambios en el código del pipeline. Cubre las partes móviles con pruebas unitarias — parseo de etiquetas y salida, serialización de artefactos, extracción de firmas, deduplicación y la escalera de parcheo-calificación — y mantén un objetivo de prueba rápido y fijo como ruta de smoke test de extremo a extremo. ## Rastrear al atacante en los registros sin que el agente vea las respuestas Existe una variante hermana, de post-compromiso, que invierte el problema: el atacante ya está en los logs, y la tarea consiste en encontrar su campaña en lugar de hacer fallar un binario. - El corpus de logs debe generarse antes de que corra cualquier cosa. Es grande y determinista según la semilla (seed), así que la misma semilla reproduce la misma evidencia en la misma máquina. - Un agente de caza recibe el código fuente de la aplicación y los logs en modo solo lectura, y envía sus hallazgos del incidente. Por diseño, dentro de su contenedor no existe ninguna clave de respuestas. - Un agente calificador en un contenedor nuevo puntúa el envío y vuelve a disparar de forma independiente cada prueba de concepto confirmada. Solo el envío cruza el límite. Protege la integridad de la evaluación: los archivos de verdad de referencia (ground-truth), el calificador y el código fuente del generador de logs son spoilers. Nunca los montes ni los leas del lado de caza. Aquí aplica la misma forma interactivo-y-luego-autónomo que en el pipeline de fallos.