Guide Agent Sandbox : solution complète pour exécuter du code IA en toute sécurité

Au printemps 2025, des chercheurs en sécurité ont testé les 16 agents IA publics du batch YCombinator Spring. Résultat ? 7 ont été compromis. Certains ont fuité des données utilisateur, d’autres ont permis l’exécution distante de code, et l’un a carrément effacé une base de données.

C’est le prix à payer lorsque vous laissez un agent IA exécuter du code. Plus de liberté, plus de risques.

Tout le monde utilise l’IA pour écrire du code, lancer des scripts, traiter des données. Mais avez-vous déjà réfléchi à ceci : oseriez-vous exécuter directement sur un serveur du code généré par un grand modèle ? S’il lance un rm -rf /, ou envoie discrètement vos clés AWS vers un serveur externe, vous n’aurez nulle part où pleurer.

C’est précisément pour cela qu’Agent Sandbox existe.

Quelle est la plus grande différence entre un agent IA et une application traditionnelle ? Ce n’est pas qu’il dialogue, ni qu’il comprend vos instructions — c’est qu’il écrit et exécute du code de lui-même.

Imaginez ce scénario : vous demandez à un agent d’analyse de données de traiter 1 Go de ventes. Il écrit un script Python pour lire, analyser et générer des graphiques. Ce code est entièrement généré par le modèle, sans relecture de votre part. Et puis il s’exécute.

Voici les risques critiques :

Exécution arbitraire de code. Le grand modèle ne connaît pas les limites de sécurité. os.system(), subprocess.run() — il les utilise sans réfléchir aux conséquences. Un prompt bien conçu peut lui faire exécuter n’importe quelle commande système.

Attaque par épuisement des ressources. Le code généré par l’agent n’a aucune conscience des ressources. Une boucle infinie sature le CPU, une récursion sans fin épuise la mémoire. Votre serveur tombe en panne.

Accès non autorisé au système de fichiers. Sans restriction des chemins, l’agent peut lire tout le disque et écrire n’importe où. Configurations, clés, données utilisateur — tout est à sa portée.

Fuite de données via le réseau. Une requête HTTP cachée dans le code peut envoyer des données sensibles vers un serveur attaquant, sans que vous le remarquiez.

OWASP a publié en 2025 le Top 10 des menaces de sécurité pour les agents IA. En tête : la manipulation de l’interaction outil-agent. En bref, un attaquant peut, via une injection de prompt ou d’autres moyens, détourner la façon dont l’agent appelle vos outils.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

Des cas d’attaque réels existent déjà :

• Vulnérabilité RCE Langflow : faille d’exécution distante de code découverte par Horizon3, permettant l’exécution arbitraire via une entrée malveillante.
• Vulnérabilité d’exécution automatique Cursor : des chercheurs ont montré que Cursor exécutait automatiquement certaines commandes MCP, déclenchables par un prompt malveillant.
• Effacement de base Replit : du code généré par l’IA a supprimé accidentellement toute une base de données.

Le sandbox n’est pas optionnel. C’est une infrastructure de base pour les applications agent IA — comme vous n’exposeriez pas un serveur sur Internet sans pare-feu, vous ne devriez pas laisser l’IA exécuter du code sans sandbox.

La valeur du sandbox se résume en trois points : isolation — enfermer le code à risque ; limitation — plafonner CPU, mémoire, réseau et accès fichiers ; audit — tracer ce qui s’est passé pour enquêter en cas d’incident.

Comparaison des principales solutions sandbox

Maintenant que le besoin est clair, quelle technologie choisir ? Trois approches dominent : conteneurs (Docker), gVisor et micro-VM Firecracker.

Voici un tableau comparatif pour vous situer :

Conteneur Docker : rapide mais insuffisant

Docker est le choix le plus courant. Démarrage rapide, faible consommation, écosystème mature. Mais les conteneurs partagent le noyau de l’hôte.

Concrètement : les processus sont isolés par namespace, mais un attaquant exploitant une faille noyau peut franchir la frontière du conteneur et obtenir root sur l’hôte.

Plusieurs failles d’évasion de conteneur ont été divulguées en 2024. Pour du code non fiable généré par l’IA, la frontière Docker ne suffit pas.

gVisor : un faux noyau en espace utilisateur

gVisor est un projet open source de Google. L’idée : ne pas utiliser directement le noyau hôte, mais implémenter un faux noyau (Sentry) en espace utilisateur.

