Cómo aislar un agente de programación para proteger archivos y credenciales

Para qué sirve aislar un agente

Un agente que ejecuta comandos puede modificar archivos o conectarse a servicios. Antes de darle acceso a un proyecto real, conviene decidir qué necesita leer, qué puede escribir y qué conexiones están permitidas.

GitHub anunció el 7 de octubre de 2026 la disponibilidad general del sandbox local de Copilot en CLI, la aplicación Copilot y sesiones de VS Code con Agent Host. El aislamiento aplica políticas sobre la ejecución de herramientas; elegir un modelo diferente no cambia por sí mismo esos límites. Ver anuncio de GitHub.

Un piloto de bajo riesgo

La siguiente propuesta es un procedimiento de evaluación, no una configuración que hayamos instalado en todos nuestros proyectos.

1. Delimita una tarea

Empieza con un cambio pequeño en una copia de un repositorio. Define qué archivos debería modificar y cómo comprobarás el resultado. Evita utilizar una base de clientes o un sistema de cobros para el primer ensayo.

2. Prepara una copia recuperable

Guarda el estado inicial y trabaja en una rama de desarrollo. Usa datos ficticios y credenciales de prueba con permisos mínimos. No coloques secretos de producción en carpetas que el agente pueda leer.

3. Comprueba la compatibilidad

Revisa los requisitos de la herramienta y del sistema operativo antes de activar el aislamiento. La documentación advierte que el comportamiento y las capacidades varían por plataforma. En algunos escenarios de CLI, un equipo incompatible puede iniciar una sesión sin sandbox con un aviso; una política obligatoria debe contemplar ese caso.

4. Define permisos mínimos

Permite solo las carpetas y destinos necesarios para el ensayo. Examina también qué pueden hacer los comandos, los servicios locales y los conectores: una restricción sobre archivos no demuestra que todas las demás herramientas estén igualmente limitadas.

5. Comprueba los límites

Crea un archivo de prueba fuera del directorio permitido e intenta leerlo desde una tarea controlada. Ensaya una escritura fuera del alcance y una conexión a un destino que hayas decidido bloquear. No uses información privada como señuelo. Registra qué se permitió, qué se rechazó y qué aviso apareció.

6. Verifica que la tarea siga funcionando

Ejecuta las pruebas del proyecto y revisa los archivos cambiados. Un aislamiento que impide todo tampoco resuelve el trabajo: el objetivo es que la tarea autorizada funcione y que los accesos ajenos a ella fallen.

Límites que debes tener presentes

El sandbox reduce el alcance de las herramientas, pero no certifica que el código sea correcto. Tampoco sustituye revisión humana, control de versiones o permisos de los servicios externos.

Las reglas de red tienen diferencias importantes entre plataformas. Por ejemplo, GitHub documenta que el proxy y las reglas de hosts en Windows dependen de que los programas respeten la configuración del proxy. No atribuyas a todos los sistemas el mismo nivel de protección. Revisar requisitos y límites por plataforma.

Cómo decidir si avanzar

Conserva una lista de accesos permitidos, intentos bloqueados, tareas completadas y fallos. Amplía permisos de uno en uno y repite las comprobaciones cuando cambies de equipo, herramienta o política.

Para un negocio pequeño, el entregable útil es una tarea que funciona con un alcance comprobado. Empezar con más autonomía solo tiene sentido después de demostrar esos límites.

Fuentes revisadas el 13 de octubre de 2026. Este artículo describe un piloto propuesto; no afirma una protección absoluta ni una implementación ya realizada en tu equipo.