Quelle est la sécurité du sandbox IA pour l’exécution de code ?

Un sandbox IA pour exécuter du code est aussi sécurisé que sa frontière d’isolation — mais cette frontière n’est qu’une partie de la réponse. La meilleure question est : qu’est-ce que le sandbox isole réellement, et qu’est-ce qui peut encore s’échapper ? La plupart des sandboxes bloquent bien certaines choses (exécution de code au niveau du processus, écritures arbitraires dans le système de fichiers de l’hôte) et en laissent d’autres ouvertes par défaut (réseau sortant, installations de paquets, secrets dans les variables d’environnement). Comprendre ces lacunes est la clé pour évaluer si un sandbox correspond à votre modèle de risque.

Ce que signifie “sécurisé” pour un sandbox d’exécution de code

La sécurité dans un sandbox d’exécution de code n’est pas une propriété binaire. C’est un ensemble de contrôles, chacun répondant à une catégorie spécifique de risque. Quand quelqu’un demande “ce sandbox est-il sécurisé ?”, il pose généralement plusieurs questions distinctes à la fois :

• Isolation de l’hôte : Le code exécuté dans le sandbox peut-il s’échapper vers le système hôte ?
• Isolation des locataires : Le code d’un utilisateur peut-il affecter la session d’un autre utilisateur ?
• Contrôle de sortie : Le code dans le sandbox peut-il atteindre Internet, les services internes ou les points de terminaison de métadonnées ?
• Portée des secrets : Les identifiants sont-ils accessibles à une plus grande partie du sandbox que nécessaire ?
• Risque de la chaîne d’approvisionnement : Les installations de paquets peuvent-elles introduire du code inattendu ou malveillant ?
• Auditabilité : Pouvez-vous reconstruire ce que l’agent a réellement fait après coup ?

Un sandbox peut être fort sur l’isolation de l’hôte et faible sur la sortie. Fort sur la sortie et faible sur les secrets. Évaluer “comment sécurisé” nécessite de vérifier chaque dimension séparément, sans accepter un seul label comme “conteneurisé” ou “basé sur microVM” comme réponse complète.

Comparaison des couches d’isolation

Il existe trois principaux modèles d’isolation utilisés dans les sandboxes d’exécution de code IA. Chacun offre une frontière différente.

Isolation par processus

L’isolation par processus utilise des primitives au niveau du système d’exploitation — espaces de noms Linux, cgroups, filtres seccomp et profils AppArmor ou SELinux — pour restreindre ce qu’un processus peut accéder. Le sandbox s’exécute en tant que processus sur le système d’exploitation hôte, partageant le noyau hôte.

Ce qu’il empêche : L’accès au système de fichiers plus large, aux autres processus en dehors du sandbox, et aux appels système explicitement bloqués par la politique seccomp.

Ce qu’il n’empêche pas : Les exploits du noyau qui escaladent les privilèges via une vulnérabilité partagée. Un contournement de seccomp ou une vulnérabilité du noyau peut franchir la frontière de l’hôte.

Quand c’est approprié : Code court, à faible risque, de confiance relative, où la vitesse de démarrage et la portabilité sont plus importantes qu’une frontière VM dure. Déconseillé pour exécuter du code arbitraire généré par un agent provenant d’utilisateurs externes.

Isolation par conteneur (Docker/espaces de noms)

L’isolation par conteneur étend l’isolation par processus avec un modèle d’image plus structuré, des espaces de noms réseau et des montages de volumes. La plupart des implémentations de sandbox basées sur Docker exécutent le code à l’intérieur d’un conteneur avec une image minimale et un profil seccomp restreint.

Ce qu’il empêche : L’accès direct au système de fichiers de l’hôte, la plupart des accès réseau aux conteneurs adjacents (lorsqu’il est correctement configuré), un accès facile aux processus hôtes.

Ce qu’il n’empêche pas : Les exploits au niveau du noyau s’appliquent toujours — les conteneurs partagent le noyau hôte. Des montages de volumes mal configurés, des profils seccomp trop larges, le mode --privileged et les sockets Docker exposés peuvent tous annuler la frontière prévue.

