So betreiben Sie mehrere KI-Programmieragenten sicher mit Git-Worktrees und isolierten Berechtigungen

Geben Sie jedem Coding-Agent einen eigenen Branch und ein eigenes Arbeitsverzeichnis und beschränken Sie anschließend separat den Zugriff des Prozesses auf Dateien, Zugangsdaten und das Netzwerk. Git-Worktrees verringern unbeabsichtigte Beeinträchtigungen zwischen Änderungen, sind aber keine Sicherheits-Sandboxen. Ein sicherer paralleler Arbeitsablauf erfordert sowohl einen übersichtlichen Repository-Zustand als auch durchsetzbare Laufzeitberechtigungen.

Diese Anleitung zeigt lokale Worktree-Befehle, aufgabenbezogene Zugriffsrechte, unabhängige Testeinrichtungen und einen Integrationsablauf mit menschlicher Überprüfung. Verwenden Sie ein Repository, das Ihnen gehört oder das Sie bearbeiten dürfen, und beginnen Sie mit entbehrlichen Aufgaben. Das Vorgehen ist toolunabhängig: Eine Coding-Agent-Oberfläche kann Teile davon automatisieren, aber die zugrunde liegenden Grenzen müssen weiterhin überprüft werden.

Was geht schief, wenn Agenten denselben Arbeitsbereich nutzen?

Zwei Agenten können nicht übernommene Änderungen überschreiben, dieselbe Abhängigkeitsdatei ändern oder den temporären Zustand einer anderen Aufgabe für den vorgesehenen Entwurf des Projekts halten. Sie können außerdem Tests in einem Verzeichnis ausführen, das sich während des Tests verändert. Der daraus resultierende Fehler lässt sich möglicherweise nur schwer reproduzieren, weil keiner der Agenten eine stabile Revision getestet hat.

Das Problem betrifft mehr als nur Quelldateien. Gemeinsame Ports, Datenbanknamen, Caches, Fixture-Verzeichnisse und Hintergrundprozesse können zu Beeinträchtigungen führen, selbst wenn die Änderungen unterschiedliche Module betreffen. Ein Agent könnte einen Dienst stoppen, den ein anderer gerade nutzt, oder Dateien anhand eines Schemas neu generieren, das noch bearbeitet wird.

Unsere Erklärung zur Koordination mehrerer Agenten beschreibt, wie Aufgabenabgrenzungen und Abhängigkeiten solche Beeinträchtigungen verringern. Bevor Sie weitere Agenten starten, halten Sie für jeden Auftrag das erwartete Ergebnis, den zulässigen Bearbeitungsbereich, die Abhängigkeiten und die Abnahmetests fest. „Gemeinsam an derselben Funktion arbeiten“ ist keine ausreichende Vereinbarung für unabhängige Änderungen.

Ein separates Verzeichnis verringert die Wahrscheinlichkeit unbeabsichtigter Beeinträchtigungen; ein separater Sicherheitskontext kontrolliert, worauf der Prozess zugreifen kann. Halten Sie diese Zwecke auseinander, damit Sie eine erfolgreiche Trennung von Branches nicht mit dem Schutz privater Dateien oder Produktionsdiensten verwechseln.

Wann sollten Sie Worktrees statt separater Klone verwenden?

Git-Worktrees sind nützlich, wenn mehrere Branches eines Repositorys gleichzeitig in eigenen Arbeitsverzeichnissen benötigt werden. Separate Klone können vorzuziehen sein, wenn ein Experiment eine unabhängigere Repository-Konfiguration oder eine andere Remote-Einrichtung erfordert. Keine der beiden Optionen schränkt für sich genommen den Zugriff des Betriebssystembenutzers auf Geheimnisse oder andere Verzeichnisse ein.

Wählen Sie anhand des tatsächlichen Arbeitsablaufs. Worktrees können die Überprüfung anhand von Branches erleichtern, während sich manche destruktiven Experimente mit separaten Klonen möglicherweise leichter auf Repository-Ebene eingrenzen lassen. Bei nicht vertrauenswürdigem Code oder einem größeren Ausführungsrisiko sollten Sie unabhängig davon, wie der Quellcode ausgecheckt wurde, eine entsprechend isolierte Laufzeitumgebung verwenden.

Die Tabelle dient als Planungshilfe, nicht als Sicherheitszertifizierung. Teste die Grenze, auf die du dich verlassen willst, einschließlich der Dateien und Dienste, die über die tatsächliche Shell des Agenten sichtbar sind.

