Meerdere AI-codeeragenten veilig uitvoeren met Git-worktrees en geïsoleerde machtigingen

Geef elke codeeragent een eigen branch en werkmap en beperk daarnaast afzonderlijk de toegang van het proces tot bestanden, inloggegevens en het netwerk. Git-worktrees verminderen onbedoelde inmenging tussen wijzigingen, maar zijn geen beveiligde sandboxen. Een veilige parallelle werkwijze vereist zowel een overzichtelijke repositorystatus als afdwingbare runtimebevoegdheden.

Deze gids laat lokale worktree-opdrachten, taakgebonden toegang, onafhankelijke testconfiguratie en een integratieproces met menselijke controle zien. Gebruik een repository die je bezit of mag aanpassen en begin met tijdelijke taken. De procedure is niet aan specifieke tools gebonden: een interface voor codeeragents kan delen ervan automatiseren, maar de onderliggende grenzen moeten nog steeds worden gecontroleerd.

Wat gaat er mis wanneer agents één werkruimte delen?

Twee agents kunnen niet-gecommitte wijzigingen overschrijven, hetzelfde afhankelijkheidsbestand aanpassen of de tijdelijke toestand van een andere taak aanzien voor het beoogde ontwerp van het project. Ze kunnen ook tests uitvoeren in een map die verandert terwijl de test loopt. De resulterende fout kan moeilijk te reproduceren zijn, omdat geen van beide agents een stabiele revisie heeft getest.

Het probleem beperkt zich niet tot bronbestanden. Gedeelde poorten, databasennamen, caches, fixturemappen en achtergrondprocessen kunnen inmenging veroorzaken, zelfs wanneer de wijzigingen verschillende modules raken. De ene agent kan een dienst stoppen die een andere gebruikt, of bestanden opnieuw genereren op basis van een schema dat nog wordt bewerkt.

Onze uitleg over coördinatie tussen meerdere agents beschrijft hoe taakgrenzen en afhankelijkheden die inmenging verminderen. Leg voordat je meer agents inzet voor elke opdracht het gewenste resultaat, het toegestane bewerkingsgebied, de afhankelijkheden en de acceptatietests vast. “Samen aan dezelfde functie werken” is geen voldoende afspraak voor onafhankelijke wijzigingen.

Een afzonderlijke map verkleint de kans op onbedoelde inmenging; een afzonderlijke beveiligingscontext bepaalt wat het proces kan bereiken. Houd die doelen gescheiden, zodat je het succesvol scheiden van branches niet aanziet voor bescherming van privébestanden of productiediensten.

Wanneer gebruik je worktrees in plaats van afzonderlijke clones?

Git-worktrees zijn handig wanneer meerdere branches van één repository tegelijkertijd elk een eigen werkmap nodig hebben. Afzonderlijke clones kunnen de voorkeur hebben wanneer een experiment een onafhankelijkere repositoryconfiguratie of een andere remote-configuratie vereist. Geen van beide opties beperkt op zichzelf de toegang van de gebruiker van het besturingssysteem tot geheimen of andere mappen.

Kies op basis van de daadwerkelijke werkwijze. Met worktrees kan review op basis van branches handiger zijn, terwijl afzonderlijke clones sommige destructieve experimenten op repositoryniveau beter kunnen isoleren. Gebruik voor niet-vertrouwde code of een groter uitvoeringsrisico een passend geïsoleerde runtime, ongeacht hoe de broncode is uitgecheckt.

De tabel is een hulpmiddel bij de planning, geen beveiligingscertificering. Test de grens waarop je wilt vertrouwen, inclusief de bestanden en services die zichtbaar zijn vanuit de daadwerkelijke shell van de agent.

Omslag: officieel Conductor-woordmerk uit de brandkit, ongewijzigd gebruikt voor redactionele herkenning. Productmerken blijven eigendom van hun eigenaar; er wordt geen affiliatie geïmpliceerd.

Hoe maak je voor elke agent een branch en worktree?

Begin vanaf een bekende, beoordeelde basis. Sla bestaand werk op voordat je van branch wisselt en inspecteer de werkmap in plaats van aan te nemen dat die schoon is. Het volgende voorbeeld gaat uit van een lokale repository waarvan de beoordeelde basis main is; gebruik de juiste basis voor je project. Kopieer geen opdracht met de verkeerde branchnaam om die vervolgens toch uit te voeren.

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

Geef elke agent het pad naar diens eigen worktree en een afgebakende taak. Noteer de basiscommit en leg uit voor welke gedeelde bestanden afstemming nodig is. Kopieer niet voor het gemak de volledige persoonlijke ontwikkelomgeving naar elke map; zo kunnen inloggegevens en niet-gerelateerd privé materiaal worden gedupliceerd.

Volg deze end-to-endvolgorde:

1. Controleer of de repository schoon is of veilig bewaarde wijzigingen bevat en kies de beoordeelde basis.
2. Maak voor elke opdracht een unieke branch en worktree.
3. Geef alleen de context die nodig is voor de taak en een duidelijke afspraak over de oplevering.
4. Configureer alleen speciale, beperkte inloggegevens als de taak die vereist.
5. Geef tests afzonderlijke tijdelijke paden, poorten en wegwerpbare servicestatus.
6. Inspecteer elke diff en elk testresultaat voordat je integratie voorstelt.
7. Voeg wijzigingen samen via de menselijke beoordeling en repositorycontroles van het project.
8. Benodigd bewijs bewaren, voltooide worktrees normaal verwijderen en tijdelijke toegang intrekken.

Met deze opdrachten wordt de repositorystatus gewijzigd; ze configureren geen sandboxing. Als een agenttool een eigen werkruimtemanager heeft, controleer dan de resulterende branches en paden, zodat dezelfde afspraken ook buiten de interface begrijpelijk blijven.

Hoe moeten sleutels, omgevingsbestanden en tokens worden geïsoleerd?

Een worktree moet niet de volledige set inloggegevens van een ontwikkelaar overnemen. Gebruik bij voorkeur een aparte identiteit met alleen de repository- en servicemachtigingen die voor de taak nodig zijn. Bewaar geheimen in goedgekeurde opslag en geef ze door via het ondersteunde mechanisme van de tool, niet in een prompt, taakbestand of gecommit .env-bestand.

De tokendocumentatie van GitHub legt tokenmachtigingen en de levenscyclus uit. Kies de kleinst mogelijke praktische scope, een passende vervaldatum en een manier om het token in te trekken. Een token dat nodig is om broncode te lezen, geeft niet automatisch toestemming om workflowbestanden te wijzigen, pull requests samen te voegen of een repository te beheren.

Omgevingsvariabelen zijn een manier om gegevens door te geven, geen volledige isolatiegrens. Een onderliggend proces kan ze overnemen en een debugopdracht of logboek kan ze blootleggen. Controleer welke variabelen elke worker ontvangt en deel geen productiegegevens met tests. Gebruik synthetische inloggegevens voor services die kunnen worden gesimuleerd.

De richtlijnen van OWASP voor geheimenbeheer bieden achtergrondinformatie over toegangsbeheer en rotatie. Als een agent een geheim leest dat niet nodig was, behandel dat dan als een configuratieprobleem, ook als er geen openbaarmaking is waargenomen. De omgeving moet onnodige toegang onmogelijk maken of bewust beperken, in plaats van erop te vertrouwen dat het model die informatie negeert.

Hoe kunnen containers of sandboxen de toegang beperken?

Inspecteer de daadwerkelijke configuratie: gebruikersidentiteit, gekoppelde paden, netwerkbeleid, bevoegdheden, sockets en beschikbare inloggegevens. Een container waarin de thuismap van de host en de socket van de containerengine zijn gekoppeld, heeft mogelijk veel meer toegang dan alleen tot de taakmap. Het label ‘sandbox’ bewijst niet dat die bronnen zijn afgeschermd.

Het overzicht van Docker-beveiliging legt belangrijke aandachtspunten voor de uitvoering uit. Gebruik de door het platform ondersteunde controles om bevoegdheden te beperken, alleen noodzakelijke gegevens te koppelen en de status van services gescheiden te houden. Test of de worker toegang heeft tot locaties die buiten de scope horen te vallen. Een geslaagde weigering is nuttig bewijs dat een controle actief is.

Netwerktoegang moet aansluiten op de taak. Een taak heeft mogelijk toegang nodig tot een pakketregister en een repositoryhost, maar niet tot willekeurige externe bestemmingen of productiedatabases. Pas controles toe op een afdwingbaar niveau en documenteer uitzonderingen. Schakel certificaatcontroles niet uit om het installeren van afhankelijkheden mogelijk te maken; los het daadwerkelijke probleem met vertrouwen of connectiviteit op.

De documentatie van rootless Docker beschrijft een optie om de bevoegdheden van de daemon en containers te beperken. Dat maakt niet elke workload onschadelijk en neemt de noodzaak om mounts en geheimen te controleren niet weg. Kies isolatie die past bij de uit te voeren code en de waarde van de hostomgeving.

Hoe moeten wijzigingen worden beoordeeld en samengevoegd?

Beoordeel ook niet-vastgelegde wijzigingen, niet alleen commits. Een agent kan melden dat een taak is voltooid terwijl relevante bestanden buiten de commit zijn gebleven, of terwijl er een andere werkmap is getest dan de voorgestelde branch. Vraag de agent om het daadwerkelijke resultaat te beschrijven en controleer het vervolgens zelfstandig.

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

Voer de relevante controles van het project uit in elke werkboom en nogmaals op de geïntegreerde revisie wanneer interacties ertoe doen. Controleer gedeelde contracten, gegenereerde bestanden en afhankelijkheidsupdates. Als de basis tijdens de beoordeling verandert, bepaal dan welk bewijs verouderd is. Laat een goedkeuring niet geldig lijken terwijl je de code wijzigt die ermee werd goedgekeurd.

