- Ce qu'un sandbox pour agent de codage doit isoler
- Workflow de référence pour exécuter du code généré par un agent
- Points de contrôle de sécurité avant l'exécution des commandes
- Comment gérer les installations de paquets et l'accès réseau
- Diffs, artefacts et journaux pour la révision humaine
- Où s'intègre Novita Agent Sandbox
- FAQ
- Articles recommandés
Un sandbox pour agent de codage permet d’exécuter les commandes et modifications de code générées par un agent dans un espace de travail délimité où les fichiers, les processus, l’accès réseau, les secrets, les journaux et les artefacts de révision peuvent être contrôlés. L’objectif pratique n’est pas de faire comme si du code généré arbitrairement était inoffensif. L’objectif est de traiter l’agent comme un contributeur non fiable disposant d’une machine de développement jetable, de limites claires, d’une exécution observable et d’un chemin d’approbation humaine avant que quoi que ce soit n’atteigne la production.
Ce qu’un sandbox pour agent de codage doit isoler
Un agent de codage devient utile lorsqu’il peut inspecter un dépôt, éditer des fichiers, exécuter des tests, installer des dépendances et fournir un correctif. Ce sont aussi les actions qui rendent l’environnement risqué. Une installation de dépendance par injection d’invite, une commande shell destructive ou un secret exposé accidentellement peuvent causer plus de dégâts qu’une mauvaise réponse textuelle.
Concevez le sandbox autour des ressources que l’agent de codage peut toucher :
| Surface | Ce qu’il faut contrôler | Pourquoi c’est important |
|---|---|---|
| Clonage du dépôt | Branche, SHA du commit, périmètre d’écriture, sous-modules, fichiers générés | Empêche l’agent de modifier la mauvaise base de code ou de cacher des modifications hors du chemin de révision. |
| Système de fichiers | Racine de l’espace de travail, fichiers montés, chemins ignorés, répertoires de sortie | Empêche un accès large aux fichiers hôtes, identifiants, caches et projets non liés. |
| Exécution Shell | Commandes autorisées, répertoire de travail, timeout, capture de sortie, portes d’approbation | Donne à l’agent assez de puissance pour construire et tester tout en limitant les actions à haut risque. |
| Installations de paquets | Politique de registre, fichiers lock, versions épinglées, stratégie de cache, journaux d’installation | Réduit l’ambiguïté de la chaîne d’approvisionnement lorsque l’agent demande de nouvelles dépendances. |
| Accès réseau | Egress par défaut, listes autorisées, comportement DNS, destinations API, miroirs de paquets | Aide à prévenir les mouvements de données non intentionnels et rend les appels externes révisables. |
| Secrets | Identifiants limités, jetons à courte durée de vie, masquage, pas de clés de production par défaut | Empêche l’agent de lire ou divulguer des identifiants dont il n’a pas besoin. |
| Artefacts | Rapports de test, sorties de build, captures d’écran, fichiers générés, journaux | Donne aux réviseurs des preuves sans se fier uniquement au résumé de l’agent. |
| Cycle de vie | Pause, reprise, instantané, réinitialisation, nettoyage, politique de rétention | Rend les exécutions de l’agent reproductibles et jetables au lieu de machines mystérieuses à longue durée de vie. |
Utilisez ce tableau comme une liste de contrôle de conception. Il s’applique que votre sandbox soit construit sur des conteneurs, machines virtuelles, microVMs, sandboxes cloud gérés ou un runner interne. La couche d’isolation exacte importe, mais les contrôles opérationnels autour de cette couche importent aussi.
Workflow de référence pour exécuter du code généré par un agent
Le workflow le plus sûr pour un agent de codage ressemble moins à un chatbot qu’à un pipeline de pull request contrôlé.
- Créez un espace de travail frais pour la tâche.
- Clonez le dépôt cible à une branche ou un commit spécifique.
- Donnez à l’agent une tâche étroite, une commande de test et un périmètre de fichiers.
- Laissez l’agent inspecter les fichiers et proposer un plan.
- Exécutez automatiquement les commandes en lecture seule à faible risque.
- Exigez une approbation ou des vérifications de politique pour les commandes risquées.
- Capturez chaque commande, code de sortie, stdout, stderr, écriture de fichier et artefact généré.
- Exécutez des tests, vérifications de type, linters, builds ou scripts ciblés à l’intérieur du sandbox.
- Exportez un correctif, un diff, les résultats de test et un ensemble d’artefacts.
- Réinitialisez ou détruisez l’espace de travail après révision, sauf si un instantané est intentionnellement conservé.
Le détail important est que le sandbox n’est pas seulement un lieu pour exécuter du code. C’est aussi l’enregistreur de preuves. Un réviseur devrait pouvoir répondre : quel dépôt a été cloné, qu’est-ce qui a changé, quelles commandes ont été exécutées, qu’est-ce qui a échoué, qu’est-ce qui a réussi, quels fichiers ont été produits et quelles ressources externes ont été contactées.
Pour les agents simples, cela peut être implémenté comme une file d’actions avec des vérifications de politique autour de chaque action. Pour les agents plus capables, gardez les mêmes limites mais rendez le plan de contrôle plus explicite : un composant décide ce que l’agent est autorisé à demander, un composant exécute les actions approuvées et un composant enregistre l’exécution.
tâche utilisateur
-> l'agent propose des lectures, éditions et commandes de fichiers
-> la couche de politique classe chaque action
-> le sandbox exécute les actions approuvées
-> les journaux, diffs et artefacts sont capturés
-> un humain révise le correctif avant fusion ou déploiement
Cette séparation empêche le modèle d’être à la fois le planificateur et l’autorité finale sur les opérations dangereuses.
Points de contrôle de sécurité avant l’exécution des commandes
Partez du principe que les commandes générées peuvent être erronées, trop larges ou influencées par le contenu du dépôt. Un agent de codage pourrait lire une instruction malveillante à partir d’un fixture de test, d’un README, d’un corps d’issue, d’un script de paquet ou d’une page web. Le sandbox doit rendre ces échecs visibles et contenus.
Avant l’exécution shell, définissez des classes de commandes :
| Classe de commande | Exemples | Politique par défaut |
|---|---|---|
| Inspection en lecture seule | pwd, ls, git status, rg, cat package.json |
Généralement autoriser et journaliser. |
| Vérification locale | npm test, pytest, go test, cargo test |
Autoriser avec timeout et capture de sortie. |
| Build ou génération | npm run build, génération de code, génération de documentation |
Autoriser lorsque les chemins de sortie sont attendus. |
| Modifications de dépendances | installation de gestionnaire de paquets, mise à jour du fichier lock | Nécessite des vérifications de politique ou une approbation. |
| Commandes réseau | récupération d’URL, appels API, clonage de dépôts supplémentaires | Nécessite une politique de destination et une journalisation. |
| Commandes destructrices | suppression, reset forcé, nettoyage de disque, chmod/chown large | Bloquer ou nécessiter une approbation humaine explicite. |
| Accès aux secrets | lecture de fichiers d’environnement, magasins d’identifiants, configurations de déploiement | Bloquer sauf si spécifique à la tâche et limité. |
Cela ne nécessite pas un analyseur statique parfait. Même des contrôles simples aident : restrictions de répertoire de travail, motifs de refus explicites, timeouts de commande, limites de taille de sortie et une invite d’approbation pour les commandes qui modifient les dépendances, touchent aux identifiants ou contactent des hôtes externes.
Les limites du système de fichiers doivent être tout aussi concrètes. Montez uniquement le dépôt et les répertoires temporaires dont l’agent a besoin. Évitez de monter le répertoire personnel de l’opérateur, les clés SSH, la configuration cloud, les identifiants du gestionnaire de paquets, les profils de navigateur ou les fichiers de l’environnement de production. Si des caches sont nécessaires pour la vitesse, préférez des caches en lecture seule ou limités à la tâche avec une rétention claire.
Comment gérer les installations de paquets et l’accès réseau
L’installation de paquets est l’une des parties les plus difficiles du sandboxing d’agent de codage car elle est à la fois utile et risquée. Les agents ont besoin de reproduire les builds et d’exécuter des tests, mais les scripts d’installation peuvent exécuter du code, tirer des dépendances transitives et contacter des infrastructures externes.
Utilisez une politique plus stricte pour le travail avec les paquets :
- Préférez les installations basées sur des fichiers lock plutôt que la résolution libre des dépendances.
- Journalisez la commande du gestionnaire de paquets, l’URL du registre, les noms des paquets, les versions et les modifications du fichier lock.
- Acheminez les téléchargements de dépendances via des registres ou miroirs approuvés lorsque c’est possible.
- Traitez les nouvelles dépendances comme des modifications de code nécessitant une révision.
- Bloquez les scripts d’installation pour les workflows à haut risque sauf si le projet en a explicitement besoin.
- Gardez les caches de dépendances séparés des secrets et des dépôts non liés.
L’egress réseau mérite le même traitement. Un agent de codage peut avoir besoin d’un accès internet pour les registres de paquets, la documentation API, les vérifications de navigateur ou les tests d’intégration. Cela ne signifie pas qu’il a besoin d’un accès sortant non restreint.
Au minimum, définissez la valeur par défaut :
| Question réseau | Valeur par défaut plus sûre |
|---|---|
| Le sandbox peut-il atteindre internet ? | Non, sauf si la tâche l’exige. |
| Peut-il résoudre des noms DNS arbitraires ? | Restreindre ou journaliser les DNS et les hôtes de destination. |
| Peut-il appeler des API de production ? | Utiliser des endpoints de staging ou des services mock par défaut. |
| Peut-il récupérer des dépendances de paquets ? | Utiliser des registres, miroirs et fichiers lock approuvés. |
| Peut-il télécharger des fichiers ou des journaux ? | Bloquer sauf si la destination est attendue et révisée. |
Ne décrivez pas ces contrôles comme une garantie que l’exfiltration ou la compromission des dépendances ne peut pas se produire. L’affirmation réaliste est plus étroite : la politique, l’isolation, la journalisation et la révision réduisent le rayon d’explosion et rendent le comportement risqué plus facile à détecter avant que le correctif ne soit approuvé.
Diffs, artefacts et journaux pour la révision humaine
La révision humaine est plus efficace lorsque le sandbox produit un ensemble de révision compact, et non un long transcript de chat.
Pour chaque exécution, capturez :
- L’URL du dépôt, la branche et le SHA du commit utilisés pour le clonage.
- L’invite de tâche ou le résumé du problème.
- Les fichiers lus et les fichiers écrits.
- Chaque commande, répertoire de travail, heure de début, heure de fin, code de sortie, stdout et stderr.
- Les commandes d’installation de dépendances et les modifications du fichier lock.
- Les résultats des tests, lint, vérification de type et build.
- Les artefacts générés tels que captures d’écran, rapports, couverture, binaires ou URL de prévisualisation.
- Le diff final dans un format de correctif ou de pull request standard.
Le réviseur doit inspecter le diff en premier, puis utiliser les journaux et artefacts pour répondre à des questions ciblées. Les tests ont-ils vraiment été exécutés ? L’agent a-t-il modifié des fichiers en dehors du périmètre demandé ? A-t-il ajouté une dépendance ? A-t-il réécrit des fichiers générés ? A-t-il appelé un service réseau ? A-t-il laissé des artefacts volumineux ou sensibles ?
Pour les équipes de production, rendez la porte de révision explicite :
- L’agent peut proposer un correctif.
- Le sandbox peut exécuter une vérification.
- Le système peut ouvrir une pull request.
- Un humain ou une politique approuvée doit décider de fusionner, déployer ou accorder des permissions élargies.
Cette limite est particulièrement importante pour les dépôts qui incluent l’infrastructure, la facturation, l’authentification, le déploiement ou les chemins de données clients.
Où s’intègre Novita Agent Sandbox
Novita Agent Sandbox est conçu pour des environnements d’exécution isolés et avec état où les agents peuvent exécuter du code, installer des dépendances, accéder aux fichiers, utiliser des workflows de navigateur et conserver l’état d’exécution entre sessions. La vue d’ensemble d’Agent Sandbox décrit trois éléments constitutifs principaux : les sandboxes pour l’exécution isolée de tâches, les templates pour des environnements préparés et les instantanés pour réutiliser un état configuré.
Pour les workflows d’agent de codage, ces primitives se mappent naturellement à un espace de travail de développement contrôlé :
| Besoin de l’agent de codage | Pattern sandbox |
|---|---|
| Démarrer depuis un environnement connu | Utiliser un template avec l’environnement d’exécution et les outils attendus. |
| Exécuter des commandes et des tests loin de l’hôte | Exécuter dans un système de fichiers et un environnement d’exécution spécifiques au sandbox. |
| Réutiliser une configuration préparée | Sauvegarder un instantané après avoir installé les dépendances approuvées ou les outils du projet. |
| Déboguer un travail d’agent de longue durée | Conserver l’état entre sessions lorsque le workflow nécessite une continuité. |
| Nettoyer après révision | Réinitialiser, arrêter ou jeter le sandbox selon votre politique de rétention. |
Gardez l’utilisation du produit et la politique de sécurité séparées. Novita Agent Sandbox peut fournir l’environnement d’exécution isolé pour les agents exécutant du code, mais votre application doit toujours définir l’accès au dépôt, la politique de commande, le périmètre des secrets, les règles réseau, la rétention des artefacts et les portes d’approbation humaine. Ces choix dépendent de votre modèle de menace et doivent être examinés par vos responsables techniques et de sécurité avant une utilisation en production publique.
Les développeurs qui souhaitent un exemple pratique peuvent également lire le guide Novita pour construire un serveur MCP d’exécution de code à distance avec Novita Sandbox. Pour la documentation produit, commencez par la documentation Novita Agent Sandbox et le guide d’installation du SDK et CLI.
FAQ
Un sandbox pour agent de codage est-il suffisant pour rendre le code généré sûr ?
Non. Un sandbox est une couche de contrôle. Vous avez toujours besoin d’un accès limité au dépôt, d’une politique de commande, de contrôles de dépendances, de restrictions réseau, de gestion des secrets, de journaux, de révision des artefacts et d’une approbation humaine avant fusion ou déploiement.
Les agents de codage doivent-ils avoir accès à internet ?
Seulement lorsque la tâche l’exige. De nombreux workflows de révision de code, refactorisation et test peuvent fonctionner sans accès internet général après la préparation des dépendances. Lorsque l’accès internet est nécessaire, journalisez les destinations et préférez les registres de paquets autorisés, les sites de documentation, les API de staging ou les mocks.
Les agents doivent-ils recevoir des secrets de production ?
Évitez de donner des secrets de production aux agents de codage par défaut. Utilisez des identifiants limités et à courte durée de vie pour la tâche spécifique, préférez les services de staging, masquez les journaux et gardez l’accès aux secrets en dehors de l’espace de travail du dépôt sauf s’il existe une raison révisée.
Que faut-il réviser avant d’approuver un correctif d’agent ?
Réviser le diff, les dépendances modifiées, les fichiers générés, le journal des commandes, les résultats de test, l’activité réseau et les artefacts. Portez une attention particulière aux modifications d’authentification, autorisation, déploiement, facturation, infrastructure, accès aux données et gestion de paquets.
Quand un sandbox doit-il être réinitialisé ?
Réinitialisez ou détruisez l’espace de travail après chaque tâche sauf si vous sauvegardez intentionnellement un instantané. Un état persistant est utile pour les workflows de longue durée, mais cela doit être un choix délibéré avec des règles de propriété, de rétention et de nettoyage.
