Coding-Agent in einer Wegwerf-VM ausführen

Warum eine kurzlebige VM besser ist als Ihr Laptop

Geben Sie einem Coding-Agenten eine kurzlebige VM. Im schlimmsten Fall zerstört er eine Maschine, die Sie in zehn Minuten neu aufsetzen können. Der Agent erhält weiterhin root-Rechte, 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 hat der Agent Zugriff auf ein Home-Verzeichnis mit Ihren SSH-Schlüsseln, Ihrem Browserprofil, Ihren .env-Dateien und allen anderen Repositories, die Sie jemals geklont haben. Auf einem Wegwerfserver hat er eine Shell, ein 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 abgesicherten Laptop ist fast immer unproblematisch. Wenn es einmal schiefgeht, besteht der Schaden nicht nur aus einem fehlerhaften Commit. Sie müssen ein Backup wiederherstellen, sofern Sie eines haben.

Den Schadensumfang benennen, bevor Sie darüber diskutieren

Der Schadensumfang umfasst alles, worauf ein Prozess zugreifen kann. Bei einem Agenten, der als Ihr normaler Benutzer auf Ihrem normalen Rechner läuft, ist diese Menge größer, als die meisten Menschen annehmen.

Dazu gehört ~/.ssh/id_ed25519, das normalerweise unverschlüsselt ist, weil Sie die Passphrase nicht mehr jedes Mal eingeben wollten. Dazu gehören ~/.aws/credentials und ~/.config/gh/hosts.yml, die absichtlich im Klartext vorliegen. Dazu gehört jedes Schwester-Repository unter ~/code, einschließlich derer mit Produktionsverbindungszeichenfolgen in einer lokalen Env-Datei. Dazu gehört auch Ihr Shell-Verlauf, in dem sich Tokens befinden, die Sie einmal eingefügt haben. Außerdem gehört das Netzwerk dazu, 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 selbstsicherer, falscher Befehl reicht aus. 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.

Der Schutzmechanismus ist nicht das Urteilsvermögen des Agenten. Entscheidend ist, dass der Rechner, auf dem der Schaden entsteht, ein Rechner ist, auf dessen Verlust Sie vorbereitet waren.

Die Kostenrechnung ist langweilig. Genau darum geht es.

Ein kleiner VPS kostet wenige Dollar im Monat. Die Wiederherstellung eines Entwickler-Laptops dauert einen Arbeitstag. Das ist der günstige Fall, bei dem Sie den Vorfall sofort bemerken und ein Backup hatten.

Rechnen Sie es mit Ihren eigenen Zahlen durch. Multiplizieren Sie Ihren Stundensatz mit der Zeit, die Sie benötigen würden, um ein Betriebssystem neu zu installieren, ein Home-Verzeichnis wiederherzustellen, einen SSH-Schlüssel zu erneuern, ein persönliches Zugriffstoken zu erneuern und zwanzig Repositories erneut zu klonen. Vergleichen Sie das Ergebnis mit den Kosten für zwölf Monate des kleinsten Servers, den Ihr Provider anbietet. Der Break-even liegt bei weniger als einem Vorfall in mehreren Jahren. Der Vorfall muss nicht einmal schwerwiegend sein, damit sich die Kosten amortisieren. Ein einziger verlorener Nachmittag durch eine beschädigte lokale Umgebung deckt die Jahreskosten bereits.

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 diesen Text schreiben, nicht, weil Sie ein Gerät nicht snapshotten können, während Sie es als Arbeitsplatz verwenden.

Die Landschaft im Juli 2026

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

Eine lokale Micro-VM. Tools dieser Kategorie starten auf Ihrer eigenen Hardware eine echte virtuelle Maschine, binden Ihr Repository darin ein und geben dem Agenten darin root-Zugriff. clawk ist das aktuelle Beispiel. Die zentrale Aussage dieses Beitrags lautet genau so: Geben Sie Coding-Agenten eine wegwerfbare Linux-VM, nicht Ihren Laptop. Im Juli 2026 unterstützt das Tool macOS 14 und höher auf Apple silicon. Außerdem gibt es experimentelle Linux-Unterstützung ü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. Das ist eine starke Trennung. 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 angehalten, sobald 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 löscht den Container beim Beenden. --network none deaktiviert darin den Netzwerkzugriff vollständig. Das ist eine gute Standardeinstellung für einen Build oder einen Testlauf. Beachten Sie, was dadurch nicht erreicht wird: Ein Container verwendet den Kernel des Hosts gemeinsam. Eine Kernel-Sicherheitslücke kann daher einen Ausbruch ermöglichen. Die Trennung verschwindet außerdem, sobald 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 effektiv root-Zugriff auf den Host.

