Sandbox de code généré par IA : exigences pour les applications de production

Les applications de production qui exécutent du code généré par IA ont besoin d’un sandbox qui impose une isolation au niveau du processus, prend en charge les sessions simultanées, expose une API de cycle de vie programmable, fournit des journaux observables et des métriques de ressources, applique des politiques sur les paquets et le réseau, et s’intègre proprement au backend de l’application. Choisir un sandbox sans évaluer systématiquement chacune de ces dimensions est la façon la plus courante pour les équipes de rencontrer des problèmes après le lancement : une charge de travail qui semblait sûre en préproduction échoue sous un trafic réel, fuit des informations entre locataires, ou exécute silencieusement du code que l’application n’avait jamais prévu d’autoriser.

Ce guide est une liste de vérification des exigences. Il couvre ce qu’il faut vérifier à chaque niveau d’isolation, ce qu’une API de cycle de vie de production doit exposer, à quoi devraient ressembler l’observabilité et les contrôles de ressources, et où les modèles d’intégration backend font ou défont la conception. Que vous évaluiez un sandbox géré ou que vous construisiez le vôtre, voici les questions qui méritent d’être posées avant de déployer.

Isolation du sandbox : processus, conteneur et microVM

L’isolation est un spectre, et chaque niveau comporte des compromis différents en termes de performance, de portabilité et de confiance accordée au code généré.

L’isolation au niveau du processus utilise les primitives du système d’exploitation — espaces de noms (namespaces), cgroups, seccomp, et profils AppArmor ou SELinux — pour restreindre ce à quoi un processus peut accéder. C’est rapide et ne nécessite pas de noyau VM séparé, mais tous les processus partagent le noyau hôte. Une vulnérabilité du noyau ou un appel système privilégié qui passe à travers le filtre seccomp peut affecter d’autres charges de travail sur le même hôte. L’isolation de processus est un point de départ raisonnable pour des chemins de code à faible risque, de courte durée et fiables, mais c’est une frontière mince pour du code généré par IA non fiable qui pourrait tenter des appels système, la création de sous-processus ou des installations de paquets.

Ce qu’il faut vérifier à ce niveau :

• Quels appels système sont bloqués, et quelle est la politique par défaut lorsqu’un appel système inconnu est tenté ?
• Les espaces de noms sont-ils délimités par tâche, par locataire, ou partagés entre les travaux ?
• Les limites cgroups sont-elles appliquées au niveau de la tâche ou seulement au niveau de l’hôte ?
• Le sandbox nettoie-t-il tous les processus, fichiers temporaires, sockets et mémoire partagée lors de la sortie ?

L’isolation au niveau du conteneur ajoute une frontière de système de fichiers et d’espace de noms réseau et rend la gestion des images reproductible. Les conteneurs sont plus rapides à démarrer que des VM complètes, plus faciles à composer et largement pris en charge par les couches d’orchestration. Le compromis est que les conteneurs partagent toujours le noyau hôte, et la frontière du conteneur n’est aussi solide que la configuration sous-jacente du runtime. Les conteneurs privilégiés, les ensembles de capacités larges, les sockets hôtes montés et le mode réseau hôte réduisent tous la frontière effective à pratiquement rien.

Ce qu’il faut vérifier à ce niveau :

• L’image du conteneur est-elle minimale, avec seulement les runtimes et outils dont la charge de travail a réellement besoin ?
• Les capacités sont-elles réduites à l’ensemble minimum requis ?
• Le conteneur est-il sans root, ou nécessite-t-il root et quels sont les contrôles autour de cela ?
• L’espace de noms PID hôte, le réseau hôte et le socket Docker sont-ils explicitement exclus ?
• Les volumes montés sont-ils limités à des chemins explicitement définis, et le système de fichiers racine est-il en lecture seule lorsque c’est possible ?

L’isolation par microVM place chaque charge de travail dans une machine virtuelle légère — avec son propre noyau invité, ses périphériques virtuels et une frontière basée sur KVM entre l’invité et l’hôte. Des technologies comme Firecracker utilisent un modèle de périphérique minimal pour réduire la surface d’attaque tout en gardant un démarrage suffisamment rapide pour une utilisation interactive. La frontière de la microVM signifie qu’une exploitation du noyau dans l’invité n’affecte pas automatiquement l’hôte ou les autres invités.

