Exécuter Codex ou un agent de codage dans un bac à sable sécurisé

Exécutez un agent de codage dans un bac à sable en lui fournissant un espace de travail de dépôt délimité, un chemin d’exécution terminal contrôlé, des permissions de fichiers explicites, des politiques réseau et d’installation de paquets, des secrets isolés, des journaux de commandes, des artefacts et un chemin d’approbation clair pour les modifications à haut risque avant la fusion ou le déploiement. Ce modèle fonctionne que l’agent soit de style Codex, connecté à l’IDE, déclenché par CI ou intégré dans votre propre plateforme de développement : le modèle peut planifier et éditer, mais le bac à sable décide ce qu’il peut toucher, ce qu’il peut exécuter, ce qu’il peut récupérer et quelles preuves un réviseur reçoit.

Qu’est-ce qu’un bac à sable pour agent de codage ?

Un bac à sable pour agent de codage est un environnement d’exécution isolé dans lequel un système d’IA peut inspecter du code, modifier des fichiers, exécuter des commandes terminales, installer des dépendances lorsque la politique le permet, lancer des tests, démarrer des serveurs d’aperçu et renvoyer une diff révisable sans obtenir un accès large à la machine du développeur ou à l’environnement de production.

Le changement important est que le bac à sable n’est pas simplement une interface de chat autour d’un modèle. C’est la frontière opérationnelle du travail. Le modèle propose des actions ; le bac à sable applique l’espace de travail, les outils, les permissions et la piste de preuve.

Pour un simple assistant de code, un checkout local et un copier-coller manuel peuvent suffire. Pour un agent capable d’exécuter des commandes ou de continuer pendant de nombreuses étapes, vous avez besoin de frontières plus solides :

• Un espace de travail dédié pour chaque tâche ou session.
• Un état de dépôt et une branche connus.
• Une interface d’exécution de commandes avec des approbations pour les opérations risquées.
• Une politique d’installation de paquets pour npm, pip, cargo, apt et outils similaires.
• Des règles de sortie réseau pour les registres, la documentation, les API et l’accès aux aperçus.
• Des secrets délimités à la tâche et cachés des journaux lorsque c’est possible.
• La sortie standard, la sortie d’erreur, les codes de sortie, les modifications de fichiers, les artefacts générés et les URLs d’aperçu capturés.
• Une porte de révision avant la fusion, le déploiement ou la publication externe.

C’est pourquoi « exécuter Codex dans un bac à sable » doit être compris comme un modèle d’infrastructure, pas un simple drapeau CLI ou une intégration d’un seul fournisseur. Codex CLI lui-même est documenté comme un agent de codage qui s’exécute localement sur votre ordinateur, et la documentation de Codex d’OpenAI décrit un flux de travail orienté terminal. Si vous exploitez ce type d’agent pour une équipe, un système CI ou un flux de travail produit, l’environnement d’exécution environnant devient le plan de contrôle.

Architecture d’un bac à sable pour agent de codage

L’architecture la plus propre sépare la boucle du modèle de la frontière d’exécution :

Couche	Responsabilité	Questions à répondre
Interface agent	Transforme l’intention de l’utilisateur en plans, modifications de fichiers, appels d’outils et résumés de révision	Quel modèle ou agent de codage est utilisé ? Comment les invites, le contexte et les schémas d’outils sont-ils gérés ?
Gestionnaire d’espace de travail	Crée le bac à sable, fait le checkout du dépôt, définit la branche et monte les fichiers autorisés	Chaque tâche est-elle isolée ? Le commit de base est-il connu ? L’espace de travail peut-il être réinitialisé ?
Exécuteur terminal	Exécute les commandes approuvées et renvoie les résultats en flux à l’agent	Quelles commandes sont autorisées automatiquement, nécessitent une approbation ou sont bloquées ?
Couche de politique	Contrôle la portée du système de fichiers, les secrets, la sortie réseau, les installations de paquets, les limites d’exécution et le nettoyage	L’agent peut-il récupérer des paquets ? Peut-il accéder à Internet public ? Peut-il lire des informations d’identification ?
Couche de preuve	Stocke les journaux, les diffs, les résultats de test, les aperçus et les artefacts	Un réviseur peut-il reconstruire ce qui s’est passé sans faire confiance au résumé du modèle ?
Porte de révision	Exige une étape humaine ou d’automatisation de confiance avant la fusion, la publication ou le déploiement	Qui approuve les modifications risquées ? Quels contrôles doivent d’abord réussir ?

