Coding-Agenten sicher in einer Wegwerf-VM ausführen

Warum eine disposable VM besser ist als Ihr Laptop

Geben Sie einem Coding-Agenten eine disposable VM. Dann kann er im schlimmsten Fall eine Maschine zerstören, die Sie in zehn Minuten neu aufsetzen können. Der Agent erhält weiterhin root, installiert weiterhin Pakete und führt weiterhin die Testsuite aus, ohne für jeden Schritt um Erlaubnis zu bitten. Der Unterschied besteht darin, wo der Schaden entsteht. Auf einem Laptop verwendet der Agent dasselbe Home-Verzeichnis wie Ihre SSH-Schlüssel, Ihr Browserprofil, Ihre .env-Dateien und jedes andere Repository, das Sie jemals geklont haben. Auf einem Wegwerfserver hat er eine Shell, einen Checkout und sonst nichts, was sich zu stehlen lohnt.

Das ist das gesamte Argument. Es geht eher um eine Asymmetrie als um eine Wahrscheinlichkeit. Ein sorgfältiger Agent auf einem sorgfältig verwalteten Laptop ist fast immer unproblematisch. Wenn es einmal nicht so ist, besteht der Schaden nicht in einem fehlerhaften Commit. Sie müssen dann ein Backup wiederherstellen, sofern Sie eines haben.

Benennen Sie den Schadensbereich, bevor Sie darüber diskutieren

Der Schadensbereich umfasst alle Dinge, auf die ein Prozess zugreifen kann. Bei einem Agenten, der als Ihr normaler Benutzer auf Ihrem normalen Rechner läuft, ist dieser Bereich größer, als die meisten Menschen denken.

Dazu gehört ~/.ssh/id_ed25519, das normalerweise unverschlüsselt ist, weil Sie das Eingeben der Passphrase vermeiden wollten. Dazu gehören ~/.aws/credentials und ~/.config/gh/hosts.yml, die absichtlich als Klartext vorliegen. Dazu gehören alle benachbarten Repositorys unter ~/code, einschließlich derer mit Produktionsverbindungszeichenfolgen in einer lokalen env-Datei. Dazu gehört auch Ihre Shell-History, die von Ihnen einmal eingefügte Token enthält. Ebenfalls eingeschlossen ist das Netzwerk, mit dem Ihr Laptop verbunden ist. Dabei handelt es sich häufig um ein Heim- oder Büronetzwerk mit nicht authentifizierten Diensten.

Dafür ist kein bösartiger Agent erforderlich. Ein selbstbewusst ausgeführter, falscher Befehl genügt. rm -rf mit einer nicht gesetzten Variable, die zu / expandiert, ein git clean -xfd im falschen Verzeichnis, ein docker system prune -af --volumes, das Ihre lokale Datenbank mit entfernt, oder ein hilfreiches chmod -R 777 in einem Home-Verzeichnis. Agenten werden mit demselben Internet trainiert, das auch allen anderen diese Befehle beigebracht hat.

Was Sie schützt, ist nicht das Urteilsvermögen des Agenten. Es ist die Tatsache, dass der Rechner, auf dem der Schaden entsteht, ein Rechner ist, dessen Verlust Sie in Kauf nehmen würden.

Die Kostenrechnung ist langweilig. Genau das ist der Punkt.

Ein kleiner VPS kostet einige Dollar pro Monat. Die Wiederherstellung eines Entwickler-Laptops kostet einen Arbeitstag. Das ist der günstige Fall, bei dem Sie das Problem sofort bemerken und ein Backup haben.

Rechnen Sie es mit Ihren eigenen Zahlen durch. Nehmen Sie Ihren Stundensatz und multiplizieren Sie ihn mit der Zeit, die Sie benötigen würden, um ein Betriebssystem neu zu installieren, ein Home-Verzeichnis wiederherzustellen, einen SSH-Schlüssel zu ersetzen, ein persönliches Zugriffstoken zu ersetzen und zwanzig Repositorys erneut zu klonen. Vergleichen Sie das Ergebnis mit den Kosten für zwölf Monate des kleinsten Servers, den Ihr Anbieter anbietet. Der Break-even-Punkt liegt bei weniger als einem Vorfall in mehreren Jahren. Der Vorfall muss nicht katastrophal sein, damit sich der Server lohnt. Bereits ein einziger verlorener Nachmittag durch eine beschädigte lokale Umgebung deckt die Kosten für das ganze Jahr.