Titelbild: Offizielles Conductor-Wortzeichen aus dem Brand-Kit, unverändert zur redaktionellen Kennzeichnung verwendet. Produktmarken verbleiben bei ihren Eigentümern; eine Zugehörigkeit wird nicht angedeutet.

Wie erstellt man pro Agent einen Branch und Worktree?

Von einer bekannten, geprüften Basis ausgehen. Vor dem Wechseln von Branches bestehende Arbeit sichern und das Arbeitsverzeichnis prüfen, statt anzunehmen, es sei sauber. Das folgende Beispiel geht von einem lokalen Repository aus, dessen geprüfte Basis main ist; verwende für dein Projekt die passende Basis. Übernimm keinen Befehl mit einem falschen Branchnamen und erzwinge anschließend nicht dessen Ausführung.

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

Jedem Agenten den Pfad zu seinem eigenen Worktree und eine klar eingegrenzte Aufgabe zuweisen. Den Basis-Commit festhalten und erläutern, welche gemeinsam genutzten Dateien abgestimmt werden müssen. Nicht der Einfachheit halber die gesamte persönliche Entwicklungsumgebung in jedes Verzeichnis kopieren; dadurch könnten Zugangsdaten und anderes privates Material dupliziert werden.

Diese durchgängige Abfolge verwenden:

1. Einen sauberen oder sicher aufbewahrten Repository-Zustand bestätigen und die geprüfte Basis auswählen.
2. Für jede Aufgabe einen eigenen Branch und Worktree erstellen.
3. Nur den für die Aufgabe notwendigen Kontext und eine klare Definition der Fertigstellung bereitstellen.
4. Dedizierte, eingeschränkte Zugangsdaten nur dann einrichten, wenn die Aufgabe sie erfordert.
5. Tests eigene temporäre Pfade, Ports und einen entbehrlichen Dienststatus zuweisen.
6. Jeden Diff und jedes Testergebnis prüfen, bevor die Integration vorgeschlagen wird.
7. Über die menschliche Prüfung und die Repository-Kontrollen des Projekts zusammenführen.
8. Benötigte Nachweise aufbewahren, abgeschlossene Worktrees regulär entfernen und temporäre Zugriffsrechte widerrufen.

Diese Befehle erstellen Repository-Zustand; sie konfigurieren keine Sandbox. Wenn ein Agententool eine eigene Workspace-Verwaltung hat, prüfen Sie die resultierenden Branches und Pfade, damit derselbe Vertrag auch außerhalb der Benutzeroberfläche verständlich bleibt.

Wie lassen sich Schlüssel, Umgebungsdateien und Tokens isolieren?

Ein Worktree sollte nicht den gesamten Zugangsdatenbestand eines Entwicklers übernehmen. Bevorzugen Sie eine eigene Identität mit ausschließlich den für die Aufgabe erforderlichen Repository- und Dienstberechtigungen. Bewahren Sie Geheimnisse an zugelassenen Orten auf und übergeben Sie sie über den unterstützten Mechanismus des Tools, nicht in einem Prompt, einer Aufgabendatei oder einer eingecheckten .env-Datei.

Die Tokendokumentation von GitHub erläutert Tokenberechtigungen und ihren Lebenszyklus. Wählen Sie den engstmöglichen praktikablen Geltungsbereich, eine angemessene Ablaufzeit und eine Möglichkeit zum Widerruf. Ein Token, das zum Lesen des Quellcodes benötigt wird, berechtigt nicht automatisch dazu, Workflow-Dateien zu ändern, Pull-Requests zusammenzuführen oder ein Repository zu verwalten.

Umgebungsvariablen sind eine Methode zur Bereitstellung, aber keine vollständige Isolationsgrenze. Ein untergeordneter Prozess kann sie übernehmen, und ein Debugging-Befehl oder Protokolleintrag kann sie offenlegen. Prüfen Sie, welche Variablen jeden Worker erreichen, und geben Sie keine Produktionswerte an Tests weiter. Verwenden Sie synthetische Zugangsdaten für Dienste, die sich simulieren lassen.

Der OWASP-Leitfaden zur Geheimnisverwaltung erläutert die Kontrolle und Rotation von Zugangsdaten. Wenn ein Agent ein Geheimnis liest, das er nicht benötigt, behandeln Sie das als Konfigurationsproblem, selbst wenn keine Offenlegung festgestellt wird. Die Umgebung sollte unnötigen Zugriff unmöglich machen oder gezielt einschränken, statt sich darauf zu verlassen, dass das Modell davon absieht.

Wie können Container oder Sandboxes den Zugriff einschränken?