Quand c’est approprié : De nombreux déploiements en production utilisent efficacement les conteneurs pour l’exécution de code IA lorsque le profil seccomp est strict, l’image minimale, la sortie restreinte et aucun accès privilégié accordé. Le modèle de risque est différent des microVM mais gérable avec une configuration soignée.

Isolation par microVM (Firecracker/gVisor)

L’isolation par microVM exécute chaque sandbox dans une machine virtuelle légère avec son propre noyau invité, isolé de l’hôte par une frontière hyperviseur KVM. Firecracker est l’implémentation la plus courante ; gVisor (avec son noyau en espace utilisateur) offre un compromis différent.

Ce qu’il empêche : Les exploits du noyau invité ne se propagent pas au noyau hôte ni aux autres invités. La surface d’attaque de l’hôte est réduite au VMM (moniteur de machine virtuelle), conçu pour être minimal.

Ce qu’il n’empêche pas : Les vulnérabilités dans le VMM lui-même (rares mais pas impossibles). Les contrôles réseau, de paquets et de secrets restent en dehors de la frontière de la VM — l’isolation par microVM ne les gère pas.

Quand c’est approprié : Exécution de code non fiable ou généré par un agent provenant d’utilisateurs externes, environnements multi-locataires où le rayon d’impact est important, et charges de travail pouvant exécuter des commandes shell arbitraires ou des scripts d’installation de paquets.

Modèle d’isolation	Noyau hôte partagé	Séparation des locataires	Surcharge de démarrage	Risque d’évasion de l’hôte
Processus	Oui	Faible	La plus faible	Le plus élevé
Conteneur	Oui	Modérée	Faible	Moyen (dépend de la configuration)
MicroVM	Non	Forte	Modérée	Faible

Ce qui peut encore s’échapper de chaque frontière

Le modèle d’isolation traite l’exécution de code au moment de l’exécution. Il ne traite pas automatiquement ce qui entre ou sort du sandbox par d’autres chemins.

Réseau sortant : Les trois modèles d’isolation laissent l’accès réseau sortant à la configuration de la politique. Une sortie ouverte par défaut signifie que le code à l’intérieur du sandbox peut atteindre l’Internet public, les points de terminaison de métadonnées cloud (169.254.169.254 sur AWS et GCP), les services internes sur le même réseau et des API externes arbitraires. C’est un chemin d’exfiltration de données, un chemin de récupération de secrets et un chemin de commande et contrôle, quel que soit le modèle d’isolation.

Installations de paquets : Un apt install, pip install ou npm install récupère et exécute du code depuis un registre externe. Si le sandbox autorise les installations de paquets et a une sortie ouverte, une collision de nom de paquet, une attaque de typosquattage ou une attaque de confusion de dépendance peut introduire du code malveillant qui s’exécute avec toutes les autorisations du sandbox. La frontière d’isolation contient le rayon d’impact mais n’empêche pas l’installation.

État partagé : Dans les déploiements multi-locataires, les caches partagés, les registres de paquets partagés, les images modèles partagées ou les montages de système de fichiers partagés créent des canaux entre locataires qui contournent la frontière d’isolation.

Secrets dans les variables d’environnement : Les variables d’environnement visibles par le processus agent sont lisibles par tout code exécuté par l’agent. Si un identifiant de base de données ou une clé API se trouve dans l’environnement, il est accessible au sandbox et à tout ce qu’il exécute ou installe.

Contrôles de sortie et réseau

La sortie est la plus grande lacune de la plupart des sandboxes. L’accès Internet sortant ouvert est courant car pratique — les agents doivent installer des paquets, appeler des API et récupérer des ressources. Mais cela crée également des risques :

Points de terminaison de métadonnées cloud : Sur une infrastructure cloud hébergée, 169.254.169.254 (et son équivalent IPv6) fournit les métadonnées d’instance, y compris les identifiants IAM. Le code à l’intérieur d’un sandbox avec sortie ouverte peut atteindre ce point de terminaison et récupérer les identifiants de l’hôte sous-jacent.