Die zweite Hälfte der Rechnung betrifft Snapshots. Ein Snapshot vor einem riskanten Lauf macht aus einem schlechten Ergebnis nicht mehr „mein gesamtes System wiederherstellen“, sondern „zurückrollen und einen anderen Prompt ausprobieren“. Diese Möglichkeit gibt es auf dem Laptop, auf dem Sie gerade tippen, nicht. Sie können keinen Snapshot eines Rechners erstellen, den Sie gleichzeitig als Arbeitsplatz verwenden.

Die Lage im Juli 2026

Auf die Frage „Wo sollte der Agent laufen?“ gibt es drei ehrliche Antworten. Sie wägen dieselben zwei Punkte gegeneinander ab: Wie stark die Grenze ist und wie viel Einrichtung Sie akzeptieren.

Eine lokale Micro-VM. Werkzeuge dieser Kategorie starten auf Ihrer eigenen Hardware eine echte virtuelle Maschine, binden Ihr Repository darin ein und geben dem Agenten dort root-Zugriff. clawk ist das aktuelle Beispiel. Die zentrale Aussage entspricht genau der These dieses Beitrags: Geben Sie Coding-Agenten eine kurzlebige Linux-VM statt Ihres Laptops. Im Juli 2026 richtet sich das Werkzeug an macOS 14 und höher auf Apple silicon. Experimentelle Linux-Unterstützung erfolgt über Firecracker. Die Installation erfolgt mit brew install clawkwork/tap/clawk. Mit clawk starten Sie innerhalb eines Repositorys die Sandbox und verbinden einen Agenten damit. Mit clawk down stoppen Sie sie. Mit clawk destroy entfernen Sie sie. Die Grenze bildet ein Hypervisor. Sie ist stark. Die Einschränkung besteht darin, dass die VM auf dem Gerät läuft, das Sie mit sich führen. Sie beansprucht daher Arbeitsspeicher und wird beendet, wenn Sie den Deckel schließen.

Ein Container. Docker ist die Lösung, die die meisten bereits installiert haben. Sie ist tatsächlich nützlich.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm verwirft den Container beim Beenden. --network none deaktiviert darin das Netzwerk vollständig. Das ist eine gute Voreinstellung für einen Build oder einen Testlauf. Beachten Sie, was dadurch nicht erreicht wird: Ein Container verwendet den Kernel des Hosts gemeinsam. Ein Kernel-Fehler kann daher einen Ausbruch ermöglichen. Die Grenze verschwindet außerdem sofort, wenn Sie --privileged hinzufügen oder /var/run/docker.sock einbinden, damit der Agent „Docker verwenden“ kann. Wenn Sie den Docker-Socket in einen Container einbinden, geben Sie diesem Container root-Zugriff auf den Host.

Ein neu erstellbarer einfacher VPS. Sie benötigen kein neues Werkzeug. Sie erhalten eine echte Kernel-Grenze und Snapshots beim Provider. Der VPS läuft weiter, wenn Sie Ihren Laptop schließen. Dieses Muster beschreibt der restliche Leitfaden. Es hält auch lange Agentenläufe aus, weil ein Auftrag mit einer Laufzeit von vier Stunden nicht davon abhängt, ob Sie nach Hause gegangen sind.

Das VPS-Muster: Geben Sie dem Agenten einen eigenen Benutzer

Beginnen Sie mit einem gehärteten System. Die ersten zehn Minuten auf einem neuen VPS behandeln die Punkte, die nicht agentspezifisch sind: Updates, eine Anmeldung ohne root, SSH nur mit Schlüsseln und eine Firewall.

