Dein Coding-Agent kann deine SSH-Schlüssel lesen. So zäunst du ihn ein

Wenn ein Coding-Agent auf deinem Laptop ls, cat oder npm install ausführt, tut er das als du. Nicht als Gast, nicht als eingeschränktes Dienstkonto, sondern als dein Benutzer, mit deinem Home-Ordner, deinen SSH-Schlüsseln, jeder .env-Datei in jedem Projekt, das du je geklont hast, und allen Git- und Cloud-Zugangsdaten, die in deiner Konfiguration liegen. Diesen Teil überspringen die meisten, wenn sie einen Agenten an ein Terminal hängen, und deshalb ist GitHubs Meldung vom 2026-10-07 wichtiger, als ihr Umfang vermuten lässt: Lokales Sandboxing für Copilot ist jetzt allgemein verfügbar.

Das Risiko ist der Text, den der Agent liest, nicht der Agent

Dieser Teil ist allgemein und betrifft kein bestimmtes Produkt. Ein Agent entscheidet anhand dessen, was er liest, was er ausführt, und er liest vieles, das du nicht geschrieben hast: die README eines frisch geklonten Repositorys, ein Issue, das jemand eröffnet hat, eine abgerufene Webseite, einen Kommentar in einer Abhängigkeit. Steht in einem dieser Texte, er solle eine Datei ausgeben oder etwas irgendwohin schicken, folgt der Agent dem womöglich, weil die Anweisung für ihn wie ein Teil der Aufgabe aussieht. Das ist Prompt Injection. Du kannst nicht jede Zeile prüfen, die ein Agent liest, also lautet die sinnvolle Frage nicht „Wird er hereingelegt?“, sondern „Was kann er erreichen, wenn es passiert?“.

Was GitHubs Sandbox einschränkt

Laut GitHub ist die Sandbox in Copilot CLI, der Copilot-App und VS-Code-Sitzungen mit Agent Host verfügbar, ohne Aufpreis zu Copilot. Tools und Befehle, die Copilot startet, laufen mit eingeschränktem Zugriff auf Dateisystem, Netzwerk, Zugangsdaten und andere Systemfunktionen, nach Richtlinien, die der Entwickler oder die Organisation festlegt. GitHub nennt, was du steuern kannst: welche Dateien und Ordner diese Befehle lesen oder ändern dürfen; den Zugriff auf das Internet, das lokale Netzwerk, Git-Zugangsdaten und GitHub-CLI-Zugangsdaten; und Sandboxing für lokale Tools wie lokale MCP-Server und Language Server, wo unterstützt. Unternehmen können die Sandbox vorschreiben und Richtlinien sperren, sodass ein Entwickler sie nicht lockern kann.

Darunter liegt das, was GitHub Microsoft eXecution Container (MXC) nennt: Es übersetzt eine einzige Sandbox-Richtlinie in die nativen Kontrollen von Windows, macOS und Linux. GitHub macht außerdem einen Punkt, dem ich zustimme: Modell und Tool-Sandbox sind getrennte Themen, die Richtlinie gilt also für das, was ausgeführt wird, egal welches Modell gerade steuert.

Schichten, die du für jeden Agenten übernehmen kannst

Egal welchen Agenten du nutzt: Das sind allgemeine Gewohnheiten, keine Einstellungen aus GitHubs Ankündigung, und jede schließt eine andere Tür:

• Nur der Projektordner. Der Agent liest und schreibt im Repository, an dem er arbeitet, und nichts darüber.
• Keine herumliegenden Zugangsdaten. Lass ihn nicht deine persönlichen Tokens erben. Braucht er Zugriff, gib ihm ein kurzlebiges Token, das auf genau diese Aufgabe beschränkt ist.
• Eine Netzwerk-Allowlist. Paket-Registries und die APIs, die die Aufgabe braucht, nicht das ganze Internet.
• Ein Mensch gibt alles Destruktive frei. Löschen, Force-Push, eine Tabelle droppen.
• Nicht vertrauenswürdige Repositories kommen in einen Container oder eine VM, nie direkt auf die Maschine mit deinen Schlüsseln.
• Lies den Diff, bevor er deine Maschine verlässt, und gib einem Agenten nie Produktionszugangsdaten.

Der nächste Schritt dauert zehn Minuten: Öffne ein Terminal so, wie dein Agent es tut, und liste auf, was dieser Benutzer lesen kann, angefangen bei ~/.ssh, dem Konfigurationsordner deiner Cloud und den .env-Dateien in deinen Projekten. Alles auf dieser Liste ist heute in Reichweite des Agenten. Wenn du Copilot nutzt, schalte die Sandbox ein und beginne mit den Regeln für Dateisystem und Zugangsdaten; mit einem anderen Agenten baust du denselben Zaun mit einem Dev Container und einem eng begrenzten Token. Quelle: GitHub Changelog, lokales Sandboxing für GitHub Copilot.