Agent Sandboxing

Le sandboxing des agents consiste à exécuter les actions d’un agent d’IA, comme des commandes shell, du code généré, des modifications de fichiers et la navigation Web, dans un environnement isolé qui limite les fichiers, réseaux, identifiants et ressources informatiques auxquels ces actions peuvent accéder. Un agent fondé sur un grand modèle de langage (LLM) choisit chaque commande à partir du texte qu’il a lu, lequel peut être erroné ou malveillant. Le sandbox applique ses limites au niveau du système d’exploitation ou de l’hyperviseur, de sorte qu’elles restent en vigueur même si le modèle suit une injection de prompt dissimulée dans une page Web ou un fichier README, ou s’il commet simplement une erreur.

Pourquoi les agents ont besoin de sandbox#

L’appel de fonctions et l’utilisation d’outils transforment le texte d’un modèle en actions réelles : un agent capable d’exécuter des commandes shell peut aussi supprimer des fichiers, lire des clés SSH ou téléverser du code source. L’aide-mémoire de l’OWASP sur la sécurité des agents d’IA classe parmi les pratiques à éviter le fait de laisser les agents exécuter du code arbitraire sans sandbox. Publié en décembre 2025, le Top 10 de l’OWASP pour les applications agentiques désigne l’exécution inattendue de code comme l’un des dix principaux risques des systèmes agentiques. Les sandbox rendent aussi les agents plus pratiques : demander à une personne d’approuver chaque commande entraîne une fatigue liée aux approbations, et Anthropic a découvert que le sandboxing de Claude Code avait réduit de 84 % les demandes d’autorisation lors de son utilisation interne, car les commandes qui restent dans les limites n’ont plus besoin d’une autorisation.

Ce qu’un sandbox restreint#

Un sandbox pour agent contrôle généralement cinq éléments :

• Système de fichiers : L’agent voit un espace de travail temporaire ou un seul dépôt, souvent sur une image de base en lecture seule, et ne peut pas lire les identifiants, les profils de navigateur ou d’autres projets.
• Réseau : Le trafic sortant est bloqué ou acheminé par un proxy qui n’autorise que les domaines répertoriés, comme un registre de paquets, afin qu’un agent détourné ne puisse pas envoyer de données au serveur d’un attaquant.
• Identifiants : Les secrets restent en dehors du sandbox ou sont fournis sous forme de jetons à courte durée de vie limités à une seule tâche, conformément au principe du moindre privilège en sécurité des données.
• Calcul : Les limites de temps CPU, de mémoire, de nombre de processus et de durée d’exécution réelle arrêtent les boucles infinies et les bombes de processus.
• Appels système : Des filtres comme seccomp bloquent les interfaces du noyau dont les outils de l’agent n’ont jamais besoin.

La force de l’isolation dépend de l’emplacement de la frontière. Les conteneurs Docker partagent le noyau de l’hôte : une faille du noyau peut donc permettre de s’en échapper. gVisor ajoute un noyau en espace utilisateur qui intercepte les appels système de chaque conteneur. Les microVM comme Firecracker, conçues par AWS pour Lambda, donnent à chaque sandbox son propre noyau minimal, démarrent en moins de 125 ms et ajoutent moins de 5 Mio de surcharge mémoire. Les interpréteurs de code hébergés et les agents de programmation dans le cloud exécutent généralement chaque tâche dans un conteneur ou une microVM vierge, détruit ensuite. Sur les machines des développeurs, le sandbox de Claude Code utilise Seatbelt sous macOS et bubblewrap sous Linux. Il permet aux commandes shell d’écrire uniquement dans le répertoire de travail et un répertoire temporaire, et achemine le trafic réseau par un proxy qui vérifie chaque hôte par rapport à une liste d’autorisation.

Le sandbox est une couche du dispositif d’exécution des agents, le logiciel qui exécute les appels d’outils du modèle. Ce dispositif vérifie chaque action proposée par rapport aux règles, exécute les actions autorisées dans le sandbox et met en pause le processus pour demander l’avis d’une personne avant les actions irréversibles, comme des paiements, des déploiements ou des messages envoyés à l’extérieur de l’organisation :

Sandboxing du code généré#