En pratique, une plateforme unique peut combiner plusieurs de ces couches. L’architecture compte toujours car elle maintient l’honnêteté des choix produits. Si un outil donne à un agent un terminal mais ne peut pas montrer les journaux de commandes, les diffs de fichiers ou la politique de sortie, il peut être pratique pour le prototypage mais trop léger pour la révision en production.

Comment devrait fonctionner l’accès au terminal dans un bac à sable pour agent de codage ?

Le terminal est l’endroit où un agent de codage devient opérationnellement utile et opérationnellement risqué. Il peut exécuter des tests, construire des actifs, inspecter des fichiers générés, démarrer des serveurs locaux et diagnostiquer des échecs. Il peut aussi supprimer des fichiers, fuiter des variables d’environnement, exécuter des scripts d’installation inattendus ou consommer de grandes ressources de calcul.

Un bon modèle de terminal comporte trois parties.

Premièrement, définissez des classes de commandes. Les commandes sûres en lecture seule telles que ls, sed, rg, git diff et les commandes d’état de test peuvent souvent s’exécuter automatiquement. Les commandes de construction et de test telles que npm test, pytest, cargo test et npm run build peuvent être autorisées avec des délais d’attente. Les commandes destructrices ou à impact externe telles que rm -rf, git push, gh pr merge, les CLI de déploiement, la publication de paquets, la migration de bases de données ou la mutation de ressources cloud doivent exiger une approbation explicite ou être complètement bloquées.

Deuxièmement, renvoyez les résultats avec structure. L’agent et le réviseur doivent voir la commande, le répertoire de travail, l’heure de début, le code de sortie, la sortie standard, la sortie d’erreur, l’état du délai d’attente et la politique de sortie tronquée. Une capture d’écran d’un terminal ne suffit pas ; le système doit préserver des journaux lisibles par machine.

Troisièmement, gérez délibérément les sessions longues. Les agents de codage ont souvent besoin d’un serveur de développement en arrière-plan, d’un observateur, d’un processus d’automatisation de navigateur ou d’une pile de tests d’intégration. Traitez les processus longs comme des ressources avec des identifiants : démarrez-les, diffusez les journaux, exposez uniquement le port d’aperçu requis et arrêtez-les lors du nettoyage. Ne laissez pas un processus en arrière-plan devenir un effet secondaire non suivi d’une session de chat.

Isolation du dépôt et contrôle de branche pour les modifications de l’agent

L’état du dépôt est l’épine dorsale d’un flux de travail révisable avec agent de codage. L’agent ne devrait pas travailler dans un dossier ambigu avec des modifications locales inconnues, sauf si l’utilisateur a explicitement choisi ce mode.

Pour les flux de travail en équipe, commencez chaque tâche à partir d’une URL de dépôt, d’une branche de base et d’un SHA de commit connus. Créez une branche de tâche ou un espace de travail détaché. Gardez les modifications de l’utilisateur séparées des modifications de l’agent et capturez la diff exacte avant la révision. Si le bac à sable prend en charge les sessions persistantes, persistez l’espace de travail intentionnellement ; ne vous fiez pas à un état de processus accidentel.

Le modèle par défaut ressemble à ceci :

1. Créer un espace de travail isolé pour la tâche-123.
2. Faire checkout du dépôt sur main@<sha_de_base>.
3. Créer la branche agent/tâche-123.
4. Lancer l'installation des dépendances selon la politique.
5. Laisser l'agent inspecter, éditer, tester et itérer.
6. Capturer le git diff, la sortie des tests, les artefacts générés et l'URL d'aperçu.
7. Ouvrir une pull request ou remettre le correctif à un réviseur humain.
8. Détruire ou archiver l'espace de travail selon la politique de conservation.

Le détail clé est l’étape 6. Un agent de codage utile ne se contente pas de dire « J’ai réparé ça. » Il renvoie les fichiers modifiés, la raison de chaque modification, quelle validation a été exécutée, ce qui a échoué et ce qui reste non vérifié.

