Le pari Sandbox

25 janvier 2026 : le pari

Deux mois après le lancement de LikeClaw, nous avons pris la décision qui allait définir le produit. Nous avons tout misé sur l’exécution sandboxée E2B.

Jusqu’à ce moment-là, nos agents IA exécutaient des tâches de manière relativement traditionnelle. Après cela, chaque tâche — chaque exécution de code, chaque opération sur des fichiers, chaque travail en arrière-plan — s’exécutait dans un conteneur sandbox E2B isolé.

Ce n’était pas une fonctionnalité de sécurité que nous avons ajoutée. C’était une décision architecturale fondamentale qui a changé le fonctionnement de l’ensemble de la plateforme. Et c’était la meilleure décision que nous ayons prise.

Pourquoi le sandboxing est plus important que tout le reste

Regardez le paysage des agents IA au début de 2026. Un schéma se répète partout : les utilisateurs donnent un accès illimité à leurs machines aux agents IA.

OpenClaw fonctionne sur votre système local. Il lit vos fichiers. Il exécute du code avec vos autorisations. Il stocke les clés API en texte clair. Les chercheurs en sécurité ont documenté des vulnérabilités généralisées dans la plateforme et son marché, entraînant des avertissements de plusieurs organisations de sécurité.

La cause profonde n’est pas qu’OpenClaw soit mal écrit. C’est que l’architecture est fondamentalement dangereuse. Lorsque vous donnez à un agent IA un accès brut à votre système, toute erreur — de l’IA, d’un auteur de compétence, d’une attaque par injection de prompt — a un rayon d’impact illimité. Une mauvaise compétence peut installer des logiciels malveillants sur votre machine. Une injection de prompt peut lire vos clés SSH. Une commande hallucinée peut supprimer vos fichiers.

Le sandboxing élimine toute la catégorie de risque.

Comment fonctionnent nos sandboxes

Lorsque vous exécutez une tâche sur LikeClaw, voici ce qui se passe :

Une nouvelle sandbox est créée. Un conteneur E2B isolé se met en place en moins de deux secondes. Il a son propre système de fichiers, son propre espace de processus, son propre réseau. Il est complètement isolé de chaque autre sandbox et de chaque autre utilisateur.

Vos fichiers de travail sont synchronisés. Les fichiers de votre espace de travail sont copiés dans la sandbox. L’IA peut les lire, les modifier, en créer de nouveaux. Mais seulement à l’intérieur de la sandbox.

L’IA exécute la tâche. À l’intérieur de la sandbox, l’IA a toutes les capacités. Elle peut exécuter du code, installer des paquets, faire des requêtes réseau, lire et écrire des fichiers. C’est un environnement entièrement fonctionnel. La différence est que “entièrement fonctionnel” signifie la sandbox, pas votre machine.

Les résultats sont synchronisés. Lorsque la tâche est terminée, les fichiers que l’IA a créés ou modifiés sont synchronisés de nouveau dans votre espace de travail dans notre stockage crypté.

La sandbox est détruite. Disparue. Chaque processus tué. Chaque fichier supprimé. Chaque connexion réseau fermée. Rien ne persiste. Rien ne fuit. Rien ne reste.

Si l’IA fait quelque chose de mal — exécute du code malveillant, suit une injection de prompt, exécute une mauvaise compétence — les dégâts sont contenus dans une sandbox qui sera détruite en quelques secondes. Votre machine, vos fichiers, vos clés API, vos identifiants ne sont jamais en danger.

Le défi d’ingénierie

Le sandboxing semble simple. “Il suffit de l’exécuter dans un conteneur.” En pratique, c’était le défi d’ingénierie le plus complexe de tout le projet.

Synchronisation des fichiers. Les utilisateurs ont besoin de leurs fichiers à l’intérieur de la sandbox, et ils ont besoin de la sortie de l’IA de retour dans leur espace de travail. Cette synchronisation bidirectionnelle doit être rapide, fiable et gérer les conflits. Nous avons construit une couche de synchronisation VFS (Virtual File System) qui surveille les changements dans les deux directions.

Exécution des tâches en arrière-plan. Les tâches planifiées s’exécutent aussi dans des sandboxes. Une tâche qui s’exécute à 3 heures du matin doit créer une sandbox, synchroniser des fichiers, exécuter, synchroniser les résultats et nettoyer — le tout sans qu’un utilisateur soit en ligne.

Performance. La création de sandboxes ajoute de la latence. Nous avons optimisé le temps de démarrage à moins de deux secondes. Les utilisateurs ne le remarquent à peine. Mais y parvenir a nécessité une gestion minutieuse des modèles, une initialisation paresseuse et des stratégies de préchauffage.

Coût. Chaque sandbox coûte des ressources de calcul. Nous devions équilibrer la sécurité (toujours sandbox) avec l’économie (les sandboxes coûtent de l’argent). La réponse était des limites de sandbox par niveau — les utilisateurs gratuits obtiennent un nombre défini d’exécutions, les utilisateurs pro en obtiennent plus, les utilisateurs avancés en obtiennent un nombre illimité.

La ligne à ne pas franchir

Voici la chose à propos de la sécurité : vous ne pouvez pas le faire à moitié.

Vous ne pouvez pas sandboxer certaines tâches et pas d’autres. Vous ne pouvez pas sandboxer les utilisateurs gratuits mais laisser les utilisateurs payants fonctionner en brut. Vous ne pouvez pas sandboxer l’exécution de code mais pas l’accès aux fichiers. Toute lacune dans le modèle de sandbox devient un vecteur d’attaque.

Nous avons donc tracé une ligne : tout s’exécute dans une sandbox. Pas d’exceptions. Pas de portes de sortie. Pas de “mode expert” qui contourne l’isolement.

Cela signifie que certaines choses sont légèrement plus lentes que l’exécution locale. Cela signifie que certaines choses nécessitent une étape supplémentaire (synchronisation des fichiers). Cela signifie que nous ne pouvons pas offrir l’accès complet à la machine que les agents IA locaux fournissent.

Ça ne nous dérange pas. Parce que nous ne pouvons pas non plus offrir l’installation de logiciels malveillants, le vol d’identifiants ou la compromission de systèmes. Et nos utilisateurs non plus.

0 compétences malveillantes. 0 systèmes compromis. 0 incidents de sécurité.

C’est le pari du sandboxing. Et ça porte ses fruits.