Quand le programme dans le conteneur fait un appel système, gVisor l’intercepte et Sentry le traite. Seules les opérations sûres passent ; le reste est refusé. Même un code malveillant ne touche pas le vrai noyau.

Avantage : bonne compatibilité, la plupart des images Docker tournent telles quelles. Inconvénient : perte de performance d’environ 10-20 %, et certains appels système spéciaux peuvent ne pas être supportés.

GKE (Google Kubernetes Engine) supporte gVisor nativement : une ligne runtimeClassName: gvisor dans la config Pod suffit.

Firecracker : isolation matérielle réelle

Firecracker est la technologie de micro-VM open source d’AWS. Chaque sandbox est une petite machine virtuelle avec son propre noyau.

Conséquence : même avec root dans le sandbox et une faille noyau exploitée, l’attaquant reste confiné dans la VM, sans impact sur l’hôte.

Firecracker démarre en 100 à 800 ms, avec une empreinte bien inférieure aux VM classiques (128 Mo de RAM minimum).

E2B, AWS Bedrock AgentCore et autres services sandbox professionnels reposent sur Firecracker.

Cadre de décision

Comment choisir ? Un arbre de décision simple :

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

1. Développement local ou tests ? Docker suffit, rapide et pratique.
2. Déploiement en production ?
   • Sécurité moyenne, performance prioritaire → gVisor
   • Haute sécurité, conformité stricte → Firecracker
3. Pas envie d’opérer l’infra vous-même ? Service managé (E2B, Bedrock AgentCore)

Mise en pratique : sandbox de développement local

Assez de théorie, passons à la pratique. Stack : FastAPI + Jupyter Kernel + conteneur gVisor.

Pourquoi cette combinaison ?

• FastAPI expose une API HTTP simple ; l’agent IA soumet des requêtes d’exécution via REST
• Jupyter Kernel offre un environnement Python interactif avec persistance des variables
• Le conteneur gVisor isole le code malveillant de l’hôte

Étape 1 : service FastAPI

Créez un fichier main.py :

# main.py
import asyncio
from contextlib import asynccontextmanager
from fastapi import FastAPI, HTTPException
from jupyter_client.manager import AsyncKernelManager
from pydantic import BaseModel

app = FastAPI()

class CodeRequest(BaseModel):
    code: str

class ExecutionResult(BaseModel):
    output: str

@asynccontextmanager
async def kernel_client():
    """Gère le cycle de vie du Jupyter Kernel"""
    km = AsyncKernelManager(kernel_name="python3")
    await km.start_kernel()
    kc = km.client()
    kc.start_channels()
    await kc.wait_for_ready()
    try:
        yield kc
    finally:
        kc.stop_channels()
        await km.shutdown_kernel()

async def execute_code(code: str, timeout: int = 30) -> str:
    """Exécute le code et retourne le résultat"""
    async with kernel_client() as kc:
        msg_id = kc.execute(code)
        try:
            while True:
                reply = await asyncio.wait_for(
                    kc.get_iopub_msg(),
                    timeout=timeout
                )
                if reply["parent_header"]["msg_id"] != msg_id:
                    continue
                msg_type = reply["msg_type"]
                if msg_type == "stream":
                    return reply["content"]["text"]
                elif msg_type == "error":
                    return f"Error: {reply['content']['evalue']}"
                elif msg_type == "status" and reply["content"]["execution_state"] == "idle":
                    break
        except asyncio.TimeoutError:
            return "Error: Execution timed out"
    return ""

@app.post("/execute", response_model=ExecutionResult)
async def execute(request: CodeRequest):
    """Interface d'exécution de code"""
    try:
        output = await execute_code(request.code)
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))
    return ExecutionResult(output=output)

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)

La logique centrale : à chaque requête, démarrer un Jupyter Kernel isolé, exécuter le code, retourner le résultat, puis détruire le Kernel.

Étape 2 : Dockerfile

FROM jupyter/base-notebook:latest

WORKDIR /app

COPY main.py /app/main.py
COPY requirements.txt /app/requirements.txt

RUN pip install --no-cache-dir -r requirements.txt

# Utilisateur non root (bonne pratique de sécurité)
USER jovyan

EXPOSE 8000

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Notez USER jovyan : bonne pratique de sécurité. Un conteneur non root limite les dégâts en cas d’évasion.

Étape 3 : déploiement GKE (gVisor activé)

