Como executar vários agentes de programação com IA em segurança, usando árvores de trabalho do Git e permissões isoladas

Dê a cada agente de programação a sua própria branch e diretório de trabalho e, em separado, restrinja o acesso do processo a ficheiros, credenciais e rede. As worktrees do Git reduzem a interferência acidental entre alterações, mas não são ambientes de segurança isolados. Um fluxo de trabalho paralelo seguro exige tanto um estado compreensível do repositório como permissões de execução aplicáveis.

Este guia mostra comandos locais de worktree, controlo de acesso ao âmbito das tarefas, configurações de teste independentes e uma sequência de integração sujeita a revisão humana. Utilize um repositório que lhe pertença ou que esteja autorizado a modificar e comece com tarefas descartáveis. O procedimento é independente das ferramentas: uma interface de agente de programação pode automatizar algumas partes, mas é necessário verificar os limites subjacentes na mesma.

O Que Pode Correr Mal Quando os Agentes Partilham um Espaço de Trabalho?

Dois agentes podem sobrescrever alterações não confirmadas, alterar o mesmo ficheiro de dependências ou interpretar o estado temporário da tarefa de outro como sendo o modelo pretendido para o projeto. Também podem executar testes num diretório que se altera enquanto o teste está a decorrer. A falha resultante pode ser difícil de reproduzir, porque nenhum dos agentes testou uma revisão estável.

O problema vai além dos ficheiros de código-fonte. Portas partilhadas, nomes de bases de dados, caches, diretórios de ficheiros de teste e processos em segundo plano podem causar interferência, mesmo quando as alterações afetam módulos diferentes. Um agente pode parar um serviço que outro está a utilizar ou voltar a gerar ficheiros a partir de um esquema que ainda está a ser editado.

O nosso guia explicativo sobre coordenação multiagente descreve como os limites das tarefas e as dependências reduzem essa interferência. Antes de criar mais agentes, defina por escrito o resultado de cada tarefa, a área de edição permitida, as dependências e os testes de aceitação. «Trabalhar em conjunto na mesma funcionalidade» não é um acordo suficiente para permitir alterações independentes.

Um diretório separado reduz a probabilidade de interferência acidental; um contexto de segurança separado controla aquilo a que o processo pode aceder. Mantenha estes objetivos distintos para não confundir uma separação bem-sucedida entre branches com a proteção de ficheiros privados ou serviços de produção.

Quando Deve Usar Worktrees em Vez de Clones Separados?

As worktrees do Git são úteis quando é necessário ter diretórios de trabalho simultâneos para várias branches de um repositório. Os clones separados podem ser preferíveis quando uma experiência exige uma configuração do repositório mais independente ou uma configuração remota diferente. Nenhuma das opções, por si só, limita o acesso do utilizador do sistema operativo a segredos ou a outros diretórios.

Escolha com base no fluxo de trabalho real. As worktrees podem facilitar a revisão baseada em branches, enquanto clones separados podem facilitar o isolamento de algumas experiências destrutivas ao nível do repositório. No caso de código não fiável ou de um risco de execução mais amplo, utilize um ambiente de execução devidamente isolado, independentemente da forma como o código-fonte foi obtido.

A tabela é um auxiliar de planeamento, não uma certificação de segurança. Teste o limite em que pretende confiar, incluindo os ficheiros e serviços visíveis a partir da shell efetivamente utilizada pelo agente.

Capa: logótipo oficial da marca Conductor, do kit de identidade visual, utilizado sem alterações para identificação editorial. As marcas dos produtos permanecem com os respetivos proprietários; não está implícita qualquer afiliação.

Como criar uma ramificação e uma árvore de trabalho por agente?

Comece por uma base conhecida e revista. Guarde o trabalho existente antes de mudar de ramificação e inspecione o diretório de trabalho em vez de presumir que está limpo. O exemplo seguinte pressupõe um repositório local cuja base revista é main; utilize a base adequada ao seu projeto. Não copie um comando com o nome de ramificação errado e depois force a sua execução.

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

Atribua a cada agente o caminho para a sua própria árvore de trabalho e uma tarefa bem delimitada. Registe o commit base e explique quais os ficheiros partilhados que exigem coordenação. Não copie todo o ambiente de desenvolvimento pessoal para cada diretório por conveniência; isso pode duplicar credenciais e material privado não relacionado.

Utilize esta sequência de ponta a ponta:

1. Confirme que o estado do repositório está limpo ou preservado em segurança e escolha a base revista.
2. Crie uma ramificação e uma árvore de trabalho únicas para cada tarefa.
3. Forneça apenas o contexto necessário para a tarefa e um contrato de conclusão claro.
4. Configure credenciais dedicadas e com âmbito limitado apenas quando a tarefa o exigir.
5. Atribua aos testes caminhos temporários, portas e estados de serviço descartáveis distintos.
6. Inspecione cada diferença e resultado dos testes antes de propor a integração.
7. Integre através da revisão humana e dos controlos do repositório do projeto.
8. Preserve as provas necessárias, remova normalmente as árvores de trabalho concluídas e revogue o acesso temporário.

Estes comandos criam o estado do repositório; não configuram o isolamento. Se uma ferramenta de agente tiver o seu próprio gestor de espaços de trabalho, inspecione as branches e os caminhos resultantes para que o mesmo contrato continue a ser compreensível fora da interface.

Como devem ser isoladas as chaves, os ficheiros de ambiente e os tokens?

Uma árvore de trabalho não deve herdar todo o conjunto de credenciais de um programador. Prefira uma identidade dedicada, com apenas as permissões necessárias no repositório e nos serviços para a tarefa. Guarde os segredos no armazenamento aprovado e disponibilize-os através do mecanismo suportado pela ferramenta, não num prompt, ficheiro de tarefas ou ficheiro .env submetido ao repositório.

A documentação de tokens do GitHub explica as permissões e o ciclo de vida dos tokens. Escolha o âmbito prático mais restrito, uma validade adequada e uma forma de revogação. Um token necessário para ler o código-fonte não implica autorização para alterar ficheiros de workflow, aprovar pull requests ou administrar um repositório.

As variáveis de ambiente são um meio de disponibilização, não uma barreira de isolamento completa. Um processo filho pode herdá-las, e um comando de depuração ou um registo pode expô-las. Verifique que variáveis são disponibilizadas a cada worker e evite partilhar valores de produção com os testes. Utilize credenciais fictícias para serviços que possam ser simulados.

As orientações da OWASP sobre gestão de segredos fornecem informações sobre o controlo do acesso e a rotação. Se um agente ler um segredo de que não precisava, trate isso como um problema de configuração, mesmo que não haja indícios de divulgação. O ambiente deve impossibilitar ou restringir deliberadamente o acesso desnecessário, em vez de depender de o modelo o ignorar.

Como podem os contentores ou as sandboxes limitar o acesso?

Inspecione a configuração real: identidade do utilizador, caminhos montados, política de rede, privilégios, sockets e credenciais disponíveis. Um contentor com o diretório pessoal do anfitrião e o socket do motor de contentores montados pode ter acesso muito além da sua pasta de tarefas. A etiqueta «sandbox» não prova que esses recursos estejam restringidos.

A visão geral da segurança do Docker explica aspetos importantes a ter em conta durante a execução. Utilize os controlos suportados pela plataforma para reduzir os privilégios, montar apenas os dados necessários e separar o estado dos serviços. Teste se o worker consegue aceder a locais que deveriam estar fora do âmbito da tarefa. Uma tentativa de acesso bloqueada com sucesso é uma prova útil de que o controlo está ativo.

O acesso à rede deve refletir as necessidades da tarefa. Uma tarefa pode precisar de um registo de pacotes e de um alojamento de repositórios, sem precisar de acesso a destinos externos arbitrários ou a bases de dados de produção. Aplique controlos numa camada que os possa impor e documente as exceções. Não desative as verificações de certificados para conseguir instalar dependências; resolva o verdadeiro problema de confiança ou de conectividade.

A documentação do Docker sem privilégios de root descreve uma opção para reduzir os privilégios do daemon e dos contentores. Isso não torna inofensiva qualquer carga de trabalho nem elimina a necessidade de rever as montagens e os segredos. Escolha um nível de isolamento adequado ao código que está a ser executado e ao valor do ambiente anfitrião.

Como devem ser revistos e fundidos os resultados das alterações?

Reveja tanto o trabalho não consolidado como os commits. Um agente pode indicar que concluiu uma tarefa, mas deixar ficheiros relevantes fora do seu commit ou testar uma diretoria de trabalho diferente do ramo proposto. Peça-lhe que identifique o resultado concreto e, em seguida, inspecione-o de forma independente.

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

Execute as verificações relevantes do projeto em cada árvore de trabalho e volte a executá-las na revisão integrada quando houver interações relevantes. Reveja os contratos partilhados, os ficheiros gerados e as atualizações das dependências. Se a base mudar durante a revisão, identifique que evidências estão desatualizadas. Não mantenha a aparência de uma aprovação enquanto altera o código que esta se destinava a aprovar.

