Agent Safehouse – outil de sandboxing d’agents locaux pour macOS

 (agent-safehouse.dev)
16 points par GN⁺ 2026-03-09 | 1 commentaires | Partager sur WhatsApp
  • Un outil qui isole les agents IA locaux via le sandbox natif de macOS afin d’empêcher toute modification en dehors du système autorisé
  • Tous les agents s’exécutent dans un environnement sandbox indépendant, sans accès au répertoire personnel de l’utilisateur ni aux autres projets
  • Application d’un modèle d’accès deny-first, où seuls les répertoires explicitement autorisés peuvent être lus ou modifiés
  • L’installation se fait avec un unique script Bash, exécutable immédiatement sans build ni dépendances supplémentaires
  • Une fonction de génération de profil basée sur un LLM permet d’automatiser la configuration sandbox-exec selon le principe du moindre privilège

Vue d’ensemble

  • Agent Safehouse est un système de sandboxing dédié à macOS qui protège les fichiers du système contre les dommages potentiels causés par des agents IA exécutés en local
    • « Go full --yolo. We've got you. » « Move fast, break nothing »
    • Il bloque les risques d’exécution de commandes imprévues liés au caractère probabiliste des LLM
  • Tous les principaux agents fonctionnent intégralement dans le sandbox, sans effet sur le système extérieur
  • Il adopte un modèle d’accès deny-first : tous les accès sont bloqués par défaut, et seuls les chemins explicitement autorisés sont accessibles
    • Exemple : ~/my-project est autorisé en lecture/écriture, tandis que ~/.ssh, ~/.aws, ~/other-repos sont refusés

Installation et exécution

  • L’installation se fait en téléchargeant un unique script shell
    • Le script est récupéré avec la commande curl, enregistré dans ~/.local/bin/safehouse, puis rendu exécutable
  • L’agent souhaité peut ensuite être lancé avec la commande safehouse
    • Exemple : safehouse claude --dangerously-skip-permissions
  • Par défaut, Safehouse accorde les droits de lecture/écriture au répertoire de travail courant (racine git), et un accès en lecture seule au répertoire de la toolchain

Exemples de validation du sandbox

  • L’accès aux fichiers sensibles est bloqué au niveau du noyau
    • L’exécution de safehouse cat ~/.ssh/id_ed25519 provoque l’erreur « Operation not permitted »
    • Les autres répertoires de projet (~/other-project) ne sont pas visibles
    • Le répertoire du projet en cours reste accessible normalement

Automatisation et génération de profils

  • En ajoutant une fonction shell, tous les agents peuvent être exécutés par défaut dans Safehouse
    • Exemple : définir une fonction safe() dans .zshrc ou .bashrc pour sandboxer automatiquement les commandes claude, codex, amp, gemini
    • Pour lancer un agent sans sandbox, il suffit d’utiliser la forme command claude
  • Une fonction de génération de profils basée sur un LLM est fournie
    • Des modèles comme Claude, Codex ou Gemini analysent les templates Safehouse afin de générer un profil sandbox-exec à privilèges minimaux
    • Le profil est enregistré dans ~/.config/sandbox-exec.profile à partir des informations sur le répertoire personnel et la toolchain
    • Il inclut les droits d’accès au répertoire de travail courant ainsi que des raccourcis de commande propres à chaque agent

Sécurité et intérêt pratique

  • Il empêche les agents locaux basés sur des LLM de supprimer des fichiers ou de modifier le système de manière involontaire
  • Il fournit un environnement d’exécution sûr par défaut en s’appuyant sur le contrôle d’accès au niveau du noyau de macOS
  • Basé sur un script unique, il peut être facilement intégré au workflow des développeurs

À lire aussi

