Isoler un agent de code IA sur un VPS : AGENTS.md piégé

Ce que montre la recherche de Forever Security

Ce que l'étude établit, et ce qu'elle ne dit pas

• Établi — un fichier d'instructions placé dans le répertoire de travail suffit à orienter l'agent, sans qu'aucune faille logicielle soit exploitée.
• Condition — l'attaque exige que l'utilisateur lance l'agent dans le dossier concerné. Selon BleepingComputer, OpenAI et Anthropic recommandent d'ailleurs de lancer l'agent dans le répertoire du projet.
• Charges inoffensives — les taux de 90 % et d'environ 50 % viennent de tests avec une charge sans danger ; ils ne mesurent pas des attaques réelles et ne se généralisent pas à tous les outils.
• Livraison inconnue — les chercheurs n'ont pas pu déterminer comment le fichier du client est arrivé dans ses téléchargements : la page web reste une hypothèse.
• Cursor CLI — cité comme lancé depuis ce dossier, mais pas décrit comme testé.
• Notre lecture — un dépôt cloné peut contenir son propre fichier d'instructions. Ce point est une déduction de notre part, pas un résultat de l'étude.

Lancer l'agent dans le bon dossier et valider les commandes : pourquoi un serveur séparé ?

Prérequis : ce qu'il faut pour monter le VPS

Monter le VPS en neuf étapes

1. 01

   Créer un utilisateur sans privilège

   sudo adduser --disabled-password --gecos "" agent
id agent
sudo -l -U agent
   La deuxième commande ne doit pas lister le groupe sudo, la troisième doit répondre que l'utilisateur n'est pas autorisé à exécuter sudo. Le compte n'a pas de mot de passe : on y entre par sudo -iu agent depuis votre compte d'administration. Prévoyez un VPS par client.

2. 02

   Réserver un répertoire par projet

   sudo install -d -o agent -g agent -m 700 /srv/agents/projet-a
   Lancez toujours l'agent depuis cette racine, jamais depuis /, ~ ou un dossier de téléchargements : un répertoire parent large charge des fichiers d'instructions que vous n'avez pas relus. Pour récupérer le code, entrez dans la session de l'agent puis clonez :
   sudo -iu agent
git clone <url-du-dépôt> /srv/agents/projet-a
   Utilisez une clé de déploiement en lecture seule, générée sur cette VM et propre au dépôt du projet.

3. 03

   Couper l'accès à vos clés

   sudo -iu agent printenv SSH_AUTH_SOCK
echo 'AllowAgentForwarding no' | sudo tee /etc/ssh/sshd_config.d/10-agents.conf
sudo sshd -t && sudo systemctl reload ssh
   La première commande ne doit rien afficher : aucun agent SSH n'est transmis à la session de l'agent de code. Connectez-vous à la VM avec ssh -o ForwardAgent=no. Ne déposez aucune clé de déploiement de production sur ce serveur, et aucun fichier de configuration d'un autre client.

4. 04

   Limiter les variables d'environnement au projet

   sudo -iu agent
install -m 600 /dev/null ~/.agent-env
   Éditez ensuite ~/.agent-env pour y mettre uniquement le jeton du fournisseur, à portée minimale, dédié à cette VM et révocable. Lancez l'agent avec un environnement vidé, afin qu'il n'hérite d'aucune variable de votre session :
   env -i HOME="$HOME" PATH="$PATH" TERM="$TERM" HTTPS_PROXY=http://127.0.0.1:8888 bash -c 'set -a; . ~/.agent-env; cd /srv/agents/projet-a && exec claude'
   Remplacez claude par la commande de votre outil. Si l'outil se connecte par compte (OAuth) plutôt que par clé d'API, le jeton vit dans le répertoire personnel de l'utilisateur : c'est ce jeton que l'étude a vu exposé avec Claude Code. Préférez une clé d'API dédiée, que vous révoquez à la destruction du serveur.

5. 05

   Fermer l'entrée avec ufw

   sudo ufw default deny incoming
sudo ufw limit 22/tcp
sudo ufw enable
   Gardez une seconde session SSH ouverte. ufw filtre par adresse et par port, pas par nom d'hôte ni par utilisateur : c'est pourquoi la sortie se règle aux deux étapes suivantes, avec un proxy et nftables.