Prüfen Sie die tatsächliche Konfiguration: Benutzeridentität, eingebundene Pfade, Netzwerkrichtlinien, Berechtigungen, Sockets und verfügbare Zugangsdaten. Ein Container, in den das Home-Verzeichnis des Hosts und der Socket der Container-Engine eingebunden sind, kann weit über seinen Aufgabenordner hinaus Zugriff haben. Die Bezeichnung „Sandbox“ belegt nicht, dass diese Ressourcen eingeschränkt sind.

Die Docker-Sicherheitsübersicht erläutert wichtige Überlegungen zur Laufzeit. Nutzen Sie die von der Plattform unterstützten Kontrollen, um Berechtigungen zu reduzieren, nur notwendige Daten einzubinden und den Dienststatus getrennt zu halten. Prüfen Sie, ob der Worker auf Bereiche zugreifen kann, die außerhalb seines Aufgabenbereichs liegen sollten. Eine erfolgreiche Zugriffsverweigerung ist ein nützlicher Beleg dafür, dass eine Kontrolle aktiv ist.

Der Netzwerkzugriff sollte sich nach der jeweiligen Aufgabe richten. Eine Aufgabe benötigt möglicherweise Zugriff auf eine Paketregistrierung und einen Repository-Host, aber keine beliebigen ausgehenden Verbindungen oder Produktionsdatenbanken. Setzen Sie Kontrollen auf einer durchsetzbaren Ebene um und dokumentieren Sie Ausnahmen. Deaktivieren Sie nicht die Zertifikatsprüfungen, damit die Installation von Abhängigkeiten funktioniert; beheben Sie stattdessen das tatsächliche Vertrauens- oder Verbindungsproblem.

Die Rootless-Docker-Dokumentation beschreibt eine Möglichkeit, die Berechtigungen des Daemons und der Container einzuschränken. Dadurch wird nicht jede Arbeitslast harmlos, und die Mounts und Geheimnisse müssen weiterhin geprüft werden. Wähle eine Isolation, die zum ausgeführten Code und zum Wert der Host-Umgebung passt.

Wie sollten Änderungen geprüft und zusammengeführt werden?

Prüfe neben Commits auch nicht committete Arbeit. Ein Agent kann eine Aufgabe als abgeschlossen melden, obwohl relevante Dateien nicht in seinem Commit enthalten sind oder er ein anderes Arbeitsverzeichnis getestet hat als den vorgeschlagenen Branch. Bitte ihn, das tatsächliche Ergebnis anzugeben, und prüfe es anschließend selbst.

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

Führe die relevanten Prüfungen des Projekts in jedem Arbeitsbaum und erneut auf der integrierten Revision aus, wenn Wechselwirkungen eine Rolle spielen. Prüfe gemeinsam genutzte Schnittstellen, generierte Dateien und Abhängigkeitsaktualisierungen. Wenn sich die Basis während der Prüfung ändert, ermittle, welche Prüfergebnisse veraltet sind. Bewahre nicht den Anschein einer Genehmigung, während du den Code änderst, für den sie erteilt wurde.

GitHubs Dokumentation zu geschützten Branches beschreibt Kontrollen auf Repository-Ebene, die den Workflow ergänzen können. Trenne die menschliche Abnahme folgenreicher Änderungen von der Fähigkeit des Agents, einen Vorschlag zu erstellen. Ein Prüf-Agent kann eine weitere Perspektive einbringen, ohne zur alleinigen Instanz für das Zusammenführen zu werden.

Unsere Prüfanleitung für agentic-autofix enthält eine passende Checkliste für die Abnahme. Wenn ein Konflikt auftritt, kläre zuerst das gewünschte Verhalten. Ein Modell aufzufordern, Konfliktmarker zu entfernen, ohne den Vertrag zu erläutern, kann zu einer sauberen Datei mit dem falschen kombinierten Verhalten führen.

Nachdem akzeptierte Arbeit sicher aufbewahrt und integriert wurde, verwende die übliche Bereinigung:

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

Füge keine Force-Flags hinzu, um eine Ablehnung zu umgehen. Ein nicht sauberer Arbeitsbaum oder ein Branch, den Git nicht als zusammengeführt betrachtet, muss geprüft werden. Bewahre nicht abgeschlossene Änderungen auf und mache dich mit der Historie vertraut, bevor du entscheidest, was entfernt werden kann.

Was solltest du bei parallelen Ausführungen überwachen?