1 commentaires

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

  • Je ne pensais pas que le projet que j’ai créé serait rendu public aussi vite
    1️⃣ Je préfère les agents qui s’exécutent directement en local. Plutôt que des conteneurs ou des serveurs distants, je me sens plus à l’aise quand ils tournent sur ma machine, que j’ai configurée finement moi-même
    2️⃣ C’est en pratique un générateur de politiques pour sandbox-exec. Il n’y a pas de dépendances, pas de virtualisation. À la place, j’ai passé beaucoup de temps à identifier les permissions minimales nécessaires pour que chaque agent puisse faire des choses comme les mises à jour automatiques, l’intégration au trousseau, le collage d’images, etc. Les recherches associées sont résumées ici : agent-safehouse.dev/docs/agent-investigations
    3️⃣ Il n’est même pas nécessaire d’utiliser l’ensemble du projet. Le seul Policy Builder permet déjà de générer des politiques sandbox-exec à placer dans ses dotfiles

    • Désolé que ce soit sorti en avance. Je l’ai essayé après avoir vu un commentaire que tu avais laissé auparavant, et c’était tellement efficace que j’ai pensé que ça méritait un post
      J’avais déjà lu des documents sur les politiques de sandbox, mais c’était la première fois que je voyais ça sous la forme d’une application directement exploitable
      Cela dit, il y avait quelques points gênants — l’accès à .gitconfig et .gitignore dans le répertoire personnel est restreint, et à cause des limitations d’accès aux processus, il est impossible de faire exécuter à Claude des commandes comme lldb ou pkill. Ce serait bien d’avoir un contrôle plus fin des permissions
    • Je me demande s’il serait possible d’appliquer ça à openclaw. C’est pratique quand ça tourne de manière accessible sur la machine locale, mais en même temps cela rend aussi le contrôle plus difficile
    • Je me demande quelle est la différence concrète entre une exécution locale et une exécution en conteneur
    • Oh, c’est exactement ce que je cherchais. J’essayais d’ajuster microsandbox, mais ça me paraît bien plus réaliste
      J’ai parcouru le site et les scripts, et je n’ai rien vu de particulièrement problématique. Y a-t-il éventuellement des points d’attention non documentés ?
    • Ironiquement, je me suis intéressé à ce projet parce que je ne fais pas confiance à l’IA, mais pour l’installer il faut quand même récupérer et exécuter un fichier .sh depuis un serveur arbitraire, ce qui est un peu cocasse
      J’aimerais bien une distribution sous forme de tarball. Avec un tarball, on peut inspecter le contenu soi-même et vérifier s’il a bien été généré automatiquement par la CI, donc c’est plus rassurant

  • Je suis content de voir ce genre de projet, et je pense qu’en ce moment le sandboxing est le plus gros défi
    Les premiers utilisateurs lanceront des agents en local sans trop réfléchir, mais à long terme, ou en entreprise, ça ne passera jamais
    Il faut gérer des scénarios complexes qui vont bien au-delà du simple contrôle des permissions réseau, fichier ou exécution, comme les tests navigateur ou la création de ressources cloud
    Au final, il faut une approche pratique qui intègre sécurité, coûts et contrôle des permissions

    • Mais est-ce que ce ne serait pas un problème fondamentalement insoluble ? Fonctionnalité et sécurité sont toujours en tension, et au final les gens choisissent la première
    • Le sandboxing au niveau des fichiers, c’est la base ; le vrai sujet difficile, c’est le contrôle des identifiants et du réseau
      J’utilise un démon local qui émet des JWT à courte durée de vie pour éviter que l’agent manipule directement les clés. Ça fonctionne bien pour l’accès API, mais au niveau du système de fichiers, on peut toujours lancer un nombre infini d’instances EC2

  • Le problème, c’est qu’il est difficile d’évaluer et de comparer plusieurs sandboxes
    Ça ressemble à un wrapper pour sandbox-exec, et il y a beaucoup de wrappers de ce type en ce moment
    Ce qu’il faut vraiment, ce sont des documents de validation de confiance et des tests automatisés. La plupart des sandboxes manquent de documentation
    Pour faire confiance, il faut des documents détaillés et des preuves de fonctionnement

    • C’est pour ça que je l’ai implémenté en Bash — pour éviter les binaires opaques
      Les profils sandbox-exec pour chaque agent sont séparés dans le dossier profiles sur GitHub, ce qui permet de les relire facilement
      Je fais aussi des tests E2E avec de vrais agents
      Même sans le wrapper Safehouse, on peut générer directement des politiques à privilèges minimaux avec Policy Builder
      Je fournis aussi un fichier d’instructions pour demander à un LLM de rédiger des profils de sandbox

  • C’est un script wrapper autour de sandbox-exec. J’aime bien le fait qu’il y ait beaucoup de préréglages bien conçus
    90 % de sandbox-exec, c’est de bien définir le bon périmètre, et les 90 % restants, c’est de le comprendre
    Cela dit, ce serait bien de pouvoir faire du sandboxing en overlay ou en copy-on-write. Il me suffit que seul un environnement temporaire soit modifié, pas mon .bashrc

    • J’ai utilisé Bash parce qu’il est difficile de faire confiance à des binaires Go ou Rust
      L’overlay FS est compliqué sur macOS, mais je m’en suis sorti en limitant tout ce qui est en dehors du CWD en lecture seule et en poussant le travail vers un dossier temporaire
    • Je développe un OSS appelé Amika. C’est un outil qui permet de lancer rapidement des sandboxes locales ou distantes, avec une bonne intégration Git
      Il permet aussi d’exposer des ports TCP/UDP et de partager avec ses coéquipiers. Voir le lien GitHub
    • J’ai créé un projet appelé Treebeard. Il combine sandbox-exec, des worktrees et un système de fichiers COW
      Il permet d’accéder en toute sécurité à des fichiers ignorés par Git. Lien Treebeard
    • Mais sandbox-exec n’est-il pas déjà deprecated ?

  • Fait intéressant : sandbox-exec est officiellement deprecated depuis macOS Sierra (2016)
    Malgré cela, il reste encore très utile. L’App Sandbox d’Apple n’est pas adapté à ce type de règles personnalisées
    J’espère qu’Apple ne le supprimera pas complètement

    • En réalité, on dirait presque qu’il était deprecated depuis sa naissance. La documentation du langage de profil est quasi inexistante, et l’essentiel a été compris par rétro-ingénierie

  • Il existe aussi un projet appelé Sandvault. Il combine sandbox-exec avec le système d’utilisateurs Unix
    Il attribue à chaque agent un compte utilisateur séparé et non privilégié, puis les interactions passent par sudo, SSH et des répertoires partagés
    Lien GitHub de Sandvault

  • J’ai créé une application GUI pour macOS qui permet de gérer visuellement sandbox-exec
    Elle inclut aussi un filtrage réseau par domaine et une fonction de détection de secrets
    multitui.com

  • Je partage une méthode pour exécuter Claude Code dans les conteneurs Apple à l’aide de la commande container d’Apple
    L’environnement se met en place via container system start → container run → container exec, puis on installe Node.js et Claude

    • Merci ! Je découvre seulement maintenant qu’il y a aussi apple/container sur Homebrew

  • Je me demande pourquoi on considère qu’exécuter des agents en local est préférable
    Pour la plupart des gens, l’exécution distante semble plus efficace — puisqu’il n’est pas nécessaire de les laisser tourner en permanence

    • L’avantage de l’exécution locale, c’est le contrôle et la propriété. C’est comparable au fait d’héberger soi-même Plex ou un serveur web
      Et en plus, cela permet d’éviter les frais d’abonnement
    • J’ai créé pixels pour essayer de résoudre ce problème. Ça peut tourner sur TrueNAS SCALE ou Incus
      Le renforcement de la sécurité est en cours, mais pour les workflows IA, c’est déjà largement suffisant
      Lien GitHub de pixels

  • Je me demande si « clunker » est le nouvel argot pour « clanker ». Roku, l’ami d’un ami, pose la question
    Je suis justement en train de galérer avec des problèmes de sandboxing, donc le timing est parfait

    • C’était une faute de frappe, je viens de la corriger