Coding agents veilig draaien in een tijdelijke VM

Waarom een tijdelijke VM beter is dan uw laptop

Geef een coding agent een tijdelijke VM en het ergste wat deze kan doen, is een machine vernietigen die u in tien minuten opnieuw kunt opbouwen. De agent krijgt nog steeds root-toegang, installeert pakketten en voert de testsuite uit zonder voor elke stap toestemming te vragen. Het verschil zit in de locatie van de schade. Op een laptop deelt de agent een home-directory met uw SSH-keys, uw browserprofiel, uw .env-bestanden en elke andere repository die u ooit heeft gekloond. Op een wegwerpserver heeft de agent een shell, een checkout en niets anders dat de moeite waard is om te stelen.

Dat is het hele argument, en het is een argument over asymmetrie in plaats van waarschijnlijkheid. Een zorgvuldige agent op een zorgvuldige laptop gaat bijna altijd goed. De ene keer dat het misgaat, zijn de kosten niet een slechte commit. Het is een herstel vanaf een back-up, mits u die heeft.

Definieer de blast radius voordat u erover discussieert

De blast radius is de verzameling zaken die een proces kan bereiken. Voor een agent die draait als uw normale gebruiker op uw normale machine, is die verzameling groter dan de meeste mensen denken.

Dit omvat ~/.ssh/id_ed25519, dat meestal ongecodeerd is omdat u het zat was om steeds de wachtwoordzin in te voeren. Het omvat ~/.aws/credentials en ~/.config/gh/hosts.yml, die ontworpen zijn als platte tekst. Het omvat elke zuster-repository onder ~/code, inclusief die met productie-verbindingsreeksen in een lokaal env-bestand. Het omvat uw shell-geschiedenis, die tokens bevat die u ooit hebt geplakt. Het omvat ook het netwerk waarop uw laptop zich bevindt, wat vaak een thuis- of kantoornetwerk is met niet-geauthenticeerde services.