Exfiltration basée sur DNS : Même si HTTP est bloqué, les requêtes DNS sortantes peuvent être utilisées pour exfiltrer des données en les encodant dans des recherches de domaine. Le blocage DNS nécessite un filtrage au niveau du résolveur, pas seulement le blocage de TCP/UDP 53 vers des serveurs externes.

Services internes : Si le sandbox s’exécute sur un segment de réseau privé, une sortie ouverte peut permettre l’accès à des bases de données internes, des panneaux d’administration et des API qui ne sont pas destinés à être accessibles depuis le code de l’agent.

Contrôles à évaluer :

Contrôle	Ce qu’il empêche	Quoi vérifier
Sortie refusée par défaut	Connexions sortantes vers des destinations non listées	Bloque-t-il également le DNS ainsi que TCP/UDP ?
Sortie basée sur une liste blanche	Connexions vers des domaines non approuvés	La liste blanche est-elle configurable par le client ?
Blocage des points de terminaison de métadonnées	Récupération d’identifiants cloud via 169.254.169.254	IPv6 est-il également bloqué ?
Proxy de sortie	Journalisation et inspection de tout le trafic sortant	Le journal du proxy est-il accessible ?
Filtrage DNS	Exfiltration basée sur DNS et résolution de noms internes	Quel résolveur est utilisé à l’intérieur du sandbox ?

Il n’existe pas de politique de sortie universellement correcte. Certaines charges de travail d’agent ont réellement besoin d’un accès Internet large pour être utiles. L’essentiel est que la politique soit délibérée et vérifiable, et non ouverte par défaut parce qu’elle n’a jamais été configurée.

Gestion des secrets

Les secrets dans les sandboxes d’agents IA suivent les mêmes principes que les secrets dans tout système logiciel, avec une contrainte supplémentaire : l’agent peut exécuter du code qui lit, enregistre ou transmet l’environnement sans intention du développeur.

Portée : Montez uniquement les identifiants dont le sandbox a réellement besoin pour la tâche en cours. Un sandbox exécutant une tâche de codage n’a pas besoin des identifiants de base de données de production. Un sandbox évaluant les sorties du modèle n’a pas besoin de la clé API d’un service de facturation.

Durée de vie : Les identifiants à courte durée de vie sont nettement plus sûrs que ceux à longue durée de vie. Si un identifiant fuit à l’intérieur d’un sandbox, une courte TTL (durée de vie) limite la fenêtre d’exposition. De nombreux systèmes IAM cloud prennent en charge des jetons à courte durée de vie qui expirent en quelques minutes ou heures.

Méthode d’injection : Les variables d’environnement sont la méthode d’injection la plus courante et la plus accessible à tout code dans le processus. Les secrets qui peuvent être injectés via des montages de système de fichiers, montés à un chemin que l’agent n’a pas besoin de parcourir, ou récupérés dynamiquement uniquement lorsque l’outil spécifique qui en a besoin s’exécute, sont plus contraints qu’un ensemble de variables d’environnement globales.

Masquage : Les secrets doivent être masqués dans stdout, stderr, les charges utiles de réponse des outils, le contexte visible par le modèle et les journaux d’audit. Un agent qui renvoie son environnement, appelle env ou transmet un jeton à un appel API défaillant peut divulguer des identifiants dans des journaux qui sont ensuite stockés ou visibles par les opérateurs.

Limites de ressources et risque de déni de service

Un sandbox sans limites de ressources est vulnérable aux charges de travail d’agent qui épuisent le CPU, la mémoire, le disque ou la bande passante réseau — soit par un code incontrôlé, une boucle infinie, une fuite mémoire dans un paquet installé, ou une tentative délibérée de perturber les charges de travail adjacentes.

Contrôles de ressources à vérifier :