Politiques de commandes, de paquets et de réseau pour les agents de codage en bac à sable

Les installations de paquets sont l’une des parties les plus difficiles de la mise en bac à sable des agents de codage. De nombreuses tâches réelles nécessitent des dépendances. De nombreux incidents de chaîne d’approvisionnement commencent également par la récupération de dépendances, les scripts post-installation ou les binaires opaques.

Une politique pratique n’est pas « n’installez jamais de paquets. » C’est « n’installez des paquets que par des chemins connus, avec journalisation et portée. »

Contrôle	Mise en œuvre pratique
Gestionnaires de paquets	Décidez quels gestionnaires de paquets sont disponibles en fonction du langage et du type de dépôt.
Accès aux registres	Autorisez les registres approuvés ; bloquez les sources de paquets arbitraires lorsque la tâche n’en a pas besoin.
Fichiers de verrouillage	Préférez les fichiers de verrouillage existants et les commandes d’installation reproductibles.
Scripts post-installation	Décidez si les scripts de cycle de vie peuvent s’exécuter automatiquement ou nécessitent une approbation.
Paquets système	Traitez les installations de paquets apt, brew et OS comme plus risquées que les installations de dépendances de projet.
Caches	Utilisez des caches de paquets contrôlés lorsque vous avez besoin de vitesse et de reproductibilité.
Journalisation	Stockez les noms de paquets, les versions, les URLs de registre, les sommes de contrôle lorsqu’elles sont disponibles et la sortie d’installation.

La politique réseau devrait être tout aussi explicite. Un agent de codage peut avoir besoin de lire la documentation publique, d’appeler une API de staging, de télécharger un paquet ou d’exposer un aperçu local. Ce sont des permissions différentes d’un accès Internet non restreint. Séparez les récupérations de paquets sortantes, la navigation web, les appels API, la livraison de webhooks et l’entrée des aperçus. Si votre produit traite du code ou des données sensibles, demandez-vous si le DNS, les journaux de proxy et les miroirs de registre sont couverts par la même politique que le trafic HTTP.

Secrets, journaux et pistes d’audit pour les espaces de travail des agents

Les secrets doivent être délimités à la plus petite surface utile. Un agent de codage n’a normalement pas besoin d’informations d’identification de production. Il peut avoir besoin d’un jeton Git en lecture seule, d’un jeton de registre de paquets, d’une clé API de staging ou d’un jeton de déploiement d’aperçu. Chacun doit être délimité à la tâche, limité dans le temps lorsque c’est possible et indisponible pour les commandes qui ne l’exigent pas.

Évitez de placer des secrets dans des fichiers que l’agent peut lire, sauf si la tâche le nécessite vraiment. Préférez un accès par intermédiaire : le bac à sable peut effectuer une opération, mais le modèle ne voit pas l’information d’identification brute. Lorsque les variables d’environnement sont nécessaires, les journaux devraient obscurcir les motifs de secrets connus, et les artefacts du réviseur ne devraient pas inclure de vidages complets de l’environnement.

Pour les pistes d’audit, stockez plus que le correctif final :

• Demande de l’utilisateur et métadonnées de la tâche.
• URL du dépôt, commit de base, branche et commit final ou diff.
• Commandes demandées, approuvées, bloquées et exécutées.
• Sorties des commandes, codes de sortie et délais d’attente.
• Lecture et écriture de fichiers lorsque la plateforme peut les capturer.
• Enregistrements de réseau et de récupération de paquets au niveau que votre politique supporte.
• URLs d’aperçu et chemins d’artefacts générés.
• Approbations humaines et décisions de fusion.

Ce n’est pas de la bureaucratie. C’est ainsi qu’un réviseur distingue une vraie correction d’une histoire plausible.

Diffs, aperçus et portes de révision avant la fusion

Le résultat le plus utile d’un agent de codage est un ensemble de modifications révisables. Cela signifie que le bac à sable devrait produire les mêmes artefacts qu’un ingénieur prudent attendrait d’une pull request :

• Une diff ciblée.
• Les tests ou commandes de construction qui ont été exécutés.
• Les échecs qui subsistent.
• Des captures d’écran, des URLs d’aperçu ou des fichiers téléchargeables lorsque l’interface utilisateur ou les actifs générés ont changé.
• Une brève explication du changement de comportement prévu.