De documentatie van GitHub over beschermde branches beschrijft controles aan de repositoryzijde die de workflow kunnen aanvullen. Houd menselijke acceptatie van ingrijpende wijzigingen gescheiden van de mogelijkheid van de agent om een voorstel te maken. Een beoordelingsagent kan een ander perspectief bieden zonder de enige partij te worden die bevoegd is om samen te voegen.

Onze agentic-autofix-beoordelingsgids bevat een verwante acceptatiechecklist. Als er een conflict ontstaat, bepaal dan eerst welk gedrag de bedoeling is. Een model vragen om conflictaanduidingen te verwijderen zonder het contract uit te leggen, kan een schoon bestand opleveren met de verkeerde gecombineerde werking.

Nadat geaccepteerd werk veilig is bewaard en geïntegreerd, gebruik je de gebruikelijke opruimcommando's:

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

Voeg geen force-vlaggen toe om een weigering te omzeilen. Een vuile werkboom of een branch die Git niet als samengevoegd beschouwt, moet worden onderzocht. Bewaar onafgemaakte wijzigingen en begrijp de geschiedenis voordat je beslist wat je kunt verwijderen.

Wat moet je tijdens parallelle runs monitoren?

Houd taakeigenaarschap, de levensduur van processen, het resourcegebruik, externe verzoeken en de wachtrij met resultaten die op beoordeling wachten in de gaten. Een worker die blijft draaien nadat een taak is afgelopen, kan inloggegevens blijven gebruiken of gedeelde services blijven wijzigen. Stel vast hoe deze wordt gestopt en hoe je bevestigt dat hij daadwerkelijk is gestopt.

Stel redelijke budgetten en voorwaarden voor opschaling vast voor elke opdracht. Herhaalde problemen met afhankelijkheden, onverwachte verzoeken om machtigingen of wijzigingen buiten de scope moeten aanleiding zijn voor inspectie, niet voor onbeperkte nieuwe pogingen. Houd logs nuttig, maar leg geen geheime waarden of onnodige privé-inhoud vast.

Onze checklist voor machtigingen van persoonlijke agents helpt bij de voorbereiding van de toegangscontrole. De analyse van de overgang naar Conductor laat ook zien waarom werk overdraagbaar moet blijven: commits, taakstatus en beoordelingsbewijs moeten behouden blijven wanneer je overstapt naar een ander orkestratieproduct.

Controleer voordat je een nieuwe reeks start of tijdelijke inloggegevens waar nodig zijn ingetrokken, of er rekening is gehouden met actieve services op de achtergrond en of voor afgeronde branches duidelijk is wat ermee gebeurt. Meet geaccepteerd werk en de inspanning van reviewers, niet alleen het aantal actieve agents. Als integratie het knelpunt is, beperk dan het werk in uitvoering in plaats van meer resultaten aan de wachtrij toe te voegen.

Controleer vóór het opruimen de procedure voor herstelbare bestanden op materiaal buiten de Git-geschiedenis. Voor een niet-gevolgde dataset, lokaal configuratiebestand of status van een externe service kan een eigen herstelplan nodig zijn.

Veelgestelde vragen

Kunnen twee agents veilig één branch gebruiken?

Gedeeld werk coördineren kan, maar onafhankelijke agents krijgen normaal gesproken elk een eigen branch en werkmap. Anders zijn wijzigingen en testresultaten moeilijk toe te wijzen en te reproduceren.

Beschermt het toevoegen van .env aan .gitignore de inhoud ervan tegen een agent?

Nee. Negeren-regels bepalen wat Git bijhoudt, niet wat leesbaar is op het bestandssysteem. Houd onnodige geheimen buiten de omgeving waartoe de werker toegang heeft.

Moet elke agent een token hebben waarmee die wijzigingen kan samenvoegen?

Nee. Verleen alleen de machtigingen die voor de opdracht nodig zijn. Een voorgestelde wijziging maken en die accepteren in de beschermde branch zijn twee verschillende bevoegdheden.

Wat als het verwijderen van de worktree niet lukt?

Controleer de map op niet-vastgelegde of niet-gevolgde wijzigingen en bewaar wat belangrijk is. Gebruik force niet als standaardstap bij het opruimen.

Is een geslaagde test in elke branch voldoende?

Niet wanneer de wijzigingen op elkaar inwerken. Voer relevante controles uit op de daadwerkelijke geïntegreerde revisie en controleer het gedrag over de grenzen heen.

Conclusie

Veilig parallel programmeren combineert geïsoleerde broncode met controles voor de runtime en inloggegevens. Met worktrees zijn wijzigingen eenvoudiger te scheiden en te beoordelen, terwijl specifieke machtigingen en goed geconfigureerde sandboxen beperken waartoe een agent toegang heeft.

Begin met een schone basis, wijs aan elke opdracht een duidelijke eigenaar toe en spreek heldere afspraken af. Integreer alleen resultaten die beoordeeld kunnen worden. Bewaar bewijsmateriaal voordat je opruimt, trek tijdelijke toegang in en schaal de gelijktijdigheid alleen op als geaccepteerde resultaten de coördinatiekosten rechtvaardigen.