Donner une VM jetable à un agent de code

Pourquoi une VM jetable est préférable à votre ordinateur portable

Donnez à un agent de programmation une VM jetable. Dans le pire des cas, il détruira une machine que vous pouvez reconstruire en dix minutes. L’agent dispose toujours des droits root, installe toujours des paquets et exécute toujours la suite de tests sans demander votre autorisation à chaque étape. La différence tient à l’endroit où les dégâts se produisent. Sur un ordinateur portable, l’agent partage un répertoire personnel avec vos clés SSH, votre profil de navigateur, vos fichiers .env et tous les autres dépôts que vous avez déjà clonés. Sur un serveur temporaire, il dispose d’un shell, d’un checkout et de rien d’autre qui vaille la peine d’être récupéré.

C’est tout l’argument. Il porte sur l’asymétrie, pas sur la probabilité. Un agent prudent sur un ordinateur portable bien protégé fonctionne correctement presque à chaque fois. La seule fois où ce n’est pas le cas, le coût ne se limite pas à un mauvais commit. Vous devez restaurer une sauvegarde, si vous en avez une.

Définissez le rayon d’impact avant d’en débattre

Le rayon d’impact désigne l’ensemble des éléments qu’un processus peut atteindre. Pour un agent exécuté avec votre utilisateur habituel sur votre machine habituelle, cet ensemble est plus vaste que la plupart des gens ne l’imaginent.

Il comprend ~/.ssh/id_ed25519, qui est généralement non chiffrée, parce que vous en avez eu assez de saisir la passphrase. Il comprend ~/.aws/credentials et ~/.config/gh/hosts.yml, qui sont en texte clair par conception. Il comprend tous les dépôts frères sous ~/code, y compris ceux qui contiennent des chaînes de connexion de production dans un fichier env local. Il comprend aussi l’historique de votre shell, qui contient des tokens que vous avez collés une fois. Il inclut également le réseau auquel votre ordinateur portable est connecté, souvent un réseau domestique ou professionnel qui expose des services sans authentification.

Rien de tout cela ne nécessite un agent malveillant. Une seule commande exécutée avec assurance mais incorrecte suffit. rm -rf avec une variable non définie qui se développe en /, un git clean -xfd dans le mauvais répertoire, un docker system prune -af --volumes qui emporte votre base de données locale, un chmod -R 777 lancé par commodité sur un répertoire personnel. Les agents sont entraînés sur le même internet que celui qui a appris ces commandes à tous les autres.

Le mécanisme qui vous protège n’est pas le jugement de l’agent. C’est le fait que la machine susceptible de subir les dommages est une machine que vous étiez prêt à perdre.

Le calcul des coûts est ennuyeux, et c’est justement le but

Un petit VPS coûte quelques dollars par mois. Récupérer un laptop de développement prend une journée, dans le meilleur des cas, lorsque vous le remarquez immédiatement et que vous aviez une sauvegarde.

Faites le calcul avec vos propres chiffres. Prenez votre tarif horaire et multipliez-le par le nombre d’heures nécessaires pour réinstaller un système d’exploitation, restaurer un répertoire personnel, renouveler une clé SSH, renouveler un personal access token et cloner à nouveau vingt dépôts. Comparez le résultat au coût de douze mois du plus petit serveur proposé par votre fournisseur. Le seuil de rentabilité est atteint avec moins d’un incident tous les quelques années. L’incident n’a pas besoin d’être catastrophique pour dépasser ce seuil. Un simple après-midi perdu à cause d’un environnement local corrompu suffit déjà à financer l’année.

La deuxième partie du calcul concerne les snapshots. Un snapshot pris avant une opération risquée transforme un mauvais résultat de « restaurer toute ma configuration » en « revenir en arrière et essayer un autre prompt ». Cette possibilité n’existe pas sur le laptop que vous utilisez pour lire ce texte, car vous ne pouvez pas créer un snapshot d’une machine qui vous sert de poste de travail.

Le paysage en juillet 2026

Il existe trois réponses honnêtes à la question « où l’agent doit-il s’exécuter ? ». Elles présentent le même compromis entre deux éléments : la solidité de la séparation et la quantité de configuration que vous acceptez.

