Så kör du flera AI-kodningsagenter säkert med Git-worktrees och isolerade behörigheter

Ge varje kodningsagent en egen gren och arbetskatalog, och begränsa sedan separat processens åtkomst till filer, autentiseringsuppgifter och nätverk. Git-worktrees minskar oavsiktlig påverkan mellan ändringar, men är inte säkerhetssandlådor. Ett säkert parallellt arbetsflöde kräver både ett överskådligt arkivtillstånd och verkställbara körningsbehörigheter.

Den här guiden visar lokala worktree-kommandon, uppgiftsavgränsad åtkomst, oberoende testmiljöer och en integrationsordning som granskas av en människa. Använd ett arkiv som du äger eller har behörighet att ändra, och börja med uppgifter som kan kastas bort. Förfarandet är verktygsneutralt: ett gränssnitt för kodningsagenter kan automatisera delar av det, men gränserna måste fortfarande kontrolleras.

Vad går fel när agenter delar arbetsyta?

Två agenter kan skriva över oincheckade ändringar, ändra samma beroendefil eller tolka en annan uppgifts tillfälliga tillstånd som projektets avsedda utformning. De kan också köra tester mot en katalog som ändras medan testet körs. Det kan vara svårt att återskapa det resulterande felet eftersom ingen av agenterna testade en stabil revision.

Problemet omfattar mer än källfiler. Delade portar, databasnamn, cacher, kataloger med testdata och bakgrundsprocesser kan orsaka störningar även när ändringarna berör olika moduler. En agent kan stoppa en tjänst som en annan använder eller återskapa filer utifrån ett schema som fortfarande redigeras.

Vår förklarande guide om samordning mellan flera agenter beskriver hur avgränsningar och beroenden mellan uppgifter minskar sådan påverkan. Innan du skapar fler arbetare bör du skriva ner resultatet för varje uppgift, vilket område som får redigeras, beroendena och acceptanstesterna. ”Arbeta tillsammans med samma funktion” är inte en tillräckligt tydlig överenskommelse för oberoende ändringar.

En separat katalog minskar risken för oavsiktlig påverkan, medan en separat säkerhetskontext styr vad processen kan komma åt. Håll isär dessa syften så att du inte misstar en lyckad separation av grenar för skydd av privata filer eller produktionstjänster.

När bör du använda worktrees i stället för separata kloner?

Git-worktrees är användbara när flera grenar i ett arkiv behöver separata arbetskataloger samtidigt. Separata kloner kan vara att föredra när ett experiment behöver mer oberoende arkivkonfiguration eller en annan fjärrinställning. Inget av alternativen begränsar i sig operativsystemsanvändarens åtkomst till hemligheter eller andra kataloger.

Välj utifrån det faktiska arbetsflödet. Worktrees kan göra granskning baserad på grenar smidig, medan separata kloner kan göra det enklare att isolera vissa destruktiva experiment på arkivnivå. För opålitlig kod eller större risker vid körning bör du använda en lämpligt isolerad körmiljö, oavsett hur källkoden hämtades.

Tabellen är ett hjälpmedel för planering, inte en säkerhetscertifiering. Testa den gräns du tänker förlita dig på, inklusive de filer och tjänster som är synliga från agentens faktiska skal.

Omslag: Conductor officiell ordmärkeslogotyp från varumärkespaketet, används oförändrad för redaktionell identifiering. Produktmärken tillhör sina respektive ägare; ingen anknytning antyds.

Hur skapar du en gren och arbetskatalog per agent?

Utgå från en känd och granskad bas. Spara befintligt arbete innan du byter gren och granska arbetskatalogen i stället för att anta att den är ren. Följande exempel utgår från ett lokalt kodförråd där den granskade basen är main; använd rätt bas för ditt projekt. Kopiera inte ett kommando med fel grennamn och tvinga sedan igenom det.

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

Tilldela varje agent sökvägen till dess egen arbetskatalog och en avgränsad uppgift. Anteckna basversionens commit och förklara vilka delade filer som kräver samordning. Kopiera inte hela den personliga utvecklingsmiljön till varje katalog av bekvämlighetsskäl; det kan duplicera autentiseringsuppgifter och orelaterat privat material.

Följ den här sekvensen från början till slut:

1. Bekräfta att kodförrådet är rent eller säkert bevarat och välj den granskade basen.
2. Skapa en unik gren och arbetskatalog för varje uppdrag.
3. Ge endast den kontext som uppgiften kräver och ett tydligt avtal om vad som räknas som slutfört.
4. Konfigurera särskilda, begränsade autentiseringsuppgifter endast när uppgiften kräver det.
5. Ge testerna separata tillfälliga sökvägar, portar och tillstånd för tjänster som kan kastas bort.
6. Granska varje diff och testresultat innan du föreslår integrering.
7. Slå ihop via projektets mänskliga granskning och kontroller för kodförrådet.
8. Bevara nödvändiga bevis, ta bort färdiga arbetskataloger på vanligt sätt och återkalla tillfällig åtkomst.

Dessa kommandon skapar tillstånd i kodförrådet; de konfigurerar inte sandlådemiljön. Om ett agentverktyg har en egen arbetsytehanterare bör du granska de resulterande grenarna och sökvägarna, så att samma upplägg förblir begripligt även utanför gränssnittet.

Hur isoleras nycklar, miljöfiler och token?

Ett arbetsträd bör inte ärva en utvecklares samtliga autentiseringsuppgifter. Använd helst en särskild identitet med endast de behörigheter för kodförråd och tjänster som uppgiften kräver. Förvara hemligheter på godkänd lagringsplats och överför dem via verktygets stödda mekanism, inte i en prompt, uppgiftsfil eller incheckad .env-fil.

GitHubs dokumentation om token förklarar tokenbehörigheter och livscykel. Välj det snävaste praktiska behörighetsomfånget, en lämplig giltighetstid och ett sätt att återkalla token. En token som behövs för att läsa källkod ger inte automatiskt behörighet att ändra arbetsflödesfiler, slå samman pull-begäranden eller administrera ett kodförråd.

Miljövariabler är ett sätt att överföra värden, inte en fullständig isoleringsgräns. En underordnad process kan ärva dem, och ett felsökningskommando eller en logg kan exponera dem. Granska vilka variabler som når varje arbetare och undvik att dela produktionsvärden med tester. Använd syntetiska autentiseringsuppgifter för tjänster som kan simuleras.

OWASP:s vägledning för hantering av hemligheter ger bakgrund om åtkomstkontroll och rotation. Om en agent läser en hemlighet som den inte behövde ska det ses som ett konfigurationsproblem, även om inget röjande kan konstateras. Miljön bör göra onödig åtkomst omöjlig eller medvetet begränsad, i stället för att förlita sig på att modellen låter bli.

Hur kan containrar eller sandlådor begränsa åtkomsten?

Granska den faktiska konfigurationen: användaridentitet, monterade sökvägar, nätverkspolicy, behörigheter, uttag och tillgängliga autentiseringsuppgifter. En container där värdens hemkatalog och containerhanterarens uttag har monterats kan ha åtkomst långt utanför sin uppgiftsmapp. Etiketten ”sandlåda” visar inte att åtkomsten till dessa resurser är begränsad.

Översikten över Docker-säkerhet förklarar viktiga aspekter av körmiljön. Använd plattformens stödda kontroller för att minska behörigheter, endast montera nödvändiga data och separera tjänstetillstånd. Testa om arbetaren kan komma åt platser som bör ligga utanför uppdraget. Ett nekande svar är ett bra tecken på att en kontroll är aktiv.

Nätverksåtkomsten bör motsvara uppgiften. En uppgift kan behöva ett paketregister och en värd för kodförråd utan att behöva godtyckliga utgående anslutningar eller produktionsdatabaser. Tillämpa kontroller på en verkställbar nivå och dokumentera undantag. Inaktivera inte certifikatkontroller för att få paketinstallationer att fungera; lös det faktiska problemet med tillit eller anslutning.

Dokumentationen om rootless Docker beskriver ett sätt att minska daemonens och containrarnas privilegier. Det gör inte varje arbetsbelastning ofarlig och undanröjer inte behovet av att granska monteringar och hemligheter. Välj isolering som passar den kod som körs och värdet på värdmiljön.

Hur bör ändringar granskas och sammanfogas?

Granska både ej incheckat arbete och incheckningar. En agent kan rapportera att en uppgift är klar trots att relevanta filer inte ingår i dess incheckning eller trots att den har testat en arbetskatalog som skiljer sig från den föreslagna grenen. Be den ange det faktiska resultatet och granska det sedan självständigt.

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

Kör projektets relevanta kontroller i varje arbetskatalog och igen på den integrerade revisionen där samspelet mellan ändringarna spelar roll. Granska delade kontrakt, genererade filer och beroendeuppdateringar. Om basen ändras under granskningen bör du ta reda på vilka belägg som inte längre är aktuella. Ge inte sken av att ett godkännande fortfarande gäller efter att koden det avsåg att godkänna har ändrats.