A documentação do GitHub sobre ramos protegidos descreve controlos ao nível do repositório que podem complementar o fluxo de trabalho. Mantenha a aceitação humana de alterações com consequências importantes separada da capacidade do agente de criar uma proposta. Um agente de revisão pode oferecer outra perspetiva sem se tornar a única autoridade para fundir alterações.

O nosso guia de revisão do agentic-autofix inclui uma lista de verificação de aceitação relacionada. Quando surgir um conflito, resolva primeiro qual é o comportamento pretendido. Pedir a um modelo para remover os marcadores de conflito sem explicar o contrato pode resultar num ficheiro limpo que combina o comportamento errado.

Depois de o trabalho aceite estar preservado e integrado em segurança, faça a limpeza normal:

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

Não adicione flags de força para contornar uma recusa. Uma árvore de trabalho com alterações por integrar ou um ramo que o Git não considera fundido precisa de ser inspecionado. Preserve as alterações inacabadas e compreenda o histórico antes de decidir o que pode ser removido.

O que deve monitorizar durante as execuções paralelas?

Monitorize a titularidade das tarefas, o tempo de vida dos processos, a utilização de recursos, os pedidos externos e a fila de resultados à espera de revisão. Um worker que continua em execução depois de uma tarefa terminar pode continuar a usar credenciais ou a modificar serviços partilhados. Determine como é parado e como confirma que parou efetivamente.

Defina limites razoáveis e condições de escalamento para cada tarefa. Falhas repetidas de dependências, pedidos de permissões inesperados ou edições fora do âmbito devem levar a uma inspeção, não a novas tentativas ilimitadas. Mantenha registos úteis, mas evite registar valores secretos ou conteúdo privado desnecessário.

A nossa lista de verificação de permissões para agentes pessoais ajuda a preparar a revisão dos acessos. A análise da transição do Conductor também ilustra por que razão o trabalho deve continuar portátil: os commits, o estado das tarefas e as provas de revisão têm de sobreviver à mudança de produto de orquestração.

Antes de iniciar outro lote, confirme que as credenciais temporárias foram revogadas quando necessário, que os serviços em segundo plano estão devidamente contabilizados e que o destino dos ramos concluídos está definido. Avalie o trabalho aceite e o esforço de revisão, não apenas o número de agentes que estiveram ativos. Se a integração for o estrangulamento, reduza o trabalho em curso em vez de acrescentar mais resultados à fila.

Antes da limpeza, consulte o fluxo de trabalho para ficheiros recuperáveis para encontrar material fora do histórico do Git. Um conjunto de dados não rastreado, um ficheiro de configuração local ou o estado de um serviço externo podem precisar de um plano de recuperação próprio.

Perguntas frequentes

Dois agentes podem usar o mesmo ramo em segurança?

É possível coordenar trabalho partilhado, mas, em geral, os agentes independentes devem receber ramos e diretórios de trabalho distintos. Caso contrário, torna-se difícil atribuir e reproduzir as edições e os resultados dos testes.

Adicionar .env a .gitignore protege o seu conteúdo contra o acesso de um agente?

Não. As regras de ignorar afetam o rastreio pelo Git, não as permissões de leitura do sistema de ficheiros. Mantenha os segredos desnecessários fora do ambiente a que o agente pode aceder.

Todos os agentes devem ter um token que lhes permita integrar alterações?

Não. Conceda apenas as permissões necessárias para a tarefa. Propor uma alteração e aceitá-la no ramo protegido são poderes distintos.

E se a remoção da árvore de trabalho não avançar?

Inspecione o diretório à procura de alterações por confirmar ou não rastreadas e preserve o que for importante. Não use a opção de forçar como procedimento habitual de limpeza.

É suficiente que os testes passem em cada ramo?

Não quando as alterações interagem. Execute as verificações relevantes na revisão integrada efetiva e inspecione o comportamento entre componentes.

Conclusão

A programação paralela segura combina o isolamento do código-fonte com controlos de execução e credenciais. As árvores de trabalho facilitam a separação e revisão das alterações, enquanto permissões dedicadas e ambientes de execução em sandbox devidamente configurados limitam aquilo a que um agente pode aceder.

Comece a partir de uma base limpa, atribua a cada tarefa um responsável e um contrato claros e integre apenas resultados que possam ser revistos. Preserve as provas antes da limpeza, revogue o acesso temporário e aumente a simultaneidade apenas quando os resultados aceites justificarem o custo de coordenação.