Une micro-VM locale. Les outils de cette catégorie démarrent une véritable machine virtuelle sur votre propre matériel, y montent votre dépôt et donnent à l’agent les droits root à l’intérieur. clawk en est l’exemple actuel. Son principe correspond exactement à la thèse de cet article : fournir aux agents de programmation une VM Linux jetable, et non votre ordinateur portable. En juillet 2026, cet outil cible macOS 14 et les versions ultérieures sur Apple silicon, avec une prise en charge expérimentale de Linux via Firecracker. Il s’installe avec brew install clawkwork/tap/clawk. Exécutez clawk dans un dépôt pour démarrer le sandbox et y connecter un agent, clawk down pour l’arrêter et clawk destroy pour le supprimer. La séparation repose sur un hyperviseur, ce qui fournit une isolation forte. La limite est que la VM s’exécute sur la machine que vous transportez, qu’elle utilise votre mémoire et qu’elle s’arrête lorsque vous fermez le capot.

Un conteneur. Docker est la solution que la plupart des utilisateurs ont déjà installée, et elle est réellement utile.

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

--rm supprime le conteneur à l’arrêt, et --network none lui interdit tout accès réseau. C’est une bonne configuration par défaut pour une compilation ou une exécution de tests. Il faut toutefois comprendre ce que cette solution ne fait pas : un conteneur partage le kernel de l’hôte, donc une faille du kernel peut permettre d’en sortir. La séparation disparaît également dès que vous ajoutez --privileged ou montez /var/run/docker.sock afin que l’agent puisse « utiliser Docker ». Monter le socket Docker dans un conteneur revient à donner à ce conteneur les droits root sur l’hôte.

Un VPS standard que vous pouvez reconstruire. Aucun nouvel outil, une véritable séparation assurée par le kernel, des snapshots fournis par le provider, et un service qui continue de fonctionner lorsque vous éteignez votre ordinateur portable. C’est le modèle décrit dans la suite de ce guide. C’est aussi celui qui résiste aux longues exécutions d’agents, car une tâche qui dure quatre heures ne tient pas compte du fait que vous êtes rentré chez vous.

Le modèle VPS : donner à l’agent son propre utilisateur

Commencez par un serveur renforcé. Les dix premières minutes sur un nouveau VPS couvrent les éléments qui ne sont pas spécifiques à l’agent : les mises à jour, une connexion sans root, SSH avec clés uniquement et un pare-feu.

Créez ensuite un compte réservé à l’agent. Ainsi, une erreur dans ce compte ne pourra pas toucher le reste du serveur.

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 signifie qu’il n’y a aucun mot de passe à deviner. Vous accédez au compte avec sudo -u agent ou avec une clé SSH. Notez que agent ne fait volontairement pas partie du groupe sudo. Un agent disposant de sudo a les privilèges root. root peut lire les fichiers de tous les autres utilisateurs. La séparation que vous venez de mettre en place serait donc uniquement apparente. Si l’agent doit réellement installer des packages, utilisez plutôt un serveur complet qui lui est réservé. Ne lui accordez pas sudo sur un serveur partagé. Les règles générales sont décrites dans le principe du moindre privilège pour les utilisateurs Linux sur un VPS.

Vérifiez la séparation avant de lui faire confiance. En tant qu’utilisateur agent, essayez de lire un fichier appartenant à votre propre compte :

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

Vous devez voir cat: /home/you/.ssh/id_ed25519: Permission denied. Si vous voyez à la place des éléments cryptographiques, votre répertoire personnel est en mode 755 et l’isolation n’est pas encore effective. Corrigez-la avec sudo chmod 700 /home/you.

Conservez entièrement les identifiants hors de la machine

L’objectif d’une machine jetable est compromis si vous y copiez vos secrets de production. La règle est simple : cette machine ne doit contenir aucun identifiant dont la rotation vous poserait problème cet après-midi.

Pour git, transférez votre agent SSH au lieu de copier une clé. La clé privée reste sur votre ordinateur portable. Seules les demandes de signature transitent par la connexion.

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