6. 06

   Installer un proxy de sortie à liste blanche

   sudo apt install tinyproxy
   Dans /etc/tinyproxy/tinyproxy.conf, réglez Listen 127.0.0.1, Port 8888, FilterDefaultDeny Yes, Filter "/etc/tinyproxy/allowlist", puis écrivez la liste :
   printf '%s\n' '^registry\.npmjs\.org$' '^api\.anthropic\.com$' | sudo tee /etc/tinyproxy/allowlist
sudo systemctl restart tinyproxy
   Chaque ligne est une expression régulière sur le nom d'hôte. Remplacez l'API d'exemple par celle de votre fournisseur, relevée dans sa documentation, et ajoutez ^github\.com$ seulement si le projet l'exige. La documentation de tinyproxy décrit un filtrage par domaine, mais ne dit pas qu'il s'applique à l'hôte des tunnels HTTPS (CONNECT) : c'est non documenté, donc à tester. Ne tenez pas ce filtre pour acquis avant le test de l'étape 8.

7. 07

   Interdire à l'agent toute autre sortie avec nftables

   Ajoutez à la fin de /etc/nftables.conf, après la ligne flush ruleset :
   table inet agent_egress {
chain output {
type filter hook output priority 0; policy accept;
meta skuid "agent" oifname "lo" tcp dport 8888 accept
meta skuid "agent" limit rate 5/minute log prefix "agent-egress-drop: "
meta skuid "agent" counter drop
}
}
   L'utilisateur agent ne peut plus joindre que le proxy local ; le reste est journalisé puis jeté. Contrôlez la syntaxe avant d'activer :
   sudo nft -c -f /etc/nftables.conf
sudo systemctl enable --now nftables

8. 08

   Tester que le filtre tient

   sudo -u agent curl -sS --max-time 5 https://example.com
sudo -u agent curl -sS -x http://127.0.0.1:8888 https://example.com
sudo -u agent curl -sS -x http://127.0.0.1:8888 -o /dev/null -w '%{http_code}\n' https://registry.npmjs.org/-/ping
   La première commande doit expirer, car le pare-feu jette la connexion directe. La deuxième doit échouer par un refus du proxy (avec curl, un message du type CONNECT tunnel failed ; le code exact figure dans le journal de tinyproxy). La troisième doit répondre 200. Ces résultats sont ceux attendus : constatez-les sur votre VM. Si la deuxième commande réussit, le filtre ne couvre pas les tunnels HTTPS : préférez alors un proxy dont la documentation couvre CONNECT, et corrigez avant de lancer l'agent.

9. 09

   Prévoir la destruction du serveur

   Rangez ces commandes dans un script versionné. Un VPS suspect se supprime et se recrée à partir de l'image d'origine, et vous révoquez le jeton du fournisseur. Pour votre propre accès, passez par un bastion : voir le guide lié en bas de page.

Chaque garde-fou borne une chose précise

Faites défiler le tableau

Relire les fichiers d'instructions avant qu'un agent les suive

Le cas du paquet function-color : ce que le filtre change, et ce qu'il ne change pas

Dépannage : les erreurs que vous allez rencontrer

• Un refus de sudo pour agent — comportement attendu : l'utilisateur n'a aucun privilège, et le libellé exact du refus dépend de la version de sudo. Faites l'opération avec votre compte d'administration, sans jamais ajouter agent au groupe sudo.
• Un échec de tunnel CONNECT (avec curl, un message du type CONNECT tunnel failed) — le proxy a probablement refusé l'hôte ; le code exact dépend de tinyproxy et figure dans son journal. Lisez son nom dans /var/log/tinyproxy/tinyproxy.log, puis ajoutez-le à la liste seulement si l'outil en a besoin.
• Selon l'outil, un délai dépassé ou un échec réseau (par exemple ETIMEDOUT ou fetch failed) — l'outil tente une connexion directe que nftables jette. Vérifiez que HTTPS_PROXY est exporté dans la session de l'agent. Certains clients ignorent cette variable : ils échouent alors fermés, et leur documentation dit s'ils acceptent un proxy.
• Permission denied en lisant le dossier d'un autre utilisateur — c'est le cloisonnement qui travaille. Si l'agent a besoin d'un fichier, copiez-le dans le répertoire du projet.
• Connexion SSH coupée après ufw enable — la règle du port 22 manquait, ou SSH écoute ailleurs. Depuis la console du VPS, lancez sudo ufw status puis sudo ufw allow <port>/tcp.

Ce que ce serveur ne règle pas

Pour une agence : un VPS par client

La documentation officielle