Le bac à sable (Sandbox) est un environnement d’exécution restreint : les programmes y sont exécutés et n’ont accès qu’aux ressources explicitement autorisées, de sorte que, en cas d’erreur ou d’exploitation malveillante, il est difficile d’affecter le système hôte et les autres programmes. Le bac à sable repose sur le postulat du « code non fiable », c’est-à-dire des programmes provenant de tiers, d’entrées utilisateur ou générés par des modèles, dont on ne peut pas présumer qu’ils sont sûrs.

Les racines conceptuelles du bac à sable se trouvent dans l’isolation des processus des systèmes d’exploitation. En 1979, Version 7 Unix a introduit l’appel système chroot (complété dans BSD par Bill Joy en 1982), qui enferme le répertoire racine d’un processus dans un sous-arbre spécifique, le rendant « aveugle » au reste du système de fichiers ; en 1993, Wahbe et al. ont proposé dans leur article Efficient Software-Based Fault Isolation l’isolation logicielle des défaillances (SFI), qui utilise la réécriture d’instructions pour limiter les accès mémoire des modules non fiables à leurs propres segments d’adresses, permettant d’isoler les défaillances sans démarrer de machine virtuelle. Au milieu des années 1990, les applets Java ont popularisé le terme « bac à sable » : le code dans le navigateur ne peut par défaut effectuer que des actions limitées, toute élévation de privilèges nécessitant une autorisation explicite ; Dean et al. ont systématiquement analysé ce modèle dans leur article Java Security: From HotJava to Netscape and Beyond.

Les implémentations modernes du bac à sable superposent trois couches : les primitives du noyau, la virtualisation et les environnements d’exécution des langages. La couche noyau utilise seccomp pour filtrer les appels système, et les namespaces et cgroups pour isoler les vues et les ressources, permettant ainsi aux conteneurs d’être isolés les uns des autres sur un même noyau ; la couche de virtualisation utilise de légères micro-machines virtuelles pour obtenir des frontières plus fortes, Firecracker réduisant le temps de démarrage et l’empreinte mémoire à des niveaux millisecondes grâce à un modèle de périphérique épuré (Firecracker: Lightweight Virtualization for Serverless Applications, NSDI 2020) ; la couche langage intègre le bac à sable directement dans l’environnement d’exécution, la mémoire linéaire et le mécanisme d’importation de WebAssembly garantissant que les modules ne peuvent interagir qu’avec les objets explicitement transmis. Récemment, les agents d’IA ont commencé à exécuter du code généré par des modèles, transformant le bac à sable d’un « mécanisme de sécurité » en une « infrastructure par défaut ».

La valeur du bac à sable réside dans la limitation des effets des défaillances et des attaques à l’intérieur des frontières, permettant l’exécution en toute confiance, l’évaluation itérative et le retour en arrière à tout moment du code non fiable. Cependant, il n’est pas absolument sûr : les vulnérabilités du noyau, les canaux auxiliaires liés aux caches partagés et les erreurs de configuration peuvent tous compromettre l’isolation, faisant de l’« évasion » un enjeu constant dans la confrontation entre défenseurs et attaquants. D’autre part, il y a le coût : plus l’isolation est forte, moins les capacités système disponibles sont nombreuses, les accès aux fichiers, au réseau et au GPU devant souvent être accordés un par un ; la difficulté d’ingénierie des bacs à sable consiste précisément à tracer une frontière appropriée, selon la tâche, entre « confinement » et « utilité ».