La deuxième commande doit répondre Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. Cela prouve que git push fonctionnera sans fichier de clé présent sur le serveur. Exécutez ensuite ls -la ~/.ssh sur la machine et vérifiez qu’elle ne contient aucune clé privée.

La redirection d’agent comporte un risque réel, qu’il faut énoncer clairement : pendant votre connexion, toute personne disposant de root sur ce serveur peut utiliser le socket transféré pour s’authentifier à votre place. Sur un serveur dont vous êtes le seul autre utilisateur, c’est un compromis acceptable. Sur une machine partagée, ce ne l’est pas. Une deploy key limitée à un seul dépôt est alors préférable. Ces choix sont présentés dans Notions de base sur la gestion des clés SSH.

Pour les clés d’API, donnez à l’agent sa propre clé, avec sa propre limite de dépenses. Stockez-la dans un fichier appartenant à l’utilisateur agent, avec le mode 600. Lorsque la machine est détruite, révoquez cette clé au lieu de vous demander si elle a fuité. Le suivi des dépenses du modèle par clé permet également de conserver des montants prévisibles dans Contrôle des coûts d’un agent IA sur un VPS.

Limiter ce que l’agent peut atteindre sur le réseau

L’isolation du système de fichiers ne constitue que la moitié de la limite. L’autre moitié est l’egress : ce à quoi le processus est autorisé à se connecter. Linux peut filtrer le trafic sortant selon l’utilisateur qui l’a créé. Cela correspond exactement à ce modèle.

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

Les règles sont lues dans l’ordre. La dernière règle REJECT intercepte donc tout ce que les lignes précédentes n’ont pas autorisé. Testez-la en tant qu’agent :

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

La commande doit échouer avec curl: (7) Failed to connect to example.com port 80: Connection refused, car la règle de rejet répond immédiatement au lieu de laisser la connexion expirer. Une requête HTTPS vers le même hôte doit toujours réussir.

Deux limites à prendre en compte. Premièrement, ces règles sont perdues au prochain redémarrage si vous ne les enregistrez pas avec sudo apt install -y iptables-persistent, puis sudo netfilter-persistent save. Deuxièmement, ce filtrage porte sur les ports et les adresses, pas sur les noms. Une règle qui autorise le port 443 autorise tous les hôtes HTTPS sur Internet. Elle suffit pour atteindre l’API du modèle, mais aussi un pastebin. Une véritable liste d’autorisation de domaines nécessite de faire passer le trafic par un proxy qui lit le nom d’hôte demandé. C’est une configuration plus complexe que la plupart des environnements utilisés par un seul développeur ne le souhaitent. Ne revendiquez que ce que vous avez réellement : un contrôle de l’egress au niveau des ports, sur une machine dont vous étiez prêt à accepter la perte.

Revenir à un état propre entre les tâches

Un état propre pour chaque tâche est un avantage souvent sous-estimé. Un agent qui a passé trois heures sur le ticket précédent a laissé des paquets installés, des migrations partiellement appliquées, un node_modules obsolète et un arbre de travail git contenant des modifications que personne n’a examinées. La tâche suivante hérite de tout cela, et vous consacrez votre budget de revue à déterminer quels éléments appartiennent à quelle exécution.

La solution simple consiste à utiliser un nouveau checkout pour chaque tâche.

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

La solution plus robuste consiste à créer un snapshot du fournisseur une seule fois, juste après la configuration de la machine et avant toute intervention d’un agent. La restauration de ce snapshot remet tout le système, paquets compris, dans un état connu. La plupart des fournisseurs proposent cette fonction dans le panneau de contrôle ou via une API, plutôt que sous la forme d’une commande à exécuter sur la machine. Les étapes exactes dépendent donc de votre fournisseur. La règle est de créer le snapshot tant que la machine est encore dans un état standard.

Conservez tout ce qui vous est utile en dehors de la machine temporaire. Cela signifie principalement pousser les branches au lieu de les conserver uniquement en local. Si la machine contient malgré tout un élément que vous regretteriez de perdre, sauvegardez-le correctement avec des sauvegardes restic sur un VPS. Une machine que vous pouvez détruire n’est utile que si sa destruction se déroule réellement sans incident.

