La première version de notre bac à sable IA avait des volumes en lecture seule, une exécution non-root, une liste de blocage qui rejetait npm install, et un timeout de 30 secondes. C'était sécurisé. C'était aussi inutilisable.
Le CEO a regardé l'implémentation et a posé une question qui a changé tout le design : « Pourquoi autant de restrictions ? Les utilisateurs vont demander à l'IA de cloner leur dépôt, installer les dépendances, lancer leur application et trouver les erreurs. Comment est-elle censée faire cela si elle ne peut pas installer de paquets ? »
Il avait raison. Nous avions optimisé pour le mauvais modèle de menace.
La mauvaise question : « Comment garder l'IA en sécurité ? »
Quand la plupart des ingénieurs pensent à donner à l'IA un accès shell, ils partent de la peur. Et si elle exécutait rm -rf / ? Et si elle installait un malware ? Et si elle exfiltrait des données ?
Ce sont des préoccupations valides sur un système partagé. Elles ne sont pas valides à l'intérieur d'un conteneur jetable qui existe uniquement pour que l'IA l'utilise.
La bonne question : « De quoi l'IA a-t-elle besoin pour vraiment aider ? »
Voici ce que les développeurs demandent à l'IA de faire quand ils déboguent un déploiement :
- « Clone mon dépôt et dis-moi pourquoi le build échoue »
- « Installe les dépendances et vérifie s'il y a des conflits de version »
- « Lance l'application localement et appelle l'endpoint de santé »
- « Vérifie si la base de données est accessible depuis le réseau de l'application »
- « Lis la config nginx et dis-moi ce qui ne va pas »
Chacune de ces demandes nécessite l'installation de paquets, l'écriture de fichiers ou du piping shell. Notre liste de blocage originale -- qui rejetait apk, pip, npm, chmod et les pipes vers sh -- rendait tout cela impossible.
Ce que nous avons réellement construit
Le bac à sable IA est un conteneur Alpine Linux complet qui s'exécute aux côtés de votre application :
┌─────────────────────────────┐
│ Hôte Docker │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Votre │ │ Bac à │ │
│ │ App │ │ sable IA │ │
│ │ :3000 │ │ root │ │
│ │ │ │ 1 Go RAM │ │
│ │ │ │ 2 CPUs │ │
│ └────┬─────┘ └────┬─────┘ │
│ │ localhost │ │
│ └─────────────┘ │
│ réseau partagé │
│ volumes partagés │
└─────────────────────────────┘Mode réseau : container:{app_container_id} -- le bac à sable partage l'espace de noms réseau de l'application. Il peut atteindre l'application sur localhost:3000. Il peut atteindre la base de données de l'application sur db:5432. Même vue du réseau que l'application elle-même.
Volumes : En écriture. L'IA peut lire vos fichiers de configuration, les modifier pour tester des corrections, et vérifier si le changement fonctionne.
Utilisateur : Root. L'IA peut faire apk add de tout ce dont elle a besoin. Projet Node ? npm install. Python ? pip install. Besoin de compiler quelque chose ? apk add build-base.
Outils pré-installés : curl, wget, dig, nc, jq, git, node, npm, python3, pip, bash.
Ressources : 1 Go de RAM, 2 coeurs CPU. Suffisant pour npm install et de petits builds.
Timeout : 5 minutes. Suffisant pour un git clone + npm install sur un projet typique.
Ce que nous bloquons encore
La liste de blocage est passée de plus de 30 patterns à 8 :
rustconst BLOCKED_COMMANDS: &[&str] = &[
"rm -rf /",
"rm -rf /*",
"mkfs",
"shutdown",
"reboot",
"halt",
"poweroff",
"kill -9 1",
];Plus les fork bombs. C'est tout.
Ce sont des commandes qui ne servent aucun objectif diagnostique et qui détruiraient le conteneur lui-même. Tout le reste -- opérations sur les fichiers, gestionnaires de paquets, piping shell, outils réseau, gestion de processus -- est autorisé.
Le modèle de sécurité, c'est le conteneur
C'est l'insight qui a changé le design. Le bac à sable EST la frontière de sécurité. Il est :
- Isolé : Un conteneur séparé avec son propre système de fichiers
- Jetable : Détruit quand l'application est supprimée, arrêté quand l'application s'arrête
- Limité en ressources : 1 Go de RAM, 2 coeurs CPU, ne peut pas consommer l'hôte
- Limité en réseau : Partage le réseau de l'application uniquement, pas le réseau hôte
- Éphémère : Pas de politique de redémarrage. Si l'hôte redémarre, le bac à sable disparaît
La question n'est pas « quelles commandes l'IA devrait-elle être autorisée à exécuter ? » La question est « quel est le rayon d'impact si l'IA fait quelque chose de destructif ? » La réponse : un conteneur jetable qui peut être recréé en quelques secondes.
L'intégration MCP
Cinq nouveaux outils exposent le bac à sable via le serveur MCP de sh0 :
| Outil | Risque | Objectif |
|---|---|---|
sandbox_exec_command | write | Exécuter n'importe quelle commande shell |
sandbox_read_file | read | Lire des fichiers depuis les volumes de l'application |
sandbox_list_processes | read | ps aux dans le conteneur de l'application |
sandbox_check_connectivity | read | Tester le réseau avec nc ou curl |
sandbox_status | read | Le bac à sable est-il en cours d'exécution ? |
L'outil à risque d'écriture sandbox_exec_command nécessite une clé API avec la portée write. Les clés en lecture seule peuvent lire les fichiers et vérifier la connectivité mais ne peuvent pas exécuter de commandes arbitraires. C'est le vrai contrôle d'accès -- pas une liste de blocage de commandes.
Les détails d'implémentation qui comptent
Cycle de vie idempotent. ensure_sandbox est le point d'entrée pour chaque appel d'outil. Si le bac à sable existe et est en cours d'exécution, il renvoie l'ID. S'il est arrêté, il le redémarre. S'il n'existe pas, il le crée. Deux appels d'outils concurrents frappant ensure_sandbox simultanément sont gérés via la réponse 409 Conflict de Docker.
Création non bloquante. Quand une application se déploie avec sandbox_enabled: true, la création du bac à sable est lancée via tokio::spawn en tâche fire-and-forget. Le pipeline de déploiement n'attend jamais le bac à sable. Si la création du bac à sable échoue, un avertissement est journalisé et le bac à sable est créé paresseusement au premier appel d'outil.
Cycle de vie apparié. Arrêtez l'application, le bac à sable s'arrête. Démarrez l'application, le bac à sable démarre. Supprimez l'application, le bac à sable est détruit. Le bac à sable suit l'application.
Double timeout. La commande est encapsulée dans l'utilitaire timeout d'Alpine (kill côté serveur) ET tokio::time::timeout (garde côté client). Si le timeout côté serveur se déclenche, le code de sortie 143 (SIGTERM) est détecté et timed_out: true est renvoyé. Si d'une manière ou d'une autre cela échoue, le timeout côté client se déclenche 5 secondes plus tard.
Ce que cela permet
Avec le bac à sable, l'assistant IA de sh0 peut maintenant :
- Débogage approfondi : Cloner le dépôt de l'utilisateur, installer les dépendances, rechercher des patterns d'erreur, tester la connectivité
- Analyse de configuration : Lire le Dockerfile, nginx.conf, les fichiers d'environnement, package.json -- comprendre la pile complète
- Tests en direct : curl les endpoints de l'application depuis le même réseau, tester les connexions à la base de données, vérifier le DNS
- Audit de dépendances : Installer le projet, vérifier les vulnérabilités, vérifier la compatibilité des versions
- Reproduction de build : Cloner, installer, construire -- reproduire exactement l'échec que l'utilisateur constate
C'est la différence entre une IA qui lit les logs et une IA qui investigue réellement.
La leçon méthodologique
Notre workflow d'audit multi-sessions a détecté la sur-ingénierie initiale. Mais c'est le CEO qui a détecté l'erreur de conception fondamentale -- parce qu'il pense à ce dont les utilisateurs ont besoin, pas à ce que les ingénieurs craignent.
Le cycle construire-auditer-auditer-approuver fonctionne au mieux quand l'étape « approuver » inclut quelqu'un qui demande « mais est-ce que quelqu'un va réellement utiliser cela ? » Un bac à sable techniquement parfait qui ne peut pas installer npm est un bac à sable que personne n'activera.
La sécurité est une contrainte, pas un objectif. L'objectif est de donner à l'IA les outils pour réellement aider. La contrainte est de le faire sans créer de risque réel. Un conteneur jetable avec une liste de blocage minimale accomplit les deux.