Come eseguire più agenti di programmazione basati sull’IA in sicurezza con i worktree Git e autorizzazioni isolate

Assegna a ogni agente di programmazione il proprio branch e la propria directory di lavoro, quindi limita separatamente l'accesso del processo ai file, alle credenziali e alla rete. I worktree Git riducono le interferenze accidentali tra le modifiche, ma non sono ambienti di sicurezza isolati. Un flusso di lavoro parallelo sicuro richiede sia uno stato del repository comprensibile, sia autorizzazioni di esecuzione applicate in modo vincolante.

Questa guida illustra i comandi locali per i worktree, l'accesso limitato alle singole attività, la configurazione indipendente dei test e una sequenza di integrazione verificata da una persona. Usa un repository di tua proprietà o che sei autorizzato a modificare e inizia con attività sacrificabili. La procedura non dipende da strumenti specifici: un'interfaccia per agenti di programmazione può automatizzarne alcune parti, ma i confini sottostanti devono comunque essere verificati.

Cosa può andare storto quando gli agenti condividono un'unica area di lavoro?

Due agenti possono sovrascrivere modifiche non confermate, modificare lo stesso file delle dipendenze o interpretare lo stato temporaneo di un'altra attività come il progetto previsto. Possono anche eseguire test su una directory che cambia durante l'esecuzione. Il problema risultante potrebbe essere difficile da riprodurre, perché nessuno dei due agenti ha testato una revisione stabile.

Il problema va oltre i file del codice sorgente. Porte, nomi di database, cache, directory di dati di test e processi in background condivisi possono causare interferenze anche se le modifiche riguardano moduli diversi. Un agente potrebbe arrestare un servizio usato da un altro o rigenerare file a partire da uno schema ancora in fase di modifica.

La nostra guida al coordinamento multi-agente spiega come la definizione dei confini e delle dipendenze delle attività riduca queste interferenze. Prima di creare altri agenti, definisci per ciascuno il risultato atteso, l'area in cui può intervenire, le dipendenze e i test di accettazione. «Lavorate insieme sulla stessa funzionalità» non è un accordo sufficiente per apportare modifiche indipendenti.

Una directory separata riduce la probabilità di interferenze accidentali; un contesto di sicurezza separato controlla le risorse a cui il processo può accedere. Tieni distinti questi obiettivi, per non scambiare la corretta separazione dei branch per una protezione dei file privati o dei servizi di produzione.

Quando usare i worktree invece dei cloni separati?

I worktree Git sono utili quando servono directory di lavoro simultanee per più branch dello stesso repository. I cloni separati possono essere preferibili se un esperimento richiede una configurazione del repository più indipendente o un'impostazione diversa dei remote. Nessuna delle due opzioni, da sola, limita l'accesso dell'utente del sistema operativo a credenziali o altre directory.

Scegli in base al flusso di lavoro effettivo. I worktree possono semplificare la revisione basata sui branch, mentre i cloni separati possono rendere più facile contenere alcuni esperimenti distruttivi a livello di repository. Per il codice non attendibile o rischi di esecuzione più ampi, usa un ambiente di esecuzione adeguatamente isolato, indipendentemente da come è stato scaricato il codice sorgente.

La tabella è uno strumento di pianificazione, non una certificazione di sicurezza. Verifica il limite su cui intendi fare affidamento, inclusi i file e i servizi visibili dalla shell effettiva dell'agente.

Copertina: logotipo del brand kit ufficiale di Conductor, usato senza modifiche a fini di identificazione editoriale. I marchi dei prodotti restano di proprietà dei rispettivi titolari; ciò non implica alcuna affiliazione.

Come creare un branch e una worktree per ogni agente?

Parti da una base nota e revisionata. Salva il lavoro esistente prima di cambiare branch e controlla la directory di lavoro invece di presumere che sia pulita. L'esempio seguente presuppone un repository locale la cui base revisionata è main; usa la base appropriata per il tuo progetto. Non copiare un comando con il nome di branch sbagliato per poi forzarne l'esecuzione.

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

Assegna a ogni agente il percorso della propria worktree e un'attività ben delimitata. Registra il commit di base e spiega quali file condivisi richiedono coordinamento. Non copiare per comodità l'intero ambiente di sviluppo personale in ogni directory: potresti duplicare credenziali e altro materiale privato non pertinente.

Segui questa sequenza completa:

1. Verifica che lo stato del repository sia pulito o conservato in sicurezza, quindi scegli la base revisionata.
2. Crea un branch e una worktree univoci per ogni incarico.
3. Fornisci solo il contesto necessario per l'attività e criteri chiari per considerarla completata.
4. Configura credenziali dedicate e con ambito limitato solo se l'attività lo richiede.
5. Assegna ai test percorsi temporanei, porte e stati dei servizi eliminabili distinti.
6. Esamina ogni diff e il risultato dei test prima di proporre l'integrazione.
7. Esegui il merge tramite la revisione umana del progetto e i controlli del repository.
8. Conserva le prove necessarie, rimuovi normalmente le worktree completate e revoca gli accessi temporanei.

Questi comandi creano lo stato del repository, ma non configurano la sandbox. Se uno strumento per agenti dispone di un proprio gestore degli spazi di lavoro, esamina i branch e i percorsi risultanti, così che lo stesso accordo resti comprensibile anche al di fuori dell’interfaccia.

Come si devono isolare chiavi, file d’ambiente e token?

Un worktree non dovrebbe ereditare l’intero insieme di credenziali di uno sviluppatore. Preferisci un’identità dedicata con le sole autorizzazioni necessarie per il repository e i servizi richiesti dall’attività. Conserva i segreti in un archivio approvato e passali tramite il meccanismo supportato dallo strumento, non in un prompt, in un file dell’attività o in un file .env incluso nel commit.

La documentazione di GitHub sui token spiega le autorizzazioni e il ciclo di vita dei token. Scegli l’ambito pratico più ristretto, una scadenza adeguata e un metodo per revocarlo. La necessità di un token per leggere il codice sorgente non implica il permesso di modificare i file dei workflow, unire le pull request o amministrare un repository.

Le variabili d’ambiente sono un meccanismo di distribuzione, non una barriera di isolamento completa. Un processo figlio potrebbe ereditarle e un comando di debug o un log potrebbe esporle. Verifica quali variabili raggiungono ciascun worker ed evita di condividere valori di produzione con i test. Usa credenziali sintetiche per i servizi che possono essere simulati.

Le linee guida di OWASP sulla gestione dei segreti forniscono informazioni di base sul controllo degli accessi e sulla rotazione. Se un agente legge un segreto di cui non aveva bisogno, consideralo un problema di configurazione anche se non si è osservata alcuna divulgazione. L’ambiente dovrebbe rendere impossibile o limitare deliberatamente l’accesso non necessario, invece di affidarsi al modello perché lo ignori.

In che modo i container o le sandbox possono limitare l’accesso?

Esamina la configurazione effettiva: identità utente, percorsi montati, criteri di rete, privilegi, socket e credenziali disponibili. Un container in cui sono montate la directory home dell’host e la socket del motore per container potrebbe avere accesso ben oltre la propria cartella di attività. L’etichetta “sandbox” non dimostra che queste risorse siano limitate.

La panoramica sulla sicurezza di Docker illustra importanti considerazioni sull’esecuzione. Usa i controlli supportati dalla piattaforma per ridurre i privilegi, montare solo i dati necessari e separare lo stato del servizio. Verifica se il worker può accedere a posizioni che dovrebbero essere fuori ambito. Un accesso negato con esito positivo è una prova utile del fatto che un controllo è attivo.

L’accesso alla rete dovrebbe rispecchiare l’incarico. Un’attività potrebbe richiedere un registro di pacchetti e un host di repository, senza bisogno di destinazioni in uscita arbitrarie o database di produzione. Applica i controlli a un livello effettivamente vincolante e documenta le eccezioni. Non disabilitare i controlli dei certificati per far funzionare l’installazione delle dipendenze: risolvi il problema effettivo di fiducia o connettività.

La documentazione di Docker senza privilegi root descrive un’opzione per ridurre i privilegi del demone e dei container. Non rende innocuo ogni carico di lavoro né elimina la necessità di esaminare i mount e i segreti. Scegli un isolamento adeguato al codice eseguito e al valore dell’ambiente host.

Come rivedere e integrare le modifiche?

Esamina il lavoro non sottoposto a commit oltre ai commit. Un agente può dichiarare completata un’attività lasciando file pertinenti fuori dal commit o effettuando i test in una directory di lavoro diversa dal branch proposto. Chiedigli di indicare il risultato effettivo, poi ispezionalo in modo indipendente.

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

Esegui i controlli pertinenti del progetto in ogni worktree e ripetili sulla revisione integrata quando conta l’interazione tra le modifiche. Esamina i contratti condivisi, i file generati e gli aggiornamenti delle dipendenze. Se la base cambia durante la revisione, individua quali evidenze non sono più attuali. Non mantenere l’apparenza di un’approvazione dopo aver modificato il codice che doveva approvare.