Ce qu’il faut vérifier à ce niveau :

• Chaque exécution d’agent, chaque locataire ou chaque session simultanée obtient-elle une microVM séparée ?
• Quelle est la latence de démarrage, de l’appel API à l’état prêt à exécuter, et est-elle mesurée à partir d’un pool chaud, d’un instantané ou d’un démarrage à froid ?
• Les images invitées sont-elles versionnées, auditées pour les runtimes et outils qu’elles incluent, et mises à jour selon un calendrier régulier ?
• Que se passe-t-il au niveau de l’hôte si le noyau invité panique ou devient injoignable ?

La décision pratique concerne votre modèle de menace. L’isolation par microVM est la frontière généralement disponible la plus solide pour le code généré par IA non fiable, mais elle ne remplace pas la politique du système de fichiers, les contrôles de sortie, la gouvernance des paquets ou la gestion des secrets. Ces contrôles doivent se superposer à la couche d’isolation que vous choisissez.

Gestion des sessions sandbox simultanées

Une application de production générant du code pour plusieurs utilisateurs simultanément a besoin d’un sandbox qui traite la concurrence comme une préoccupation de première classe, non comme une réflexion après coup.

Les questions clés sont :

Isolation par session : Lorsque 50 sessions s’exécutent en même temps, chaque session a-t-elle son propre système de fichiers isolé, son arbre de processus, son espace de noms réseau et son périmètre d’identifiants ? La fuite d’état entre sessions est l’un des modes de défaillance les plus dommageables dans les applications sandboxées multi-locataires, et elle est souvent invisible lors des tests où les sessions s’exécutent séquentiellement.

Limites de sessions et contre-pression : Le sandbox expose-t-il les limites de concurrence sous forme de contrat API clair ? Si 500 requêtes arrivent et que la plateforme prend en charge 100 sessions simultanées, l’API renvoie-t-elle une erreur structurée, met-elle la requête en file d’attente, ou se dégrade-t-elle silencieusement ? Les applications de production ont besoin de ce signal pour implémenter la contre-pression, la gestion des files d’attente et le retour d’information à l’utilisateur.

Équité des ressources sous charge : Lorsqu’une session consomme un CPU ou une mémoire anormalement élevée, les autres sessions sont-elles protégées par des limites de ressources par session, ou une seule charge de travail bruyante peut-elle dégrader l’ensemble du pool ?

Pools chauds et latence de démarrage des sessions : Les fonctionnalités de codage interactif nécessitent des temps de démarrage de session inférieurs à la seconde. Cela nécessite généralement un pool d’environnements pré-initialisés qui peuvent être réclamés immédiatement plutôt que démarrés à la demande. Vérifiez si la plateforme documente la disponibilité du pool chaud et la latence de démarrage attendue à différents niveaux de concurrence.

Réutilisation de session vs environnements frais : Certaines applications bénéficient de la réutilisation d’une session de longue durée pour plusieurs tours d’agent, tandis que d’autres ont besoin d’un environnement propre pour chaque requête. Vérifiez que les deux modèles sont pris en charge et que la réutilisation de session n’entraîne pas d’état obsolète d’une conversation précédente.

API de cycle de vie : Créer, Exécuter, Terminer

L’API de cycle de vie est l’interface entre votre application et le runtime du sandbox. Une API de qualité production doit exposer au minimum :

Créer : Initialiser une nouvelle session sandbox, éventuellement à partir d’un modèle ou d’un instantané, avec des limites de ressources spécifiées, des variables d’environnement et des volumes montés. La réponse doit inclure un ID de session et un signal de disponibilité, pas seulement un accusé de réception.

Exécuter : Soumettre du code ou une commande à exécuter. Cela doit être un appel asynchrone qui renvoie un ID d’exécution. L’API doit prendre en charge la spécification d’un répertoire de travail, des remplacements d’environnement pour l’appel et un délai d’expiration.