Überwache die Aufgabenverantwortung, die Prozesslaufzeit, die Ressourcennutzung, externe Anfragen und die Warteschlange der auf Prüfung wartenden Ergebnisse. Ein Worker, der nach Ende einer Aufgabe weiterläuft, kann weiterhin Zugangsdaten verwenden oder gemeinsam genutzte Dienste verändern. Stelle fest, wie er gestoppt wird und wie du bestätigst, dass er tatsächlich gestoppt wurde.

Legen Sie für jede Aufgabe angemessene Budgets und Eskalationsbedingungen fest. Wiederholte Abhängigkeitsfehler, unerwartete Berechtigungsanfragen oder Änderungen außerhalb des Umfangs sollten eine Überprüfung auslösen, nicht unbegrenzte Wiederholungsversuche. Halten Sie Protokolle nützlich, ohne geheime Werte oder unnötige private Inhalte aufzuzeichnen.

Unsere Checkliste für Berechtigungen persönlicher Agenten hilft bei der Vorbereitung der Zugriffsprüfung. Auch die Analyse des Conductor-Übergangs zeigt, warum Arbeit portabel bleiben sollte: Commits, Aufgabenstatus und Review-Belege müssen einen Wechsel des Orchestrierungsprodukts überstehen.

Prüfen Sie vor dem Start eines weiteren Durchlaufs, ob temporäre Zugangsdaten gegebenenfalls widerrufen wurden, Hintergrunddienste berücksichtigt sind und abgeschlossene Branches einer bekannten weiteren Verwendung zugeordnet sind. Messen Sie die akzeptierte Arbeit und den Aufwand für Reviews, nicht nur die Zahl der aktiven Agenten. Wenn die Integration den Engpass bildet, reduzieren Sie die laufende Arbeit, statt die Warteschlange mit weiteren Ergebnissen zu füllen.

Prüfen Sie vor dem Aufräumen den Arbeitsablauf für wiederherstellbare Dateien auf Inhalte außerhalb des Git-Verlaufs. Für einen nicht nachverfolgten Datensatz, eine lokale Konfigurationsdatei oder den Zustand eines externen Dienstes ist möglicherweise ein eigener Wiederherstellungsplan erforderlich.

FAQ

Können zwei Agenten sicher denselben Branch verwenden?

Gemeinsame Arbeit lässt sich koordinieren, aber unabhängige Agenten sollten normalerweise jeweils eigene Branches und Arbeitsverzeichnisse erhalten. Andernfalls lassen sich Änderungen und Testergebnisse nur schwer zuordnen und reproduzieren.

Schützt es den Inhalt einer .env-Datei vor einem Agenten, wenn man sie zu .gitignore hinzufügt?

Nein. Ignorierregeln beeinflussen die Git-Nachverfolgung, nicht die Leseberechtigungen des Dateisystems. Bewahren Sie unnötige Geheimnisse außerhalb der für den Worker zugänglichen Umgebung auf.

Sollte jeder Agent ein Token zum Zusammenführen von Änderungen haben?

Nein. Gewähren Sie nur die für die Aufgabe erforderlichen Berechtigungen. Eine Änderung vorzuschlagen und sie in den geschützten Branch zu übernehmen, erfordert unterschiedliche Befugnisse.

Was, wenn sich der Worktree nicht entfernen lässt?

Prüfen Sie das Verzeichnis auf nicht commitete oder nicht nachverfolgte Arbeit und sichern Sie, was wichtig ist. Verwenden Sie Gewalt nicht routinemäßig zum Aufräumen.

Reicht es, wenn die Tests in jedem Branch bestehen?

Nicht, wenn die Änderungen miteinander interagieren. Führen Sie relevante Prüfungen für die tatsächlich integrierte Revision durch und untersuchen Sie das Verhalten über Bereichsgrenzen hinweg.

Fazit

Sicheres paralleles Programmieren verbindet die Isolation des Quellcodes mit Kontrollen für Laufzeit und Zugangsdaten. Worktrees erleichtern es, Änderungen voneinander zu trennen und zu überprüfen, während dedizierte Berechtigungen und passend konfigurierte Sandboxes den Zugriff eines Agenten einschränken.

Beginnen Sie mit einer sauberen Ausgangsbasis, weisen Sie jeder Aufgabe eine klare Zuständigkeit und einen klaren Vertrag zu und integrieren Sie nur überprüfbare Ergebnisse. Sichern Sie Belege vor dem Aufräumen, widerrufen Sie temporäre Zugriffsrechte und erhöhen Sie die Parallelität nur, wenn die akzeptierten Ergebnisse den Koordinationsaufwand rechtfertigen.