Erstellen Sie anschließend ein Konto, das ausschließlich für den Agenten vorhanden ist. Dadurch kann ein Fehler innerhalb dieses Kontos keine anderen Bereiche des Servers verändern.

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password bedeutet, dass kein Passwort erraten werden kann. Sie erreichen das Konto mit sudo -u agent oder einem SSH-Schlüssel. Beachten Sie, dass agent absichtlich nicht zur Gruppe sudo gehört. Ein Agent mit sudo hat root-Rechte. root kann die Dateien aller anderen Benutzer lesen. Damit wäre die gerade eingerichtete Trennung nur scheinbar vorhanden. Wenn der Agent tatsächlich Pakete installieren muss, spricht das für einen eigenen Server und nicht dafür, ihm auf einem gemeinsam genutzten Server sudo zu geben. Die allgemeinen Regeln finden Sie unter Prinzip der geringsten Rechte für Linux-Benutzer auf einem VPS.

Prüfen Sie die Abgrenzung, bevor Sie ihr vertrauen. Versuchen Sie als Benutzer agent, eine Datei zu lesen, die zu Ihrem eigenen Konto gehört:

sudo -u agent cat /home/you/.ssh/id_ed25519

Sie sollten cat: /home/you/.ssh/id_ed25519: Permission denied sehen. Wenn stattdessen Schlüsselmaterial angezeigt wird, hat Ihr Home-Verzeichnis den Modus 755. Die Isolation ist dann noch nicht wirksam. Beheben Sie das mit sudo chmod 700 /home/you.

Halten Sie die Zugangsdaten vollständig vom Rechner fern

Der Zweck eines Wegwerf-Rechners ist hinfällig, wenn Sie Ihre Produktionsgeheimnisse darauf kopieren. Die Regel ist einfach: Auf diesem Rechner darf sich nichts befinden, bei dem Sie es bedauern würden, es noch heute Nachmittag zu rotieren.

Für git leiten Sie Ihren SSH-Agent weiter, anstatt einen Schlüssel zu kopieren. Der private Schlüssel bleibt auf Ihrem Laptop. Nur Signaturanfragen werden über die Verbindung übertragen.

ssh -A agent@203.0.113.10
ssh -T git@github.com

Der zweite Befehl sollte Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. beantworten. Damit ist nachgewiesen, dass git push ohne eine Schlüsseldatei auf dem Server funktioniert. Führen Sie anschließend ls -la ~/.ssh auf dem Rechner aus und bestätigen Sie, dass sich darin kein privater Schlüssel befindet.

Die Weiterleitung des Agents hat einen wichtigen Vorbehalt. Während Ihrer Verbindung kann jeder Benutzer mit root-Rechten auf diesem Server den weitergeleiteten Socket verwenden, um sich als Sie zu authentifizieren. Auf einem Server, dessen einziger anderer Benutzer Sie selbst sind, ist das ein akzeptabler Kompromiss. Auf einem gemeinsam genutzten Rechner ist das nicht akzeptabel. In diesem Fall ist ein auf ein Repository beschränkter Deploy-Schlüssel die bessere Lösung. Die Optionen werden unter Grundlagen der SSH-Schlüsselverwaltung erläutert.

Für API-Schlüssel geben Sie dem Agent einen eigenen Schlüssel mit einem eigenen Ausgabenlimit. Speichern Sie ihn in einer Datei, die dem Benutzer agent gehört und den Modus 600 hat. Wenn der Rechner zerstört wird, widerrufen Sie diesen Schlüssel, anstatt sich zu fragen, ob er möglicherweise offengelegt wurde. Wenn die Modellausgaben pro Schlüssel sichtbar bleiben, bleiben auch die Zahlen unter Kostenkontrolle für AI-Agents auf einem VPS vorhersehbar.

Begrenzen Sie, was der Agent im Netzwerk erreichen kann

Die Isolation des Dateisystems ist nur die Hälfte der Begrenzung. Die andere Hälfte ist der ausgehende Netzwerkverkehr: Mit welchen Zielen darf der Prozess kommunizieren? Linux kann ausgehenden Netzwerkverkehr anhand des Benutzers filtern, der ihn erstellt hat. Das passt genau zu diesem Muster.

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

Die Regeln werden der Reihe nach ausgewertet. Daher greift die abschließende REJECT für alles, was die vorherigen Zeilen nicht erlaubt haben. Testen Sie dies als Agent:

sudo -u agent curl -sS -m 5 http://example.com