Diffuser la sortie : Récupérer stdout et stderr sous forme de flux, pas seulement comme résultat final après la fin de l’exécution. La diffusion en continu est importante pour les travaux de longue durée, les étapes d’agent qui prennent plusieurs secondes, et toute UX qui montre à l’utilisateur une progression incrémentielle.

Terminer : Mettre fin à une exécution en cours avant qu’elle ne se termine. Le sandbox doit garantir que l’arbre de processus est nettoyé, pas seulement le processus parent.

Nettoyer : Détruire la session et libérer toutes les ressources associées — système de fichiers, mémoire, emplacements de processus, état réseau et toutes les informations d’identification détenues. Cet appel doit être idempotent afin que les tentatives après une erreur réseau ne provoquent pas d’erreurs.

Télécharger et télécharger des fichiers : Transférer des fichiers d’entrée dans le sandbox avant l’exécution et récupérer les artefacts de sortie après. Les transferts de fichiers doivent être limités par des limites de taille et contrôlés par des politiques pour déterminer quels chemins sont inscriptibles.

Des capacités supplémentaires qui méritent d’être vérifiées pour une utilisation en production :

• Pause et reprise : Peut-on suspendre une session de longue durée et la reprendre plus tard sans perdre l’état ? Ceci est utile pour la limitation du débit, le contrôle des coûts et le transfert de session entre les tours d’agent.
• Instantané : L’état actuel de la session peut-il être capturé et utilisé comme point de départ pour les sessions futures ? C’est le mécanisme clé pour les pools chauds et les environnements réutilisables.
• Application du délai d’expiration : Si le code exécuté dépasse le délai d’expiration horloge murale, la plateforme le termine-t-elle proprement et signale-t-elle le statut de sortie correct ?

Observabilité : Journaux, métriques et traces

Vous ne pouvez pas déboguer ou auditer ce que vous ne pouvez pas voir. Les sandbox de production ont besoin d’observabilité intégrée, pas ajoutée après coup.

Capture de stdout et stderr : Chaque exécution doit produire un enregistrement de sortie capturé associé à l’ID de session et à l’ID d’exécution. Cela doit être accessible via l’API après la fin de l’exécution, pas seulement disponible en tant que flux en temps réel.

Journaux d’exécution : La plateforme doit enregistrer quel code a été exécuté, quand il a commencé, quand il s’est terminé, quel était le code de sortie, quel utilisateur ou locataire possédait la session, et quel modèle ou instantané a été utilisé. Ces enregistrements sont le minimum nécessaire pour reconstruire ce qui s’est passé quand quelque chose ne va pas.

Métriques de ressources : Les applications de production ont besoin de métriques par session pour l’utilisation du CPU, le pic de mémoire, le temps horloge murale et les écritures sur le système de fichiers. Cela permet la planification de capacité, la détection d’anomalies et l’attribution des coûts par session.

Traçage des erreurs : Lorsqu’un sandbox ne parvient pas à démarrer, à exécuter ou à nettoyer, la surface d’erreur doit être structurée : code d’erreur, message, ID de session, et suffisamment de contexte pour distinguer une erreur utilisateur (mauvais code, paquet manquant) d’une erreur de plateforme (quota dépassé, défaillance interne).

Piste d’audit : Pour les applications multi-locataires, la piste d’audit doit rendre le comportement de l’agent reconstructible : ID de session, locataire, séquence d’exécution, installations de paquets, domaines externes contactés, fichiers écrits et résultat du nettoyage. Le code client brut et la sortie complète des commandes peuvent ne pas appartenir aux journaux d’audit par défaut — concevez pour ce que vos politiques de conservation et d’accès peuvent réellement prendre en charge.

Ce qu’il faut éviter : un sandbox qui affiche seulement “échec de l’exécution” sans erreur structurée, sans journaux au niveau de la session et sans moyen de distinguer un délai d’expiration d’un OOM d’une tentative d’évasion de processus. Cela vous oblige à instrumenter tout au niveau de l’application, ce qui double le travail et manque les événements que le sandbox peut observer directement.

Limites CPU, mémoire et délai d’expiration