Niets daarvan vereist een kwaadwillende agent. Het vereist één zelfverzekerd foutief commando. rm -rf "$BUILD_DIR"/* met BUILD_DIR niet ingesteld, wat expandeert naar /* en de standaard weigering van GNU rm om / zelf te verwijderen omzeilt, een git clean -xfd in de verkeerde map, een docker system prune -af --volumes die uw lokale database meeneemt, een behulpzame chmod -R 777 op een thuismap. Agents zijn getraind op hetzelfde internet dat die commando's aan iedereen heeft geleerd.

Het mechanisme dat u redt, is niet het oordeelsvermogen van de agent. Het is dat de machine die de schade oploopt, er een is die u bereid was te verliezen.

De kostenberekening is saai, en dat is precies het punt

Een kleine VPS kost een paar dollar per maand. Het herstellen van een laptop van een ontwikkelaar kost een dag, en dat is nog het gunstige scenario waarbij u het direct opmerkt en een back-up heeft.

Maak de berekening met uw eigen cijfers. Neem uw uurtarief en vermenigvuldig dit met het aantal uren dat nodig is om een besturingssysteem opnieuw te installeren, een home-directory te herstellen, een SSH key te roteren, een personal access token te roteren en twintig repositories opnieuw te clonen. Vergelijk dit met twaalf maanden van de kleinste server die uw provider aanbiedt. Het omslagpunt ligt onder de één incident per paar jaar, en het incident hoeft niet catastrofaal te zijn om dit punt te bereiken. Eén middag die verloren gaat aan een corrupte lokale omgeving betaalt de kosten voor het hele jaar al terug.

Het tweede deel van de berekening betreft snapshots. Een snapshot voor een risicovolle actie verandert een slecht resultaat van "mijn leven herstellen" in "terugdraaien en een andere prompt proberen". Die optie bestaat niet op de laptop waar u nu op typt, omdat u geen snapshot kunt maken van een machine terwijl u deze als uw werkstation gebruikt.

Het landschap per oktober 2026

Er zijn drie eerlijke antwoorden op de vraag "waar moet de agent draaien", en deze maken een afweging tussen dezelfde twee factoren: hoe sterk de grens is en hoeveel configuratiewerk u accepteert.

Een lokale micro VM. Tools in deze categorie starten een echte virtuele machine op uw eigen hardware, koppelen uw repository hierin en geven de agent root-rechten binnen de omgeving. clawk is het huidige voorbeeld, en de insteek hiervan is precies de stelling van dit artikel: geef coding agents een wegwerpbare Linux VM, niet uw laptop. Per oktober 2026 richt het zich op macOS 14 en nieuwer op Apple silicon, met experimentele Linux-ondersteuning via Firecracker, en de installatie verloopt via brew install clawkwork/tap/clawk. U voert clawk uit binnen een repository om de sandbox op te starten en een agent te koppelen, clawk down om deze te stoppen, en clawk destroy om deze te verwijderen. De grens is een hypervisor, wat een sterke beveiliging biedt. De beperking is dat de VM op de machine draait die u bij u draagt; hij concurreert dus om uw geheugen en stopt zodra u de laptop dichtklapt.

Een container. Docker is de oplossing die de meeste mensen al geïnstalleerd hebben, en het is oprecht nuttig.

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

--rm verwijdert de container bij afsluiten en --network none geeft deze helemaal geen netwerktoegang, wat een goede standaardinstelling is voor een build of een testrun. Wees u bewust van wat dit niet doet: een container deelt de kernel van de host, dus een kernel-bug is een uitweg, en de grens verdwijnt zodra u --privileged toevoegt of /var/run/docker.sock koppelt zodat de agent "Docker kan gebruiken". Het koppelen van de Docker-socket aan een container staat gelijk aan het geven van root-rechten op de host aan die container.

Een eenvoudige VPS die u opnieuw kunt opbouwen. Geen nieuwe tool, een echte kernel-grens, snapshots van de provider, en de machine blijft draaien wanneer u uw laptop afsluit. Dit is het patroon dat de rest van deze handleiding beschrijft, en het is de methode die lange agent-taken overleeft, omdat een taak die vier uur duurt niet merkt dat u naar huis bent gegaan.

Het VPS-patroon: geef de agent een eigen gebruiker

Begin met een beveiligde server. De eerste tien minuten op een nieuwe VPS behandelen de onderdelen die niet specifiek zijn voor de agent: updates, een login zonder root-rechten, SSH-toegang uitsluitend via sleutels en een firewall.

Maak vervolgens een account aan dat uitsluitend voor de agent bestaat, zodat een fout binnen dit account geen invloed heeft op de rest van de server.

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 betekent dat er geen wachtwoord is om te raden en u bereikt het account met sudo -u agent of een SSH-sleutel. Let op: agent zit bewust niet in de sudo-groep. Een agent met sudo heeft root-rechten en root kan de bestanden van elke andere gebruiker lezen; de scheiding die u zojuist heeft aangebracht is dan slechts schijn. Als de agent daadwerkelijk pakketten moet installeren, is dat een argument voor een eigen server, niet voor het toekennen van sudo op een gedeelde server. De algemene regels staan in minste privileges voor Linux-gebruikers op een VPS.

Controleer de grens voordat u deze vertrouwt. Probeer als de agent-gebruiker de home-directory van uw eigen account weer te geven:

sudo -u agent ls /home/you

U hoort ls: cannot open directory '/home/you': Permission denied te zien. Als u in plaats daarvan een lijst met bestanden ziet, is uw home-directory leesbaar voor andere gebruikers. De agent kan dan alles lezen wat niet afzonderlijk is beveiligd, zoals een voor iedereen leesbaar .env-bestand. Herstel dit met sudo chmod 700 /home/you. Uw private SSH-sleutel wordt niet door deze test beschermd: ssh negeert een private sleutelbestand dat toegankelijk is voor andere gebruikers. Elke sleutel die voor u werkt, is dus al onleesbaar voor agent, ongeacht de rechten van uw home-directory.

Houd inloggegevens volledig buiten de machine

Het nut van een tijdelijke machine vervalt als u uw productiegeheimen daarop kopieert. De regel is simpel: niets op die machine mag een inloggegeven zijn waarvan u het erg zou vinden om het vanmiddag nog te moeten roteren.

Voor git geldt: stuur uw SSH-agent door in plaats van een sleutel te kopiëren. De privésleutel blijft op uw laptop en alleen verzoeken voor ondertekening gaan over de verbinding.

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

Het tweede commando zou Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. moeten antwoorden. Dat bewijst dat git push werkt zonder dat er een sleutelbestand op de server aanwezig is. Voer daarna ls -la ~/.ssh uit op de machine en bevestig dat er geen privésleutel in staat.

Agent forwarding heeft één belangrijk voorbehoud, dus wees daar duidelijk over: zolang u verbonden bent, kan iedereen met root-rechten op die server de doorgestuurde socket gebruiken om zich als u te authenticeren. Op een server waar u de enige andere gebruiker bent, is dat een acceptabele afweging. Op een gedeelde machine is dat niet zo, en is een deploy key die beperkt is tot één repository een betere oplossing. De keuzes worden behandeld in SSH-sleutelbeheer basisprincipes.

Geef voor API-sleutels de agent een eigen sleutel met een eigen bestedingslimiet, opgeslagen in een bestand dat eigendom is van de gebruiker agent met modus 600. Wanneer de machine wordt vernietigd, trekt u die sleutel in in plaats van u af te vragen of deze is gelekt. Het inzichtelijk houden van de modelkosten per sleutel is ook de manier waarop de cijfers in AI-agent kostenbeheersing op een VPS voorspelbaar blijven.

Beperk de netwerktoegang van de agent

Bestandsysteemisolatie is slechts de helft van de beveiliging. De andere helft is uitgaand verkeer: met welke bestemmingen het proces mag communiceren. Linux kan uitgaand verkeer filteren op basis van de gebruiker die het heeft gegenereerd, wat precies in dit patroon past.

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

De regels worden in volgorde gelezen, dus de laatste REJECT vangt alles op wat de voorgaande regels niet hebben toegestaan. Test dit als de agent:

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

Dit zou direct moeten falen met een curl: (7) Failed to connect to example.com-fout, gevolgd door een melding die afhankelijk is van uw versie van curl, omdat de reject-regel onmiddellijk antwoordt in plaats van de verbinding te laten hangen. Een HTTPS-verzoek naar dezelfde host zou nog steeds moeten slagen.

Twee eerlijke beperkingen. Ten eerste gaan deze regels verloren bij de volgende herstart tenzij u ze opslaat met sudo apt install -y iptables-persistent en vervolgens sudo netfilter-persistent save. Ten tweede filtert dit poorten en adressen, geen namen. Een regel die poort 443 toestaat, staat elke HTTPS-host op het internet toe; dit is voldoende om de model-API te bereiken, maar ook voldoende om een pastebin te bereiken. Een echte domein-allowlist vereist dat het verkeer door een proxy gaat die de opgevraagde hostnaam leest, wat meer infrastructuur vergt dan de meeste opstellingen voor individuele ontwikkelaars wensen. Claim alleen wat u heeft: uitgaande controle op poortniveau, op een machine die u bereid was te verliezen.

Terugkeren naar een schone status tussen taken

Een schone status per taak is een onderschat voordeel. Een agent die drie uur aan het vorige ticket heeft gewerkt, laat geïnstalleerde pakketten, half uitgevoerde migraties, een verouderde node_modules en een git-werkmap met niet-gecontroleerde wijzigingen achter. De volgende taak erft dit allemaal, waardoor u uw tijd voor revisie kwijt bent aan het uitzoeken welke rommel bij welke run hoort. Een beperktere agent laat sowieso minder achter. Door een wegwerpmachine te combineren met een vaardigheid die de agent dwingt tot de kleinst mogelijke werkende wijziging, blijven zowel de diff als de achtergebleven status klein genoeg om te controleren.

De goedkope versie is een verse checkout per taak.

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

De krachtigere versie is een provider-snapshot dat één keer wordt gemaakt, direct nadat de machine is opgezet en voordat een agent deze heeft aangeraakt. Het herstellen van die snapshot brengt het hele systeem, inclusief pakketten, terug naar een bekende status. De meeste providers bieden dit aan in het configuratiescherm of via een API, in plaats van als een commando op de machine zelf; de exacte stappen zijn dus afhankelijk van uw provider. De discipline is om het snapshot te maken terwijl de machine nog in een standaardtoestand verkeert.

Houd alles wat belangrijk is buiten de wegwerpmachine. Dit betekent in de praktijk: branches pushen in plaats van ze lokaal bewaren. Als de machine toch iets bevat wat u zou missen, maak dan een goede back-up met restic-back-ups op een VPS. Een machine die u kunt vernietigen is alleen nuttig als het vernietigen ervan daadwerkelijk zonder gevolgen is.

Als u meerdere geïsoleerde omgevingen wilt zonder voor meerdere servers te betalen, kan één grotere VPS direct gast-VM's hosten. Geneste virtualisatie op een VPS beschrijft hoe dit werkt, inclusief hoe u controleert of uw provider dit toestaat. Isolatie werkt hier twee kanten op; als u liever heeft dat twee agents op dezelfde machine samenwerken in plaats van volledig van elkaar afgeschermd te zijn, kan één Claude Code-sessie tekst direct naar een andere sturen in plaats van elke overdracht via u te laten verlopen.

Wanneer een laptop met de juiste zorg volstaat

Wees hier eerlijk over, want het overschatten van isolatie zorgt ervoor dat mensen niet meer luisteren.

Als u elk commando controleert voordat het wordt uitgevoerd, volstaat een laptop. De toestemmingsvraag is een effectieve controle en veilig Claude Code draaien op een server legt uit wat elk niveau daarvan daadwerkelijk blokkeert. Als uw werk uit één repository bestaat zonder productie-inloggegevens op de machine, is de mogelijke schade al beperkt. Als uw agentsessies kort en onder toezicht zijn, is het blootstellingsvenster eveneens kort.

Het antwoord verandert zodra u de prompts overslaat. Dit is belangrijk om over na te denken nu auto mode de standaard is in Claude Code en een nieuwe installatie niet langer om toestemming vraagt voordat bestanden worden bewerkt of commando's worden uitgevoerd. Onbeheerde runs, taken die 's nachts draaien en elke workflow waarbij u een plan goedkeurt en vervolgens wegloopt, verwijderen de menselijke controle die voorheen als beveiliging diende. Op dat moment moet de machine die taak overnemen. Hetzelfde geldt voor alles wat het bereik van de agent vergroot, inclusief het draaien van een coding agent op een VPS voor meerdere repositories tegelijk.

De beslissing gaat in feite niet over hoeveel u het model vertrouwt. Het gaat erom wat er naast het model staat wanneer het model een fout maakt.

FAQ

Is een container voldoende isolatie voor een coding agent?

Voor het meeste werk wel, onder twee voorwaarden. De container mag niet draaien met --privileged, en /var/run/docker.sock mag niet in de container gemount zijn, omdat beide opties het proces toegang geven tot root op de host. Een container deelt de kernel van de host, waardoor de grens zwakker is dan bij een virtuele machine. Als de agent niet-vertrouwde code van het internet uitvoert, heeft een echte VM of een aparte server de voorkeur.

Heeft de agent sudo nodig op de server?

Nee, en het verlenen van sudo-rechten heft de isolatie op die u heeft opgebouwd, omdat root elk ander account op de machine kan inzien. Maak de agent-gebruiker aan zonder sudo en geef deze alleen schrijfrechten voor de eigen werkmap. Als de taak echt pakketinstallaties vereist, geef de agent dan een eigen machine in plaats van root-rechten op een gedeelde machine.

Hoe laat ik de agent pushen naar git zonder mijn SSH-key op de machine te plaatsen?

Forward uw SSH-agent met ssh -A wanneer u verbinding maakt. Ondertekeningsverzoeken verlopen via de verbinding terwijl de private key op uw laptop blijft, waardoor ssh -T git@github.com authenticeert en git push werkt zonder dat er een private key op de server staat. Het nadeel is dat root op die server de geforwarde socket kan gebruiken terwijl u verbonden bent; gebruik daarom een repository-scoped deploy key op elke machine die u met anderen deelt.

Welke grootte VPS heeft een agent nodig?

Het werk van een agent bestaat grotendeels uit het bewerken van bestanden, het uitvoeren van builds en het draaien van tests; kies de grootte van de machine daarom op basis van de build en niet op basis van het model. Een gehost model draait op de hardware van de provider, wat netwerkverkeer toevoegt maar nauwelijks lokale belasting. De agent zelf stelt een ondergrens: per 20 oktober 2026 vermelden de systeemvereisten van Claude Code 4 GB RAM als minimum. Begin bij 4 GB, zelfs voor scriptwerk, en stap over naar 8 GB als de repository containers bouwt of substantiële compilaties uitvoert.

Hoe vaak moet ik de machine vernietigen en opnieuw opbouwen?

Bouw de machine opnieuw op wanneer de status niet langer verklaarbaar is, en minimaal wanneer een credential op de machine mogelijk is blootgesteld. Een verse checkout tussen taken door vangt dagelijkse afwijkingen op, en een snapshot die vóór de eerste agent-run is gemaakt, geeft u een schoon systeemimage om naar terug te keren. Als het opnieuw opbouwen als een zware taak voelt, is dat een teken dat er iets belangrijks leeft op een machine die u als wegwerpbaar bestempelde.