Qu’est-ce qu’un sandbox IA ? Comment délimiter l’exécution du code des agents

Un agent de programmation peut proposer une modification sans rien exécuter. Le risque change lorsqu’il installe un paquet, lance un test, ouvre un fichier importé ou démarre un serveur. Ces actions exécutent des programmes avec les permissions de l’environnement. Une commande de test peut lancer des scripts de dépendances ; une analyse peut ouvrir des fichiers que l’utilisateur n’avait pas prévu de partager.

Prenez un agent chargé de réparer une application défaillante. Il lit le projet, modifie un module, installe des dépendances et lance les tests. Lui donner votre environnement habituel lui donne aussi accès à tout ce que cet environnement peut atteindre : répertoires montés, identifiants, services réseau et éventuellement systèmes de production. Une frontière d’exécution permet de lui attribuer moins de capacités.

L’objectif est de rendre les actions autorisées explicites. Un sandbox peut exécuter du code incorrect, contacter un endpoint autorisé ou détourner un identifiant fourni volontairement. Traitez le code généré et ses dépendances comme des entrées à vérifier, puis concevez l’environnement en fonction des conséquences de leur exécution.

Une exécution classique commence par un projet ou des entrées. L’agent propose du code ou une commande, un outil l’exécute dans l’environnement configuré et renvoie des éléments vérifiables : sortie, code de retour ou fichier généré. L’agent peut s’appuyer sur ces résultats pour effectuer une autre modification.

Pour une application, le résultat peut inclure un serveur d’aperçu. Pour une tâche de données, un graphique. Pour une revue de code, un test en échec avec ses journaux. Un contrat utile précise les entrées, ce qui a été exécuté, les sorties et ce qui doit subsister à l’arrêt.

Sandbox désigne un objectif, pas une implémentation unique. Les conteneurs Linux classiques utilisent des espaces de noms et d’autres contrôles pour séparer les processus en partageant le noyau hôte. La documentation de sécurité Docker couvre les espaces de noms, cgroups, capabilities et risques d’accès au daemon Docker. Les montages, privilèges et interfaces exposés font toujours partie de la frontière.

gVisor ajoute un noyau applicatif en espace utilisateur qui implémente une interface de type Linux. Il assure la médiation avec l’hôte et vise à réduire l’exposition aux vulnérabilités du noyau hôte. Cette couche supplémentaire invite aussi à évaluer la compatibilité et les performances des applications.

Une microVM exécute un noyau invité derrière une frontière de machine virtuelle. Firecracker en est une implémentation : sa conception décrit des invités Linux, KVM, un modèle de périphériques réduit et un jailer pour la production. La plateforme doit toujours configurer le stockage, le réseau, l’identité et le cycle de vie de chaque environnement.

Un sandbox n’est pas nécessairement jetable. L’isolation décrit la frontière autour de l’exécution ; la persistance décrit ce qui reste ensuite. Vous pouvez exécuter une tâche courte sur du code durable, conserver un environnement entre les échanges ou supprimer ses fichiers une fois le résultat récupéré.

Précisez ce qui persiste. Un dépôt sauvegardé diffère d’un cache de dépendances, d’un volume monté ou de la mémoire d’un processus en cours. L’arrêt d’un environnement peut en conserver certains et en perdre d’autres. Une session longue ne remplace ni les sauvegardes ni le contrôle de version.

Pour les agents de programmation, un espace de travail durable avec son propre cycle d’exécution est utile. L’équipe peut continuer à examiner le code après l’arrêt d’un aperçu, puis reconstruire à partir des entrées enregistrées. Pour des calculs ponctuels, conserver la référence d’entrée et l’artefact de sortie peut suffire.

L’isolation du runtime ne décide pas si l’action demandée par un agent est appropriée. Si l’environnement peut joindre un service externe et possède un identifiant accepté par celui-ci, le code peut utiliser cet accès. Protéger l’hôte et limiter les permissions de l’application sont deux tâches liées, mais distinctes.

Le modèle de sécurité de gVisor distingue explicitement les ressources externes au sandbox de celles mises à disposition à l’intérieur. Appliquez cette distinction aux fichiers, destinations réseau et identifiants exposés. Transmettre des données sensibles à un environnement isolé reste une décision de les rendre accessibles à la tâche.

Il en va de même pour la production. Un agent peut produire un build valide tout en introduisant un contrôle de permissions défectueux ou une requête coûteuse. Gardez la revue applicative et l’autorisation de publication dans le workflow : l’isolation ne prouve pas qu’une fonctionnalité est correcte.

Un assistant de programmation a besoin des fichiers du projet, d’outils de compilation et d’un moyen d’examiner les modifications. Un agent qui crée des applications a aussi besoin d’un processus d’aperçu et d’une route accessible. Un agent d’analyse de données doit accéder aux entrées utiles et pouvoir restituer un artefact. Ces tâches peuvent partager une infrastructure sans avoir les mêmes permissions ni règles de conservation.

L’exécution de scripts clients est un autre cas. Le code peut être volontairement hostile, et une tâche ne doit ni consommer le quota d’un autre client ni accéder à ses données. Évaluez explicitement ce modèle de confiance avant de traiter un espace de développement pratique comme un service d’exécution de code arbitraire.

Mesurez le parcours complet de la tâche pour comparer les options. Le temps de démarrage du runtime ne couvre pas la mise à disposition du code, l’installation des dépendances, la file d’attente, le lancement de l’application ni les contrôles de santé. Le délai avant que l’agent puisse exploiter un résultat est souvent plus utile.

Définissez le contrat d’exécution avant de choisir un fournisseur ou de créer l’intégration. Testez-le avec des charges représentatives, y compris les échecs. Une commande bloquée, une dépendance manquante ou un aperçu arrêté doivent produire un état que votre application peut comprendre et gérer pour reprendre.

Adios relie les étapes de programmation dans un espace de travail adossé au code source. Sa documentation décrit les fichiers, les opérations Git, l’activité de l’agent, les builds, les journaux, les contrôles d’aperçu et le déploiement. L’équipe conserve ainsi un projet auquel revenir après la fin d’une commande ou d’un aperçu.

Un client MCP compatible peut utiliser les outils hébergés d’Adios pour créer un espace de travail, écrire des fichiers, préparer un aperçu et consulter les journaux. L’authentification limite le client aux ressources autorisées de l’équipe. Le workflow MCP documenté prévoit une approbation explicite avant le déploiement.

La présentation de la sécurité d’Adios décrit les espaces de noms Linux, les cgroups et les limites de ressources lorsqu’ils sont pris en charge par le runtime choisi. Ces contrôles documentés doivent guider l’évaluation ; le mot sandbox ne promet ni microVM ni noyau invité dédié pour chaque espace de travail. Confirmez les propriétés requises pour le code à exécuter.

Pour essayer ce workflow, connectez un client MCP ou ouvrez un espace de travail, modifiez légèrement le code et examinez le build et l’aperçu. Conservez le résultat dans Git. Vous aurez une base concrète pour déterminer les besoins de la prochaine tâche de l’agent.