Waarom een tijdelijke VM gebruiken voor AI coding agents

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 onder uw normale gebruikersaccount op uw normale machine, is die verzameling groter dan de meeste mensen vermoeden.

Dit omvat ~/.ssh/id_ed25519, dat meestal ongecodeerd is omdat u het beu was om telkens de wachtwoordzin in te voeren. Het omvat ~/.aws/credentials en ~/.config/gh/hosts.yml, die van ontwerp uit platte tekst zijn. Het omvat elke zusterrepository onder ~/code, inclusief die met productie-verbindingsreeksen in een lokaal env-bestand. Het omvat uw shell-geschiedenis, waarin tokens staan die u ooit hebt geplakt. Het omvat ook het netwerk waarop uw laptop is aangesloten; dit is vaak een thuis- of kantoornetwerk met niet-geauthenticeerde services.

Niets hiervan vereist een kwaadwillende agent. Het vereist slechts één zelfverzekerd foutief commando. rm -rf met een niet-ingestelde variabele die expandeert naar /, een git clean -xfd in de verkeerde map, een docker system prune -af --volumes die uw lokale database meeneemt, of een behulpzame chmod -R 777 op een thuismap. Agents zijn getraind op hetzelfde internet dat deze commando's aan iedereen heeft geleerd.

Het mechanisme dat u redt, is niet het oordeelsvermogen van de agent. Het is het feit dat de machine die de schade oploopt, een machine 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 juli 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 VM. clawk is het huidige voorbeeld, en de insteek ervan is precies de stelling van dit artikel: geef coding agents een wegwerpbare Linux-VM, niet uw laptop. Per juli 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 in 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 standaard 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 het voor een taak die vier uur duurt niet uitmaakt 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 voor de agent zijn: updates, een login zonder root-rechten, SSH met uitsluitend 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 groep sudo. 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 voor de vorm. 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 privilege voor Linux-gebruikers op een VPS.

Controleer de grens voordat u deze vertrouwt. Probeer als de gebruiker agent een bestand te lezen dat toebehoort aan uw eigen account:

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

U hoort cat: /home/you/.ssh/id_ed25519: Permission denied te zien. Als u in plaats daarvan sleutelmateriaal ziet, staat uw home-directory op modus 755 en is de isolatie nog niet effectief. Herstel dit met sudo chmod 700 /home/you.

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

Bestandssysteemisolatie vormt de helft van de beveiligingsgrens. 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 uiteindelijke 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 moeten falen met curl: (7) Failed to connect to example.com port 80: Connection refused, omdat de reject-regel onmiddellijk antwoordt in plaats van de verbinding te laten hangen. Een HTTPS-verzoek aan 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 aangevraagde hostnaam leest, wat meer infrastructuur vergt dan de meeste opstellingen van 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, is een laptop prima. De toestemmingsvraag is een echte 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 impact bij een incident al beperkt. Als uw agentsessies kort en onder toezicht zijn, is het blootstellingsvenster ook klein.

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

De beslissing gaat niet echt over hoeveel u het model vertrouwt. Het gaat erom wat er naast het model staat op het moment dat 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 een pad naar root op de host geven. Een container deelt de kernel van de host, waardoor de grens zwakker is dan bij een virtual machine. Als de agent niet-vertrouwde code uitvoert die van het internet is gehaald, geef dan de voorkeur aan een echte VM of een aparte server.

Heeft de agent sudo nodig op de server?

Nee, en het verlenen van sudo tenietdoet de isolatie 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 schrijftoegang tot 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 server 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 voorbehoud is dat root op die server de geforwarde socket kan gebruiken terwijl u verbonden bent; gebruik daarom een deploy key met repository-scope op elke machine die u met anderen deelt.

Welke grootte VPS heeft een agent nodig?

Het werk van een agent bestaat voornamelijk uit het bewerken van bestanden, het uitvoeren van builds en het draaien van tests; stem de grootte van de machine daarom af op de build in plaats van op het model. Een gehost model draait op de hardware van de provider, wat netwerkverkeer toevoegt maar nauwelijks lokale belasting. Begin bij 2 GB RAM voor scriptwerk en schaal op naar 8 GB als de repository containers bouwt of aanzienlijke 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 zodra een credential op de machine mogelijk is blootgesteld. Een schone checkout tussen taken door vangt dagelijkse drift op, en een snapshot die is gemaakt vóór de eerste run van de agent biedt een schoon systeemimage om naar terug te keren. Als het opnieuw opbouwen als een zware last voelt, is dat een teken dat er iets belangrijks leeft op een machine die u als wegwerpbaar had bestempeld.