Sécuriser pi, votre agent de code IA, avec Greywall : guide pratique

Les agents de code IA comme pi sont devenus des compagnons indispensables au quotidien. Mais par défaut, pi fonctionne en mode YOLO : accès complet au filesystem, exécution de n’importe quelle commande, aucune restriction. C’est un choix délibéré de son créateur, mais cette liberté a un coût réel. Aujourd’hui, je vous propose de découvrir Greywall, un outil qui permet de sandboxer pi grâce à une approche deny-by-default au niveau kernel.

Pourquoi sandboxer un agent de code IA ?#

pi en mode YOLO, c’est pratique mais risqué. Sans restriction, l’agent peut :

• Lire vos secrets : clés SSH (~/.ssh/id_rsa), fichiers .env, credentials AWS ou GCP,
• Exfiltrer des données : envoyer des fichiers vers un serveur distant via curl,
• Modifier votre système : altérer ~/.bashrc, ~/.gitconfig, les hooks git,
• Exécuter des commandes destructrices : rm -rf /, git push --force, npm publish,
• Être manipulé par injection de prompt : du contenu malveillant dans un fichier peut influencer son comportement.

Greywall apporte une défense en profondeur : même en mode YOLO, l’agent est contenu dans un sandbox kernel-level qui limite ce qu’il peut réellement faire.

Vue d’ensemble de Greywall#

Greywall est un sandbox sans conteneur, fonctionnant au niveau du kernel, basé sur le principe deny-by-default : tout est interdit par défaut, vous ouvrez uniquement ce dont l’agent a besoin.

Fonctionnalités par plateforme#

Architecture en bref#

L’architecture repose sur quatre piliers :

• Filesystem : lecture et écriture contrôlées par allowlists/denylists,
• Réseau : routé via un proxy SOCKS5 (greyproxy) avec filtrage par domaine,
• Commandes : blocage des commandes dangereuses, même dans les pipelines et sous-shells,
• Credentials : substitution transparente des clés API via greyproxy.

Installation et premiers pas#

Linux (Arch, Ubuntu, Fedora)#

# Installer Greywall
curl -fsSL https://raw.githubusercontent.com/GreyhavenHQ/greywall/main/install.sh | sh

# Dépendances Linux
# Arch
sudo pacman -S bubblewrap socat xdg-dbus-proxy libsecret
# Ubuntu/Debian
sudo apt install bubblewrap socat xdg-dbus-proxy libsecret-tools
# Fedora
sudo dnf install bubblewrap socat xdg-dbus-proxy libsecret

macOS#

brew tap greyhavenhq/tap
brew install greywall

Greyproxy est installé automatiquement comme dépendance.

Vérification et setup#

# Vérifier l'installation
greywall check

# Installer et démarrer greyproxy (proxy SOCKS5 + dashboard)
greywall setup

# Vérifier les fonctionnalités kernel (Linux)
greywall --linux-features

Sans greyproxy, tout le réseau est bloqué par défaut — c’est voulu.

Lancer pi dans le sandbox#

# Sandbox basique : seul le CWD est accessible, réseau bloqué
greywall -- pi

Attention : à ce stade, pi n’a pas encore de profil agent intégré dans Greywall. Les profils natifs existent pour Claude Code, Codex, Gemini CLI, Cursor, OpenCode, etc. — mais pas encore pour pi. Pas de panique, on peut très bien s’en sortir !

Profil de sécurité pour pi#

Puisque pi n’a pas encore de profil dédié, deux approches s’offrent à nous.

Approche 1 : le mode apprentissage (recommandé pour démarrer)#

Le mode learning trace les accès filesystem de pi et génère automatiquement un profil de moindre privilège :

# Lancer en mode learning
greywall --learning -- pi

# Travailler normalement quelques minutes...
# Quitter pi — le profil est généré automatiquement

# Voir le profil généré
greywall profiles show pi

