Un conteneur est-il suffisant ou ai-je besoin d'une microVM ?

Cela dépend de ce qui s'y exécute. Pour votre propre code présentant un risque d'injection, un conteneur durci sans identifiants et avec des flux de sortie restreints est généralement proportionné. Pour du code arbitraire provenant de sources non approuvées, partez du principe que le noyau partagé peut être contourné et utilisez une microVM.

En quoi cela diffère-t-il des outils de moindre privilège ?

Le moindre privilège limite ce que l'agent peut demander ; le bac à sable limite ce qui se passe lorsque quelque chose s'exécute malgré tout. L'un régit la requête, l'autre régit l'environnement dans lequel elle s'exécute, et les agents qui exécutent du code ont besoin des deux.

Le bac à sable ralentit tout. Est-ce que cela en vaut la peine ?

Comparez par rapport au coût de l'alternative, pas par rapport à zéro. La majeure partie de la latence provient du démarrage de l'environnement, ce que les pools et les images préchauffées éliminent en grande partie ; la défaillance qu'il prévient est une compromission de l'hôte qui exécute l'agent.

Sécurité et supervisionMis à jour 2026-08-22 · Version 1.0

Exécution en bac à sable

Exécutez tout ce qu'un agent génère ou invoque au sein d'un environnement isolé et jetable, sans identifiants ambiants, avec un système de fichiers restreint, une sortie contrôlée et des limites strictes de ressources. Le bac à sable n'est pas là parce que l'agent est malveillant, mais parce que les entrées de l'agent peuvent l'être.

Preuve: Observation du secteurConfiance: ÉlevéSource: Observation du secteurSource: Expérience personnelleSource: Publication scientifique

Lisible par machine: JSON

Définition

L'exécution en bac à sable consiste à exécuter le code généré par l'agent et les actions invoquées par celui-ci au sein d'un environnement isolé et éphémère dont le système de fichiers, le réseau, les identifiants et les ressources sont limités par l'hôte plutôt que par l'agent, afin qu'un agent compromis ou erroné ne puisse rien affecter en dehors de cet environnement.

Problème

Un agent qui exécute du code sur l'hôte hérite de cet hôte : ses identifiants, son système de fichiers, sa position réseau. Une seule injection réussie ou une seule commande erronée mais exécutée avec assurance devient alors impossible à distinguer d'une compromission de la machine.

Quand l'utiliser

Utilisez-le dès qu'un agent exécute du code, lance des commandes shell, installe des paquets ou traite des fichiers non approuvés. Le seuil est bas : si l'agent peut déclencher une exécution, cette exécution doit se faire dans un bac à sable.

Solution

Rendez-le éphémère. Créez l'environnement par tâche, détruisez-le ensuite, et ne transmettez jamais un état que la tâche suivante n'a pas demandé. C'est par la persistance qu'une compromission ponctuelle devient un point d'ancrage.

Supprimez les identifiants ambiants. Rien dans l'environnement ne devrait être utilisable simplement parce qu'il s'y trouve ; n'injectez que les secrets strictement nécessaires à la tâche, pour sa seule durée.

Limitez le système de fichiers à l'ensemble de travail. Montez le dépôt ou l'entrée, rien d'autre, et montez en lecture seule tout ce qui n'a pas besoin d'être écrit.

Contraignez les flux de sortie à l'intérieur du bac à sable, pas autour. L'isolation et la politique réseau représentent le même contrôle du point de vue de l'attaquant, et un bac à sable avec un réseau ouvert est une prison avec un téléphone.

Limitez les ressources — CPU, mémoire, disque, temps d'exécution réel, nombre de processus. La consommation incontrôlée est le mode de défaillance qui survient en premier et le plus souvent, généralement sans le moindre adversaire.

Journalisez ce qui a franchi la limite : quels fichiers sont entrés, lesquels sont sortis, quelles destinations ont été atteintes. La limite n'est utile que si vous pouvez voir ce qui l'a traversée.

Composants

Une primitive d'isolation : conteneur, microVM ou équivalent, choisie selon le niveau de robustesse requis par la charge de travail.Une gestion du cycle de vie éphémère, avec la destruction comme comportement par défaut plutôt que comme simple étape de nettoyage.Un mécanisme d'injection de secrets limité à la tâche et à sa durée.Une politique réseau appliquée à l'intérieur des limites du bac à sable.Des quotas de ressources et des délais d'expiration (timeouts), appliqués par l'hôte.Une journalisation aux limites : entrées, sorties et destinations.

Avantages

Transforme l'événement « l'agent a exécuté quelque chose de malveillant » d'un incident grave en un conteneur jeté.
Permet de donner en toute sécurité une véritable capacité d'exécution à un agent, ce qui est souvent indispensable pour le rendre utile.
Limite aussi bien les erreurs involontaires que les attaques — le même contrôle intercepte une boucle infinie et une charge utile injectée.
Offre un espace d'observation clair : tout ce que la tâche a touché a franchi une seule et unique limite.

Risques