Maintenez la fusion ou le déploiement final derrière une porte contrôlée par un humain, à moins que votre organisation n’ait construit une politique d’automatisation de confiance distincte pour ce dépôt et ce niveau de risque exacts. La révision humaine est particulièrement importante lorsque les modifications touchent l’authentification, la facturation, l’accès aux données, les appels réseau, l’infrastructure, les versions de dépendances, les migrations générées ou le contenu visible par l’utilisateur.

La gestion des aperçus mérite sa propre règle : exposez uniquement le service et le port nécessaires à la révision. Un bac à sable qui démarre une application web devrait donner aux réviseurs une URL d’aperçu délimitée, pas un accès réseau large à l’espace de travail.

Stratégie de nettoyage et de réinitialisation pour les sessions d’agent longues

Chaque bac à sable a besoin d’un cycle de vie. Sans cela, l’infrastructure d’agent de codage de longue durée devient un tas d’espaces de travail obsolètes, de journaux divulgués et de processus toujours en cours.

Pour les tâches courtes, un modèle éphémère fonctionne bien : créez un bac à sable, exécutez le travail, extrayez les artefacts, puis détruisez-le. Pour les tâches plus importantes, la persistance peut être précieuse : l’agent peut avoir besoin de faire une pause, d’attendre une révision, de reprendre à partir de la même branche ou de maintenir un serveur de développement en cours pendant une session de révision. La persistance devrait être une fonctionnalité explicite du produit avec une date d’expiration, un propriétaire et des règles de conservation.

Définissez le nettoyage pour :

• Processus en arrière-plan et ports ouverts.
• Fichiers temporaires et sorties de construction.
• Caches de paquets et archives téléchargées.
• Secrets délimités à la tâche.
• Journaux et artefacts.
• Branches ou arbres de travail devenus obsolètes.

La réinitialisation est tout aussi importante. Un réviseur devrait pouvoir réexécuter la validation de l’agent à partir du commit de base ou de la branche finale. Si le résultat ne fonctionne qu’à cause d’un état invisible à l’intérieur d’une session longue, le flux de travail est difficile à approuver.

Où se situe Novita Agent Sandbox dans ce flux de travail

Novita Agent Sandbox est conçu pour l’infrastructure d’agent où l’exécution de code, l’automatisation de navigateur, les flux de travail de type « computer use », l’analyse de données, les évaluations et les flux de travail d’agent plus longs nécessitent un environnement d’exécution isolé. La documentation de Novita Agent Sandbox décrit le produit comme un environnement avec état pour exécuter des charges de travail d’agent, avec des chemins SDK et CLI pour travailler avec le cycle de vie du bac à sable, les fichiers, les commandes, les sessions de navigateur et les primitives de flux de travail associées.

Pour les équipes qui utilisent déjà les API de modèle Novita AI, une couche de bac à sable peut réduire l’écart entre l’inférence du modèle et l’exécution des actions. Le modèle peut raisonner, appeler des outils et planifier des modifications de code ; le bac à sable peut fournir l’espace de travail isolé où ces actions sont exécutées, journalisées, prévisualisées et révisées.

Utilisez des frontières de produit prudentes lors de la conception de votre flux de travail :

• Traitez Novita Agent Sandbox comme l’environnement d’exécution, pas comme une garantie de sécurité générale.
• Gardez les secrets, les installations de paquets, la sortie réseau et les actions de publication derrière votre propre politique.
• Validez les détails actuels du SDK, CLI, tarifs et limites de compte à partir de la documentation Novita avant de les coder en dur dans votre automatisation de production.
• Évaluez les frontières d’isolation, la compatibilité avec les agents tiers et les exigences de conformité par rapport à votre propre politique avant de vous fier à un bac à sable en production.

Cette séparation maintient l’utilité des conseils de mise en œuvre même lorsque la couche agent change. Vous pouvez utiliser des agents de style Codex, des agents de codage internes, des agents de navigateur ou des travailleurs d’évaluation tout en conservant les mêmes questions de contrôle du bac à sable.

Liste de contrôle de mise en œuvre pour le bac à sable d’agent de codage