La consommation de ressources sans limite est l’une des façons les plus simples pour une charge de travail sandboxée de causer des problèmes en production — soit en dégradant d’autres sessions, soit en créant des coûts d’infrastructure imprévus.

Un sandbox de production doit appliquer des limites au niveau de la session, pas seulement au niveau de l’hôte :

CPU : Limiter le temps CPU qu’une seule session peut consommer. Une session qui génère une boucle infinie ne doit pas dégrader les autres sessions sur le même hôte. Vérifiez si la limite est une limite stricte (le processus est limité ou tué) ou une limite souple (il est en concurrence avec d’autres processus pour le CPU disponible).

Mémoire : Définir un plafond mémoire qui déclenche un nettoyage ou une terminaison plutôt que de permettre à la session d’épuiser la mémoire de l’hôte. Vérifiez ce qui se passe lorsque la limite est atteinte : OOM kill, réponse d’erreur structurée, ou blocage silencieux.

Délai d’expiration horloge murale : Chaque appel d’exécution doit avoir une durée maximale. Le délai d’expiration doit être applicable au niveau de la plateforme, pas seulement au niveau du client — si le client abandonne la connexion, le sandbox doit quand même terminer l’exécution à la limite configurée.

Utilisation du disque : Le code généré peut écrire des fichiers de sortie volumineux, installer des paquets volumineux ou remplir le répertoire de travail. Un quota de disque sur le répertoire de travail de la session empêche les écritures incontrôlées.

Nombre de processus : Le code généré par IA peut créer des sous-processus, des workers en arrière-plan ou des commandes shell qui créent elles-mêmes plus de processus. Une limite sur le nombre total de processus dans l’espace de noms de la session empêche les bombes de processus et les arborescences de sous-processus incontrôlées.

Lors de l’évaluation d’une plateforme sandbox, vérifiez si ces limites sont configurables par session (afin que différents niveaux d’utilisateurs ou types de tâches puissent avoir des limites différentes), si elles sont appliquées au niveau du sandbox, et si le fait d’atteindre une limite produit une erreur API structurée ou un échec silencieux.

Politiques d’installation de paquets

Le code généré par IA demande fréquemment des installations de paquets — pip install, npm install, apt-get, clones Git, téléchargements directs d’URL. Chacune de ces opérations extrait du code externe dans le sandbox au moment de l’exécution, ce qui est l’une des opérations les plus risquées qu’un sandbox doive gouverner.

Une politique de paquets de production devrait couvrir :

Listes d’autorisation de registres : Quels registres de paquets sont autorisés ? PyPI et npm sont les valeurs par défaut, mais de nombreuses équipes souhaitent la possibilité de restreindre l’accès à des miroirs internes, des registres organisés ou des sources explicitement approuvées.

Mise en cache des installations : Lorsque de nombreuses sessions installent les mêmes paquets populaires, un cache de couche ou un proxy pull-through évite les téléchargements redondants, réduit la latence de démarrage et vous donne un point pour inspecter ce qui est récupéré.

Mode hors ligne : Certaines charges de travail doivent s’exécuter sans aucune installation de paquets — l’environnement est pré-intégré dans l’image ou le modèle, et les tentatives d’installation doivent échouer avec une erreur claire. C’est le mode approprié pour les exécutions d’évaluation où la reproductibilité est plus importante que la flexibilité.

Vérification de hachage et fichiers de verrouillage : Lorsque les paquets sont autorisés, les versions épinglées et la vérification de hachage réduisent le risque qu’une compromission de registre modifie le code qui s’exécute à l’intérieur du sandbox.

Limites de taille : Les paquets et leurs dépendances transitives peuvent être volumineux. Un plafond de taille sur l’empreinte téléchargée totale par session empêche l’épuisement accidentel ou intentionnel du stockage.

Journalisation des paquets : Chaque tentative d’installation doit être enregistrée dans le journal d’audit d’exécution : nom du paquet, version demandée, source du registre et succès ou échec. Ce sont les données dont vous avez besoin pour reconstruire ce qui est entré dans le sandbox lors d’un incident.