Der Zugriff sollte mit curl: (7) Failed to connect to example.com port 80: Connection refused fehlschlagen, weil die Reject-Regel sofort antwortet, anstatt die Verbindung hängen zu lassen. Eine HTTPS-Anfrage an denselben Host sollte weiterhin erfolgreich sein.

Es gibt zwei wichtige Einschränkungen. Erstens gehen diese Regeln beim nächsten Neustart verloren, wenn Sie sie nicht mit sudo apt install -y iptables-persistent und anschließend mit sudo netfilter-persistent save speichern. Zweitens filtert diese Methode Ports und Adressen, nicht Namen. Eine Regel, die Port 443 erlaubt, ermöglicht den Zugriff auf jeden HTTPS-Host im Internet. Damit kann der Agent zwar die Model API erreichen, aber auch einen Pastebin-Dienst. Eine echte Domain-Allowlist erfordert, dass der Netzwerkverkehr über einen Proxy läuft, der den angeforderten Hostnamen auswertet. Das ist für die meisten Setups einzelner Entwickler mehr Aufwand als gewünscht. Behaupten Sie nur das, was tatsächlich gewährleistet ist: eine ausgehende Kontrolle auf Portebene auf einer Maschine, deren Verlust Sie einkalkuliert haben.

Zwischen Aufgaben auf einen sauberen Zustand zurücksetzen

Ein sauberer Zustand pro Aufgabe ist ein unterschätzter Vorteil. Ein Agent, der drei Stunden am letzten Ticket gearbeitet hat, hinterlässt installierte Pakete, teilweise angewendete Migrationen, ein veraltetes node_modules und einen Git-Arbeitsbaum mit Änderungen, die niemand geprüft hat. Die nächste Aufgabe übernimmt alles davon, und Sie verbrauchen Ihr Review-Budget damit, herauszufinden, welches Durcheinander zu welchem Lauf gehört.

Die einfache Variante ist ein neuer Checkout pro Aufgabe.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

Die zuverlässigere Variante ist ein Provider-Snapshot, der einmal erstellt wird, direkt nachdem die Maschine eingerichtet wurde und bevor ein Agent sie verwendet hat. Durch die Wiederherstellung dieses Snapshots wird das gesamte System einschließlich der Pakete in einen bekannten Zustand zurückversetzt. Die meisten Provider bieten diese Funktion im Control Panel oder über eine API an, nicht als Befehl auf der Maschine. Die genauen Schritte hängen daher von Ihrem Provider ab. Entscheidend ist, den Snapshot zu erstellen, solange die Maschine noch unverändert ist.

Bewahren Sie alles, was Ihnen wichtig ist, außerhalb der verworfenen Maschine auf. Das bedeutet meistens, Branches zu pushen, statt sie nur lokal aufzubewahren. Falls sich auf der Maschine doch etwas befindet, dessen Verlust Sie bedauern würden, sichern Sie es ordnungsgemäß mit restic-Backups auf einem VPS. Eine Maschine, die Sie zerstören können, ist nur dann nützlich, wenn die Zerstörung tatsächlich problemlos verläuft.

Wenn Sie mehrere isolierte Umgebungen benötigen, ohne mehrere Server zu bezahlen, kann ein größerer VPS direkt Gast-VMs hosten. Verschachtelte Virtualisierung auf einem VPS erklärt die Funktionsweise und wie Sie prüfen, ob Ihr Provider dies erlaubt.

Wenn ein sorgfältig genutzter Laptop tatsächlich ausreicht

Seien Sie dabei ehrlich. Eine übertriebene Darstellung der Isolation führt dazu, dass die Nutzer nicht mehr zuhören.

Wenn Sie jeden Befehl prüfen, bevor er ausgeführt wird, ist ein Laptop ausreichend. Die Berechtigungsabfrage ist eine echte Kontrollmaßnahme. Claude Code sicher auf einem Server ausführen zeigt, was die einzelnen Stufen tatsächlich blockieren. Wenn Ihre Arbeit nur ein Repository umfasst und sich auf dem Rechner keine Zugangsdaten für Produktionssysteme befinden, ist der mögliche Schadensumfang bereits gering. Wenn Ihre Agentensitzungen kurz sind und überwacht werden, ist auch das Zeitfenster der Gefährdung kurz.

