Geef AI-codeeragents een tijdelijke, wegwerpbare VM
Laat AI-codeeragents werken in een VM die u kunt vernietigen: beperk de schade, begin per taak met een schone staat en houd de VPS-kosten laag.
Waarom een tijdelijke VM beter is dan uw laptop
Geef een codeeragent een tijdelijke VM. Het ergste wat de agent kan doen, is een machine vernietigen die u in tien minuten opnieuw kunt opbouwen. De agent krijgt nog steeds root, installeert nog steeds pakketten en voert nog steeds de testsuite uit zonder voor elke stap toestemming te vragen. Het verschil is waar de schade terechtkomt. Op een laptop deelt de agent een homedirectory met uw SSH-sleutels, uw browserprofiel, uw .env-bestanden en elke andere repository die u ooit hebt gekloond. Op een wegwerpserver heeft de agent een shell, een checkout en verder niets dat de moeite waard is om te stelen.
Dat is het volledige argument. Het gaat om asymmetrie, niet om waarschijnlijkheid. Een zorgvuldige agent op een zorgvuldige laptop werkt bijna altijd goed. De ene keer dat dit niet zo is, bestaat de schade niet uit een slechte commit. U moet dan een backup terugzetten, als u die hebt.
Benoem de impact voordat u erover discussieert
De impact omvat de verzameling zaken die een proces kan bereiken. Voor een agent die als uw normale gebruiker op uw normale machine draait, is die verzameling groter dan de meeste mensen denken.
Daartoe behoort ~/.ssh/id_ed25519, dat meestal niet versleuteld is omdat u het invoeren van de wachtwoordzin zat was. Ook ~/.aws/credentials en ~/.config/gh/hosts.yml behoren ertoe; deze zijn bewust als platte tekst ontworpen. Daarnaast omvat de verzameling elke naastgelegen repository onder ~/code, inclusief repositories met productie-connection strings in een lokaal env-bestand. Ook uw shellgeschiedenis valt hieronder, omdat daarin tokens staan die u ooit hebt geplakt. Ten slotte omvat de verzameling het netwerk waarop uw laptop is aangesloten. Dat is vaak een thuis- of kantoornetwerk met niet-geauthenticeerde services.
Daarvoor is geen kwaadwillende agent nodig. Eén zelfverzekerd uitgevoerd, verkeerd commando volstaat. rm -rf waarbij een niet-ingestelde variabele wordt uitgebreid naar /, een git clean -xfd in de verkeerde directory, een docker system prune -af --volumes die uw lokale database verwijdert, of een behulpzame chmod -R 777 in een homedirectory. Agents worden getraind op hetzelfde internet waarop iedereen deze commando's heeft geleerd.
Wat u beschermt, is niet het beoordelingsvermogen van de agent. Het is het feit dat de machine waarop de schade ontstaat een machine is die u bereid was te verliezen.
De kostenberekening is saai, en dat is precies de bedoeling
Een kleine VPS kost enkele dollars per maand. Het herstellen van een laptop van een ontwikkelaar kost een dag. Dat is het gunstige geval, waarin u het probleem direct opmerkt en een back-up had.
Bereken dit met uw eigen cijfers. Neem uw uurtarief en vermenigvuldig dit met het aantal uren dat nodig is om een besturingssysteem opnieuw te installeren, een persoonlijke homedirectory te herstellen, een SSH-sleutel te vervangen, een persoonlijk toegangstoken te vervangen en twintig repositories opnieuw te klonen. Vergelijk dat met twaalf maanden van de kleinste server die uw provider aanbiedt. Het omslagpunt ligt op minder dan één incident per meerdere jaren. Het incident hoeft niet catastrofaal te zijn om dat omslagpunt te overschrijden. Eén verloren middag door een beschadigde lokale omgeving is al voldoende om de kosten van een jaar te dekken.
De tweede helft van de berekening betreft snapshots. Met een snapshot vóór een risicovolle uitvoering verandert een slechte uitkomst van "herstel mijn volledige werkomgeving" in "zet de vorige toestand terug en probeer een andere prompt". Die optie bestaat niet op de laptop waarop u dit typt. U kunt geen snapshot van een machine maken terwijl u die als werkplek gebruikt.
Het landschap in juli 2026
Er zijn drie eerlijke antwoorden op de vraag "waar moet de agent draaien". Ze vormen steeds een afweging tussen dezelfde twee factoren: hoe sterk de grens is en hoeveel configuratie u accepteert.
Een lokale micro-VM. Tools in deze categorie starten een echte virtuele machine op uw eigen hardware, koppelen uw repository daarin aan en geven de agent daarin root-toegang. clawk is momenteel het voorbeeld. De kern van dit bericht is precies dit: geef coding agents een wegwerpbare Linux-VM, niet uw laptop. In juli 2026 is deze gericht op macOS 14 en hoger op Apple silicon, met experimentele Linux-ondersteuning via Firecracker. De installatie verloopt met brew install clawkwork/tap/clawk. Voer clawk uit in een repository om de sandbox te starten en een agent eraan te koppelen, clawk down om deze te stoppen en clawk destroy om deze te verwijderen. De grens wordt gevormd door een hypervisor en is daarom sterk. De beperking is dat de VM op de machine staat die u bij u draagt. De VM gebruikt daar geheugen en stopt wanneer u de laptop sluit.
Een container. Docker is het antwoord dat de meeste mensen al geïnstalleerd hebben en het is daadwerkelijk nuttig.
docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash--rm verwijdert de container bij het afsluiten en --network none geeft deze helemaal geen netwerktoegang. Dat is een goede standaardinstelling voor een build of testrun. Wees duidelijk over wat dit niet doet: een container deelt de kernel van de host. Een kernelbug kan daardoor een uitweg bieden. De grens verdwijnt zodra u --privileged toevoegt of /var/run/docker.sock koppelt, zodat de agent "Docker kan gebruiken". De Docker-socket in een container koppelen staat gelijk aan de container root-toegang op de host geven.
Een gewone VPS die u opnieuw kunt opbouwen. U hebt geen nieuwe tool nodig, er is een echte kernelgrens, de provider biedt snapshots en de VPS blijft draaien wanneer u uw laptop uitschakelt. Dit is het patroon dat de rest van deze handleiding beschrijft. Het is ook het patroon dat lange runs van agents aankan, omdat een taak die vier uur duurt er niet van afhankelijk is of u naar huis bent gegaan.
Het VPS-patroon: geef de agent een eigen gebruiker
Begin met een geharde server. De eerste tien minuten op een nieuwe VPS behandelen de onderdelen die niet specifiek zijn voor agents: updates, een niet-root-login, SSH met alleen sleutels en een firewall.
Maak vervolgens een account dat alleen voor de agent bestaat. Zo kan een fout binnen dit account niets anders op de server raken.
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. U krijgt toegang tot het account met sudo -u agent of een SSH-sleutel. Let erop dat agent bewust geen lid is van de groep sudo. Een agent met sudo heeft root-toegang. root kan de bestanden van alle andere gebruikers lezen. Daardoor is de scheiding die u zojuist hebt aangebracht slechts schijn. Als de agent daadwerkelijk pakketten moet installeren, is dat een argument voor een volledige server die de agent beheert, niet om sudo toe te kennen op een gedeelde server. De algemene regels staan in minimale rechten voor Linux-gebruikers op een VPS.
Controleer de grens voordat u de configuratie vertrouwt. Probeer als gebruiker agent een bestand te lezen dat bij uw eigen account hoort:
sudo -u agent cat /home/you/.ssh/id_ed25519U hoort cat: /home/you/.ssh/id_ed25519: Permission denied te zien. Als u in plaats daarvan sleutelgegevens ziet, heeft uw home-directory mode 755 en is de isolatie nog niet daadwerkelijk ingesteld. Herstel dit met sudo chmod 700 /home/you.
Houd de referenties volledig buiten de machine
Het doel van een wegwerpmachine gaat verloren als u uw productiereferenties erop kopieert. De regel is eenvoudig: op die machine mag niets staan waarvan u het problematisch zou vinden om het deze middag te vervangen.
Gebruik voor git het doorsturen van uw SSH-agent in plaats van een sleutel te kopiëren. De privésleutel blijft op uw laptop en alleen verzoeken om handtekeningen gaan via de verbinding.
ssh -A agent@203.0.113.10
ssh -T git@github.comDe tweede opdracht moet Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. beantwoorden. Daarmee toont u aan dat git push werkt zonder dat er een sleutelbestand op de server aanwezig is. Voer daarna ls -la ~/.ssh uit op de machine en controleer of er geen privésleutel op staat.
Het doorsturen van de agent heeft één belangrijk aandachtspunt. Zolang u verbonden bent, kan iedereen met root op die server de doorgestuurde socket gebruiken om zich als u te authenticeren. Op een server waarvan u de enige andere gebruiker bent, is dat een aanvaardbare afweging. Op een gedeelde machine is dat niet het geval. Daar is een deploy key die tot één repository is beperkt een betere oplossing. De verschillende opties worden besproken in Basisprincipes van SSH-sleutelbeheer.
Geef de agent voor API-sleutels een eigen sleutel met een eigen bestedingslimiet. Sla deze op in een bestand dat eigendom is van de gebruiker agent en de modus 600 heeft. Wanneer de machine wordt vernietigd, trekt u die sleutel in. Dan hoeft u zich niet af te vragen of de sleutel is uitgelekt. Door de modelkosten per sleutel zichtbaar te houden, blijven ook de bedragen in Kostenbeheersing voor AI-agents op een VPS voorspelbaar.
Beperk wat de agent op het netwerk kan bereiken
Bestandssysteemisolatie vormt de ene helft van de afscherming. De andere helft is uitgaand verkeer: waarmee het proces verbinding mag maken. Linux kan uitgaand verkeer filteren op basis van de gebruiker die het proces heeft gestart. Dat past precies bij dit patroon.
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 REJECTDe regels worden in volgorde gelezen. De laatste REJECT vangt daarom alles op wat door de eerdere regels niet is toegestaan. Test dit als de agent:
sudo -u agent curl -sS -m 5 http://example.comDit moet mislukken met curl: (7) Failed to connect to example.com port 80: Connection refused, omdat de reject-regel direct antwoord geeft in plaats van de verbinding te laten blijven wachten. Een HTTPS-verzoek naar dezelfde host moet nog steeds slagen.
Er zijn twee belangrijke beperkingen. Ten eerste gaan deze regels verloren bij de volgende reboot, 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 internet toe. Dat is voldoende om de model-API te bereiken, maar ook om een pastebin te bereiken. Een echte domeinallowlist vereist dat het verkeer via een proxy loopt die de aangevraagde hostnaam leest. Dat vereist meer infrastructuur dan de meeste omgevingen met één ontwikkelaar willen beheren. Claim alleen wat u daadwerkelijk hebt: egresscontrole op poortniveau, op een machine die u bereid was te verliezen.
Een schone toestand tussen taken herstellen
Een schone toestand per taak is een onderschat voordeel. Een agent die de vorige ticket drie uur heeft uitgevoerd, heeft geïnstalleerde pakketten, gedeeltelijk toegepaste migraties, een verouderde node_modules en een git-working tree met niet-gecontroleerde wijzigingen achtergelaten. De volgende taak neemt dit allemaal over. U besteedt vervolgens uw reviewbudget aan het bepalen welke rommel bij welke uitvoering hoort.
De eenvoudige optie is een nieuwe checkout per taak.
sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'De grondigere optie is een provider-snapshot die u eenmaal maakt, direct nadat de machine is ingesteld en voordat een agent deze heeft gebruikt. Als u die snapshot terugzet, keert het hele systeem, inclusief de pakketten, terug naar een bekende toestand. De meeste providers bieden dit in het configuratiescherm of via een API aan, en niet als een opdracht op de machine. De exacte stappen zijn daarom afhankelijk van uw provider. De juiste werkwijze is om de snapshot te maken zolang de machine nog niets bijzonders doet.
Bewaar alles wat u nodig hebt buiten de wegwerpbare machine. Dat betekent meestal dat u branches pusht in plaats van ze lokaal te bewaren. Als de machine toch iets bevat dat u zou missen, maakt u daarvan op de juiste manier een back-up met restic-back-ups op een VPS. Een machine die u kunt vernietigen, is alleen nuttig als die vernietiging daadwerkelijk zonder problemen verloopt.
Als u meerdere geïsoleerde omgevingen wilt zonder voor meerdere servers te betalen, kan één grotere VPS rechtstreeks guest-VM's hosten. Geneste virtualisatie op een VPS beschrijft hoe dit werkt en hoe u controleert of uw provider dit toestaat.
Wanneer een laptop met de nodige zorg echt volstaat
Wees hier eerlijk over. Als u isolatie overdreven voorstelt, luisteren mensen niet meer.
Als u elke opdracht controleert voordat deze wordt uitgevoerd, volstaat een laptop. De toestemmingsprompt is een echte beveiligingsmaatregel. In Claude Code veilig uitvoeren op een server wordt uitgelegd wat elk niveau daadwerkelijk blokkeert. Als uw werk uit één repository bestaat en er nergens op de computer productiereferenties staan, is de mogelijke impact al beperkt. Als uw agentsessies kort zijn en onder toezicht plaatsvinden, is de blootstellingsperiode ook kort.
Het antwoord verandert zodra u de prompts overslaat. Onbeheerde uitvoeringen, taken die 's nachts worden uitgevoerd en workflows waarbij u een plan goedkeurt en daarna wegloopt, verwijderen allemaal de menselijke controle die voor de beperking zorgde. Vanaf dat moment moet de computer dit zelf doen. Hetzelfde geldt voor alles wat het bereik van de agent vergroot, waaronder een codeagent uitvoeren op een VPS voor meerdere repositories tegelijk.
De beslissing gaat niet echt over hoeveel vertrouwen u in het model hebt. Het gaat erom wat zich naast het model bevindt wanneer het model een fout maakt.
FAQ
Biedt een container voldoende isolatie voor een coding agent?
Voor de meeste werkzaamheden wel, onder twee voorwaarden. De container mag niet met --privileged worden uitgevoerd en /var/run/docker.sock mag er niet in worden gemount, omdat beide het proces een pad naar root op de host geven. Een container deelt de kernel van de host. De grens is daarom zwakker dan bij een virtuele machine. Als de agent niet-vertrouwde code uitvoert die van internet is opgehaald, geeft u de voorkeur aan een echte VM of een afzonderlijke server.
Heeft de agent sudo nodig op de server?
Nee. Als u sudo geeft, maakt u de opgebouwde isolatie ongedaan, omdat root alle andere accounts op het systeem kan lezen. Maak de agentgebruiker aan zonder sudo en geef deze alleen schrijfrechten voor de eigen werkdirectory. Als voor de taak daadwerkelijk pakketinstallatie nodig is, geeft u de agent een volledige machine die deze zelf beheert, in plaats van root op een machine die deze met anderen deelt.
Hoe laat ik de agent naar git pushen zonder mijn SSH-sleutel op de machine te plaatsen?
Forward uw SSH-agent met ssh -A wanneer u verbinding maakt. Verzoeken om handtekeningen gaan via de verbinding, terwijl de private key op uw laptop blijft. Daardoor verzorgt ssh -T git@github.com de authenticatie en werkt git push zonder private key op de server. Het aandachtspunt is dat root op die server de doorgestuurde socket kan gebruiken zolang 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?
Werk van een agent bestaat voornamelijk uit bestanden bewerken, builds uitvoeren en tests uitvoeren. Stem de grootte van de machine daarom af op de build en niet op het model. Een gehost model draait op de hardware van de provider. Dat veroorzaakt netwerkverkeer en vrijwel geen lokale belasting. Begin met 2 GB RAM voor scriptwerk en ga over naar 8 GB als de repository containers bouwt of omvangrijke code compileert.
Hoe vaak moet ik de machine vernietigen en opnieuw opbouwen?
Bouw de machine opnieuw op zodra de status niet meer verklaarbaar is en in ieder geval wanneer een credential op de machine mogelijk is blootgesteld. Een nieuwe checkout tussen taken beperkt dagelijkse afwijkingen. Een snapshot die u vóór de eerste agent-run maakt, geeft u een schone systeemimage om naar terug te keren. Als opnieuw opbouwen duur aanvoelt, wijst dat erop dat iets belangrijks staat op een machine die u als wegwerpbaar had aangemerkt.