La question à poser à un fournisseur de sandbox n’est pas “les utilisateurs peuvent-ils installer des paquets ?” mais “comment chaque installation est-elle auditée, quels registres sont autorisés par défaut, et puis-je configurer une politique plus stricte pour les charges de travail sensibles ?”

Contrôles réseau et de sortie

L’accès réseau est le deuxième vecteur majeur permettant à un sandbox d’atteindre des destinations inattendues. Une sortie ouverte par défaut est pratique en développement, mais c’est une mauvaise valeur par défaut pour les applications de production exécutant du code généré par IA.

Sortie refusée par défaut : La posture de production la plus solide consiste à bloquer toutes les connexions sortantes par défaut et à autoriser explicitement les destinations dont une session a légitimement besoin. Cela nécessite plus de configuration mais rend le modèle d’accès vérifiable.

Destinations autorisées : Pour les agents de codage, les destinations autorisées typiques peuvent inclure les registres de paquets, un ensemble spécifique d’API publiques que l’agent est conçu pour appeler, et rien d’autre. Pour les agents d’analyse de données, la liste peut inclure des sources de données spécifiques. Vérifiez que la plateforme prend en charge les listes d’autorisation de destinations par session ou par locataire.

Politique DNS : Le DNS doit être traité de manière cohérente avec la politique de sortie. Une session qui ne peut pas atteindre des destinations HTTP arbitraires ne devrait pas non plus être capable de résoudre des noms DNS arbitraires et d’utiliser cela pour déduire la topologie du réseau ou contourner les contrôles via des canaux basés sur DNS.

Accès aux services internes : Le code généré par IA ne doit pas pouvoir atteindre les points de terminaison de métadonnées cloud (par exemple, le service de métadonnées d’instance AWS), les API internes, les bases de données privées ou les panneaux d’administration, sauf s’ils sont explicitement configurés. Vérifiez si la politique réseau par défaut du sandbox bloque les plages d’adresses internes bien connues.

Sortie de téléchargement de paquets : Les installations de paquets sont des opérations réseau. Si la sortie est restreinte, assurez-vous que la liste d’autorisation du registre de paquets est cohérente avec la politique de sortie, ou utilisez un proxy pull-through à l’intérieur du réseau de confiance.

Journalisation des connexions sortantes : Même lorsque la sortie est autorisée, la journalisation des domaines et des IP contactés par une session est utile pour les enquêtes sur les incidents. Toutes les plateformes sandbox ne fournissent pas cela nativement ; vérifiez ce que vous obtiendrez.

Secrets et injection d’identifiants

Les agents IA ont fréquemment besoin d’identifiants — clés API, connexions à des bases de données, jetons OAuth, identifiants cloud de courte durée. La façon dont un sandbox gère les secrets est importante à la fois pour la sécurité et la fiabilité opérationnelle.

Périmètre étroit : Chaque session ne doit recevoir que les secrets nécessaires à la tâche spécifique qu’elle exécute. Monter un fichier d’environnement large avec tous les identifiants dans chaque session est pratique sur le plan opérationnel, mais cela signifie que du code compromis ou malveillant dans n’importe quelle session peut accéder à tous ces identifiants.

Identifiants de courte durée : Lorsque le backend le prend en charge, privilégiez les jetons de courte durée avec une TTL limitée à la durée de la session. Cela limite la fenêtre pendant laquelle un identifiant divulgué est utile.

Mécanisme d’injection : Vérifiez si les secrets sont injectés en tant que variables d’environnement, fichiers montés ou via une API de secrets. Les variables d’environnement sont accessibles à tous les processus de la session par défaut ; les fichiers montés peuvent être délimités à un chemin et un ensemble de permissions. Pour les identifiants les plus sensibles, envisagez une API de secrets qui fournit des valeurs uniquement à un processus explicitement autorisé.

Rédaction : Le sandbox ne doit pas renvoyer les secrets via stdout, stderr, les journaux d’exécution, les messages d’erreur ou les réponses d’outils visibles par le modèle. La rédaction est une responsabilité de la couche application, mais un sandbox qui prend en charge le nettoyage configurable des journaux réduit le rayon d’impact d’une exposition accidentelle.

