Sandboxes pour agents IA : exécution de code sécurisée 2026

Votre agent IA vient d'écrire un script Python, et il veut maintenant l'exécuter. Ce script pourrait installer des dépendances, appeler une API, écrire des fichiers, puis se terminer proprement. Ou il pourrait lancer un rm -rf sur un volume monté, exfiltrer vos variables d'environnement, ou ouvrir un reverse shell — soit parce que le modèle a halluciné quelque chose de dangereux, soit parce qu'une injection de prompt le lui a ordonné.

C'est la réalité inconfortable des systèmes agentiques en 2026 : la capacité même qui rend les agents IA utiles — exécuter à la volée le code qu'ils génèrent — est aussi la plus grande surface d'attaque de votre stack. Si vous construisez quoi que ce soit où un LLM produit et exécute du code, la question n'est plus s'il faut isoler, mais jusqu'à quelle profondeur.

Ce guide décortique les technologies d'isolation, les plateformes bâties par-dessus, et les modèles qui séparent une démo jouet d'un déploiement sûr en production.

Pourquoi les conteneurs seuls ne suffisent pas

Le premier réflexe de la plupart des ingénieurs est de se tourner vers Docker. C'est familier, c'est partout, et ça semble isolé. Le problème : les conteneurs standards partagent le noyau de l'hôte. Chaque appel système (syscall) émis par le code de votre agent va directement au même noyau qui exécute vos autres charges de travail.

Ce noyau partagé est le vecteur d'évasion. Une seule faille noyau (kernel CVE) — et il en apparaît de nouvelles chaque année — peut permettre à du code non fiable de s'échapper du conteneur et d'atteindre l'hôte. Pour du code interne de confiance, ce risque est acceptable. Pour du code écrit par un LLM à partir d'un texte potentiellement empoisonné par un attaquant, il ne l'est pas.

Le principe de zero-trust pour les sandboxes d'agents est sans détour : traitez tout code généré par un LLM comme potentiellement malveillant. Pas « probablement correct ». Malveillant. Une fois cette posture adoptée, les choix d'architecture en découlent naturellement.

Les trois niveaux d'isolation

Il existe trois niveaux pratiques d'isolation, chacun échangeant des performances contre une frontière de sécurité plus solide.

Niveau 1 — Conteneurs standards (le minimum viable)

Docker, containerd et consorts. Les namespaces et les cgroups vous offrent une isolation des processus et des ressources, mais le noyau est partagé. C'est le plancher, pas le plafond. À n'utiliser que lorsque le code est semi-fiable ou que le rayon d'impact est réellement contenu — par exemple un conteneur éphémère sans réseau, sans secret, et avec un système de fichiers en lecture seule.

Niveau 2 — Noyaux en espace utilisateur (gVisor)

gVisor s'intercale entre la charge de travail et l'hôte. Il intercepte les appels système en espace utilisateur et réimplémente lui-même une grande partie de l'API du noyau, si bien que le code non fiable parle rarement directement au vrai noyau de l'hôte. Vous obtenez une frontière nettement plus solide que les conteneurs, pour un coût de performance modeste. Modal et plusieurs autres plateformes utilisent gVisor comme couche d'isolation par défaut, avec des démarrages à froid sous la seconde.

Niveau 3 — microVM (Firecracker, Kata Containers)

C'est l'étalon-or. Chaque charge de travail obtient son propre noyau invité dédié, tournant dans une machine virtuelle légère. Une vulnérabilité dans le noyau invité ne peut pas atteindre le noyau de l'hôte, car ce sont deux noyaux séparés avec une frontière de virtualisation matérielle entre eux.

Firecracker — la technologie même qui propulse AWS Lambda — est le choix de facto. Les chiffres l'expliquent : démarrage à froid en moins de 125 ms, surcoût mémoire inférieur à 5 Mio par VM, et surcoût de calcul inférieur à 5 pour cent par rapport au bare metal. Avec le snapshot et la restauration, vous pouvez provisionner une sandbox en environ 28 ms en restaurant une image mémoire préchauffée via une couche copy-on-write. Vous obtenez une isolation de niveau VM à une vitesse proche de celle d'un conteneur.

Comparatif des plateformes : qui exécute quoi

Vous construisez rarement sur Firecracker brut vous-même. Une vague de plateformes enveloppe désormais ces technologies d'isolation dans des SDK pensés pour les agents. Voici comment se comparent les principales options en matière d'isolation et de latence de démarrage à froid — les deux chiffres qui comptent le plus pour des agents interactifs.

E2B se distingue parce qu'elle a été bâtie spécifiquement pour les développeurs d'agents IA — ni pour le compute général, ni pour le CI/CD. Chaque sandbox obtient son propre noyau et son propre namespace réseau, si bien qu'une vulnérabilité du noyau invité ne peut atteindre l'hôte, et le SDK est façonné autour des workflows d'agents plutôt que rétro-adapté depuis un outil de déploiement.

Northflank adopte l'approche inverse : une plateforme de développement complète prenant en charge Firecracker, Kata Containers, Cloud Hypervisor et gVisor, vous laissant choisir le compromis sécurité/performance par charge de travail. Cette flexibilité compte lorsque certains de vos agents exécutent un outillage interne de confiance et d'autres du code arbitraire soumis par les utilisateurs.

Ce qu'une sandbox sécurisée impose réellement

La profondeur d'isolation est nécessaire mais pas suffisante. Une microVM avec un réseau grand ouvert et vos clés AWS montées à l'intérieur reste une catastrophe en sursis. La vraie isolation signifie que la sandbox ne peut atteindre ni les processus de l'hôte, ni ses systèmes de fichiers, ni ses interfaces réseau — et signifie que vous contrôlez exactement ce que la sandbox peut atteindre.