• Limites CPU : L’étranglement ou les limites strictes par session empêchent une session de monopoliser la capacité de l’hôte.
• Limites mémoire : Les politiques de kill OOM doivent terminer la session du sandbox, pas le processus hôte.
• Quotas disque : Les limites d’écriture par session empêchent une session de remplir le stockage partagé.
• Délai d’exécution : Les sessions qui dépassent une limite de temps murale doivent être terminées proprement, pas laissées en cours d’exécution.
• Limites de débit réseau : Les limites de bande passante sortante peuvent contraindre l’exfiltration même lorsque la politique de sortie autorise la destination.
• Limites de processus simultanés : Les agents qui bifurquent agressivement ou engendrent des processus en arrière-plan peuvent épuiser les slots de la table des processus.

Les violations des limites de ressources méritent également d’être journalisées. Une session qui atteint systématiquement l’étranglement CPU ou le kill OOM lors de tâches qui devraient être légères est un signal qui mérite investigation.

Visibilité d’audit

Les contrôles d’isolation réduisent le rayon d’impact lorsque quelque chose tourne mal. Les journaux d’audit sont la façon dont vous découvrez que quelque chose a tourné mal et reconstruisez ce qui s’est passé.

Pour les sandboxes d’agents IA en particulier, une couverture d’audit utile comprend :

• Exécution de processus : Chaque commande exécutée, avec la liste complète des arguments, UID et processus parent. Sans listes d’arguments, curl et python dans un journal ne sont pas significatifs.
• Accès au système de fichiers : Lectures et écritures sur des chemins sensibles. Les écritures et suppressions sont de priorité plus élevée que les lectures pour la plupart des modèles de menace.
• Réseau sortant : Destinations, protocoles, requêtes DNS et octets transférés. La journalisation des requêtes DNS est souvent absente mais importante.
• Installations de paquets : Gestionnaire de paquets, nom du paquet, version, registre source et empreinte.
• Cycle de vie de session : Événements de création, pause, reprise, terminaison et nettoyage avec codes de raison.
• Événements de limite de ressources : Kill OOM, étranglement CPU, terminaison par délai d’attente.

Le mécanisme de collecte compte autant que la couverture. Les journaux générés à l’intérieur du processus sandbox peuvent être supprimés ou modifiés par un agent suffisamment privilégié. La collecte au niveau du noyau (via auditd, eBPF ou instrumentation de l’hyperviseur) est générée sous la couche applicative, là où l’agent n’a aucun accès en écriture.

Questions à poser à tout fournisseur ou projet de sandbox

Utilisez cette liste de contrôle lors de l’évaluation d’un service de sandbox géré ou d’un framework de sandbox open source :

Isolation

• Chaque session d’agent obtient-elle son propre environnement isolé, ou les sessions sont-elles regroupées sur des environnements d’exécution partagés ?
• Quel modèle d’isolation est utilisé : processus, conteneur ou microVM ?
• Le noyau invité est-il partagé avec l’hôte ?

Réseau et sortie

• La sortie est-elle ouverte par défaut ou refusée par défaut ?
• La politique de sortie peut-elle être configurée par locataire ou par session ?
• Le point de terminaison de métadonnées cloud (169.254.169.254) est-il bloqué ?
• Comment le DNS est-il géré à l’intérieur du sandbox ?

Installations de paquets

• Les installations de paquets sont-elles autorisées par défaut ?
• Les installations peuvent-elles être limitées à des registres approuvés ?
• Les événements d’installation sont-ils journalisés avec la source et l’empreinte ?

Secrets

• Comment les identifiants sont-ils injectés dans le sandbox ?
• Les identifiants peuvent-ils être limités à l’outil ou à la tâche spécifique qui en a besoin ?
• Les secrets sont-ils masqués dans les journaux et les sorties visibles par le modèle ?

Limites de ressources

• Les limites de CPU, mémoire, disque et délai d’exécution sont-elles appliquées ?
• Que se passe-t-il lorsqu’une limite est atteinte — étranglement, kill ou alerte ?

Journaux d’audit