Ein einfacher, wiederherstellbarer VPS. Sie benötigen kein neues Tool. Sie erhalten eine echte Kernel-Grenze und Snapshots beim Provider. Der VPS läuft weiter, wenn Sie Ihren Laptop ausschalten. Dieses Muster beschreibt der restliche Leitfaden. Es ist für lange Agent-Läufe geeignet, weil es einem vier Stunden dauernden Auftrag egal ist, 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 nicht agentspezifischen Schritte: 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 erreichen.

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 greifen mit sudo -u agent oder einem SSH-Schlüssel auf das Konto zu. 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 dem Agenten 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.

Anmeldedaten vollständig vom Rechner fernhalten

Der Zweck eines Wegwerfrechners ist verfehlt, wenn Sie Ihre Produktionsgeheimnisse darauf kopieren. Die Regel ist einfach: Auf diesem Rechner darf sich nichts befinden, bei dem Sie eine sofortige Rotation heute Nachmittag vermeiden möchten.

Für git leiten Sie Ihren SSH-Agent weiter, statt einen Schlüssel zu kopieren. Der private Schlüssel bleibt auf Ihrem Laptop. Nur Signaturanforderungen 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 auf dem Server vorhandene Schlüsseldatei funktioniert. Führen Sie anschließend ls -la ~/.ssh auf dem Rechner aus und bestätigen Sie, dass darin kein privater Schlüssel enthalten ist.

Die Weiterleitung des Agents hat einen wichtigen Vorbehalt. Solange Sie verbunden sind, 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 vertretbarer Kompromiss. Auf einem gemeinsam genutzten Rechner ist es das nicht. Dort ist ein auf ein einzelnes Repository beschränkter Deploy-Key die bessere Lösung. Die Optionen werden in Grundlagen der SSH-Schlüsselverwaltung behandelt.

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, statt sich zu fragen, ob er möglicherweise offengelegt wurde. Wenn die Modellausgaben pro Schlüssel sichtbar bleiben, bleiben auch die Zahlen in Kontrolle der AI-Agent-Kosten auf einem VPS vorhersehbar.

Netzwerkzugriff des Agents begrenzen

Die Dateisystemisolierung bildet nur die eine Hälfte der Grenze. 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 erzeugt 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. Die letzte REJECT erfasst daher alles, was durch die vorherigen Zeilen nicht erlaubt wurde. Testen Sie dies als Agent:

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

Der Test 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.

Dabei gibt es zwei wichtige Einschränkungen. Erstens gehen diese Regeln beim nächsten Reboot verloren, sofern 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 erreichen Sie zwar die Model-API, aber auch einen Pastebin-Dienst. Eine echte Allowlist für Domains erfordert, dass der Netzwerkverkehr über einen Proxy läuft, der den angeforderten Hostnamen auswertet. Das ist für die meisten Setups mit nur einem Entwickler mehr Infrastruktur, als sie benötigen. Machen Sie nur die Zusage, die Sie tatsächlich einhalten: Egress-Kontrolle auf Portebene auf einer Maschine, deren Verlust Sie einkalkuliert hatten.

Sauberer Zustand zwischen Aufgaben

Ein sauberer Zustand pro Aufgabe ist ein unterschätzter Vorteil. Ein Agent, der drei Stunden am letzten Ticket gearbeitet hat, hinterlässt möglicherweise installierte Pakete, halb angewendete Migrationen, einen veralteten node_modules und einen Git-Arbeitsbaum mit Änderungen, die niemand geprüft hat. Die nächste Aufgabe übernimmt all das. Sie verwenden dann Ihr Prüfungsbudget darauf, herauszufinden, welches Durcheinander zu welchem Lauf gehört. Ein eingeschränkterer Agent hinterlässt von vornherein weniger. Zusammen mit einer Fähigkeit, die den Agenten zur kleinsten funktionierenden Änderung führt hält eine temporäre Maschine daher sowohl den Diff als auch den verbleibenden Zustand klein genug, um ihn zu prüfen.

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 robustere Variante ist ein Provider-Snapshot, der einmal erstellt wird, direkt nachdem die Maschine eingerichtet wurde und bevor ein Agent sie verwendet hat. Durch das Wiederherstellen dieses Snapshots wird das gesamte System einschließlich der Pakete in einen bekannten Zustand zurückversetzt. Die meisten Provider stellen diese Funktion im Control Panel oder über eine API bereit, 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 temporären Maschine auf. Das bedeutet meist, Branches zu pushen, statt sie lokal zu sammeln. Falls sich auf der Maschine doch etwas befindet, das Sie vermissen 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 ihr Löschen tatsächlich problemlos bleibt.