GitHubs dokumentation om skyddade grenar beskriver kontroller på förvarsnivå som kan komplettera arbetsflödet. Låt mänskligt godkännande av ändringar med betydande konsekvenser vara fristående från agentens möjlighet att skapa ett förslag. En granskningsagent kan ge ett annat perspektiv utan att bli den enda som får avgöra om något ska sammanfogas.

Vår granskningsguide för agentic-autofix innehåller en relaterad checklista för godkännande. När en konflikt uppstår bör du först reda ut vilket beteende som är avsett. Om du ber en modell ta bort konfliktmarkörer utan att förklara kraven kan resultatet bli en ren fil med felaktigt sammanslaget beteende.

När godkänt arbete har bevarats och integrerats på ett säkert sätt använder du vanlig rensning:

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

Lägg inte till tvingande flaggor för att kringgå en vägran. En arbetskatalog med ändringar eller en gren som Git inte anser vara sammanfogad måste granskas. Bevara ofärdiga ändringar och förstå historiken innan du avgör vad som kan tas bort.

Vad bör du övervaka under parallella körningar?

Håll koll på uppgiftsägarskap, processens livslängd, resursanvändning, externa förfrågningar och kön med resultat som väntar på granskning. En arbetare som fortsätter att köras efter att en uppgift har avslutats kan fortsätta använda autentiseringsuppgifter eller ändra delade tjänster. Ta reda på hur den stoppas och hur du bekräftar att den verkligen har stoppats.

Sätt rimliga budgetar och villkor för eskalering för varje uppgift. Upprepade beroendefel, oväntade behörighetsförfrågningar eller ändringar utanför omfattningen bör leda till granskning, inte obegränsade nya försök. Se till att loggarna är användbara utan att registrera hemliga värden eller onödigt privat innehåll.

Vår checklista för behörigheter för personliga agenter hjälper till att förbereda åtkomstgranskningen. Analysen av övergången till Conductor visar också varför arbetet bör förbli portabelt: incheckningar, uppgiftsstatus och granskningsunderlag måste finnas kvar även om orkestreringsprodukten byts ut.

Innan du påbörjar nästa omgång bör du kontrollera att tillfälliga autentiseringsuppgifter har återkallats där det är lämpligt, att bakgrundstjänster har hanterats och att färdiga grenar har en tydlig disposition. Mät accepterat arbete och granskarinsats, inte bara antalet aktiva agenter. Om integreringen är flaskhalsen bör du minska mängden pågående arbete i stället för att lägga till mer utdata i kön.

Innan du städar upp bör du kontrollera arbetsflödet för återställning av filer efter material som ligger utanför Git-historiken. En ospårad datamängd, lokal konfigurationsfil eller status hos en extern tjänst kan behöva en egen återställningsplan.

Vanliga frågor

Kan två agenter använda samma gren på ett säkert sätt?

Det går att samordna gemensamt arbete, men oberoende agenter bör normalt få separata grenar och arbetskataloger. Annars blir det svårt att avgöra vem som gjort ändringar och testresultat och att återskapa dem.

Skyddar det innehållet från en agent att lägga till .env i .gitignore?

Nej. Ignoreringsregler påverkar Git-spårning, inte läsbehörighet till filsystemet. Förvara onödiga hemligheter utanför den miljö som arbetaren har åtkomst till.

Bör varje agent ha en token som kan slå samman ändringar?

Nej. Ge endast de behörigheter som uppgiften kräver. Att skapa ett föreslaget ändringsförslag och att godkänna det till den skyddade grenen är två olika behörigheter.

Vad gör jag om borttagningen av en worktree misslyckas?

Granska katalogen efter ocommittat eller ospårat arbete och bevara det som är viktigt. Använd inte tvång som ett rutinmässigt steg vid rensning.

Räcker det med ett godkänt test i varje gren?

Inte när ändringarna påverkar varandra. Kör relevanta kontroller mot den faktiskt integrerade revisionen och granska beteendet över gränserna.

Slutsats

Säker parallell kodning kombinerar isolering av källkod med kontroller av körmiljö och autentiseringsuppgifter. Worktrees gör ändringar lättare att separera och granska, medan särskilda behörigheter och korrekt konfigurerade sandlådor begränsar vad en agent kan komma åt.

Börja från en ren bas, ge varje uppgift en tydlig ansvarig och ett tydligt kontrakt, och integrera endast resultat som går att granska. Bevara underlag innan du städar upp, återkalla tillfällig åtkomst och öka samtidigheten endast när accepterade resultat motiverar samordningskostnaden.