Cómo ejecutar varios agentes de programación con IA de forma segura usando árboles de trabajo de Git y permisos aislados

Asigna a cada agente de programación su propia rama y directorio de trabajo y, después, restringe por separado el acceso del proceso a archivos, credenciales y red. Los árboles de trabajo de Git reducen las interferencias accidentales entre cambios, pero no son entornos aislados de seguridad. Un flujo de trabajo paralelo seguro requiere tanto un estado del repositorio comprensible como permisos de ejecución aplicables.

Esta guía muestra comandos locales para árboles de trabajo, acceso limitado a las tareas, configuraciones de prueba independientes y una secuencia de integración revisada por una persona. Usa un repositorio que sea de tu propiedad o que tengas autorización para modificar, y empieza con tareas desechables. El procedimiento no depende de ninguna herramienta: una interfaz para agentes de programación puede automatizar algunas partes, pero aun así hay que comprobar los límites subyacentes.

¿Qué sale mal cuando los agentes comparten un mismo espacio de trabajo?

Dos agentes pueden sobrescribir cambios sin confirmar, modificar el mismo archivo de dependencias o interpretar el estado temporal de otra tarea como el diseño previsto del proyecto. También pueden ejecutar pruebas en un directorio que cambia mientras se ejecutan. El fallo resultante puede ser difícil de reproducir porque ninguno de los agentes probó una revisión estable.

El problema va más allá de los archivos de código fuente. Los puertos, nombres de bases de datos, cachés, directorios de datos de prueba y procesos en segundo plano compartidos pueden provocar interferencias, aunque los cambios afecten a módulos distintos. Un agente podría detener un servicio que otro está utilizando o regenerar archivos a partir de un esquema que todavía se está editando.

Nuestra explicación sobre la coordinación multiagente describe cómo los límites de las tareas y las dependencias reducen esas interferencias. Antes de crear más agentes, anota el resultado de cada asignación, el área de edición permitida, las dependencias y las pruebas de aceptación. «Trabajar juntos en la misma función» no es un acuerdo suficiente para realizar cambios independientes.

Un directorio separado reduce la probabilidad de interferencias accidentales; un contexto de seguridad separado controla a qué puede acceder el proceso. Mantén estos propósitos diferenciados para no confundir una separación de ramas exitosa con la protección de archivos privados o servicios de producción.

¿Cuándo conviene usar árboles de trabajo en lugar de clones separados?

Los árboles de trabajo de Git son útiles cuando se necesitan directorios de trabajo simultáneos para varias ramas de un mismo repositorio. Los clones separados pueden ser preferibles cuando un experimento requiere una configuración del repositorio más independiente o una configuración de remoto distinta. Ninguna de las dos opciones, por sí sola, limita el acceso del usuario del sistema operativo a secretos u otros directorios.

Elige según el flujo de trabajo real. Los árboles de trabajo pueden facilitar la revisión basada en ramas, mientras que los clones separados pueden facilitar la contención de algunos experimentos destructivos a nivel del repositorio. Para código no confiable o un mayor riesgo de ejecución, usa un entorno de ejecución debidamente aislado, independientemente de cómo se haya obtenido el código fuente.

La tabla sirve como ayuda de planificación, no como certificación de seguridad. Comprueba el límite en el que pretendes confiar, incluidos los archivos y servicios visibles desde el shell real del agente.

Portada: logotipo oficial de Conductor del kit de marca, usado sin cambios para identificar el contenido editorial. Las marcas de los productos siguen siendo propiedad de sus respectivos titulares; esto no implica afiliación.

¿Cómo se crea una rama y un árbol de trabajo para cada agente?

Empieza desde una base conocida y revisada. Guarda el trabajo existente antes de cambiar de rama e inspecciona el directorio de trabajo en lugar de dar por sentado que está limpio. El siguiente ejemplo supone un repositorio local cuya base revisada es main; usa la base adecuada para tu proyecto. No copies un comando con el nombre de rama equivocado y luego fuerces su ejecución.

git status --short
git branch --show-current
git worktree list
git switch main
git worktree add -b agent/docs ../agent-docs main
git worktree add -b agent/tests ../agent-tests main
git worktree list

Asigna a cada agente la ruta de su propio árbol de trabajo y una tarea acotada. Registra el commit base y explica qué archivos compartidos requieren coordinación. No copies todo el entorno de desarrollo personal en cada directorio por comodidad; eso puede duplicar credenciales y material privado no relacionado.

Sigue esta secuencia de principio a fin:

1. Confirma que el estado del repositorio esté limpio o se haya preservado de forma segura, y elige la base revisada.
2. Crea una rama y un árbol de trabajo únicos para cada tarea.
3. Proporciona únicamente el contexto necesario para la tarea y un acuerdo claro sobre su finalización.
4. Configura credenciales específicas y con permisos limitados solo cuando la tarea lo requiera.
5. Asigna a las pruebas rutas temporales, puertos y estados de servicio desechables distintos.
6. Inspecciona cada diferencia y resultado de prueba antes de proponer la integración.
7. Integra los cambios mediante la revisión humana y los controles del repositorio del proyecto.
8. Conserva las pruebas necesarias, elimina normalmente los árboles de trabajo ya terminados y revoca el acceso temporal.

Estos comandos crean el estado del repositorio; no configuran el entorno aislado. Si una herramienta de agente tiene su propio gestor de espacios de trabajo, inspecciona las ramas y rutas resultantes para que el mismo contrato siga siendo comprensible fuera de la interfaz.

¿Cómo deben aislarse las claves, los archivos de entorno y los tokens?

Un árbol de trabajo no debería heredar todo el conjunto de credenciales de un desarrollador. Es preferible usar una identidad específica con solo los permisos necesarios para el repositorio y los servicios que requiere la tarea. Guarda los secretos en un almacenamiento aprobado y pásalos mediante el mecanismo compatible con la herramienta, no en una instrucción, un archivo de tarea ni un archivo .env incluido en una confirmación.

La documentación de tokens de GitHub explica los permisos y el ciclo de vida de los tokens. Elige el alcance práctico más limitado, una caducidad adecuada y un método para revocarlo. Un token necesario para leer el código fuente no implica permiso para modificar archivos de flujos de trabajo, fusionar solicitudes de cambios ni administrar un repositorio.

Las variables de entorno son un mecanismo de transferencia, no un límite de aislamiento completo. Un proceso secundario puede heredarlas, y un comando de depuración o un registro puede exponerlas. Revisa qué variables recibe cada trabajador y evita compartir valores de producción con las pruebas. Usa credenciales ficticias para los servicios que se puedan simular.

La guía de OWASP para la gestión de secretos ofrece información sobre el control del acceso y la rotación. Si un agente lee un secreto que no necesitaba, considéralo un problema de configuración aunque no se observe ninguna divulgación. El entorno debería hacer imposible o restringir deliberadamente el acceso innecesario, en vez de confiar en que el modelo no le preste atención.

¿Cómo pueden los contenedores o entornos aislados limitar el acceso?

Inspecciona la configuración real: identidad del usuario, rutas montadas, política de red, privilegios, sockets y credenciales disponibles. Un contenedor con el directorio personal del host y el socket del motor de contenedores montados puede tener acceso a mucho más que su carpeta de tareas. La etiqueta «entorno aislado» no demuestra que esos recursos estén restringidos.

La descripción general de la seguridad de Docker explica importantes consideraciones de tiempo de ejecución. Usa los controles compatibles con la plataforma para reducir los privilegios, montar solo los datos necesarios y separar el estado del servicio. Comprueba si el trabajador puede acceder a ubicaciones que deberían estar fuera del alcance. Una denegación correcta es una prueba útil de que hay un control activo.

El acceso a la red debe corresponderse con la tarea asignada. Una tarea puede necesitar un registro de paquetes y un host de repositorios sin necesitar destinos salientes arbitrarios ni bases de datos de producción. Aplica controles en una capa que permita hacerlos cumplir y documenta las excepciones. No desactives las comprobaciones de certificados para que funcione la instalación de dependencias; resuelve el problema real de confianza o conectividad.

La documentación de Docker sin privilegios describe una opción para reducir los privilegios del daemon y los contenedores. No hace que todas las cargas de trabajo sean inofensivas ni elimina la necesidad de revisar los montajes y los secretos. Elige un aislamiento adecuado al código que se ejecuta y al valor del entorno del host.

¿Cómo se deben revisar e integrar los cambios?

Revisa tanto el trabajo sin confirmar como las confirmaciones. Un agente puede informar que una tarea está completa aunque deje archivos pertinentes fuera de su confirmación o pruebe un directorio de trabajo distinto de la rama propuesta. Pídele que identifique el resultado real y luego revísalo de forma independiente.

git -C ../agent-docs status --short
git -C ../agent-tests status --short
git diff --stat main...agent/docs
git diff main...agent/docs
git diff --stat main...agent/tests
git diff main...agent/tests

Ejecuta las comprobaciones pertinentes del proyecto en cada árbol de trabajo y vuelve a ejecutarlas en la revisión integrada cuando haya interacciones importantes. Revisa los contratos compartidos, los archivos generados y las actualizaciones de dependencias. Si la base cambia durante la revisión, identifica qué pruebas han quedado obsoletas. No mantengas la apariencia de una aprobación mientras cambias el código que debía aprobarse.

