L’IA en cage : comment sandboxer un agent sans casser sa valeur

L’intégration d’agents IA dans nos environnements de développement soulève une question fondamentale : jusqu’où peut-on leur faire confiance ?

Dans notre équipe, nous avons rapidement été confrontés à un problème concret. En tant que développeurs, nous avons accès à de multiples environnements - production, staging, systèmes internes - souvent avec des permissions élevées. Donner un accès direct à un agent IA dans ce contexte représente un risque majeur : exfiltration de données, exécution de code non maîtrisée, dépendance à des services externes.

Pour continuer à bénéficier de la puissance de ces outils tout en maîtrisant les risques, nous avons fait un choix structurant : sandboxer systématiquement nos agents.

Dans cette conférence, je présenterai comment nous avons mis en place une sandbox pour nos agents IA en nous appuyant sur des outils existants :

isolation via des environnements Docker
limitation des accès réseau via des policies strictes
contrôle des interactions avec les systèmes externes
gestion des permissions et des secrets
Nous n’avons pas construit une solution sur mesure.
Nous avons assemblé des briques connues - mais avec une contrainte forte : limiter les risques sans rendre l’outil inutilisable.

Ce sont ces choix, ces compromis et leurs impacts concrets que je partagerai.

Transcript

1. L'IA en cage Comment sandboxer un agent sans casser sa valeur Julien Maitrehenry github.com/jmaitrehenry · jmaitrehenry.ca
2. J U L I E N M A I T R E H E N R Y Qui suis-je ? Dev, Ops, Cloud Architect, mentor Cloud Architect & acting CTO @Paren Des credentials partout 🔑 jmaitrehenry.ca github.com/jmaitrehenry linkedin/in/jmaitrehenry
3. AGENDA Pourquoi mettre l'IA en cage ? sbx, c'est quoi ? Réseau & secrets Le workflow au quotidien Ce que la cage ne protège pas Lancer de tomates 🍅 (alias Q&A)
4. Pourquoi mettre l'IA en cage ?
5. Sur ma machine de dev… 🔑 Clés SSH - tous les environnements ☁ Credentials cloud (AWS, GCP, Azure…) 🗂 Code de plusieurs projets 📄 Documents personnels 😅 Des .env qui traînent
6. Et je donne accès à tout ça… à un agent IA autonome ? 🤔
7. Les risques 💀 Exfiltration de données ⚡ Exécution de code non maîtrisé 👁 Lecture de secrets en clair 🌊 Side effects sur la prod La question n'est pas « mon agent est-il malveillant ? » mais « que se passe-t-il quand il se trompe avec mes droits ? »
8. Le piège de l'over-approval Début je lis tout +1h je fais confiance +3h je clique sans lire Fatigue j'approuve aveuglément 🫠 Ce n'est pas de la paresse. C'est de la biologie.
9. La cage remplace votre vigilance défaillante.
10. sbx, c'est quoi ?
11. Petit point vocabulaire docker sandbox run … ⚠ DEPRECATED — plugin Docker Desktop, plus maintenu ❯ sbx run claude . ✅ La CLI actuelle — standalone
12. sbx : un binaire standalone • Docker Desktop NON requis • Pas de souci de licensing en entreprise • Un seul prérequis : compte Docker Hub (login OAuth) ❯ brew install docker/tap/sbx # winget / apt aussi ❯ sbx login # OAuth Docker Hub
13. MicroVM ≠ container Isolation Host protégé ? sbx (microVM) Hyperviseur — kernel dédié ✅ Oui Container + socket Namespaces ❌ Non Docker-in-Docker Container privilégié ⚠ Partiel Exécution directe Aucune ❌ Non
14. Concrètement, ça change quoi ? 🖥 Kernel + daemon Docker privés docker ps sur l'hôte ne voit pas la sandbox et l'agent ne voit pas vos containers 📁 Workspace monté au même chemin /Users/vous/projet reste /Users/vous/projet: stack traces directement ouvrables 🧹 sbx rm = tout disparaît Images, containers, paquets. Vos fichiers de workspace restent (passthrough)
15. La base : 4 commandes ❯ sbx run claude . # agent dans une microVM ❯ sbx ls # lister (pas docker ps !) ❯ sbx exec -ti claude-xx bash # shell dans la VM ❯ sbx rm claude-xx # tout nettoyer
16. Réseau & secrets
17. 3 niveaux de policy réseau 🌐 Open Tout autorisé Tests seulement, jamais avec des credentials ⚖ Balanced Deny par défaut + dev courant autorisé (npm, GitHub, APIs IA…) Le bon point de départ ★ 🔒 Locked Down Tout bloqué sauf whitelist Contrôle max — même votre provider IA est bloqué
18. Affiner & auditer ❯ sbx policy allow network 'api.github.com' ❯ sbx policy allow network '**.npmjs.org' ❯ sbx policy log # CHAQUE requête : règle, forward ou block 👆 L'audit trail. Le reçu qui permet de faire confiance.
19. Comment l'agent s'authentifie sans connaître les credentials ? 🤯
20. Le proxy host-side Agent IA dans la microVM → Proxy sur votre host → API externe api.openai.com requête SANS credentials requête + Authorization: Bearer *** 🗝 Le secret vit dans le keychain OS — jamais dans la VM 💉 Le proxy injecte le header au passage 🚫 L'agent ne peut ni lire, ni loguer, ni exfiltrer le token
21. Le setup tient en une ligne ❯ sbx secret set -g github 🔄 Rotation : on change la valeur du secret et c’est tout ✍ SSH agent forwarding inclus, commits signés sans donner la clé privée 📦 Bonus : registres privés avec sbx secret set --registry
22. Le workflow au quotidien
23. Mon setup réel : plusieurs repos Un agent, le contexte de tout l'écosystème - une seule cible en écriture. ❯ sbx create --template jmaitrehenry/sandbox-templates:copilot-docker \ copilot . \ ../ohio-dashboard:ro ../customer-api:ro ../data-api:ro ../WebApp:ro 📁 . le repo principal, en lecture-écriture 🔒 ../*:ro les repos voisins en lecture seule : contexte sans risque 🧩 --template image custom : les deps requises déjà installées
24. Standardiser l'équipe : les templates FROM docker/sandbox-templates:copilot- docker USER root RUN apt-get purge -y nodejs RUN curl - fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash – RUN apt-get install -y nodejs USER agent ❯ docker buildx build --push --platform linux/arm64/v8,linux/amd64 -t myorg/sandbox-templates:copilot-docker-node24 . • Versionné, partagé via registry • Toute l'équipe, même env • ⚠ Encore expérimental
25. Standardiser l'équipe : les kits # spec.yaml network: allow: ['api.github.com'] secrets: [github, openai] install: ['apt install -y jq'] ❯ sbx kit push ghcr.io/org/kit:1.0 • Versionné, partagé via OCI registry • Toute l'équipe, même env • ⚠ Encore expérimental
26. Le fix qui sauve : jemalloc sur ARM Le ripgrep intégré crashe sur Apple Silicon - #9554 # 1. neutraliser le ripgrep intégré - idempotent, persistant ❯ sbx exec copilot-dataget bash -c "grep -qxF \ 'export USE_BUILTIN_RIPGREP=0' /etc/sandbox-persistent.sh \ || echo 'export USE_BUILTIN_RIPGREP=0' >> /etc/sandbox-persistent.sh" # 2. entrer dans la VM, puis lancer l'agent ❯ sbx exec -ti copilot-dataget bash cd /Users/julien/dev/app && copilot --yolo Idempotent et persistant : la ligne n'est ajoutée qu'une seule fois.
27. sbx sans argument = dashboard Le panneau réseau (Tab) : les requêtes de l'agent en live, allow/block à la volée.
28. Plusieurs agents, un seul repo ? ❯ sbx run claude --branch auto . # worktree isolé sous .sbx/ ❯ sbx run copilot --branch auto . # chacun sa branche ❯ sbx run --clone claude . # copie complète du repo Votre working tree n'est jamais touché. Diff + cherry-pick 🍒 à la fin. 💡 Ajoutez .sbx/ au .gitignore
29. Ce que la cage ne protège pas
30. Limite #1 : votre workspace Le workspace monté est en lecture-écriture. L'agent peut modifier, supprimer, réécrire vos fichiers non commités. La cage protège le système, pas le répertoire que vous lui donnez. Mitigation : --branch, --clone, ou montage :ro
31. Limite #2 : l'exfiltration La policy limite les destinations, pas le contenu. GitHub autorisé (Balanced) = un agent compromis par prompt injection peut pousser votre code vers un repo externe. Mitigation : Locked Down + sbx policy log + review des diffs
32. Limite #3 : le contexte Tout le workspace est lisible par l'agent… …et transite vers le provider IA pour l'inférence. Ce qui est monté est, de fait, partagé. Mitigation : ne monter que le strict nécessaire, :ro si possible
33. Limite #4 : les hooks La sandbox limite les actions dans la VM… …mais pas à l’extérieur ! Un hook git, un github workflow peuvent executer des commandes preparé par votre agent et impacté votre système. Mitigation : vérifier les changements manuelement dans certains dossier: .github, .husky, Makefile, etc
34. Notre bilan ✅ Gains • Sérénité (YOLO sans surveiller) • Auditabilité (policy log) • Multi-agents (branch/clone) • Kits versionnés ⚠ Frictions • Login Docker Hub obligatoire • Setup des policies au départ • Debug réseau parfois silencieux • Overhead VM (boot, RAM) • Kits expérimentaux
35. Notre setup final MicroVM Copilot (YOLO) Docker Daemon privé Workspace monté → Proxy host Policy réseau Injection headers Logs → APIs autorisées ✓ GitHub / npm / OpenAI ✗ tout le reste Jamais dans la VM ↑ La requête sort sans credentials → le proxy l'enrichit. Le token n’est jamais disponible au LLM.
36. 4 choses à retenir 1 sbx remplace docker sandbox, standalone, sans Docker Desktop 2 MicroVM = isolation réelle du système hôte (le workspace reste à vous de protéger) 3 Secrets injectés par le proxy, jamais dans la VM 4 Dashboard + branch mode + kits = workflow complet, du solo à l'org
37. Merci Questions RÉPONSES INFORMATION docs.docker.com/ai/sandboxes · brew install docker/tap/sbx · jmaitrehenry.ca Lien de la présentation