Une isolation plus faible que prévu : un noyau partagé ne constitue pas une barrière de sécurité contre une évasion déterminée, et traiter un conteneur comme une microVM est une erreur de catégorie.
Des identifiants introduits en douce par commodité — un seul fichier de configuration monté annule tout l'intérêt du modèle.
Des bacs à sable qui deviennent discrètement persistants parce que la reconstruction est lente, faisant ainsi disparaître le caractère éphémère qui garantissait la sécurité.
Une évasion via la surface partagée restante : volumes montés, API de l'orchestrateur ou réseau que le bac à sable peut encore atteindre.

Quand ne pas l'utiliser

Les agents en lecture seule sans capacité d'exécution, où il n'y a rien à isoler et où le coût n'apporte aucun bénéfice.
Les parcours en ligne critiques en termes de latence, où le démarrage de l'environnement domine la tâche et où un contrôle plus restreint — un interpréteur limité, une fonction pure — est plus adapté.
Lorsque le bac à sable aurait besoin des identifiants mêmes qu'il a pour but de retenir, ce qui indique que la tâche devrait être divisée plutôt qu'isolée.

Technologies

ContainersmicroVMs (Firecracker / gVisor)Ephemeral workspacesResource quotas and timeoutsScoped secret injection

Exemples

Un agent de codage qui clone un dépôt dans un conteneur neuf par tâche, avec le dépôt monté, aucun identifiant cloud présent et des flux de sortie limités au registre de paquets. L'installation d'une dépendance malveillante détruit le conteneur et rien d'autre.
Un agent d'analyse de données exécutant du code Python généré dans une microVM avec le jeu de données d'entrée monté en lecture seule, aucun réseau et une limite de temps d'exécution réel. Le code généré peut être erroné ; il ne peut pas être coûteux ni exfiltrer de données.
Un agent de traitement de documents qui ouvre des PDF non approuvés dans un environnement jetable, car une faille d'analyseur dans un fichier téléversé constitue une véritable voie d'accès à l'hôte et le fichier provient de l'extérieur.

KPI

Part des exécutions exécutées en bac à sable: Le taux de couverture. Tout ce qui s'exécute en dehors du bac à sable représente la posture de sécurité réelle, indépendamment de ce que fait la part exécutée en bac à sable.
Durée de vie du bac à sable: La durée de vie des environnements. Des durées de vie croissantes signifient que le caractère éphémère s'érode au profit de la persistance.
Dépassements des limites de ressources: Tâches arrêtées par un quota ou un délai d'expiration. Un indicateur utile mêlant générations incontrôlées et limites réelles définies de manière trop stricte.
Secrets présents au moment de l'exécution: Nombre d'identifiants accessibles à l'intérieur de l'environnement. L'objectif est le strict minimum requis par la tâche, et souvent zéro.

Modes de défaillance observés

Le montage de commodité : un répertoire personnel, un fichier d'identifiants ou un socket monté pour qu'une tâche cesse d'échouer.
La réutilisation persistante : l'environnement cesse d'être propre à chaque tâche car la reconstruction coûte trop cher, de sorte que l'état et la compromission survivent tous deux.
Flux de sortie ouverts à l'intérieur de la limite : une isolation forte avec un réseau libre n'est qu'un confinement limité au système de fichiers.
Accessibilité de l'orchestrateur : le bac à sable peut appeler l'API qui gère les bacs à sable, ce qui constitue une évasion par conception plutôt que par faille.

Leçons apprises

Isolez l'exécution avant de faire confiance à la génération. C'est le bac à sable qui permet de laisser un agent exécuter du code de manière raisonnable.
Le caractère éphémère est la véritable propriété de sécurité ; l'isolation seule ne fait que différer le problème.
L'identifiant qui n'est pas présent ne peut pas être volé — et c'est le seul contrôle qui tient après une évasion.
La plupart des activations de bac à sable sont des erreurs involontaires, pas des attaques. C'est la preuve que le modèle fonctionne, et non qu'il était inutile.

FAQ

Un conteneur est-il suffisant ou ai-je besoin d'une microVM ?: Cela dépend de ce qui s'y exécute. Pour votre propre code présentant un risque d'injection, un conteneur durci sans identifiants et avec des flux de sortie restreints est généralement proportionné. Pour du code arbitraire provenant de sources non approuvées, partez du principe que le noyau partagé peut être contourné et utilisez une microVM.
En quoi cela diffère-t-il des outils de moindre privilège ?: Le moindre privilège limite ce que l'agent peut demander ; le bac à sable limite ce qui se passe lorsque quelque chose s'exécute malgré tout. L'un régit la requête, l'autre régit l'environnement dans lequel elle s'exécute, et les agents qui exécutent du code ont besoin des deux.
Le bac à sable ralentit tout. Est-ce que cela en vaut la peine ?: Comparez par rapport au coût de l'alternative, pas par rapport à zéro. La majeure partie de la latence provient du démarrage de l'environnement, ce que les pools et les images préchauffées éliminent en grande partie ; la défaillance qu'il prévient est une compromission de l'hôte qui exécute l'agent.