Voici un exemple minimal avec E2B qui exécute du code d'agent non fiable dans une frontière stricte :

from e2b_code_interpreter import Sandbox
 
# Chaque appel lance une microVM Firecracker isolée
with Sandbox.create(timeout=30) as sandbox:
    # Code généré par l'agent — traité comme non fiable
    execution = sandbox.run_code(agent_generated_code)
 
    if execution.error:
        # Capturez l'échec, ne renvoyez jamais d'erreurs brutes de l'hôte au modèle
        handle_error(execution.error)
    else:
        result = execution.results
 
# La sandbox est détruite à la sortie — aucun état persistant, aucune fenêtre d'évasion

Les primitives défensives à superposer à toute sandbox :

• Aucune authentification ambiante. Ne montez jamais de clés cloud, de mots de passe de base de données ou de jetons à longue durée de vie dans la sandbox. Si le code a besoin d'une ressource externe, faites-la transiter par un proxy que vous contrôlez et auditez.
• Listes d'autorisation en sortie. Refus par défaut du trafic réseau sortant. N'ouvrez que les hôtes précis qu'exige la tâche. Ce seul contrôle neutralise la plupart des tentatives d'exfiltration.
• Délais courts et plafonds de ressources stricts. Bornez le CPU, la mémoire et le temps d'horloge. Une boucle folle ou un mineur de cryptomonnaie doit mourir en quelques secondes.
• Éphémère par défaut. Détruisez la sandbox après chaque tâche. L'état persistant est pratique et dangereux ; n'y recourez que pour une raison précise et avec un plan de nettoyage.
• Lecture seule autant que possible. Montez les entrées en lecture seule. Donnez à l'agent un unique répertoire de travail où écrire.

La fuite qui n'a rien à voir avec le code

Voici le résultat qui recadre tout le problème. Une recherche de l'Université de Washington a constaté que 63,4 pour cent des agents LLM sans isolation appropriée ont divulgué des données sensibles via la conversation — et non via l'exécution de code.

Relisez bien. Le danger n'est pas seulement que l'agent exécute curl evil.com. C'est qu'un agent serviable, lorsqu'une instruction injectée le lui demande, va volontiers lire un fichier et en résumer le contenu dans le chat. Aucun code malveillant n'est exécuté. Le modèle fait simplement ce qu'on lui a dit, et votre secret s'échappe par le canal de réponse.

Cela signifie que sandboxer le runtime du code n'est que la moitié du travail. Vous devez aussi sandboxer les données que l'agent peut voir et les canaux par lesquels il peut s'exprimer. Traitez la fenêtre de contexte de l'agent comme une partie de la frontière de confiance :

• Gardez les secrets entièrement hors du contexte ; référencez-les par identifiant, pas par valeur.
• Filtrez et classifiez ce que les outils renvoient au modèle avant que cela n'atterrisse dans le contexte.
• Appliquez des garde-fous de sortie sur la réponse finale de l'agent, pas seulement sur ses appels d'outils.

Une microVM parfaitement isolée ne vous sert à rien si l'agent lit votre base de données clients et la recopie dans une réponse.

Adapter la profondeur d'isolation au risque

Toutes les charges de travail n'ont pas besoin d'une microVM. Le bon modèle consiste à adapter la profondeur d'isolation à votre modèle de menace réel :

• Code interne de confiance, sans secret à proximité → un conteneur durci suffit.
• Code semi-fiable, rayon d'impact limité → gVisor vous offre un solide juste milieu, à faible latence.
• Code arbitraire, influencé par l'utilisateur ou généré par un LLM, avec quoi que ce soit de précieux à portée → microVM, point final.

Dans le doute, allez plus profond. L'écart de coût entre un conteneur et une microVM Firecracker se mesure désormais en dizaines de millisecondes et en pourcentages à un chiffre de surcoût. Le coût d'une évasion, lui, se mesure en rapports d'incident et en confiance perdue.

Passer en production

Si vous déployez aujourd'hui de l'exécution de code agentique, une architecture de départ saine ressemble à ceci :

1. Choisissez un fournisseur de sandbox basé sur microVM (E2B pour le natif agent, Northflank si vous voulez contrôler le niveau d'isolation par charge de travail).
2. Exécutez chaque exécution de code de manière éphémère — une sandbox par tâche, détruite à la fin.
3. Refus réseau par défaut, avec une liste d'autorisation en sortie explicite par type de tâche.
4. Faites transiter toutes les authentifications par un proxy audité ; rien de sensible ne réside dans la sandbox.
5. Protégez le canal de conversation avec autant de soin que le canal de code, car c'est là que se produit la majorité des fuites réelles.

L'ère agentique tourne sur du code qu'aucun humain n'a relu avant son exécution. C'est toute la proposition de valeur — et tout le risque. Le sandboxing, c'est la manière de conserver la valeur sans hériter de la catastrophe.

Chez Noqta, nous aidons les équipes de la région MENA à concevoir et déployer des systèmes d'agents IA avec la sécurité intégrée dès le premier jour — de l'architecture d'isolation aux frontières de données zero-trust. Si vous mettez des agents autonomes en production, le moment de bien régler la sandbox, c'est avant le premier incident, pas après.

Sources : Firecrawl — AI Agent Sandbox, Northflank — Best Code Execution Sandbox, Spheron — E2B, Daytona, Firecracker Setup, ARMO — AI Agent Sandboxing Guide.