# Lancer pi avec le profil appris (chargé automatiquement)
greywall -- pi

C’est le moyen le plus rapide d’obtenir un profil sur mesure sans deviner les besoins exacts de l’agent.

Approche 2 : un config custom qui étend le template code#

Le template code de Greywall est conçu pour les agents de code IA. On peut l’étendre avec les spécificités de pi :

{
  "extends": "code",
  "filesystem": {
    "denyRead": [
      "~/.ssh/id_*",
      "~/.gnupg/**",
      ".env",
      ".env.*"
    ],
    "denyWrite": [
      "~/.bashrc",
      "~/.zshrc",
      "~/.ssh/**",
      ".git/hooks/**"
    ]
  },
  "command": {
    "deny": [
      "git push --force",
      "npm publish"
    ]
  },
  "credentials": {
    "inject": [
      "ANTHROPIC_API_KEY",
      "OPENAI_API_KEY"
    ]
  }
}

Ce fichier se place dans ~/.config/greywall/greywall.json (Linux) ou ~/Library/Application Support/greywall/greywall.json (macOS).

# Lancer pi avec ce profil
greywall -- pi

Le template code apporte déjà les protections de base : blocage des commandes système dangereuses, protection des fichiers sensibles, routage réseau via proxy.

Combiner avec des toolchains#

Si votre projet utilise plusieurs langages, vous pouvez combiner les profils toolchains intégrés :

# pi + Node.js + Go
greywall --profile node,go -- pi

# pi + Python
greywall --profile python -- pi

# pi + Rust
greywall --profile rust -- pi

Ces profils toolchains autorisent les accès nécessaires aux caches, runtimes et dépendances de chaque écosystème.

Ce qu’il faut protéger absolument#