Sur GKE, une seule ligne dans la config Pod :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: agent-sandbox
spec:
  template:
    spec:
      runtimeClassName: gvisor  # Clé : activer gVisor
      containers:
      - name: sandbox
        image: your-registry/agent-sandbox:latest
        ports:
        - containerPort: 8000
        resources:
          limits:
            memory: "512Mi"
            cpu: "500m"

Votre environnement d’exécution tourne déjà dans un sandbox gVisor.

Étape 4 : restrictions de sécurité

La config ci-dessus n’est pas suffisante pour la production. Ajoutez au minimum :

# Politique réseau : limiter aux API nécessaires
# Système de fichiers en lecture seule
securityContext:
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false

# Timeout d'exécution
# Le paramètre timeout est déjà dans le code FastAPI

Avancé : déploiement sur cluster Kubernetes

Pour un déploiement à grande échelle, un seul conteneur ne suffit plus. Utilisez le contrôleur Agent Sandbox de Kubernetes.

Google a open-sourcé en 2025 le projet Agent Sandbox, avec une API déclarative de gestion des sandboxes.

Concepts clés du CRD Sandbox

Agent Sandbox définit plusieurs ressources personnalisées :

• Sandbox : instance isolée avec identité stable, stockage persistant, gestion du cycle de vie
• SandboxTemplate : modèle de configuration standardisée
• SandboxClaim : demande à la demande d’une instance sandbox

Exemple de configuration Sandbox :

apiVersion: sandbox.k8s.io/v1alpha1
kind: Sandbox
metadata:
  name: my-agent-sandbox
spec:
  template:
    spec:
      runtimeClassName: gvisor
      containers:
      - name: executor
        image: python:3.11-slim
        command: ["sleep", "infinity"]
      # Stockage persistant
      volumes:
      - name: workspace
        emptyDir: {}
      # Limites de ressources
      resources:
        limits:
          memory: "1Gi"
          cpu: "1"

Gestion du cycle de vie

Un atout d’Agent Sandbox : pause et reprise :

# Mettre en pause le sandbox (libère CPU et la plupart de la mémoire)
kubectl patch sandbox my-agent-sandbox --type=merge -p '{"spec":{"paused":true}}'

# Reprendre le sandbox
kubectl patch sandbox my-agent-sandbox --type=merge -p '{"spec":{"paused":false}}'

Utile pour les agents exécutés par intermittence : pause sans charge quand inactif, reprise en quelques secondes à la demande.

Pool de préchauffage

Pour réduire la latence de démarrage, Agent Sandbox supporte un pool préchauffé — des sandboxes créées à l’avance en état pause, activées à la demande.

Le cold start passe de secondes à millisecondes.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Choix des services managés

Si vous ne voulez pas opérer l’infrastructure, les services managés sont une bonne option :

E2B : open source + cloud managé

E2B est un service sandbox conçu pour les agents IA. Deux modes :

• E2B Cloud : service cloud à la consommation
• E2B on AWS : déploiement open source sur votre compte AWS

E2B repose sur Firecracker. SDK concis :

from e2b import Sandbox

# Créer le sandbox
sandbox = Sandbox()

# Exécuter le code
result = sandbox.run_code("print('Hello, World!')")

# Fermer le sandbox
sandbox.close()

E2B on AWS convient aux entreprises exigeant la souveraineté des données — tout reste dans votre compte.

AWS Bedrock AgentCore

AWS a lancé Bedrock AgentCore en 2025 pour l’exécution de code et l’automatisation navigateur des agents IA.

Code Interpreter : runtimes Python/JavaScript/TypeScript, chaque session dans une micro-VM isolée, fichiers jusqu’à 5 Go.

Browser Tool : l’agent peut ouvrir des pages, remplir des formulaires, cliquer — utile pour le scraping et l’interaction avec des SaaS.

Facturation à l’usage vCPU/mémoire, pas au temps d’instance : les ressources sont libérées après exécution.

Recommandations

Conclusion

En résumé : la sécurité n’est pas optionnelle, c’est une infrastructure de base pour les agents IA.

Côté technologie :

• Petite équipe, validation rapide : Docker ou gVisor suffisent
• Application entreprise, haute sécurité : Firecracker ou service managé
• Déjà sur Kubernetes : contrôleur Agent Sandbox

Quel que soit votre choix, commencez par un test local. Un FastAPI minimal + Docker, puis renforcez la sécurité et passez en production.

Retenez : plus tôt vous ajoutez un sandbox, mieux c’est. Attendre un incident pour réagir coûte bien plus cher.