jai - un outil d’isolation simple pour les agents IA

 (jai.scs.stanford.edu)
3 points par GN⁺ 2026-03-29 | 1 commentaires | Partager sur WhatsApp
  • Outil léger permettant d’isoler l’exécution d’agents IA sous Linux, en fournissant une frontière d’exécution sûre via une simple commande, sans configuration complexe de conteneur
  • Les cas où des outils IA accèdent au système de fichiers réel et suppriment ou endommagent des données se multiplient, mettant en évidence le besoin d’un environnement d’exécution sûr
  • Protège le répertoire personnel avec un overlay copy-on-write et isole /tmp et /var/tmp pour empêcher toute modification des fichiers d’origine
  • Propose trois modes d’isolation — Casual, Strict et Bare — afin de choisir le niveau de sécurité et la portée des accès
  • Projet open source développé par une équipe de recherche de Stanford, offrant un moyen de protection pratique pour utiliser les outils IA de façon plus sûre

jai, un outil léger pour l’isolation des agents IA

  • jai est un outil conçu pour isoler (containment) facilement des agents IA dans un environnement Linux
    • Il fournit une frontière d’exécution sûre en une seule commande, sans configuration complexe de conteneur ou de VM
    • Il peut être intégré immédiatement aux workflows existants, comme l’assistance au code ou l’exécution de scripts

  • Exemples de problèmes réels

    • Plusieurs utilisateurs ont signalé des pertes de fichiers et suppressions de répertoires lors de l’utilisation d’outils IA
      • Nick Davidov a rapporté que 15 ans de photos de famille avaient été supprimés par une commande terminal
      • Claude Code d’Anthropic a supprimé son répertoire personnel, entraînant la perte de projets de développement
      • Cursor a vidé l’arborescence de travail, avec un signalement indiquant que « tout avait disparu »
      • Un utilisateur de Reddit a mentionné qu’Antigravity avait supprimé l’intégralité du disque D
      • Un autre utilisateur de Cursor a signalé la suppression de 100 Go de fichiers
    • Ces cas montrent la faille de sécurité qui apparaît lorsque l’on autorise des outils IA à accéder à un compte réel

  • Fonctionnalités clés de jai

    • Établit automatiquement une frontière entre le compte d’exécution et le répertoire personnel
      • Le répertoire de travail conserve des droits complets en lecture/écriture
      • Le répertoire personnel est protégé par un overlay copy-on-write, de sorte que les fichiers d’origine ne sont pas modifiés
      • /tmp et /var/tmp sont séparés dans des espaces indépendants, tandis que les autres fichiers sont limités à la lecture seule
    • Il suffit de préfixer une commande avec jai pour l’exécuter en isolation
      • Exemples : jai codex, jai claude, ou simplement jai pour lancer un shell
    • Utilisable immédiatement sans Dockerfile ni processus de build d’image
      • Il n’est pas nécessaire de configurer des flags bwrap complexes ni d’écrire des scripts

  • Choix du mode d’isolation

    • Trois modes sont proposés : Casual / Strict / Bare
      • Casual : protège le répertoire personnel en copy-on-write, avec lecture possible de la plupart des fichiers
      • Strict : exécute via un utilisateur jai distinct, avec un répertoire personnel vide pour une isolation renforcée
      • Bare : répertoire personnel vide, mais conservation de l’UID utilisateur
    • Chaque mode diffère en matière de confidentialité (confidentiality), intégrité (integrity) et prise en charge de NFS
      • Le mode Strict offre l’isolation la plus forte, mais ne prend pas en charge les répertoires personnels sur NFS

  • Comparaison avec les outils alternatifs

    • Docker
      • Adapté à la reproductibilité d’environnements basés sur des images, mais trop lourd pour un sandboxing temporaire d’outils hôtes
      • Ne propose pas d’overlay du répertoire personnel
    • bubblewrap
      • Sandbox par espaces de noms puissant, mais qui impose de spécifier soi-même la configuration du système de fichiers
      • jai supprime cette complexité
    • chroot
      • N’est pas un mécanisme d’isolation sécurisé et, faute de fonctionnalités comme les montages, les espaces de noms PID ou la séparation des privilèges, n’est pas recommandé pour le sandboxing sous Linux

  • Limites de sécurité

    • jai ne garantit pas une sécurité totale
      • En tant que « casual sandbox », il réduit l’étendue des dégâts sans bloquer toutes les attaques
      • Le mode Casual protège peu la confidentialité, et même le mode Strict reste différent d’une isolation au niveau conteneur ou VM
      • Dans un environnement multi-tenant ou à haut risque, il est recommandé d’utiliser un conteneur ou une machine virtuelle

  • Contexte du projet

    • Développé conjointement par le groupe de recherche Stanford Secure Computer Systems (SCS) et la Future of Digital Currency Initiative (FDCI)
    • Fourni comme logiciel open source gratuit, afin d’aider les utilisateurs à employer l’IA de manière plus sûre