Wenn Sie mehrere isolierte Umgebungen benötigen, aber nicht für mehrere Server bezahlen möchten, kann ein größerer VPS direkt Gast-VMs hosten. Verschachtelte Virtualisierung auf einem VPS beschreibt die Funktionsweise und zeigt auch, wie Sie prüfen, ob Ihr Provider dies erlaubt. Isolation wirkt hier in beide Richtungen. Wenn zwei Agenten lieber auf derselben Maschine zusammenarbeiten sollen, statt voneinander abgeschottet zu sein, kann eine Claude-Code-Sitzung Text direkt an eine andere senden, anstatt jede Übergabe über Sie zu leiten.

Wann ein sorgfältig abgesicherter Laptop wirklich ausreicht

Seien Sie hierbei ehrlich. Wer die Isolation überbewertet, wird irgendwann nicht mehr ernst genommen.

Wenn Sie jeden Befehl vor der Ausführung prüfen, reicht ein Laptop aus. Die Berechtigungsabfrage ist eine echte Kontrolle. Claude Code sicher auf einem Server ausführen zeigt, was die einzelnen Stufen tatsächlich blockieren. Wenn Ihre Arbeit aus einem einzigen Repository besteht und sich auf dem Rechner keinerlei Produktionszugangsdaten befinden, ist der mögliche Schadensumfang bereits gering. Wenn Ihre Agent-Sitzungen kurz sind und überwacht werden, ist auch das Zeitfenster für einen Vorfall kurz.

Das ändert sich, sobald Sie die Abfragen überspringen. Das ist besonders jetzt relevant, da der Auto-Modus am 14 August 2026 zum Standard von Claude Code wird und eine neue Installation nicht mehr nachfragt, bevor sie Dateien bearbeitet oder Befehle ausführt. Unbeaufsichtigte Ausführungen, Jobs über Nacht und alle Workflows, bei denen Sie einen Plan genehmigen und sich anschließend entfernen, beseitigen die menschliche Kontrolle, die zuvor für die Begrenzung des Schadens gesorgt hat. Dann muss der Rechner diese Aufgabe übernehmen. Das gilt auch für alles, was die Reichweite des Agents vergrößert, einschließlich einen Coding-Agent auf einem VPS auszuführen, der gleichzeitig auf mehrere Repositories zugreift.

Bei dieser Entscheidung geht es nicht wirklich darum, wie sehr Sie dem Modell vertrauen. Entscheidend ist, was sich in seiner Umgebung befindet, wenn das Modell einen Fehler macht.

FAQ

Ist ein Container als Isolation für einen Coding-Agenten ausreichend?

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 den Container eingebunden sein, weil beides dem Prozess einen Pfad zu root auf dem Host eröffnet. Ein Container verwendet den Kernel des Hosts gemeinsam mit ihm. 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 VM oder einen separaten Server.

Benötigt der Agent sudo auf dem Server?

Nein. Die Vergabe von sudo hebt die eingerichtete Isolation wieder auf, weil root jedes andere Konto auf dem Server 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 eigene Maschine statt root-Zugriff auf eine gemeinsam genutzte Maschine.

Wie kann der Agent ohne meinen SSH-Schlüssel auf dem Server in git pushen?

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 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 Maschinen, die Sie mit anderen Personen teilen, einen auf das Repository beschränkten Deploy-Schlüssel.

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

Die Arbeit des Agenten besteht hauptsächlich aus dem Bearbeiten von Dateien sowie dem 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 bei Skriptaufgaben mit 2 GB RAM. Erhöhen Sie den Arbeitsspeicher auf 8 GB, wenn das Repository Container erstellt oder umfangreich kompiliert wird.

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

Erstellen Sie die Maschine neu, sobald der Zustand nicht mehr nachvollziehbar ist. Das gilt mindestens dann, wenn ein Zugangsschlüssel auf der Maschine möglicherweise offengelegt wurde. Ein neuer Checkout zwischen den Aufgaben beseitigt die tägliche Abweichung vom Ausgangszustand. Ein vor dem ersten Agentenlauf erstellter Snapshot liefert ein sauberes Systemabbild, zu dem Sie zurückkehren können. Wenn die Neuerstellung aufwendig wirkt, ist das ein Zeichen dafür, dass wichtige Daten auf einer Maschine liegen, die Sie als temporär bezeichnet haben.