Agent Safehouse : le sandbox macOS par profils pour agents de code
Sandbox your local AI agents so they can read/write only what they need
En bref
- De quoi s’agit-il ?
- Un outil en Shell qui s'appuie sur sandbox-exec et sur des profils Scheme composables pour appliquer un modèle deny-first aux agents LLM tournant sur macOS. Le point de vue : la mécanique est cohérente, la portabilité est nulle, et l'outil se présente lui-même comme une couche de durcissement, pas comme une frontière de sécurité.
- À qui s’adresse-t-il ?
- Adoptez Agent Safehouse si votre poste de développement est un Mac et que vous lancez déjà des agents de code avec des permissions larges. Passez votre chemin si vous travaillez sous Linux, où sandbox-exec n'existe pas et où les alternatives citées par le projet reposent sur Landlock, seccomp-bpf ou bubblewrap.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 2 jours.
- En quel langage est-il écrit ?
- Principalement Shell, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : un agent qui lit tout votre répertoire personnel
Un agent de code lancé sans restriction hérite des droits de votre session. Il peut lire votre fichier de clés SSH, vos identifiants Git globaux, vos variables d'environnement, vos fichiers .env de projets voisins, et écrire n'importe où dans votre arborescence. Le README d'Agent Safehouse part de ce constat et propose une couche de confinement locale : l'agent ne voit que les fichiers et les intégrations dont il a besoin pour travailler. Le public visé est précis : des développeurs sur macOS qui utilisent des agents de code et qui acceptent de payer une petite friction de configuration en échange d'une réduction de la surface d'accès. Le projet se décrit lui-même comme une couche de durcissement, pas comme une frontière parfaite contre un attaquant déterminé. Cette honnêteté dans le README est un bon signal : elle évite de vendre une garantie que sandbox-exec ne peut pas offrir.
sandbox-exec, des profils Scheme et un modèle deny-first
Le mécanisme repose sur sandbox-exec, l'outil de sandboxing de macOS qui prend en entrée un fichier de politique au format Scheme. Agent Safehouse assemble ce fichier à partir de profils composables livrés avec l'outil, puis le passe à sandbox-exec. La logique est deny-first : rien n'est autorisé au départ, et chaque règle ajoute une permission explicite. Le README énumère les variables qui alimentent ce rendu : HOME_DIR sert à produire des règles précises relatives au répertoire personnel, WORK_DIR expose le répertoire de travail via trois primitives nommées workdir-literal, workdir-subpath et workdir-prefix. Ces primitives acceptent des chemins relatifs commençant par un slash, ce qui permet à un profil réutilisable de cibler par exemple <workdir>/.env sans coder en dur le chemin absolu du projet. Le comportement par défaut est plus étroit qu'on ne pourrait le croire : traversée en lecture seule des métadonnées sur /, sur le chemin de $HOME et sur $HOME lui-même, lecture des racines de répertoire pour ~/.config et ~/.cache, et quelques fichiers explicitement autorisés par des profils toujours actifs. La documentation donne un test concret : stat "$HOME" peut réussir alors que ls "$HOME" et cat ~/secret.txt échouent tant qu'aucune règle plus spécifique n'accorde le chemin.
Résolution des chemins système et piège des liens symboliques
Un détail mérite l'attention de quiconque écrit ses propres profils. Les modules intégrés peuvent référencer des chemins de compatibilité macOS comme /etc ou /private/etc/resolv.conf. Sur macOS, /etc est un lien symbolique vers /private/etc. Au moment du rendu, Safehouse résout les chemins absolus présents dans les règles allow file-read* et émet des autorisations correspondantes pour la cible réelle lorsque le chemin écrit est un lien symbolique. Cela évite d'élargir les profils source à une lecture récursive de /private/etc. La portée de ce mécanisme est volontairement limitée, et le README le dit : seules les autorisations littérales et de sous-chemin en lecture des profils intégrés sont concernées. Les chemins fournis par l'utilisateur sont normalisés séparément, et les règles intégrées en écriture ou limitées aux métadonnées ne sont pas étendues automatiquement. Si vous écrivez un profil qui pointe vers un chemin système derrière un lien symbolique, vous devez donc vérifier vous-même que la règle atteint la bonne cible. C'est le genre de limite qui ne se voit qu'au moment où quelque chose casse.
Installation et politique locale par machine
Deux voies d'installation sont documentées. Via Homebrew : brew install eugene1g/safehouse/agent-safehouse. Ou en script autonome, avec un téléchargement depuis les releases GitHub vers ~/.local/bin/safehouse, suivi d'un chmod +x. Le README recommande ensuite de garder les réglages propres à chaque machine hors de la configuration de projet, dans un wrapper de shell et un profil local ajouté. Le motif concret : une fonction safe qui appelle safehouse avec --add-dirs-ro="$HOME/server" et --append-profile="$SAFEHOUSE_APPEND_PROFILE", puis une fonction safe-claude qui ajoute --dangerously-skip-permissions. Le fichier de profil local, en Scheme, autorise des exceptions comme (home-literal "/.gitignore_global") ou (subpath "/Volumes/Shared/Engineering"), et peut aussi resserrer avec (deny file-read* file-write* (workdir-literal "/.env")). La distinction posée par le README est nette : --add-dirs-ro et --add-dirs pour l'accès aux dossiers partagés, --append-profile pour les exceptions locales et les surcharges finales. Les profils ajoutés se chargent en dernier, donc leurs règles deny peuvent restreindre les autorisations par défaut.
Worktrees Git : un instantané figé au lancement
Le projet gère un cas pénible : un répertoire de travail qui est lui-même la racine d'un worktree Git. Dans cette situation, le worktree détecté reçoit l'accès aux métadonnées Git partagées quand le répertoire commun vit en dehors du répertoire de travail sélectionné, et les autres worktrees liés existants du même dépôt deviennent lisibles par défaut pour l'inspection croisée. La limite est explicite dans le README : cet instantané ne se met pas à jour pour les processus déjà en cours. Si vous créez des worktrees sous un parent stable comme ~/worktrees, la recommandation est d'ajouter ce parent explicitement avec --add-dirs-ro plutôt que de compter sur la détection. C'est un compromis raisonnable entre commodité et prévisibilité, mais il faut le connaître : un worktree créé après le lancement de l'agent ne sera pas dans le périmètre, et rien ne vous le signalera.
Ce que l'outil ne fait pas, et pour qui c'est le mauvais choix
Agent Safehouse est spécifiquement taillé pour macOS, et le README le rappelle en renvoyant vers des alternatives Linux : vetto, bubblewrap, firejail, nono.sh, sandlock et isolated-agent. Ces projets ne reposent pas sur sandbox-exec mais sur Landlock, seccomp-bpf, seccomp-notify ou des espaces de noms utilisateur non privilégiés selon les cas. La différence d'approche est structurelle : sandbox-exec est un composant du système Apple, tandis que les solutions Linux s'appuient sur des primitives du noyau qui n'ont pas d'équivalent direct côté macOS. Sur un poste Linux, Agent Safehouse n'est donc pas l'outil à adapter, c'est l'outil à écarter. Deuxième réserve : le projet se qualifie lui-même de couche de durcissement et non de frontière parfaite. Un agent qui exploite une faille dans un binaire autorisé, ou qui passe par une intégration légitimement ouverte, reste hors du champ de ce que la politique peut bloquer. Troisième point à vérifier : l'outil dépend de sandbox-exec, dont la disponibilité et le comportement varient selon les versions de macOS. Le matériel fourni ne permet pas de dire jusqu'où va cette compatibilité, et c'est un risque à évaluer avant de bâtir un processus d'équipe dessus.
Coût de maintenance et licence
Le rythme de publication est régulier : v0.11.0 en juillet 2026, v0.11.1 le 17 juillet, v0.12.0 le 7 septembre, avec un dernier push au 9 septembre 2026. Le projet n'est pas archivé. La version 0.x indique cependant qu'aucune garantie de stabilité d'interface n'est acquise, et les profils Scheme que vous écrivez peuvent devoir suivre des changements de primitives comme workdir-prefix ou home-subpath. Côté licence, Apache-2.0 : elle autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et d'état des modifications. Le README ne signale ni CLA ni clause additionnelle, mais rien dans le matériel fourni ne permet de se prononcer sur la politique de contribution du dépôt. Sur ce point comme sur les autres, lisez le fichier LICENSE et le CONTRIBUTING du dépôt plutôt que de vous fier à un résumé.
Conclusion éditoriale
Adoptez Agent Safehouse si votre poste de développement est un Mac et que vous lancez déjà des agents de code avec des permissions larges. Passez votre chemin si vous travaillez sous Linux, où sandbox-exec n'existe pas et où les alternatives citées par le projet reposent sur Landlock, seccomp-bpf ou bubblewrap. Avant de l'installer, vérifiez que la commande sandbox-exec est toujours fonctionnelle sur votre version de macOS et testez le comportement par défaut sur votre répertoire personnel avec stat "$HOME", ls "$HOME" et cat sur un fichier sensible : la documentation affirme que les deux derniers échouent, c'est cette affirmation qu'il faut confirmer chez vous avant de faire confiance au reste.
Notes de la communauté