Sobald Sie die Abfragen überspringen, ändert sich die Situation. Unbeaufsichtigte Ausführungen, Aufgaben über Nacht und alle Abläufe, bei denen Sie einen Plan genehmigen und danach den Rechner verlassen, entfernen die menschliche Kontrolle, die bisher für die Begrenzung gesorgt hat. Dann muss der Rechner diese Aufgabe übernehmen. Dasselbe gilt für alles, was die Reichweite des Agenten vergrößert, einschließlich einen Coding-Agenten auf einem VPS ausführen, der gleichzeitig auf mehreren Repositories arbeitet.

Bei dieser Entscheidung geht es nicht wirklich darum, wie sehr Sie dem Modell vertrauen. Es geht darum, was sich neben dem Modell befindet, wenn es einen Fehler macht.

FAQ

Bietet ein Container genug Isolation für einen Coding-Agenten?

Für die meisten Aufgaben ja, unter zwei Bedingungen. Der Container darf nicht mit --privileged ausgeführt werden und /var/run/docker.sock darf nicht in ihn eingebunden sein, weil beides dem Prozess einen Pfad zum root-Konto des Hosts eröffnet. Ein Container verwendet den Kernel des Hosts gemeinsam. Die Grenze ist daher schwächer als bei einer virtuellen Maschine. Wenn der Agent nicht vertrauenswürdigen Code aus dem Internet ausführt, verwenden Sie besser eine echte virtuelle Maschine oder einen separaten Server.

Benötigt der Agent sudo auf dem Server?

Nein. Wenn Sie ihm sudo geben, machen Sie die aufgebaute Isolation wieder rückgängig, weil root alle anderen Konten auf dem Rechner lesen kann. Erstellen Sie den Agentenbenutzer ohne sudo und geben Sie ihm nur Schreibzugriff auf sein eigenes Arbeitsverzeichnis. Wenn die Aufgabe tatsächlich die Installation von Paketen erfordert, geben Sie dem Agenten eine vollständige, ihm zugewiesene Maschine statt root-Zugriff auf eine gemeinsam genutzte Maschine.

Wie kann der Agent an git pushen, ohne meinen SSH-Schlüssel auf dem Rechner abzulegen?

Leiten Sie Ihren SSH-Agenten mit ssh -A weiter, wenn Sie die Verbindung herstellen. Signaturanfragen werden über die Verbindung übertragen, während der private Schlüssel auf Ihrem Laptop bleibt. Dadurch authentifiziert sich ssh -T git@github.com und git push funktioniert ohne privaten Schlüssel auf dem Server. Beachten Sie jedoch, dass root auf diesem Server den weitergeleiteten Socket verwenden kann, solange Sie verbunden sind. Verwenden Sie daher auf jedem Rechner, den Sie mit anderen Personen gemeinsam nutzen, einen auf das Repository beschränkten Deploy-Schlüssel.

Welche Größe muss ein VPS für einen Agenten haben?

Bei der Arbeit des Agenten geht es hauptsächlich um das Bearbeiten von Dateien sowie das Ausführen von Builds und Tests. Dimensionieren Sie die Maschine daher nach dem Build und nicht nach dem Modell. Ein gehostetes Modell läuft auf der Hardware des Anbieters. Dadurch entsteht Netzwerkverkehr und fast keine lokale Last. Beginnen Sie für Skripting-Aufgaben mit 2 GB RAM und wechseln Sie zu 8 GB, wenn das Repository Container erstellt oder umfangreiche Kompilierungen durchführt.

Wie oft sollte ich die Maschine löschen und neu erstellen?

Erstellen Sie sie neu, sobald der Zustand nicht mehr erklärbar ist, und mindestens immer dann, wenn ein Zugangsdaten auf der Maschine möglicherweise offengelegt wurde. Ein neuer Checkout zwischen Aufgaben behebt die tägliche Abweichung. Ein Snapshot vor dem ersten Agentenlauf stellt ein sauberes Systemabbild bereit, zu dem Sie zurückkehren können. Wenn das Neuerstellen zu aufwendig wirkt, ist das ein Zeichen dafür, dass etwas Wichtiges auf einer Maschine liegt, die Sie als wegwerfbar bezeichnet haben.