• Les journaux sont-ils générés au niveau du noyau/de l’hyperviseur ou à l’intérieur du processus sandbox ?
• Quelles catégories d’événements sont journalisées par défaut ?
• Les journaux peuvent-ils être exportés vers un SIEM externe ou un système d’agrégation de journaux ?
• Quelle est la politique de conservation des journaux ?

Locataires multiples

• Les charges de travail de différents locataires sont-elles isolées les unes des autres ?
• Existe-t-il des caches, images ou montages partagés qui créent des canaux entre locataires ?

Où se situe Novita Agent Sandbox

Novita Agent Sandbox est conçu pour les charges de travail d’agent qui nécessitent des environnements d’exécution isolés pour le code, les fichiers, les processus et les sessions de plus longue durée. Il cible les équipes qui construisent des agents de codage, des pipelines d’évaluation, des agents d’analyse de données et des flux de travail d’agents basés sur un navigateur.

Le sandbox prend en charge les contrôles de cycle de vie de session, y compris la pause, la reprise et la pause automatique pour les sessions inactives. Il fournit des métriques de ressources et des journaux d’exécution au niveau de la session accessibles via l’API. Pour les équipes utilisant déjà les API de modèles Novita, il peut servir de couche d’exécution dans une architecture d’agent où le modèle planifie et appelle des outils, et le sandbox gère l’exécution runtime dans un environnement isolé.

Lors de l’évaluation de Novita Agent Sandbox pour des cas d’utilisation sensibles à la sécurité, vérifiez le modèle d’isolation actuel, les paramètres par défaut de la politique de sortie, la couverture des journaux et la gestion des secrets dans la documentation produit avant de prendre des décisions architecturales. Les exigences de sécurité varient considérablement selon la charge de travail — ce qui est approprié pour un pipeline d’évaluation interne peut ne pas être suffisant pour un produit multi-locataire traitant du code fourni par l’utilisateur.

Comme pour tout sandbox, la posture de sécurité dépend à la fois des paramètres par défaut de la plateforme et de vos contrôles au niveau de l’application : comment les identifiants sont limités, ce que l’agent est autorisé à demander, quels appels d’outils nécessitent une approbation humaine et comment les journaux d’audit sont surveillés.

Limites et ce qu’aucun sandbox n’élimine

Aucun sandbox n’élimine tous les risques. Comprendre ce qui reste en dehors de la frontière est aussi important que comprendre ce que la frontière apporte.

Décisions de confiance au niveau applicatif : Le sandbox contrôle l’exécution runtime. Il ne décide pas ce que l’agent est autorisé à demander. Si votre application permet à un agent de demander un identifiant, d’exécuter des commandes shell arbitraires ou d’appeler n’importe quelle API, le sandbox réduit le rayon d’impact mais n’empêche pas ces actions.

Injection de prompt : Un agent qui traite du contenu non fiable — pages web, fichiers téléchargés par l’utilisateur, réponses API externes — peut être manipulé via ce contenu pour entreprendre des actions qu’il ne devrait pas. C’est un problème de conception d’application, pas un problème de sandbox. Le sandbox peut limiter où ces actions aboutissent, mais la logique de décision réside dans votre application.

Vulnérabilités zero-day : Tous les modèles d’isolation ont des vulnérabilités connues et inconnues. L’isolation par microVM fournit la frontière la plus solide dans l’utilisation en production actuelle, mais des vulnérabilités VMM existent. La défense en profondeur — combiner plusieurs contrôles plutôt que de faire confiance à une seule frontière — est une posture plus robuste que n’importe quel modèle d’isolation unique.

Ingénierie sociale via la sortie du modèle : Un agent peut produire une sortie qui persuade un opérateur humain d’entreprendre une action dangereuse. Les sandboxes n’auditent pas les décisions humaines.

Risque de conformité et réglementaire : Les contrôles d’isolation traitent le risque technique. Les exigences réglementaires (RGPD, HIPAA, SOC 2, ISO 27001) traitent du traitement des données, de la conservation, de la documentation et des exigences d’audit qui vont au-delà de ce qu’un sandbox fournit au niveau de l’infrastructure.

