Sandboxing des agents

1. Vue d'ensemble du concept et problème systémique

Les agents autonomes expriment leur plein potentiel uniquement lorsqu'ils peuvent exécuter des commandes système dans un terminal, écrire du code, installer des paquets et tester des applications en temps réel. Cependant, accorder à l'agent un accès direct au système hôte du développeur ou au serveur constitue un risque critique pour la sécurité de l'information :

1. Imprévisibilité des LLM : Le modèle peut générer une commande destructrice suite à une hallucination (par exemple, un rm -rf récursif accidentel sur un chemin mal formé).
2. Attaques par Prompt Injection indirecte (Indirect Injection) : Si l'agent analyse un site web externe ou lit un dépôt GitHub tiers, un prompt malveillant caché dans le texte peut contraindre le modèle à lire les fichiers ~/.ssh/id_rsa, .env et à les envoyer vers le serveur distant de l'attaquant via curl.
3. Épuisement des ressources de l'hôte : Une boucle infinie ou une Fork Bomb peut paralyser l'ensemble du serveur.

Le Sandboxing d'Agent résout ce conflit en fournissant à l'agent un environnement absolument sûr, isolé et éphémère.

2. Taxonomie architecturale et modèle mental

Selon les exigences de sécurité et de rapidité de démarrage, on distingue quatre niveaux d'isolation architecturaux :

• 1. Isolation par processus OS (Namespaces & Cgroups, Bubblewrap) : Séparation fondamentale du système de fichiers, des PID et des limites mémoire au sein de Linux. Offre le démarrage le plus rapide (<50 ms), mais ne protège pas contre les exploits au niveau du noyau.
• 2. Virtualisation au niveau du noyau (gVisor / User-space Kernel) : Couche spécifique développée par Google qui émule le noyau Linux dans l'espace utilisateur. Chaque appel système (syscall) est filtré et n'interagit jamais avec le noyau réel de l'hôte.
• 3. MicroVM matérielles (AWS Firecracker, Kata Containers) : La référence en matière de sécurité cloud. Une véritable machine virtuelle minimaliste dotée de son propre noyau Linux, démarrant en 100–150 ms et totalement isolée au niveau de l'hyperviseur matériel KVM.
• 4. WebAssembly (Wasm / WASI Runtimes) : Exécution du code dans un bytecode isolé interne (par exemple, Wasmtime). Idéal pour l'exécution sécurisée de JavaScript/Python sans système d'exploitation, mais présente des limitations concernant les appels aux utilitaires système.

3. Pipeline technique et mécanique interne

Le cycle de vie de l'exécution isolée d'une tâche se compose de 4 étapes :

1. Provisionnement Éphémère (Déploiement rapide) : L'orchestrateur crée une nouvelle instance de micro-conteneur à partir d'un snapshot pré-préparé contenant l'environnement installé (Node.js, Python, Git).
2. Montage de l'Espace de Travail Virtuel & Redaction des Secrets (Montage de l'environnement) : Seul le dossier de travail du projet actuel est monté dans le sandbox. Tous les jetons d'accès réels (clés AWS, identifiants DB de Production) sont remplacés par des jetons mock ou des jetons éphémères à portée limitée.
3. Exécution & Interception des Syscalls (Exécution contrôlée) : L'agent envoie la commande via gRPC ou WebSocket API. Le driver du sandbox exécute la commande, diffuse le flux stdout/stderr à l'agent, et arrête automatiquement l'exécution si le processus dépasse la limite de temps (Execution Timeout) ou de mémoire (OOM Watchdog).
4. Démontage Instantané & Garbage Collection (Nettoyage complet) : À la fin de la tâche, tout le conteneur est irrévocablement détruit ainsi que tous les artefacts temporaires. Aucun état n'est transféré à la session suivante.

4. Scénarios d'ingénierie pratiques en production

01. Code Interpreter sécurisé pour les utilisateurs

Le service permet aux utilisateurs de télécharger des tableaux CSV/Excel et de demander à l'agent d'écrire un script Python pour une visualisation complexe. Le code s'exécute dans un micro-conteneur E2B sans risque de lecture des fichiers voisins d'autres utilisateurs.

02. Test autonome de dépôts tiers et de PR

L'agent télécharge automatiquement une Pull Request, effectue npm install et lance les tests. Si une dépendance contient un script preinstall malveillant (Supply-chain attack), l'attaque échouera contre les murs du sandbox.

03. Scraping web et navigation isolés

L'agent utilise Headless Chromium pour consulter des sites dangereux sur le réseau. Le navigateur tourne dans un conteneur isolé sans accès au magasin de mots de passe système ni au VPN d'entreprise.

5. Pièges courants, erreurs typiques et sécurité

• Fuites SSRF via Network Egress (Fuite d'adresses internes) : Par défaut, le conteneur peut pinguer le réseau local de l'hôte. Il est impératif de configurer une politique stricte de trafic egress (Network Isolation), bloquant l'accès à localhost et aux sous-réseaux des métadonnées cloud.
• Déséquilibre Latency vs Security : Les machines virtuelles complètes mettent plusieurs secondes à démarrer, ce qui frustre l'utilisateur. Utilisez un pool de conteneurs « préchauffés » (Warm Pools) ou la technologie Forking MicroVM pour une réponse instantanée.
• Starvation des Ressources (Fork Bombs) : Un agent ou un script peut créer des processus indéfiniment (:(){ :|:& };:). Limitez toujours strictement le nombre maximal de processus (pids_limit) et la mémoire (mem_limit).