Si vous voulez plusieurs environnements isolés sans payer plusieurs serveurs, un VPS plus puissant peut héberger directement des VM invitées. La virtualisation imbriquée sur un VPS explique son fonctionnement, notamment comment vérifier si votre fournisseur l’autorise.

Quand un laptop reste réellement acceptable avec des précautions

Soyez honnête à ce sujet. Présenter l’isolation comme infaillible finit par faire perdre confiance.

Si vous vérifiez chaque commande avant son exécution, un laptop convient. La demande d’autorisation est un véritable contrôle, et exécuter Claude Code en toute sécurité sur un serveur explique ce que chaque niveau bloque réellement. Si votre travail se limite à un dépôt et qu’aucun identifiant de production ne se trouve sur la machine, le périmètre d’impact est déjà limité. Si vos sessions avec l’agent sont courtes et supervisées, la fenêtre d’exposition l’est également.

La situation change dès que vous ignorez les demandes d’autorisation. Les exécutions sans surveillance, les tâches nocturnes et tout workflow dans lequel vous approuvez un plan avant de vous éloigner suppriment le contrôle humain qui assurait le confinement. La machine doit alors prendre le relais. Il en va de même pour tout ce qui étend la portée de l’agent, notamment exécuter un agent de programmation sur un VPS sur plusieurs dépôts à la fois.

La décision ne dépend pas vraiment du degré de confiance que vous accordez au modèle. Elle dépend de ce qui se trouve à côté de lui lorsqu’il se trompe.

FAQ

Un conteneur fournit-il une isolation suffisante pour un agent de programmation ?

Pour la plupart des tâches, oui, à deux conditions. Le conteneur ne doit pas s’exécuter avec --privileged et ne doit pas avoir /var/run/docker.sock monté à l’intérieur, car l’un ou l’autre fournit au processus un chemin vers root sur l’hôte. Un conteneur partage le kernel de l’hôte. La séparation est donc moins forte qu’avec une machine virtuelle. Si l’agent exécute du code non fiable récupéré sur Internet, préférez une véritable VM ou un serveur séparé.

L’agent a-t-il besoin de sudo sur le serveur ?

Non. Lui donner sudo annule l’isolation mise en place, car root peut lire les données de tous les autres comptes de la machine. Créez l’utilisateur de l’agent sans sudo et donnez-lui un accès en écriture uniquement à son propre répertoire de travail. Si la tâche nécessite réellement l’installation de paquets, donnez à l’agent une machine entière dont il est propriétaire plutôt que root sur une machine partagée.

Comment permettre à l’agent d’envoyer des commits vers git sans installer ma clé SSH sur la machine ?

Transférez votre SSH agent avec ssh -A lors de la connexion. Les demandes de signature transitent par la connexion, tandis que la clé privée reste sur votre ordinateur portable. Ainsi, ssh -T git@github.com s’authentifie et git push fonctionne sans clé privée sur le serveur. Attention : root sur ce serveur peut utiliser le socket transféré pendant votre connexion. Utilisez donc une deploy key limitée au dépôt sur toute machine que vous partagez avec d’autres personnes.

De quelle taille de VPS un agent a-t-il besoin ?

Le travail de l’agent consiste principalement à modifier des fichiers, à exécuter des builds et à lancer des tests. Dimensionnez donc la machine en fonction du build, et non du modèle. Un modèle hébergé s’exécute sur le matériel du fournisseur, ce qui génère du trafic réseau mais presque aucune charge locale. Commencez avec 2 GB de RAM pour les tâches de scripting et passez à 8 GB si le dépôt construit des conteneurs ou compile des éléments importants.

À quelle fréquence dois-je détruire et reconstruire la machine ?

Reconstruisez-la lorsque son état ne peut plus être expliqué et, au minimum, chaque fois qu’un identifiant présent sur la machine a pu être exposé. Un nouveau checkout entre les tâches suffit à gérer la dérive quotidienne. Un snapshot pris avant la première exécution de l’agent vous fournit une image système propre à restaurer. Si la reconstruction semble coûteuse, cela indique qu’un élément important réside sur une machine que vous considériez comme jetable.