Travailler en sécurité avec une IA en ligne de commande

Une IA en ligne de commande (par exemple Claude Code) exécute de vraies commandes sur votre poste de travail. Il ne faut pas la faire tourner sous votre propre compte, encore moins sous root. La bonne pratique est de lui donner son propre compte utilisateur, sans sudo, et de partager avec elle un seul répertoire de travail via un groupe commun. L'IA ne peut alors accéder qu'à son home et à ce répertoire partagé.

Le schéma repose sur trois éléments : un utilisateur dédié à l'IA, un groupe partagé, et un répertoire en setgid.

1. Créer un compte dédié à l'IA

On crée un utilisateur normal (ici agent), sans mot de passe de connexion et surtout sans l'ajouter au groupe sudo :

bash

adduser --disabled-password --gecos "" agent

Important

Ne mettez jamais ce compte dans sudo. Une IA sans droits d'élévation ne peut pas casser la machine, seulement agir dans les répertoires où on l'autorise.

Se connecter au compte de l'IA

Comme le compte n'a pas de mot de passe, on s'y connecte par clé SSH. ssh-copy-id ne peut pas servir ici (il lui faudrait un mot de passe pour déposer la clé), donc on installe la clé publique manuellement.

Il faut être root (les options -o/-g et chown vers un autre utilisateur l'exigent). Déposez votre clé publique (celle de votre poste, VOTRE_USER) dans le compte de l'IA :

bash

install -d -o agent -g agent -m 700 ~agent/.ssh
cat /home/VOTRE_USER/.ssh/id_ed25519.pub >> ~agent/.ssh/authorized_keys
chown agent:agent ~agent/.ssh/authorized_keys
chmod 600 ~agent/.ssh/authorized_keys

La connexion se fait ensuite sans mot de passe :

bash

ssh agent@localhost

Pour aller plus vite, créez un petit wrapper ~/bin/agent :

~/bin/agent

#!/bin/bash
ssh agent@localhost

Rendez-le exécutable (755) :

bash

chmod 755 ~/bin/agent

Pour pouvoir le lancer en tapant simplement agent, le dossier ~/bin doit être dans le PATH. Ajoutez cette ligne à la fin de votre ~/.profile (ou ~/.bashrc) :

bash

export PATH="$HOME/bin:$PATH"

Rechargez le fichier (ou ouvrez un nouveau terminal) pour l'appliquer :

bash

source ~/.profile

Vous pouvez maintenant vous connecter avec un simple :

bash

agent

2. Créer le groupe partagé

Ce groupe est le point commun entre vous (le dev ou le sysadmin) et l'IA :

bash

addgroup equipe

3. Ajouter le dev et l'IA au groupe

Une commande par membre :

bash

adduser dev equipe
adduser agent equipe

Chaque utilisateur doit ouvrir une nouvelle session (ou faire newgrp equipe) pour que l'appartenance au groupe prenne effet.

Vérifiez :

bash

getent group equipe

equipe:x:1200:dev,agent

4. Créer le répertoire partagé avec les bons droits

Le point clé est le bit setgid (le s dans les droits du groupe) : tout fichier ou dossier créé dedans hérite automatiquement du groupe equipe, quel que soit l'auteur.

bash

mkdir /home/projet
chown root:equipe /home/projet
chmod 2770 /home/projet

Le 2770 se lit :

• 2 : bit setgid (héritage du groupe sur les nouveaux fichiers) ;
• 770 : le groupe a lecture, écriture, exécution ; les autres utilisateurs n'ont rien.

Vérifiez, le s doit apparaître à la place du x du groupe :

bash

ls -ld /home/projet

drwxrws--- 2 root equipe 4096 juil. 24 10:00 /home/projet

5. Vérifier le umask

Le setgid transmet le bon groupe, mais pas le droit d'écriture au groupe : pour que les fichiers créés dans le répertoire partagé soient modifiables par tout le groupe, ils doivent être en 664, donc le umask doit valoir 002. Sur Debian c'est le réglage par défaut. Vérifiez :

bash

umask

Cela doit répondre 0002. Si ce n'est pas le cas, ajoutez umask 002 au ~/.profile du compte de l'IA.

Attention à cp -a

Un fichier arrivé normalement dans le répertoire (éditeur, touch, >, cp, cp -r) prend automatiquement le bon groupe grâce au setgid. Mais cp -a (comme rsync -a) inclut --preserve=ownership : il rétablit le groupe de la source et ignore le setgid. La copie peut donc atterrir avec un mauvais groupe, inaccessible à l'autre membre.

Pour corriger le groupe après coup, sans droits root, il suffit de recréer sur place avec un cp -r vers un temporaire, puis de remplacer l'original :

bash

cp -r data data.tmp   # la copie hérite du groupe setgid (fichiers ET dossiers)
rm -rf data
mv data.tmp data

cp -r ne préserve pas le propriétaire : la copie prend le groupe du répertoire (et le bit setgid sur les dossiers). Le rm et le mv sont autorisés car le répertoire est ouvert en écriture au groupe (sans sticky bit), même si les fichiers ne vous appartiennent pas.

Mieux encore : évitez le problème à la source en ne préservant pas le propriétaire dès la copie (cp -r, cp -a --no-preserve=ownership, rsync -rlt).

6. Vérifier le résultat

Connecté en tant que agent (ssh agent@localhost), créez un fichier dans le répertoire partagé : il doit appartenir au groupe equipe et être modifiable par le groupe.

bash

touch /home/projet/test.txt
ls -l /home/projet/test.txt

-rw-rw-r-- 1 agent equipe 0 juil. 24 10:05 /home/projet/test.txt

Le groupe (equipe) a bien rw : le dev pourra éditer ce fichier, et inversement.

Bonnes pratiques

• Aucun sudo pour le compte IA : elle ne travaille que dans son home et dans le répertoire partagé.
• Un seul répertoire partagé par projet : ne partagez pas tout le home du dev.
• Sauvegarde et versionnage : gardez le travail sous Git dans le répertoire partagé, pour pouvoir revenir en arrière facilement.