Nettoyage : Après la fin de la session, vérifiez que les variables d’environnement, les fichiers de secrets montés et toutes les données d’identifiants mises en cache sont nettoyés dans le cadre du démontage de la session, et non laissés pour la session suivante.

Stockage de fichiers éphémère ou persistant

Différentes charges de travail ont différents besoins de persistance, et un sandbox de production devrait prendre en charge les deux modèles clairement.

Sessions éphémères : La valeur par défaut pour l’exécution de code de courte durée est une session qui crée un répertoire de travail propre, exécute le code, produit une sortie et est détruite. Les sessions éphémères sont faciles à raisonner : chaque exécution commence à partir d’une base de référence connue, aucun état ne s’accumule et le nettoyage est simple. Elles sont le bon choix pour les travaux d’évaluation, les complétions de code ponctuelles et toute tâche où la reproductibilité est plus importante que la continuité.

Espaces de travail persistants : Les agents de codage de longue durée, les flux de travail de développement itératifs et les sessions d’agent multi-tours ont souvent besoin d’un espace de travail qui survit à plusieurs appels d’exécution. Les fichiers installés, les dépendances mises en cache, le code écrit et l’historique accumulés lors d’un tour doivent être disponibles lors du suivant. Les espaces de travail persistants sont plus complexes à exploiter : ils accumulent de l’état, ils peuvent dériver du modèle, et ils ont besoin d’un cycle de vie explicite — quand l’espace de travail est-il nettoyé, à qui appartient-il, et quels contrôles d’accès le protègent entre les sessions ?

Instantanés et modèles : Les modèles vous permettent de définir un environnement de base connu et bon — runtimes, outils, dépendances — et de lancer des sessions de manière cohérente. Les instantanés capturent l’état actuel d’une session en cours et l’utilisent comme point de départ pour les sessions futures. Les deux sont utiles pour les équipes qui ont besoin d’environnements reproductibles et d’une faible latence de démarrage. Vérifiez que les modèles sont versionnés, que la création et la mise à jour sont contrôlées, et que les instantanés sont isolés par locataire.

Exportation d’artefacts de sortie : Après l’exécution, qu’est-ce qui peut quitter le sandbox ? Une politique de production devrait définir quels chemins de fichiers sont exportables, quelles limites de taille s’appliquent, et si les artefacts sont examinés ou filtrés avant que l’application ne les reçoive.

État inter-sessions : Soyez explicite sur le fait que la conception de votre application prévoit ou non le partage d’état entre sessions. Le partage accidentel — via un cache de paquets partagé, un volume partagé ou un espace de travail mal routé — est une défaillance courante d’isolation multi-locataire.

Intégration backend : REST, WebSocket, SDK

Un sandbox n’est utile que s’il s’intègre proprement dans le backend de l’application. Les trois principaux modèles d’intégration sont REST, WebSocket et SDK.

REST : Une API REST est l’intégration la plus simple pour les applications qui soumettent des requêtes d’exécution discrètes et interrogent les résultats. Elle fonctionne bien pour les tâches de courte durée, est facile à déboguer avec des outils HTTP standard et s’intègre naturellement dans les architectures de services existantes. Le compromis est que l’interrogation des résultats ajoute de la latence par rapport aux notifications push, et la diffusion en continu des sorties de longue durée nécessite soit SSE, soit l’interrogation d’un point de terminaison de journal.

WebSocket : Une connexion WebSocket prend en charge une communication bidirectionnelle à faible latence entre l’application et le sandbox. C’est le bon choix pour les cas d’utilisation interactifs : un assistant de codage qui diffuse la sortie au fur et à mesure que le code s’exécute, un agent navigateur qui doit envoyer des commandes et recevoir des réponses en temps réel, ou un harnais d’évaluation qui surveille l’exécution en continu. Le compromis est la complexité opérationnelle : les connexions WebSocket nécessitent un état persistant, une gestion de la reconnexion et une infrastructure plus complexe à la fois sur le client et le serveur.