La documentación de GitHub sobre ramas protegidas describe controles del lado del repositorio que pueden complementar el flujo de trabajo. Mantén separada la aceptación humana de los cambios importantes de la capacidad del agente para crear una propuesta. Un agente de revisión puede aportar otra perspectiva sin convertirse en la única autoridad para integrar cambios.

Nuestra guía de revisión de agentic-autofix ofrece una lista de comprobación relacionada para la aceptación. Cuando surja un conflicto, primero resuelve cuál es el comportamiento previsto. Pedirle a un modelo que elimine los marcadores de conflicto sin explicarle el contrato puede dar como resultado un archivo limpio que combine comportamientos incorrectos.

Una vez que el trabajo aceptado esté protegido e integrado, usa los comandos habituales de limpieza:

git worktree list
git worktree remove ../agent-docs
git worktree remove ../agent-tests
git branch -d agent/docs
git branch -d agent/tests

No añadas indicadores de forzado para saltarte una negativa. Si el árbol de trabajo está sucio o Git no considera que una rama se haya integrado, hay que inspeccionarla. Conserva los cambios sin terminar y comprende el historial antes de decidir qué se puede eliminar.

¿Qué debes supervisar durante las ejecuciones en paralelo?

Supervisa la propiedad de las tareas, la duración de los procesos, el uso de recursos, las solicitudes externas y la cola de resultados pendientes de revisión. Un trabajador que sigue ejecutándose después de que termina una tarea puede seguir usando credenciales o modificando servicios compartidos. Averigua cómo se detiene y cómo confirmar que realmente se ha detenido.

Establece límites razonables y condiciones de escalamiento para cada tarea. Los fallos reiterados de dependencias, las solicitudes de permisos inesperadas o los cambios fuera del alcance deberían dar lugar a una inspección, no a reintentos ilimitados. Mantén registros útiles, pero evita guardar valores secretos o contenido privado innecesario.

Nuestra lista de verificación de permisos para agentes personales ayuda a preparar la revisión de acceso. El análisis de transición de Conductor también muestra por qué el trabajo debe seguir siendo portátil: los cambios confirmados, el estado de las tareas y las pruebas de revisión deben sobrevivir a un cambio de producto de orquestación.

Antes de iniciar otro lote, comprueba que se hayan revocado las credenciales temporales cuando corresponda, que se hayan tenido en cuenta los servicios en segundo plano y que se sepa qué hacer con las ramas completadas. Mide el trabajo aceptado y el esfuerzo de revisión, no solo la cantidad de agentes activos. Si la integración es el cuello de botella, reduce el trabajo en curso en vez de añadir más resultados a la cola.

Antes de limpiar, consulta el flujo de trabajo para archivos recuperables para encontrar material fuera del historial de Git. Un conjunto de datos sin seguimiento, un archivo de configuración local o el estado de un servicio externo pueden requerir su propio plan de recuperación.

Preguntas frecuentes

¿Pueden dos agentes usar una misma rama de forma segura?

Es posible coordinar el trabajo compartido, pero normalmente los agentes independientes deberían tener ramas y directorios de trabajo distintos. De lo contrario, resulta difícil atribuir y reproducir los cambios y los resultados de las pruebas.

¿Añadir .env a .gitignore protege su contenido de un agente?

No. Las reglas de exclusión afectan al seguimiento de Git, no a los permisos de lectura del sistema de archivos. Mantén los secretos innecesarios fuera del entorno accesible para el agente.

¿Debería tener cada agente un token que le permita combinar cambios?

No. Concede solo los permisos necesarios para la tarea. Proponer un cambio y aceptarlo en la rama protegida son facultades distintas.

¿Y si la eliminación del árbol de trabajo no se completa?

Inspecciona el directorio para detectar trabajo sin confirmar o sin seguimiento y conserva lo que importe. No uses la opción forzada como método habitual de limpieza.

¿Basta con que las pruebas pasen en cada rama?

No cuando los cambios interactúan. Ejecuta las comprobaciones pertinentes en la revisión integrada real e inspecciona el comportamiento entre los distintos límites.

Conclusión

La programación paralela segura combina el aislamiento del código fuente con controles de ejecución y credenciales. Los árboles de trabajo facilitan la separación y revisión de los cambios, mientras que los permisos específicos y los entornos aislados configurados adecuadamente limitan lo que un agente puede alcanzar.

Comienza con una base limpia, asigna a cada tarea una persona responsable y un contrato claros, e integra solo resultados que se puedan revisar. Conserva las pruebas antes de limpiar, revoca los accesos temporales y amplía la concurrencia solo cuando los resultados aceptados justifiquen el costo de coordinación.