Lokale KI-Coding-Sandbox: Sitzungsgrenzen prüfen

Eine Sandbox kann die Auswirkungen eines unbeabsichtigten Befehls begrenzen. Dafür muss das Team wissen, für welche Sitzung sie gilt, welche Richtlinie tatsächlich aktiv wurde und welche Ressourcen erreichbar bleiben.

GitHub kündigte lokales Sandboxing für die Copilot-App am 23. September als öffentliche Vorschau an. Die Funktion legt Regeln für Dateisystem, Netzwerk und Zugangsdaten für lokale Repository- und Working-Tree-Sitzungen fest. Sie ist standardmäßig deaktiviert und gilt nicht für Copilot-Cloud-Sandboxen, Remote-Host-Sitzungen oder die separat konfigurierte Copilot CLI. Die Ankündigung und Einrichtungsanleitung von GitHub beschreiben den aktuellen Umfang.

Diese Einschränkungen sind wichtiger als das Wort Sandbox. Eine Projekteinstellung gilt nicht automatisch für jede Agentensitzung, jeden Rechner oder jedes Tool. Die Sicherheitsfrage lautet: Waren für genau diese Sitzung die erwarteten Beschränkungen aktiv, bevor der Agent einen Befehl ausführte?

Was die Vorschau steuert

Die Projekteinstellungen der Copilot-App umfassen Dateisystemzugriff, ausgehenden Internet- und lokalen Netzwerkzugriff sowie Git- und GitHub-CLI-Zugangsdaten für authentifizierte Aktionen. Dateiregeln können Lese-/Schreibpfade, schreibgeschützte Pfade und gesperrte Verzeichnisse festlegen. Verwaltete Enterprise-Einstellungen können die effektive Richtlinie weiter einschränken.

Laut GitHub werden Regeln beim Start einer Sandbox-Sitzung angewendet. Änderungen gelten für neue Sitzungen oder nach einem Neustart der bestehenden Sitzung. Kann das Betriebssystem eine angeforderte Regel nicht erzwingen, bricht die Sandbox-Shell mit einem Fehler ab, statt ungeschützt fortzufahren.

Das ist ein nützliches Fail-closed-Verhalten an der Shell-Grenze. Es belegt nicht, dass jede Anwendung, Erweiterung, Credential-Ablage oder Remote-Ausführung denselben Schutzbereich hat. Beschränke Aussagen auf die dokumentierte lokale Copilot-App-Sitzung.

Grenzen testbar machen

Lege vor der regelmäßigen Nutzung fest, was erlaubt und verboten sein soll:

1. Mit einem Wegwerf-Repository beginnen. Verwende keine Kundendaten, Produktionszugänge oder wertvolle uncommittete Arbeit.
2. Lesen und Schreiben trennen. Erlaube Schreibzugriff nur für benötigte Projektpfade. Halte Geheimnisse, persönliche Dateien und andere Repositories außerhalb davon oder sperre sie ausdrücklich.
3. Netzwerkbedarf festlegen. Entscheide, ob Internet oder lokales Netzwerk nötig sind. Öffne den Zugriff nicht vorsorglich; dokumentiere bekannte Ausnahmen.
4. Zugangsdaten prüfen. Entscheide, ob Git- oder GitHub-CLI-Anmeldung benötigt wird. Verwende eine passende Identität und Repository-Reichweite statt Zugangsdaten als pauschale Funktion zu behandeln.
5. Ungefährliche Tests definieren. Lege eine Dummy-Datei außerhalb des erlaubten Bereichs ab und prüfe harmlose Lese- und Schreibversuche. Bei gesperrtem Netzwerk teste eine harmlose Anfrage an einen bekannten Endpunkt. Notiere erwartetes und tatsächliches Ergebnis, Clientversion, Betriebssystem und Sitzungstyp.
6. Richtlinienänderungen in einer neuen Sitzung prüfen. Starte eine neue Sitzung oder den bestehenden Kontext neu und teste erneut. Eine geänderte Projekteinstellung wirkt nicht automatisch rückwirkend auf einen laufenden Prozess.
7. Enterprise-Regeln klären. Lass dir vom Administrator erklären, welche verwalteten Einstellungen den Projektwunsch einschränken oder überschreiben, und dokumentiere das Ergebnis für die unterstützte Umgebung.

Das sind empfohlene Prüfungen, keine für diesen Artikel ausgeführten Tests. Prüfe die aktuelle GitHub-Dokumentation und nutze eine freigegebene Testumgebung.

Drei typische Fehler beim Umfang

Lokal mit universell verwechseln. GitHub trennt lokale Repository- und Working-Tree-Sitzungen von Cloud-Sandboxen und Remote-Hosts. Eine Prüfung in einem Modus sagt nichts über die anderen aus. Die Copilot CLI braucht eigene Sandbox-Einstellungen.

„Aktiviert“ als Nachweis behandeln. Ein Schalter dokumentiert eine Absicht. Der Nachweis ist ein Test der gestarteten Sitzung: Welche Dateien kann sie lesen oder ändern, welche Netzwerkpfade funktionieren und welche Zugangsdaten stehen bereit? Wiederhole den Test nach Richtlinien- oder App-Änderungen.

Sichere Entwicklung ersetzen wollen. Sandboxing kann den Wirkungsradius unbeabsichtigter Befehle verringern. Code Reviews, Abhängigkeitskontrollen, geschützte Branches, minimale Berechtigungen und Incident Response bleiben nötig.

Nach Arbeitsabläufen einführen

Beginne mit einem risikoarmen Ablauf und einer schriftlichen Richtlinie. Halte erlaubte Pfade, Netzwerkbedarf, Zugangsdaten, Sitzungstyp und die Tests fest, die die wirksame Richtlinie belegen. Lass Ausnahmen prüfen, bevor sensible Repositories einbezogen werden.

Der praktische Nutzen ist nicht, dass ein KI-Coding-Agent automatisch vertrauenswürdig wird. Das Team kann einige lokale Sitzungen mit expliziten, testbaren Grenzen versehen und bei nicht anwendbaren Betriebssystemregeln geschlossen abbrechen. Dafür muss der Umfang sichtbar und gepflegt sein.

Weiterführende Artikel

• Ein MCP-Endpunkt ist keine vollständige Sicherheitsgrenze behandelt einen getrennten Zugriffspfad für Remote-Tools.
• GitHubs Anleitung zur lokalen Sandbox und die Ankündigung der öffentlichen Vorschau.

Redaktioneller Hinweis: Zusammenfassung der öffentlichen Vorschau-Dokumentation von GitHub mit einer vorgeschlagenen Prüfliste. Für diesen Artikel wurde keine lokale Sandbox eingerichtet oder getestet. Das Titelbild ist eine eigene Konzeptgrafik, kein Produktscreenshot.