Les agents qui écrivent et exécutent du code, qu’il s’agisse d’assistants d’analyse de données ou d’outils de programmation agentique, ont besoin des limites les plus strictes, car le code généré peut faire tout ce que l’interpréteur peut faire. La couche la plus interne est l’isolation ordinaire des processus, que la bibliothèque standard de Python peut illustrer : ce script exécute le code écrit par le modèle dans un répertoire temporaire, avec un environnement vide et une limite de temps CPU définie au moyen du module resource (Linux et macOS).

import os
import resource
import subprocess
import sys
import tempfile

os.environ["API_KEY"] = "sk-live-123"  # Un secret détenu par le processus de l’agent lui-même

# Le code écrit par le modèle : il lit l’environnement, puis boucle à l’infini
generated = "import os\nprint('API_KEY =', os.environ.get('API_KEY'), flush=True)\nwhile True: pass"


def limit_cpu():
    """Stop the child process after 2 seconds of CPU time."""
    resource.setrlimit(resource.RLIMIT_CPU, (2, 2))


# Exécuter en mode isolé, dans un répertoire temporaire et avec un environnement vide
cmd = [sys.executable, "-I", "-c", generated]
with tempfile.TemporaryDirectory() as workspace:
    proc = subprocess.run(cmd, cwd=workspace, env={}, capture_output=True, text=True, preexec_fn=limit_cpu)

print(proc.stdout.strip())
print("exit code:", proc.returncode)

Le processus enfant affiche API_KEY = None, car il démarre avec un environnement vide et ne peut pas voir le secret du processus parent. Il se termine avec le code -24, ce qui signifie que le noyau l’a tué avec SIGXCPU lorsque sa boucle infinie a atteint la limite de temps CPU de 2 secondes. Un conteneur ou une microVM ajoute à ce processus les frontières du système de fichiers et du réseau.

Sandboxing et contrôles connexes#

• Garde-fous d’IA : Des classificateurs et des règles qui filtrent les entrées, les sorties ou les actions proposées avant leur exécution. Le sandbox contient les effets d’une action après qu’un garde-fou l’a laissée passer.
• Autorisations : Le contrôle d’accès détermine quels outils et ressources un agent peut utiliser. Le sandboxing applique ces décisions au niveau du système d’exploitation, sous-jacent à toute vérification que le modèle pourrait contourner par la persuasion.
• Conteneurisation : Empaqueter un logiciel et ses dépendances pour assurer un déploiement reproductible. Un conteneur sert de sandbox lorsqu’il s’exécute avec des privilèges supprimés, des montages restreints et des règles de trafic sortant.
• Sandbox de test : Copies hors production d’un système où le logiciel est testé en toute sécurité. Les sandbox d’agents encadrent chacune des actions d’un agent, en production comme en développement.

Où utilise-t-on les sandbox d’agents ?#

• Agents de programmation : Chaque tâche reçoit un conteneur ou une machine virtuelle vierge contenant un dépôt. L’agent y installe les dépendances, exécute les tests et renvoie un diff pour examen humain.
• Agents qui utilisent un ordinateur : Les agents qui manipulent un ordinateur de bureau ou un navigateur à l’aide de captures d’écran et de clics s’exécutent dans une machine virtuelle dotée de ses propres comptes, car chaque page consultée peut contenir des instructions qui leur sont destinées.
• Interpréteurs de code : Les assistants qui analysent des feuilles de calcul ou des images téléversées exécutent leur code Python dans un sandbox propre à chaque session, souvent sans accès à Internet.
• Serveurs MCP et compétences d’agent : Les outils tiers et les scripts de compétences s’exécutent avec les identifiants de l’utilisateur. Les hôtes prudents démarrent donc les serveurs locaux et les scripts dans la même frontière que le shell de l’agent.

Les plateformes d’agents hébergées appliquent les mêmes limites à leurs propres flux de travail. Les agents de la plateforme Ultralytics, qui enchaînent la détection YOLO26, des modèles vision-langage et des blocs d’alerte, limitent chaque exécution d’essai partagée à 60 secondes, 20 images d’entrée et 20 appels de modèle ou de fournisseur. Leur bloc Webhook n’envoie des requêtes qu’à des URL HTTPS publiques, ne suit aucune redirection et expire au bout de 5 secondes.