- Qué necesita aislar un sandbox de agente de codificación
- Flujo de trabajo de referencia para ejecutar código generado por agentes
- Puntos de control de seguridad antes de la ejecución de comandos
- Cómo manejar instalaciones de paquetes y acceso a la red
- Diffs, artefactos y registros para revisión humana
- Dónde encaja Novita Agent Sandbox
- Preguntas frecuentes
- Artículos recomendados
Un sandbox de agente de codificación permite que los comandos y cambios de código generados por el agente se ejecuten en un espacio de trabajo delimitado, donde se pueden controlar archivos, procesos, acceso a la red, secretos, registros y artefactos de revisión. El objetivo práctico no es fingir que el código generado arbitrariamente es inofensivo. El objetivo es tratar al agente como un colaborador no confiable con una máquina de desarrollo desechable, límites claros, ejecución observable y una ruta de aprobación humana antes de que cualquier cosa llegue a producción.
Qué necesita aislar un sandbox de agente de codificación
Un agente de codificación se vuelve útil cuando puede inspeccionar un repositorio, editar archivos, ejecutar pruebas, instalar dependencias y devolver un parche. Esas también son las acciones que hacen que el entorno sea riesgoso. Una instalación de dependencia inyectada mediante prompt, un comando de shell destructivo o un secreto expuesto accidentalmente pueden causar más daño que una respuesta de texto incorrecta.
Diseña el sandbox en torno a los recursos que un agente de codificación puede tocar:
| Superficie | Qué controlar | Por qué es importante |
|---|---|---|
| Checkout del repositorio | Rama, SHA del commit, alcance de escritura, submódulos, archivos generados | Evita que el agente modifique el código base incorrecto u oculte cambios fuera de la ruta de revisión. |
| Sistema de archivos | Raíz del espacio de trabajo, archivos montados, rutas ignoradas, directorios de salida | Previene el acceso amplio a archivos del host, credenciales, cachés y proyectos no relacionados. |
| Ejecución de shell | Comandos permitidos, directorio de trabajo, tiempo de espera, captura de salida, controles de aprobación | Le da al agente suficiente poder para construir y probar, mientras limita acciones de alto riesgo. |
| Instalaciones de paquetes | Política de registro, archivos de bloqueo, versiones fijadas, estrategia de caché, registros de instalación | Reduce la ambigüedad en la cadena de suministro cuando el agente solicita nuevas dependencias. |
| Acceso a la red | Salida predeterminada, listas blancas, comportamiento DNS, destinos de API, mirrors de paquetes | Ayuda a prevenir el movimiento de datos no intencionado y hace que las llamadas externas sean revisables. |
| Secretos | Credenciales con alcance limitado, tokens de corta duración, redacción, sin claves de producción por defecto | Evita que el agente lea o filtre credenciales que no necesita. |
| Artefactos | Informes de prueba, salidas de compilación, capturas de pantalla, archivos generados, registros | Proporciona a los revisores evidencia sin depender solo del resumen del agente. |
| Ciclo de vida | Pausar, reanudar, instantánea, restablecer, limpiar, política de retención | Hace que las ejecuciones del agente sean repetibles y desechables en lugar de máquinas misteriosas de larga duración. |
Usa esta tabla como lista de verificación de diseño. Se aplica tanto si tu sandbox está construido sobre contenedores, máquinas virtuales, microVM, sandboxes en la nube gestionados o un runner interno. La capa de aislamiento exacta importa, pero también importan los controles operativos alrededor de esa capa.
Flujo de trabajo de referencia para ejecutar código generado por agentes
El flujo de trabajo más seguro para un agente de codificación se parece menos a un chatbot y más a un pipeline controlado de solicitudes de extracción (pull request).
- Crear un espacio de trabajo nuevo para la tarea.
- Hacer checkout del repositorio objetivo en una rama o commit específico.
- Dar al agente una tarea acotada, un comando de prueba y un alcance de archivos.
- Permitir que el agente inspeccione archivos y proponga un plan.
- Ejecutar automáticamente comandos de solo lectura de bajo riesgo.
- Requerir aprobación o verificaciones de política para comandos riesgosos.
- Capturar cada comando, código de salida, stdout, stderr, escritura de archivos y artefacto generado.
- Ejecutar pruebas, verificaciones de tipos, linters, compilaciones o scripts específicos dentro del sandbox.
- Exportar un parche, diff, salida de pruebas y paquete de artefactos.
- Restablecer o destruir el espacio de trabajo después de la revisión, a menos que se guarde intencionalmente una instantánea.
El detalle importante es que el sandbox no es solo un lugar para ejecutar código. También es el registrador de evidencia. Un revisor debería poder responder: ¿qué repositorio se revisó, qué cambió, qué comandos se ejecutaron, qué falló, qué pasó, qué archivos se produjeron y qué recursos externos se contactaron?
Para agentes simples, esto se puede implementar como una cola de acciones con verificaciones de política alrededor de cada acción. Para agentes más capaces, mantén los mismos límites pero haz que el plano de control sea más explícito: un componente decide lo que el agente puede solicitar, un componente ejecuta las acciones aprobadas y un componente registra la ejecución.
tarea del usuario
-> el agente propone lecturas, ediciones y comandos de archivos
-> la capa de política clasifica cada acción
-> el sandbox ejecuta las acciones aprobadas
-> se capturan registros, diffs y artefactos
-> un humano revisa el parche antes de fusionar o desplegar
Esa separación evita que el modelo sea tanto el planificador como la autoridad final sobre operaciones peligrosas.
Puntos de control de seguridad antes de la ejecución de comandos
Comienza con la suposición de que los comandos generados pueden ser incorrectos, demasiado amplios o estar influenciados por el contenido del repositorio. Un agente de codificación podría leer una instrucción maliciosa de un fixture de prueba, un README, el cuerpo de un issue, un script de paquete o una página web. El sandbox debería hacer que esos fallos sean visibles y estén contenidos.
Antes de la ejecución de shell, define clases de comandos:
| Clase de comando | Ejemplos | Política predeterminada |
|---|---|---|
| Inspección de solo lectura | pwd, ls, git status, rg, cat package.json |
Generalmente permitir y registrar. |
| Verificación local | npm test, pytest, go test, cargo test |
Permitir con tiempo de espera y captura de salida. |
| Compilación o generación | npm run build, codegen, generación de documentación |
Permitir cuando se esperan rutas de salida. |
| Cambios de dependencias | instalación del gestor de paquetes, actualización de lockfile | Requerir verificaciones de política o aprobación. |
| Comandos de red | fetch de URLs, llamadas a APIs, clonación de repositorios adicionales | Requerir política de destino y registro. |
| Comandos destructivos | eliminar, restablecimiento forzado, limpieza de disco, chmod/chown amplio | Bloquear o requerir aprobación humana explícita. |
| Acceso a secretos | lectura de archivos de entorno, almacenes de credenciales, configuraciones de despliegue | Bloquear a menos que sea específico de la tarea y esté acotado. |
Esto no requiere un analizador estático perfecto. Incluso los controles simples ayudan: restricciones del directorio de trabajo, patrones de denegación explícitos, tiempos de espera de comandos, límites de tamaño de salida y un aviso de aprobación para comandos que mutan dependencias, tocan credenciales o contactan hosts externos.
Los límites del sistema de archivos también deben ser igualmente concretos. Monta solo el repositorio y los directorios temporales que el agente necesita. Evita montar el directorio de inicio del operador, claves SSH, configuraciones de nube, credenciales del gestor de paquetes, perfiles de navegador o archivos de entorno de producción. Si se necesitan cachés para la velocidad, prefiere cachés de solo lectura o con alcance de tarea y retención clara.
Cómo manejar instalaciones de paquetes y acceso a la red
La instalación de paquetes es una de las partes más difíciles del sandboxing de agentes de codificación porque es útil y riesgosa a la vez. Los agentes necesitan reproducir compilaciones y ejecutar pruebas, pero los scripts de instalación pueden ejecutar código, obtener dependencias transitivas y contactar infraestructura externa.
Usa una política más estricta para el trabajo con paquetes:
- Prefiere instalaciones basadas en lockfile sobre la resolución libre de dependencias.
- Registra el comando del gestor de paquetes, la URL del registro, los nombres de paquetes, las versiones y los cambios en el lockfile.
- Dirige las descargas de dependencias a través de registros o mirrors aprobados cuando sea posible.
- Trata las nuevas adiciones de dependencias como cambios de código que requieren revisión.
- Bloquea los scripts de instalación para flujos de trabajo de alto riesgo a menos que el proyecto los necesite explícitamente.
- Mantén los cachés de dependencias separados de los secretos y repositorios no relacionados.
La salida de red merece el mismo tratamiento. Un agente de codificación puede necesitar acceso a internet para registros de paquetes, documentación de API, comprobaciones de navegador o pruebas de integración. Eso no significa que necesite acceso de salida sin restricciones.
Como mínimo, define el valor predeterminado:
| Pregunta de red | Valor predeterminado más seguro |
|---|---|
| ¿Puede el sandbox alcanzar internet? | No, a menos que la tarea lo requiera. |
| ¿Puede resolver nombres DNS arbitrarios? | Restringir o registrar DNS y hosts de destino. |
| ¿Puede llamar a APIs de producción? | Usar endpoints de staging o servicios simulados por defecto. |
| ¿Puede obtener dependencias de paquetes? | Usar registros, mirrors y lockfiles aprobados. |
| ¿Puede subir archivos o registros? | Bloquear a menos que el destino sea esperado y revisado. |
No describas estos controles como una garantía de que no pueda ocurrir exfiltración o compromiso de dependencias. La afirmación realista es más limitada: la política, el aislamiento, el registro y la revisión reducen el radio de explosión y hacen que el comportamiento riesgoso sea más fácil de detectar antes de que el parche sea confiable.
Diffs, artefactos y registros para revisión humana
La revisión humana es más efectiva cuando el sandbox produce un paquete de revisión compacto, no una transcripción larga de chat.
Para cada ejecución, captura:
- La URL del repositorio, la rama y el SHA del commit utilizado para el checkout.
- El prompt de la tarea o el resumen del issue.
- Archivos leídos y archivos escritos.
- Cada comando, directorio de trabajo, hora de inicio, hora de fin, código de salida, stdout y stderr.
- Comandos de instalación de dependencias y cambios en el lockfile.
- Resultados de pruebas, lint, verificación de tipos y compilación.
- Artefactos generados como capturas de pantalla, informes, cobertura, binarios o URLs de vista previa.
- Diff final en formato estándar de parche o solicitud de extracción.
El revisor debe inspeccionar primero el diff, luego usar registros y artefactos para responder preguntas específicas. ¿Realmente se ejecutaron las pruebas? ¿Modificó el agente archivos fuera del alcance solicitado? ¿Agregó una dependencia? ¿Reescribió archivos generados? ¿Llamó a un servicio de red? ¿Dejó artefactos grandes o sensibles?
Para equipos de producción, haz explícita la puerta de revisión:
- El agente puede proponer un parche.
- El sandbox puede ejecutar la verificación.
- El sistema puede abrir una solicitud de extracción.
- Un humano o una política aprobada debe decidir si fusionar, desplegar o conceder permisos más amplios.
Ese límite es especialmente importante para repositorios que incluyen infraestructura, facturación, autenticación, despliegue o rutas de datos de clientes.
Dónde encaja Novita Agent Sandbox
Novita Agent Sandbox está diseñado para entornos de ejecución aislados y con estado donde los agentes pueden ejecutar código, instalar dependencias, acceder a archivos, usar flujos de trabajo de navegador y preservar el estado de ejecución entre sesiones. La descripción general de Agent Sandbox describe tres componentes básicos: sandboxes para ejecución aislada de tareas, plantillas para entornos preparados e instantáneas para reutilizar el estado configurado.
Para flujos de trabajo de agentes de codificación, esos primitivos se asignan naturalmente a un espacio de trabajo de desarrollo controlado:
| Necesidad del agente de codificación | Patrón del sandbox |
|---|---|
| Comenzar desde un entorno conocido | Usar una plantilla con el runtime y las herramientas esperadas. |
| Ejecutar comandos y pruebas lejos del host | Ejecutar dentro del sistema de archivos y entorno de runtime específicos del sandbox. |
| Reutilizar una configuración preparada | Guardar una instantánea después de instalar dependencias aprobadas o herramientas del proyecto. |
| Depurar trabajo de agente de larga duración | Preservar el estado entre sesiones cuando el flujo de trabajo necesita continuidad. |
| Limpiar después de la revisión | Restablecer, detener o descartar el sandbox según tu política de retención. |
Mantén separados el uso del producto y la política de seguridad. Novita Agent Sandbox puede proporcionar el entorno de ejecución aislado para agentes que ejecutan código, pero tu aplicación aún necesita definir el acceso al repositorio, la política de comandos, el alcance de los secretos, las reglas de red, la retención de artefactos y los controles de aprobación humana. Esas elecciones dependen de tu modelo de amenazas y deben ser revisadas por tus responsables de ingeniería y seguridad antes de su uso en producción pública.
Los desarrolladores que quieran un ejemplo práctico también pueden leer la guía de Novita para construir un servidor MCP de ejecución remota de código con Novita Sandbox. Para la documentación del producto, comienza con la documentación de Novita Agent Sandbox y la guía de instalación de SDK y CLI.
Preguntas frecuentes
¿Es suficiente un sandbox de agente de codificación para hacer seguro el código generado?
No. Un sandbox es una capa de control. Aún necesitas acceso acotado al repositorio, política de comandos, controles de dependencias, restricciones de red, manejo de secretos, registros, revisión de artefactos y aprobación humana antes de la fusión o el despliegue.
¿Deberían los agentes de codificación tener acceso a internet?
Solo cuando la tarea lo requiera. Muchos flujos de trabajo de revisión de código, refactorización y pruebas pueden ejecutarse sin acceso general a internet después de preparar las dependencias. Cuando se necesita acceso a internet, registra los destinos y prefiere registros de paquetes en lista blanca, sitios de documentación, APIs de staging o simulaciones.
¿Deberían los agentes recibir secretos de producción?
Evita proporcionar secretos de producción a los agentes de codificación por defecto. Usa credenciales acotadas y de corta duración para la tarea específica, prefiere servicios de staging, redacta los registros y mantén el acceso a secretos fuera del espacio de trabajo del repositorio a menos que haya una razón revisada.
¿Qué se debe revisar antes de confiar en un parche de agente?
Revisa el diff, las dependencias cambiadas, los archivos generados, el registro de comandos, los resultados de pruebas, la actividad de red y cualquier artefacto. Presta especial atención a cambios en autenticación, autorización, despliegue, facturación, infraestructura, acceso a datos y gestión de paquetes.
¿Cuándo se debe restablecer un sandbox?
Restablece o destruye el espacio de trabajo después de cada tarea a menos que guardes intencionalmente una instantánea. El estado persistente es útil para flujos de trabajo de larga duración, pero debe ser una elección deliberada con reglas de propiedad, retención y limpieza.
