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.

Legen Sie den Schadensradius fest, bevor Sie darüber diskutieren

Der Schadensradius umfasst alle Ressourcen, die ein Prozess erreichen 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 in der Regel unverschlüsselt ist, weil Sie die Passphrase nicht mehr 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 der Repositories mit Produktions-Connection-Strings in einer lokalen Env-Datei. Dazu gehört auch Ihre Shell-Historie, die Tokens enthält, 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 einziger, selbstsicher falsch ausgeführter Befehl genügt. rm -rf "$BUILD_DIR"/* mit nicht gesetztem BUILD_DIR, das zu /* expandiert und die standardmäßige Weigerung von GNU rm umgeht, / selbst zu löschen, ein git clean -xfd im falschen Verzeichnis, ein docker system prune -af --volumes, das Ihre lokale Datenbank mitlöscht, oder ein hilfreiches chmod -R 777 auf einem Home-Verzeichnis. Agenten werden mit denselben Inhalten aus dem Internet trainiert, durch die auch alle anderen diese Befehle gelernt haben.

Der Mechanismus, der Sie schützt, ist nicht das Urteilsvermögen des Agenten. Entscheidend ist, dass sich der potenzielle Schaden auf einem Rechner befindet, dessen Verlust Sie einkalkuliert haben.

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 Oktober 2026

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

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-Rechte. clawk ist das aktuelle Beispiel. Die zentrale Aussage dieses Beitrags lautet genau: Geben Sie Coding-Agenten eine kurzlebige Linux-VM, nicht Ihren Laptop. Im Oktober 2026 richtet sich das Tool an macOS 14 und höher auf Apple-Silicon-Geräten. 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. Mit clawk down stoppen Sie sie, und mit clawk destroy entfernen Sie sie. Die Abgrenzung erfolgt durch einen Hypervisor und ist daher stark. Die Einschränkung besteht darin, dass die VM auf dem Gerät läuft, das Sie mit sich führen. Sie beansprucht dessen Arbeitsspeicher und wird angehalten, sobald Sie den Deckel schließen.

Ein Container. Docker ist die Lösung, die die meisten bereits installiert haben, und 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 sämtliche Netzwerkverbindungen. Das ist eine gute Voreinstellung für einen Build oder einen Testlauf. Wichtig ist, was dadurch nicht erreicht wird: Ein Container verwendet den Kernel des Hosts gemeinsam mit diesem. Eine Kernel-Sicherheitslücke kann daher einen Ausbruch ermöglichen. Die Abgrenzung 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 root-Rechte auf dem Host.

Ein einfacher VPS, den Sie neu aufsetzen können. Sie benötigen kein neues Werkzeug. Sie erhalten eine echte Kernel-Abgrenzung und Snapshots beim Provider. Der VPS läuft weiter, wenn Sie Ihren Laptop herunterfahren. Dieses Muster beschreibt der restliche Leitfaden. Es ist für lange Agentenläufe geeignet, weil ein Job, der vier Stunden dauert, 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 Teile, die nicht vom Agenten abhängen: Updates, eine Anmeldung ohne root, SSH nur mit Schlüssel und eine Firewall.

Erstellen Sie anschließend ein Konto, das ausschließlich für den Agenten vorgesehen ist. Dadurch kann ein Fehler innerhalb dieses Kontos nichts anderes auf dem Server beeinträchtigen.

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 soeben eingerichtete Trennung nur noch eine Fassade. Wenn der Agent tatsächlich Pakete installieren muss, spricht das für einen eigenen Server, nicht dafür, ihm auf einem gemeinsam genutzten Server sudo zu geben. Die allgemeinen Regeln finden Sie unter Least Privilege für Linux-Benutzer auf einem VPS.

Prüfen Sie die Grenze, bevor Sie dem Agenten vertrauen. Listen Sie als Benutzer agent das Home-Verzeichnis des eigenen Kontos auf:

sudo -u agent ls /home/you

Sie sollten ls: cannot open directory '/home/you': Permission denied sehen. Wenn stattdessen eine Dateiliste angezeigt wird, können andere Benutzer Ihr Home-Verzeichnis lesen. Der Agent kann dann alle darin enthaltenen Dateien lesen, die nicht separat geschützt sind, zum Beispiel eine weltweit lesbare Datei .env. Beheben Sie das mit sudo chmod 700 /home/you. Ihr privater SSH-Schlüssel wird durch diesen Test nicht geschützt: ssh ignoriert eine private Schlüsseldatei, auf die andere Benutzer zugreifen können. Jeder Schlüssel, der bei Ihnen tatsächlich funktioniert, ist für agent daher bereits unlesbar, unabhängig von den Berechtigungen Ihres Home-Verzeichnisses.

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 Agenten begrenzen

Die Isolation des Dateisystems bildet nur die eine Hälfte der Grenze. Die andere Hälfte ist der ausgehende Netzwerkverkehr: Welche Ziele darf der Prozess erreichen? Linux kann ausgehenden Datenverkehr 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 in der angegebenen Reihenfolge ausgewertet. Die letzte REJECT-Regel 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 Befehl sollte sofort mit einem curl: (7) Failed to connect to example.com-Fehler fehlschlagen. Die genaue Meldung hängt von Ihrer curl-Version ab, weil die Reject-Regel sofort antwortet, anstatt die Verbindung hängen zu lassen. Eine HTTPS-Anfrage an denselben Host sollte weiterhin funktionieren.

Zwei wichtige Einschränkungen. Erstens gehen diese Regeln beim nächsten Reboot 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, gestattet 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 Datenverkehr über einen Proxy läuft, der den angeforderten Hostnamen ausliest. Das ist für die meisten Setups mit einem einzelnen Entwickler mehr Infrastruktur, als sie benötigen. Behaupten Sie nur das, was Sie tatsächlich umgesetzt haben: eine Egress-Kontrolle auf Portebene auf einem Rechner, dessen Verlust Sie einkalkuliert haben.

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 Laptop mit angemessenen Schutzmaßnahmen tatsächlich ausreicht

Seien Sie dabei ehrlich. Eine übertriebene Darstellung der Isolation führt dazu, dass Ihnen niemand mehr zuhört.

Wenn Sie jeden Befehl prüfen, bevor er ausgeführt wird, reicht ein Laptop aus. Die Berechtigungsabfrage ist eine wirksame Kontrolle. Unter Claude Code sicher auf einem Server ausführen wird erläutert, was die einzelnen Stufen tatsächlich blockieren. Wenn Ihre Arbeit auf ein einzelnes Repository beschränkt ist 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 möglichen Zugriff kurz.

Das ändert sich, sobald Sie die Abfragen überspringen. Das ist besonders relevant, weil der Auto-Modus jetzt der Standard in Claude Code ist und eine neue Installation Sie nicht mehr fragt, bevor Dateien bearbeitet oder Befehle ausgeführt werden. Unbeaufsichtigte Ausführungen, Jobs über Nacht und alle Abläufe, bei denen Sie einen Plan genehmigen und anschließend den Rechner verlassen, entfernen die menschliche Kontrolle, die bisher für die Begrenzung gesorgt hat. Dann muss der Rechner diese Begrenzung selbst übernehmen. Dasselbe gilt für alles, was den Zugriff des Agenten erweitert, einschließlich einen Coding-Agent auf einem VPS ausführen, der gleichzeitig über mehrere Repositorys 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

Reicht ein Container als Isolation für einen Coding-Agenten aus?

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 der Prozess sonst jeweils einen Pfad zu root auf dem Host erhält. 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, sollten Sie eine echte VM oder einen separaten Server verwenden.

Benötigt der Agent sudo auf dem Server?

Nein. Die Vergabe von sudo hebt die eingerichtete Isolation wieder auf, weil root alle anderen Konten auf dem System 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, sollten Sie dem Agenten eine eigene Maschine überlassen, statt ihm root-Zugriff auf einer gemeinsam genutzten Maschine zu geben.

Wie kann der Agent in git pushen, ohne meinen SSH-Schlüssel auf dem System 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 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 jeder Maschine, die Sie mit anderen Personen gemeinsam nutzen, einen auf das Repository beschränkten Deploy Key.

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, aber nahezu keine lokale Last. Der Agent selbst setzt dennoch eine Untergrenze: Stand Oktober 20, 2026, nennen die Systemanforderungen von Claude Code 4 GB RAM als Minimum. Beginnen Sie auch für Skripting-Aufgaben mit 4 GB. Erhöhen Sie den Arbeitsspeicher auf 8 GB, wenn das Repository Container baut oder umfangreich kompiliert.

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

Bauen Sie die Maschine neu auf, sobald sich ihr Zustand nicht mehr nachvollziehbar erklären lässt. Das gilt mindestens dann, wenn ein Zugangsdaten auf dem System möglicherweise offengelegt wurde. Ein frischer Checkout zwischen Aufgaben verhindert die tägliche Zustandsabweichung. Ein Snapshot vor dem ersten Agentenlauf liefert ein sauberes Systemabbild, zu dem Sie zurückkehren können. Wenn ein Neuaufbau zu aufwendig wirkt, ist das ein Hinweis darauf, dass etwas Wichtiges auf einer Maschine liegt, die Sie als Wegwerfmaschine bezeichnet haben.