La sécurité dans un sandbox d’exécution de code est mieux conçue comme un ensemble de contrôles à évaluer et configurer, pas une propriété que vous acquérez en choisissant un produit. Les questions d’évaluation ci-dessus s’appliquent à chaque décision de sandbox — y compris votre propre infrastructure si vous construisez plutôt que d’acheter.

FAQ

À quel point un environnement d’exécution de code IA sandboxé est-il sécurisé par rapport à l’exécution de code sur un serveur ?

Un sandbox bien configuré réduit considérablement le rayon d’impact de l’exécution de code non fiable par rapport à son exécution directement sur un serveur. Il contraint l’accès au système de fichiers, la portée des processus et l’accès réseau. Cependant, la différence dépend de la configuration. Un conteneur à sortie ouverte avec une large injection de variables d’environnement peut être moins sûr qu’un serveur renforcé avec des contrôles réseau. Le modèle d’isolation est un point de départ, pas une garantie.

L’isolation par microVM signifie-t-elle qu’un sandbox est totalement sécurisé ?

Non. L’isolation par microVM (Firecracker, basée sur KVM) fournit une frontière hôte solide que les conteneurs à noyau partagé n’offrent pas. Mais elle ne contrôle pas la sortie, les secrets, les installations de paquets ou la couverture d’audit. Une microVM avec sortie ouverte et aucune collecte de journaux n’est pas “totalement sécurisée” même si la couche d’isolation est solide.

Le code généré par IA peut-il s’échapper d’un sandbox ?

Cela dépend du modèle d’isolation et de la configuration. Les évasions de conteneurs nécessitent d’exploiter le noyau ou une mauvaise configuration ; les évasions de microVM nécessitent d’exploiter le VMM. Les deux sont possibles mais rares. Les risques plus pratiques sont l’exfiltration de données via des chemins réseau autorisés, la lecture de secrets depuis l’environnement ou l’installation de paquets malveillants via des gestionnaires de paquets non restreints.

Quel est le plus grand risque de sécurité dans la plupart des sandboxes de code IA ?

La sortie réseau ouverte est le risque le moins souvent traité. De nombreux sandboxes autorisent un accès Internet sortant non restreint par défaut car c’est pratique pour les agents qui ont besoin d’installer des paquets et d’appeler des API. Cela crée des chemins pour l’exfiltration de données, le vol d’identifiants via des points de terminaison de métadonnées cloud et une communication de commande et contrôle qui existent indépendamment de la force de la frontière d’isolation.

Dois-je utiliser un sandbox géré ou construire le mien ?

Les sandboxes gérés gèrent la complexité opérationnelle du cycle de vie des microVM ou conteneurs, de la capacité de l’hôte et de la gestion des images. Construire le vôtre vous donne plus de contrôle sur l’ensemble de la pile de politiques. Dans les deux cas, les mêmes questions d’évaluation s’appliquent : politique de sortie, gestion des secrets, couverture des journaux, limites de ressources et export d’audit. La décision de construire ou d’acheter est distincte de l’évaluation de sécurité.

Qu’est-ce qui rend la sécurité d’un sandbox d’agent différente de la sécurité traditionnelle d’exécution de code ?

La sécurité traditionnelle d’exécution de code suppose que vous savez à peu près quel code va s’exécuter. Les agents IA changent cela : une seule invite peut amener une session à installer des paquets, écrire des fichiers, exécuter des commandes shell, appeler des API externes et engendrer des sous-processus sans approbation explicite du développeur pour chaque étape. Cela rend la couverture d’audit plus importante (vous ne pouvez pas anticiper chaque action), les contrôles de sortie plus importants (l’agent peut atteindre des destinations que vous n’aviez pas prévues) et la portée des secrets plus importante (l’agent a accès à tout dans son environnement).

Articles recommandés

• Firecracker for AI Agent Sandboxes: Benefits, Limits, and Evaluation Questions
• Audit Logs for AI Agent Sandboxes: What Security Teams Need
• AI-Generated Code Sandbox: Requirements for Production Apps