À lire aussi

1 commentaires

 
GN⁺ 2026-03-29
Réactions sur Hacker News

  • Il suffit d’ajouter la configuration suivante à .claude/settings.json

    {
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowRead": ["."],
      "denyRead": ["~/"],
      "allowWrite": ["."],
      "denyWrite": ["/"]
    }
  }
}

    Pour autoriser l’accès à des répertoires externes, il suffit de modifier allowRead
    Cette fonctionnalité est une nouvelle option de sandbox ajoutée il y a 10 jours

    • J’ai déjà vu claude se tromper de répertoire courant ou exécuter des commandes comme rm -rf *
      Heureusement, ça ne s’est pas produit en même temps, mais rien que d’y penser fait froid dans le dos
      L’idée du sandbox est bonne, mais pour être efficace, elle doit être imposée à bas niveau
      Comme claude lui-même est un énorme programme généré par IA, ajouter une couche de sécurité de moins de 3000 lignes écrites par des humains peut constituer une défense utile
    • Une future version de claude-code pourrait silencieusement renommer ou supprimer ce paramètre
      C’est pourquoi certains préféreront peut-être un logiciel de sandboxing distinct
    • Quelqu’un a partagé un exemple de configuration semi-humoristique qui autorise le GPU tout en empêchant seulement la suppression de /
      La configuration permet l’accès aux périphériques /dev/nvidia*, avec l’idée satirique d’accepter l’exfiltration de données
    • Il existe déjà des outils de sécurité traditionnels éprouvés depuis des décennies
      Si on exécute claude sous un utilisateur aux privilèges limités, l’isolation est automatiquement héritée par les sous-processus
    • Sur Linux (Arch) et macOS (Tahoe), la fonctionnalité de sandbox ne fonctionnait pas correctement
      Une issue correspondante a été ouverte
      bubblewrap et seatbelt fonctionnent bien de façon indépendante, mais lorsqu’ils sont lancés via claude-code, ils semblent désactivés

  • Il est surprenant de voir à quel point les gens installent facilement des agents IA sur leur ordinateur personnel
    Cela fait des décennies qu’on protège la sécurité des systèmes, et soudain on accorde tous les droits à un logiciel imprévisible

    • Déjà à l’époque où les outils de build récupéraient automatiquement les dépendances, on ignorait les avertissements, et aujourd’hui les attaques de la chaîne d’approvisionnement se répètent
      La commodité à court terme passe avant la sécurité à long terme
    • En réalité, ceux qui acceptent ce genre de risque et ceux qui privilégient la sécurité sont deux groupes différents
    • En entreprise, les accès sont déjà limités, donc c’est surtout plus sensible sur un PC personnel
      Sur ma VM de développement distante, Claude ne voit que des données qu’il peut consulter sans problème
    • Aux débuts de Docker aussi, l’ambiance était au “il suffit de télécharger une image !”
      Mais l’industrie a vite pris conscience des risques de sécurité et a réagi

  • Une simple séparation des permissions Unix suffit aussi
    Il suffit d’avoir deux comptes utilisateur et de ne mettre en groupe que les dossiers à partager avec l’IA
    Voir ce billet de blog connexe

  • La page d’accueil dit “arrêtez la confiance aveugle”, et la méthode d’installation consiste à faire un build manuel au lieu d’un curl | bash

    • Extraire soi-même le fichier tar et installer avec makepkg -i est bien plus sûr
      Le PKGFILE fait une trentaine de lignes, et la fonction de build seulement 7
      À côté, des scripts comme rustup (910 lignes), claude (158 lignes) ou opencode (460 lignes) sont bien plus complexes
    • À l’inverse, chaîner curl | tar | makepkg sur une seule ligne est une méthode peu fiable

  • Ce projet est bien conçu et me semble un peu plus sûr et pratique que ma propre méthode
    Moi, j’isole l’agent dans un compte utilisateur séparé
    Il arrive cependant que les permissions s’emmêlent, donc je les corrige avec des scripts
    Au final, la méthode la plus sûre reste de lui donner carrément un ordinateur portable séparé
    Rien n’est plus sûr qu’un matériel physiquement isolé

    • Mais pour communiquer avec des services externes, il faut fournir des clés API, avec le risque qu’elles fuient
      L’agent a des capacités proches d’un test d’intrusion, donc une simple séparation par utilisateur ne rassure pas complètement
    • De mon côté aussi, j’utilise actuellement la séparation par utilisateur
      Avec des conteneurs, l’agent se retrouve perdu quand il essaie de créer lui-même des conteneurs

  • Le site donne une impression de “vibe-coded” et paraît donc de faible qualité, mais l’outil lui-même a été implémenté directement par un professeur de Stanford
    Voir la FAQ

    • Puisque j’en suis l’auteur, je le dis moi-même : je ne suis pas bon en webdesign, mais je suis spécialiste des systèmes d’exploitation
      J’ai corrigé la documentation pour qu’elle soit exacte, donc vous pouvez lui faire confiance
      Le côté ironique, c’est que j’ai laissé le site tel que l’IA l’avait produit
    • L’auteur est David Mazieres, qui mène des recherches sur les systèmes de fichiers en espace utilisateur depuis le début des années 2000
      Il dirige le Stanford Secure Computer Systems Group
    • jai est un outil à haut risque, mais le site web est simple, donc même s’il est vibe-coded, ce n’est pas très grave
    • Malgré tout, personnellement, je préfère une page HTML sobre

  • Le fait que l’agent ait les droits d’écriture dans le répertoire du projet est inquiétant, car cela permet un exploit persistant
    Via des fichiers comme .pyc, .venv ou .git/hooks, il peut s’exécuter hors du sandbox
    Cette vulnérabilité a aussi été confirmée dans une conversation ChatGPT
    C’est pourquoi la méthode la plus sûre est un transfert de fichiers basé sur des patchs git
    Il faudrait n’exporter du sandbox vers l’extérieur que les fichiers modifiés correspondant à des éléments commités dans git

    • Ce serait bien d’ajouter une option pour rendre le répertoire .git/ en lecture seule
      On peut transformer le CWD en overlay avec jai -D, mais fusionner les changements reste délicat
    • Moi, j’exécute carrément le code uniquement à l’intérieur du sandbox, au niveau VM
      L’agent travaille sur une branche git worktree séparée, puis je ne fusionne qu’après revue
      Cela permet de conserver un flux de sécurité fondé sur la revue
    • Il ne faut jamais autoriser les git hooks

  • Comme alternative simple, certains lancent l’agent en SSH depuis un compte utilisateur séparé
    Ils bind-mountent le répertoire du projet pour contrôler l’accès
    Cela se marie bien avec la fonction SSH Remote de VSCode

    • Moi aussi, j’utilise un compte dédié depuis 6 mois, et il suffit de gérer les répertoires accessibles
      C’est une méthode d’isolation bien plus simple et efficace qu’un système de sécurité complexe

  • En pratique, il y a des problèmes bien plus subtils que rm -rf
    Une fois, claude-code a créé un dossier /public/blog/ pour enregistrer un SVG, ce qui a cassé le routage Apache
    Ce n’était ni une suppression ni un problème de permissions, mais un comportement non intentionnel a suffi pour que le blog renvoie des 404
    jai peut éviter ce genre de grosse erreur, mais ces problèmes fins restent difficiles

  • Excellent projet, mais le titre laisse à désirer
    J’aime bien la structure actuelle : accès complet au répertoire courant, reste en lecture seule, et répertoire personnel en copy-on-write
    Cette approche devrait devenir le modèle de sécurité par défaut des agents IA

    • Comme il n’y a pas de titre sur le site, quelque chose comme “jai - filesystem containment for AI agents” conviendrait mieux