Utilisez cette liste de contrôle avant de faire passer un bac à sable d’agent de codage au-delà d’un prototype.

Domaine	Question minimale de production
Espace de travail	Chaque tâche obtient-elle un système de fichiers délimité et un commit de base de dépôt connu ?
Branchement	Les modifications de l’agent sont-elles isolées sur une branche ou un correctif que les réviseurs peuvent inspecter ?
Terminal	Les commandes sont-elles journalisées avec le répertoire de travail, la sortie, le code de sortie et le délai d’attente ?
Approbation	Quelles commandes s’exécutent automatiquement, nécessitent une approbation ou sont bloquées ?
Paquets	Les installations de dépendances sont-elles reproductibles et journalisées ?
Réseau	La sortie réseau est-elle séparée entre récupérations de paquets, navigation dans la documentation, appels API et accès aux aperçus ?
Secrets	Les informations d’identification sont-elles délimitées à la tâche et obscurcies dans les journaux ?
Aperçus	Les ports d’aperçu sont-ils explicites et faciles à arrêter ?
Artefacts	Les fichiers générés, captures d’écran, rapports et journaux sont-ils attachés à la révision ?
Persistance	La pause/reprise de session est-elle intentionnelle, avec propriétaire et date d’expiration ?
Nettoyage	Les processus, ports, fichiers temporaires, secrets et espaces de travail obsolètes sont-ils supprimés ?
Révision	Un humain approuve-t-il la fusion, la publication ou le déploiement pour les modifications risquées ?

Si votre configuration actuelle ne peut pas répondre à plusieurs de ces questions, maintenez le flux de travail dans une voie de prototype. L’agent peut toujours être utile, mais il ne devrait pas recevoir un accès large au dépôt, au réseau ou aux informations d’identification.

FAQ

Puis-je exécuter Codex lui-même dans un bac à sable cloud ?

Conceptuellement, oui : un agent de codage en terminal peut être exécuté dans un espace de travail isolé si l’environnement prend en charge le système d’exploitation, le chemin d’authentification, l’E/S terminale, l’accès au système de fichiers et l’accès réseau requis par l’agent. Ne supposez pas d’intégration officielle ou de compatibilité totale à moins que le fournisseur du bac à sable et le fournisseur de l’agent ne le documentent pour votre configuration exacte.

Docker est-il suffisant pour un bac à sable d’agent de codage ?

Docker peut être utile pour le développement local, les tâches CI et les environnements reproductibles, mais « suffisant » dépend de votre modèle de menace. Demandez ce qui partage un noyau, quels montages de fichiers existent, comment la sortie réseau est contrôlée, si les secrets sont exposés au conteneur et comment les évasions ou les compromissions de dépendances seraient gérées. Pour les charges de travail sensibles, les équipes de sécurité évaluent souvent des frontières d’isolation plus fortes et des contrôles de sortie plus stricts.

Un agent de codage devrait-il avoir un accès Internet ?

Seulement lorsque la tâche en a besoin, et seulement à travers une politique que vous pouvez expliquer. La consultation de documentation, l’accès au registre de paquets, les appels API de staging et la navigation arbitraire sont des permissions différentes. Journalisez ce que l’agent a récupéré, maintenez les installations de paquets reproductibles et évitez de donner un accès réseau de production à une session de codage à usage général.

Que devrait examiner un réviseur avant de fusionner le code généré par l’agent ?

Révisez la diff, les commandes qui ont été exécutées, la sortie des tests/construction, les modifications de dépendances, les artefacts générés, le comportement de l’aperçu et toute validation ignorée. Portez une attention particulière à l’authentification, aux autorisations, au traitement des données, aux appels réseau, aux migrations, aux scripts d’installation et aux secrets.

Comment Novita aide-t-il avec les bacs à sable pour agents de codage ?

Novita Agent Sandbox fournit un environnement d’exécution isolé pour l’agent pour les charges de travail telles que l’exécution de code, l’automatisation de navigateur, les tâches de type « computer use », l’analyse de données, les évaluations et les flux de travail plus longs. Associez-le à des politiques explicites de dépôt, de commande, de paquet, de réseau, de secrets et de révision lors de la construction d’un flux de travail d’agent de codage.

Articles recommandés

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