SDK : Un SDK natif au langage masque les détails de transport, gère l’authentification, fournit des interfaces typées pour la gestion des sessions et l’exécution, et inclut souvent des aides pour la diffusion en continu des sorties, le téléchargement de fichiers et la gestion des modèles. Un SDK est le moyen le plus rapide d’intégration pour la plupart des développeurs d’applications. Vérifiez que le SDK est activement maintenu, couvre toute la surface de l’API et gère les erreurs de manière structurée sur laquelle votre application peut agir.

Points d’intégration que votre application doit posséder : Quel que soit le transport, votre application est responsable de l’autorisation (quels utilisateurs peuvent créer des sessions et avec quelles limites de ressources), des portes d’approbation (quels appels d’outils ou exécutions de code nécessitent une révision humaine avant d’être exécutés), du traitement des résultats (comment la sortie du sandbox est présentée ou utilisée par l’agent) et du nettoyage (déclenchement du démontage de la session lorsque le flux utilisateur se termine ou que le tour de l’agent se termine).

Une API sandbox bien conçue n’essaie pas de posséder la logique métier de votre application. Elle expose des primitives — créer, exécuter, diffuser, terminer, nettoyer — et laisse votre couche applicative construire le comportement produit approprié par-dessus.

Récupération après échec et nettoyage

Les systèmes de production échouent. Un sandbox qui gère les échecs avec élégance évite les fuites de ressources, l’état obsolète et les incidents difficiles à déboguer.

Gestion du dépassement de délai d’exécution : Lorsqu’une exécution en cours dépasse son délai d’expiration, la plateforme doit terminer proprement l’arborescence des processus et renvoyer une réponse d’erreur structurée — ne pas laisser une session zombie consommer des ressources. Vérifiez ce qui arrive à la session après un dépassement de délai : est-elle automatiquement nettoyée, ou nécessite-t-elle un appel de nettoyage explicite ?

Récupération après crash de session : Si l’hôte du sandbox plante ou si la VM de session se termine de manière inattendue, la plateforme doit détecter l’échec, marquer la session comme terminée et signaler cet état via l’API afin que l’application puisse réagir. Les sessions ne doivent pas disparaître silencieusement sans signal API.

Garanties de nettoyage : Un appel d’API cleanup ou terminate doit libérer de manière fiable toutes les ressources : allocations CPU et mémoire, quota de système de fichiers, emplacements de processus, état réseau et identifiants. Le nettoyage doit être idempotent — l’appeler plusieurs fois sur le même ID de session ne doit pas renvoyer d’erreur. Cela compte en pratique : le code d’application qui réessaie le nettoyage après une erreur réseau ne doit pas casser.

Échecs d’exécution partielle : Lorsque le code échoue en cours d’exécution — une exception non gérée, un processus tué, un paquet manquant — le sandbox doit renvoyer un résultat structuré qui distingue le succès partiel (une partie de la sortie a été produite avant l’échec) de l’échec total. Les applications construites sur des résultats partiels ont besoin de cela pour éviter de présenter une sortie incomplète ou trompeuse aux utilisateurs.

Gestion des processus incontrôlés : Si le code généré crée un processus d’arrière-plan qui survit à l’exécution principale, le sandbox doit le terminer dans le cadre du nettoyage de la session plutôt que de le laisser s’exécuter indéfiniment. Vérifiez si le nettoyage de la plateforme couvre l’ensemble de l’arbre des processus, pas seulement l’enfant immédiat de l’appel d’exécution.

Erreurs de capacité et de quota : Lorsque la plateforme est à la capacité maximale de sessions ou qu’un locataire a atteint son quota, l’API doit renvoyer un code d’erreur spécifique que l’application peut gérer explicitement — pas un 500 générique ou un blocage silencieux. Cela permet à l’application de mettre en file d’attente, d’atténuer ou de renvoyer un message utile à l’utilisateur.

Novita Agent Sandbox

Novita Agent Sandbox est une plateforme sandbox gérée conçue pour les charges de travail d’agents. Elle cible les agents de codage, les agents d’analyse de données, les flux de travail orientés navigateur et les sessions d’agent de plus longue durée où le code généré doit s’exécuter dans un environnement isolé et observable sans atterrir sur les serveurs d’application ou l’infrastructure partagée.