La documentazione di GitHub sui branch protetti descrive controlli a livello di repository che possono integrare il flusso di lavoro. Mantieni separata l’approvazione umana delle modifiche rilevanti dalla capacità dell’agente di creare una proposta. Un agente di revisione può offrire un altro punto di vista senza diventare l’unica autorità a decidere l’integrazione.

La nostra guida alla revisione di agentic-autofix fornisce una checklist di accettazione correlata. Quando sorge un conflitto, chiarisci prima il comportamento previsto. Chiedere a un modello di rimuovere i marcatori di conflitto senza spiegargli il contratto può produrre un file pulito, ma con un comportamento combinato errato.

Dopo aver conservato e integrato in sicurezza il lavoro approvato, procedi con la normale pulizia:

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

Non aggiungere flag di forzatura per aggirare un rifiuto. Un worktree non pulito o un branch che Git non considera unito richiede un’ispezione. Conserva le modifiche non concluse e ricostruisci la cronologia prima di decidere cosa rimuovere.

Che cosa monitorare durante le esecuzioni parallele?

Monitora la titolarità delle attività, la durata dei processi, l’uso delle risorse, le richieste esterne e la coda dei risultati in attesa di revisione. Un worker che continua a funzionare dopo la fine di un’attività può continuare a usare credenziali o modificare servizi condivisi. Stabilisci come viene arrestato e come confermare che si sia effettivamente fermato.

Stabilisci limiti ragionevoli e condizioni di escalation per ogni incarico. Errori ripetuti delle dipendenze, richieste di permessi inaspettate o modifiche fuori ambito dovrebbero indurre a esaminare la situazione, non a riprovare senza limiti. Conserva log utili, evitando però di registrare valori segreti o contenuti privati non necessari.

La nostra lista di controllo dei permessi per agenti personali aiuta a preparare la revisione degli accessi. Anche l’analisi della transizione di Conductor mostra perché il lavoro dovrebbe rimanere trasferibile: i commit, lo stato delle attività e le prove della revisione devono sopravvivere al passaggio a un altro prodotto di orchestrazione.

Prima di avviare un altro lotto, verifica che le credenziali temporanee siano state revocate, ove opportuno, che i servizi in background siano stati considerati e che sia stata decisa la destinazione dei branch completati. Misura il lavoro accettato e l’impegno richiesto ai revisori, non solo il numero di agenti attivi. Se l’integrazione è il collo di bottiglia, riduci il lavoro in corso anziché aggiungere altro output alla coda.

Prima della pulizia, consulta la procedura per il recupero dei file per il materiale che non si trova nella cronologia Git. Un dataset non tracciato, un file di configurazione locale o lo stato di un servizio esterno potrebbero richiedere un piano di recupero specifico.

Domande frequenti

Due agenti possono usare lo stesso branch in sicurezza?

È possibile coordinare il lavoro condiviso, ma di norma gli agenti indipendenti dovrebbero avere branch e directory di lavoro distinti. Altrimenti, diventa difficile attribuire e riprodurre le modifiche e i risultati dei test.

Aggiungere .env a .gitignore protegge il suo contenuto da un agente?

No. Le regole di esclusione riguardano il tracciamento Git, non i permessi di lettura del filesystem. Tieni i segreti non necessari fuori dall’ambiente accessibile al worker.

Ogni agente dovrebbe avere un token che gli consenta di integrare le modifiche?

No. Concedi solo i permessi necessari per l’incarico. Proporre una modifica e accettarla nel branch protetto sono autorità diverse.

E se la rimozione del worktree non va a buon fine?

Controlla la directory per verificare la presenza di modifiche non confermate o file non tracciati e conserva ciò che è importante. Non usare la modalità forzata come normale procedura di pulizia.

Basta che i test passino in ogni branch?

Non quando le modifiche interagiscono. Esegui i controlli pertinenti sulla revisione effettivamente integrata e verifica il comportamento tra i diversi ambiti.

Conclusione

La programmazione parallela sicura combina l’isolamento del codice sorgente con controlli su runtime e credenziali. I worktree facilitano la separazione e la revisione delle modifiche, mentre permessi dedicati e sandbox configurate in modo appropriato limitano ciò che un agente può raggiungere.

Parti da una base pulita, assegna a ogni incarico un responsabile e un contratto chiari e integra solo risultati verificabili. Conserva le prove prima della pulizia, revoca gli accessi temporanei e aumenta la concorrenza solo quando i risultati accettati giustificano il costo del coordinamento.