GitHub - amlalabs/amla-sandbox Les cadres d’agents populaires exécutent généralement du code généré par un modèle de langage (LLM) via des mécanismes comme subprocess ou exec(). Cela revient à exécuter du code arbitraire sur votre machine hôte — une vulnérabilité critique. Une simple injection de prompt peut suffire à compromettre votre système. Actuellement, les frameworks comme LangChain, AutoGen ou SWE-Agent utilisent des méthodes d’exécution risquées : - LangChain : exec(command, globals, locals) → CVE-2025-68664, GitHub #5294 - AutoGen : subprocess.run() - SWE-Agent : subprocess.run(["bash", ...]) Certains frameworks proposent une isolation via Docker (comme OpenHands ou AutoGen), mais cela suppose de gérer un daemon Docker et une infrastructure de conteneurs complexe. amla-sandbox est une solution différente : un sandbox basé sur WebAssembly (WASM) avec une sécurité par capacités. Il permet aux agents d’appeler uniquement les outils que vous avez explicitement autorisés, avec des contraintes que vous définissez. Il inclut un système de fichiers virtuel isolé, sans accès réseau ni possibilité d’échapper à l’environnement (pas de shell, pas de sortie vers le système hôte). Aucun Docker, aucune machine virtuelle. Un seul binaire, fonctionnant partout. Pourquoi cela compte Appeler des outils est coûteux : chaque appel nécessite un aller-retour vers le modèle LLM. Dix appels = dix invocations du modèle. Le mode code permet de regrouper ces opérations, mais on ne peut pas exécuter sans contrôle le code généré. Les utilisateurs sont donc confrontés à un dilemme : payer le coût en tokens ou exécuter du code non sécurisé. amla-sandbox résout ce dilemme : il offre l’efficacité du mode code tout en garantissant une isolation réelle. Modèle de sécurité Le sandbox s’exécute dans un environnement WebAssembly, avec WASI pour une interface système minimale. WASM assure une isolation mémoire par défaut : la mémoire linéaire est vérifiée à chaque accès, et il est impossible d’atteindre l’espace mémoire hôte. Le runtime wasmtime utilisé est conçu avec une approche defense-in-depth et a même été formellement vérifié pour sa sécurité mémoire. Au-dessus de cette isolation, chaque appel d’outil passe par une validation de capacité : ```python from amla_sandbox import Sandbox, MethodCapability, ConstraintSet, Param sandbox = Sandbox( capabilities=[ MethodCapability( method_pattern="stripe/charges/*", constraints=ConstraintSet([ Param("amount") <= 10000, Param("currency").is_in(["USD", "EUR"]), ]), max_calls=100, ), ], tool_handler=my_handler, ) Cela fonctionne sandbox.execute('await stripe.charges.create({amount: 500, currency: "USD"})') Cela échoue : le montant dépasse la limite sandbox.execute('await stripe.charges.create({amount: 50000, currency: "USD"})') ``` Ce design s’inspire de la sécurité par capacités, comme dans le système seL4 : l’accès n’est pas implicite, il doit être explicitement accordé. Les agents n’ont pas d’autorités ambiantes simplement parce qu’ils s’exécutent dans votre processus. Cela est crucial face au problème fondamental des injections de prompt : une stratégie de défense en profondeur limite la portée des attaques. Démarrage rapide API JavaScript : les outils utilisent une syntaxe d’objet. Utilisez return ou console.log() pour les sorties. Système de fichiers virtuel : uniquement accessible sous /workspace et /tmp. Intégration avec LangGraph : prise en charge via des outils dédiés. Contrôle granulaire : chaque capacité peut être limitée en nombre d’appels, en paramètres, etc. Architecture Le sandbox suspend l’exécution lors d’un appel d’outil. Le processus hôte exécute l’outil après vérification des capacités, puis reprend l’exécution. Le runtime JavaScript (QuickJS) fonctionne à l’intérieur du WASM. Précompilation : la première exécution compile le module WASM (~300 ms). Une fois mis en cache, les chargements suivants prennent ~0,5 ms. Langage de contraintes Permet des correspondances de motifs sur les noms de méthodes. Exemple : stripe/charges/* autorise tous les appels à stripe.charges.create, stripe.charges.list, etc. Compromis Ce que vous obtenez : - Isolation sans infrastructure - Contrôle par capacités - Économie de tokens grâce au mode code Ce que vous n’obtenez pas : - Un environnement Linux complet - Prise en charge des modules natifs - Accès au GPU - Protection contre les boucles infinies (un while(true){} bloquera le processus — la limite de pas ne compte que les yields WASM, pas les instructions JS) Si vous avez besoin d’une machine virtuelle persistante avec des dépendances complexes, optez pour e2b ou Modal. amla-sandbox est conçu pour le cas courant : exécuter du code généré par des agents avec un accès contrôlé aux outils. Licence Le code Python est sous licence MIT. Le binaire WASM est propriétaire : vous pouvez l’utiliser avec ce package, mais ne pouvez pas le extraire ni le redistribuer séparément. Site web · Exemples · Documentation