Pour les équipes qui utilisent déjà les API de modèles Novita AI, Agent Sandbox peut faire partie d’une architecture d’agent plus large : le modèle planifie et génère du code, le sandbox fournit une exécution isolée avec un cycle de vie programmable, et la couche applicative possède l’autorisation, les portes d’approbation et le traitement des résultats.

Novita a décrit des capacités incluant l’isolation par microVM, la prise en charge des sessions simultanées, une API de cycle de vie couvrant la création, l’exécution, la diffusion, la terminaison et le nettoyage, la pause et la reprise automatique pour la gestion de l’état de session, les modèles et instantanés pour un démarrage rapide et reproductible de l’environnement, et l’intégration avec les API de modèles Novita. Vérifiez la disponibilité actuelle des fonctionnalités, les options de configuration des ressources et les prix sur la documentation de Novita Agent Sandbox et la page produit avant de prendre des décisions architecturales. Les affirmations concernant les limites d’isolation spécifiques, les limites de concurrence, la latence de démarrage et la politique réseau doivent être confirmées par rapport à la documentation actuelle du produit.

Lors de l’évaluation de Novita Agent Sandbox par rapport aux exigences de ce guide, appliquez la même liste de vérification que pour tout autre fournisseur : frontière d’isolation par session, exhaustivité de l’API de cycle de vie, surface d’observabilité, limites de ressources configurables, options de politique de paquets, contrôles de sortie, gestion des secrets, modèle de persistance et prise en charge de l’intégration backend.

FAQ

Quel modèle d’isolation dois-je choisir pour le code généré par IA ?

L’isolation par microVM offre la frontière la plus solide pour le code généré par IA non fiable, mais elle ajoute de la complexité opérationnelle. L’isolation par conteneur est adéquate pour les charges de travail à plus faible risque lorsque le conteneur est correctement durci — pas de mode privilégié, capacités minimales, système de fichiers racine en lecture seule lorsque c’est possible, et aucun montage de socket hôte. L’isolation de processus seule est une frontière trop mince pour du code non fiable qui peut tenter des appels système, la création de sous-processus ou des installations de paquets. Adaptez le niveau d’isolation à votre modèle de menace réel.

Comment gérer les installations de paquets dans un sandbox de production ?

Utilisez des listes d’autorisation de registres plutôt qu’un accès ouvert par défaut. Ajoutez un cache de type pull-through pour réduire les téléchargements redondants et vous donner un point d’inspection. Consignez chaque tentative d’installation avec le nom du paquet, la version, la source et le résultat. Pour les charges de travail où la reproductibilité est plus importante que la flexibilité — exécutions d’évaluation, pipelines automatisés — envisagez un mode hors ligne où l’environnement est pré-intégré et les installations sont totalement interdites.

Que doit exposer une API de cycle de vie au minimum ?

Créer, exécuter avec diffusion de la sortie, terminer et nettoyer. La diffusion de la sortie est la capacité qui manque le plus souvent dans les implémentations minimales, et c’est celle qui compte le plus pour les interfaces utilisateur interactives des agents. Le nettoyage doit être idempotent et doit couvrir l’ensemble de l’arbre des processus, pas seulement le processus d’entrée.

Comment empêcher les secrets de fuir via un sandbox ?

Limitez étroitement les identifiants à la tâche — pas un fichier d’environnement large. Privilégiez les jetons de courte durée. Ne consignez pas l’intégralité de stdout par défaut si des secrets peuvent y apparaître. Vérifiez que le sandbox nettoie les variables d’environnement et les fichiers de secrets montés lors du démontage de la session. Traitez la rédaction comme une responsabilité de l’application, pas une garantie du sandbox.

---

Articles recommandés

• Firecracker for AI Agent Sandboxes: Benefits, Limits, and Evaluation Questions
• MCP Servers in Isolated Sandboxes: Filesystem, Secrets, and Network Tradeoffs
• Build an AI Data Analyst with Sandboxed Python and Controlled Package Access