Greywall inclut une protection automatique des fichiers dangereux : .git/hooks/*, ~/.bashrc, ~/.zshrc, ~/.ssh/ sont bloqués en écriture même sans configuration explicite.

Protection des credentials#

C’est l’une des fonctionnalités les plus puissantes de Greywall. Le principe est élégant (requiert greyproxy v0.3.4+) :

1. Détection : Greywall scanne les variables d’environnement pour les noms connus (ANTHROPIC_API_KEY, AWS_SECRET_ACCESS_KEY, etc.) et les suffixes courants (_API_KEY, _TOKEN, _SECRET, _PASSWORD).
2. Remplacement : Chaque credential est remplacé par un placeholder opaque (greyproxy:credential:v1:gw-<id>:<digest>).
3. Substitution HTTP : Quand pi fait une requête HTTP contenant un placeholder, greyproxy substitue la vraie valeur avant de transmettre.
4. Nettoyage : À la sortie du sandbox, la session est supprimée de greyproxy.

Résultat : pi ne voit jamais les vraies clés API. Seul greyproxy les manipule.

En pratique#

# Protection automatique
greywall -- pi

# Injection depuis greyproxy (les clés n'existent pas dans l'environnement)
greywall --inject ANTHROPIC_API_KEY --inject OPENAI_API_KEY -- pi

# Ajouter une variable custom comme secret
greywall --secret MY_CUSTOM_KEY -- pi

# Ignorer un faux positif
greywall --ignore-secret PI_OFFLINE -- pi

Il est aussi possible de stocker les credentials directement dans le dashboard greyproxy (http://localhost:43080/settings#credentials), sans qu’elles n’existent dans l’environnement.

Sur Linux, Greywall monte des versions réécrites des fichiers .env avec des placeholders. Sur macOS, les fichiers .env sont entièrement bloqués en lecture — utilisez --inject à la place.

Contrôle réseau et filesystem#

Réseau : proxy SOCKS5 et allowlist#

Toutes les requêtes réseau passent par greyproxy, qui filtre par domaine. La politique par défaut est Deny :

# Mode sans réseau (greyproxy ne tourne pas)
greywall -- pi

# Avec réseau contrôlé (configurer les domaines dans le dashboard)
greywall -- pi

Les domaines à autoriser typiquement pour un agent de code :

Exposer des ports#

# Autoriser pi à lancer un dev server
greywall -p 3000 -p 5173 -- pi

# Forward un port du host (ex: PostgreSQL, Redis) — Linux uniquement
greywall -f 5432 -f 6379 -- pi

Monitoring, audit et mode apprentissage#

Violations en temps réel#

# Mode monitoring — affiche uniquement les violations
greywall -m -- pi

Exemple de sortie :

[VIOLATION] read denied: /home/user/.ssh/id_rsa (Landlock)
[VIOLATION] write denied: /home/user/.bashrc (protected file)
[VIOLATION] command denied: git push --force origin main (command policy)
[VIOLATION] network denied: evil.com:443 (greyproxy)

Chaque violation est loggée et visible en temps réel. Si pi tente de lire ~/.ssh/id_rsa, d’écrire dans ~/.bashrc ou de se connecter à un domaine inconnu → bloqué et loggé.

Dashboard greyproxy#

Le dashboard accessible à http://localhost:43080 permet de visualiser :

• Activity : toutes les connexions réseau en temps réel,
• Pending : requêtes en attente de décision,
• Rules : règles allow/deny actives,
• Credentials : credentials stockés et sessions actives.

Mode debug#

# Output verbeux complet
greywall -d -- pi

# Monitoring + debug
greywall -m -d -- pi

Limites connues et modèle de sécurité#

Greywall est une défense en profondeur, pas une garantie absolue. Il est important de comprendre ses limites :

• Code hostile déterminé : un attaquant motivé pourrait s’échapper via des vulnérabilités kernel,
• Exfiltration vers des destinations autorisées : Greywall filtre la destination, pas le contenu,
• Corps des requêtes HTTP : la substitution de credentials ne s’applique pas au body,
• Protocoles non-HTTP : TCP brut, WebSockets après upgrade — pas d’inspection,
• Limites de ressources : CPU, mémoire, fork bombs — hors périmètre.

Différences Linux vs macOS#

En résumé : ✅ Greywall protège contre les accidents et les injections de prompt basiques, ⚠️ il ne protège pas contre un adversaire déterminé.

Checklist de déploiement#

Installation#

• Installer Greywall (curl -fsSL ... | sh ou brew install greywall)
• Installer les dépendances Linux (bubblewrap, socat)
• Lancer greywall setup pour installer greyproxy
• Vérifier avec greywall check

Configuration#

• Lancer greywall --learning -- pi pour découvrir les besoins réels de pi
• Affiner le profil ou créer un config custom étendant le template code
• Ajouter les domaines LLM autorisés dans le dashboard greyproxy
• Configurer la protection des credentials (--inject ou dashboard)

Validation#

• Lancer greywall -m -- pi et vérifier les violations
• Tester que la lecture de ~/.ssh/id_* est bloquée
• Tester que l’écriture dans ~/.bashrc est bloquée
• Tester que git push --force est bloqué

Quotidien#

• Utiliser greywall -- pi au lieu de pi nu
• Consulter le dashboard greyproxy régulièrement
• Auditer les violations avec -m de temps en temps

Conclusion#

Greywall transforme un agent de code tout-puissant en un outil maîtrisé. En adoptant une approche deny-by-default au niveau kernel, il permet de profiter de la puissance de pi sans exposer ses secrets, son système ou son réseau. La protection transparente des credentials, le filtrage réseau et le mode apprentissage en font un compagnon idéal pour tout développeur soucieux de sécurité.

Ce guide ne couvre que l’essentiel — pour aller plus loin, n’hésitez pas à consulter la documentation officielle et le GitHub de Greywall.

Des questions sur la mise en œuvre, le profil de sécurité, ou d’autres cas d’usage à explorer ? N’hésitez pas à me les poser en commentaire !