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 de terminal contrôlé, des permissions de fichiers explicites, des politiques réseau et d’installation de packages, des secrets isolés, des journaux de commandes, des artefacts, et un chemin d’approbation clair pour les modifications à haut risque avant fusion ou déploiement. Ce modèle fonctionne que l’agent soit de type Codex, connecté à un IDE, déclenché par CI ou intégré à votre propre plateforme développeur : 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 relecteur 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, éditer des fichiers, exécuter des commandes terminal, installer des dépendances lorsque la politique le permet, lancer des tests, démarrer des serveurs d’aperçu, et renvoyer un diff révisable sans avoir un accès large à la machine du développeur ni à l’environnement de production.

Le changement important est que le bac à sable n’est pas simplement une enveloppe 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 preuves.

Pour un simple assistant de codage, une extraction locale et un copier-coller manuel peuvent suffire. Pour un agent capable d’exécuter des commandes ou de continuer sur plusieurs étapes, vous avez besoin de limites plus fortes :

• 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 approbations pour les opérations risquées.
• Une politique d’installation de packages 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 limités à la tâche et, si possible, masqués dans les journaux.
• Les flux stdout, stderr, codes de sortie, modifications de fichiers, artefacts générés et URL d’aperçu capturés.
• Une porte d’examen avant fusion, déploiement ou publication externe.

C’est pourquoi « exécuter Codex dans un bac à sable » doit être compris comme un modèle d’infrastructure, et non comme un simple indicateur CLI ou une intégration avec 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 utilisez 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 du 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 utilisateur en plans, éditions 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, extrait le 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 de terminal	Exécute les commandes approuvées et renvoie les résultats à l’agent	Quelles commandes sont autorisées automatiquement, nécessitent une approbation ou sont bloquées ?
Couche politique	Contrôle la portée du système de fichiers, les secrets, la sortie réseau, les installations de packages, les limites d’exécution et le nettoyage	L’agent peut-il récupérer des packages ? Peut-il accéder à Internet public ? Peut-il lire des identifiants ?
Couche de preuves	Stocke les journaux, les diffs, les résultats de tests, les aperçus et les artefacts	Un relecteur peut-il reconstruire ce qui s’est passé sans se fier au résumé du modèle ?
Porte d’examen	Exige une étape humaine ou d’automatisation de confiance avant fusion, publication ou déploiement	Qui approuve les modifications risquées ? Quelles vérifications doivent d’abord être effectuées ?

En pratique, une même plateforme peut combiner plusieurs de ces couches. L’architecture compte néanmoins car elle permet de rester honnête sur les choix produits. Si un outil donne à un agent un terminal mais ne peut pas afficher les journaux de commandes, les diffs de fichiers ou la politique de sortie, il peut être pratique pour le prototypage mais trop mince pour une révision en production.

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

Le terminal est l’endroit où un agent de codage devient à la fois utile sur le plan opérationnel et risqué. Il peut exécuter des tests, construire des ressources, inspecter des fichiers générés, démarrer des serveurs locaux et diagnostiquer des échecs. Il peut aussi supprimer des fichiers, divulguer des variables d’environnement, exécuter des scripts d’installation inattendus ou consommer d’importantes ressources de calcul.

Un bon modèle de terminal comporte trois parties.

D’abord, 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 être exécutées 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’expiration. Les commandes destructrices ou à impact externe telles que rm -rf, git push, gh pr merge, les CLI de déploiement, la publication de packages, les migrations de bases de données ou les mutations de ressources cloud doivent exiger une approbation explicite ou être bloquées complètement.

Ensuite, diffusez les résultats de manière structurée. L’agent et le relecteur doivent voir la commande, le répertoire de travail, l’heure de début, le code de sortie, stdout, stderr, l’état d’expiration et la politique de troncature des sorties. Une capture d’écran d’un terminal ne suffit pas ; le système doit conserver des journaux lisibles par machine.

Troisièmement, gérez les sessions de longue durée de manière réfléchie. 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 de longue durée comme des ressources avec des identifiants : démarrez‑les, diffusez leurs journaux, exposez uniquement le port d’aperçu nécessaire et arrêtez‑les lors du nettoyage. Ne laissez pas un processus d’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 d’agent de codage révisable. L’agent ne doit 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 utilisateur séparées des modifications de l’agent et capturez le diff exact 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. Extraire le dépôt à main@<sha_base>.
3. Créer la branche agent/task-123.
4. Exécuter l’installation des dépendances selon la politique.
5. Laisser l’agent inspecter, éditer, tester et itérer.
6. Capturer git diff, les résultats de test, les artefacts générés et l’URL d’aperçu.
7. Ouvrir une pull request ou remettre le correctif à un relecteur 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, les validations effectuées, les échecs éventuels et ce qui reste non vérifié.

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

Les installations de packages sont l’un des aspects les plus difficiles de la mise en bac à sable des agents de codage. De nombreuses tâches réelles nécessitent des dépendances. Mais de nombreux incidents de supply chain commencent également par le téléchargement de dépendances, les scripts post‑installation ou les binaires opaques.

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

Contrôle	Implémentation pratique
Gestionnaires de packages	Décidez quels gestionnaires de packages sont disponibles selon le langage et le type de dépôt.
Accès aux registres	Autorisez les registres approuvés ; bloquez les sources de packages arbitraires lorsque la tâche ne les nécessite pas.
Fichiers verrou	Préférez les fichiers verrou 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	Considérez les installations de apt, brew et de paquets OS comme à risque plus élevé que l’installation de dépendances de projet.
Caches	Utilisez des caches de packages contrôlés lorsque la vitesse et la reproductibilité sont nécessaires.
Journalisation	Stockez les noms des packages, versions, URL des registres, sommes de contrôle lorsque disponibles, et la sortie d’installation.

La politique réseau doit être tout aussi explicite. Un agent de codage peut avoir besoin de lire de la documentation publique, d’appeler une API de staging, de télécharger un package ou d’exposer un aperçu local. Ces usages sont différents d’un accès Internet sans restriction. Séparez les téléchargements de packages sortants, la navigation web, les appels API, la livraison de webhooks et l’accès aux 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 registres 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 limités à la surface d’utilisation la plus petite possible. Un agent de codage n’a normalement pas besoin d’identifiants de production. Il peut avoir besoin d’un jeton Git en lecture seule, d’un jeton de registre de packages, d’une clé API de staging ou d’un jeton de déploiement d’aperçu. Chacun doit être limité à la tâche, limité dans le temps si 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 intermédié : le bac à sable peut effectuer une opération, mais le modèle ne voit pas l’identifiant brut. Lorsque des variables d’environnement sont nécessaires, les journaux doivent masquer les motifs de secret connus, et les artefacts de révision ne doivent pas inclure de vidages complets d’environnement.

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

• Requête utilisateur et métadonnées de tâche.
• URL du dépôt, commit de base, branche, et commit ou diff final.
• Commandes demandées, approuvées, bloquées et exécutées.
• Sorties des commandes, codes de sortie et délais d’expiration.
• Lectures et écritures de fichiers lorsque la plateforme peut les capturer.
• Enregistrements de réseau et de téléchargement de packages au niveau que votre politique prend en charge.
• URL 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 relecteur distingue un vrai correctif d’une histoire plausible.

Diffs, aperçus et portes d’examen avant fusion

La sortie la plus utile d’un agent de codage est un ensemble de modifications révisable. Le bac à sable doit donc produire les mêmes artefacts qu’un ingénieur attentif attendrait d’une pull request :

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

Gardez la fusion ou le déploiement final derrière une porte contrôlée par un humain, sauf si votre organisation a établi une politique d’automatisation de confiance distincte pour ce dépôt exact et ce niveau de risque. L’examen humain est particulièrement important lorsque les modifications touchent à l’authentification, à la facturation, à l’accès aux données, aux appels réseau, à l’infrastructure, aux versions de dépendances, aux migrations générées ou au 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 doit donner aux relecteurs une URL d’aperçu limitée, et non un accès réseau large à l’espace de travail.

Stratégie de nettoyage et de réinitialisation pour les sessions d’agent de longue durée

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 utile : 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 doit ê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 :

• Les processus en arrière‑plan et les ports ouverts.
• Les fichiers temporaires et les sorties de construction.
• Les caches de packages et les archives téléchargées.
• Les secrets limités à la tâche.
• Les journaux et artefacts.
• Les branches ou espaces de travail qui ont été remplacés.

La réinitialisation est tout aussi importante. Un relecteur doit pouvoir relancer 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 de longue durée, le flux de travail est difficile à approuver.

Où Novita Agent Sandbox s’inscrit dans ce flux de travail

Novita Agent Sandbox est conçu pour l’infrastructure d’agents 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 d’agents 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 un SDK et des chemins CLI pour travailler avec le cycle de vie du bac à sable, les fichiers, les commandes, les sessions de navigateur et les primitives de flux 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 d’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 limites de produit conservatrices lors de la conception de votre flux de travail :

• Considérez Novita Agent Sandbox comme l’environnement d’exécution, et non comme une garantie de sécurité générale.
• Gardez les secrets, les installations de packages, 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 une automatisation de production.
• Évaluez les limites 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 permet de garder les conseils d’implémentation utiles même lorsque la couche agent change. Vous pouvez utiliser des agents de type Codex, des agents de codage internes, des agents de navigateur ou des workers d’évaluation tout en conservant les mêmes questions de contrôle du bac à sable.

Liste de vérification pour l’implémentation d’un bac à sable pour agent de codage

Utilisez cette liste avant de faire passer un bac à sable pour agent de codage au‑delà d’un prototype.

Domaine	Question minimale pour la production
Espace de travail	Chaque tâche obtient‑elle un système de fichiers 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 relecteurs 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’expiration ?
Approbation	Quelles commandes s’exécutent automatiquement, nécessitent une approbation ou sont bloquées ?
Packages	Les installations de dépendances sont‑elles reproductibles et journalisées ?
Réseau	La sortie réseau est‑elle séparée entre téléchargements de packages, navigation de documentation, appels API et accès aux aperçus ?
Secrets	Les identifiants sont‑ils limités à la tâche et masqués 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 joints à la révision ?
Persistance	La mise en 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, gardez le flux de travail dans une phase de prototype. L’agent peut encore être utile, mais il ne doit pas recevoir un accès large au dépôt, au réseau ou aux identifiants.

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, les E/S du terminal, l’accès au système de fichiers et l’accès réseau dont l’agent a besoin. Ne supposez pas une intégration officielle ou une 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‑vous 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 traitées. Pour les charges de travail sensibles, les équipes de sécurité évaluent souvent des limites d’isolation plus fortes et des contrôles de sortie plus stricts.

Un agent de codage doit‑il avoir accès à Internet ?

Seulement lorsque la tâche le nécessite, et uniquement via une politique que vous pouvez expliquer. La consultation de documentation, l’accès à un registre de packages, les appels à une API de staging et la navigation arbitraire sont des permissions différentes. Journalisez ce que l’agent a récupéré, gardez les installations de packages reproductibles et évitez de donner un accès réseau de production à une session de codage généraliste.

Que doit examiner un relecteur avant de fusionner du code généré par un agent ?

Examinez le diff, les commandes exécutées, la sortie des tests/constructions, les changements de dépendances, les artefacts générés, le comportement des aperçus et toute validation ignorée. Accordez une attention particulière à l’authentification, aux permissions, au traitement des données, aux appels réseau, aux migrations, aux scripts d’installation et aux secrets.

Comment Novita aide‑t‑il pour les bacs à sable d’agent de codage ?

Novita Agent Sandbox fournit un environnement d’exécution d’agent isolé pour des 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 commandes, de packages, 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

• Construire un agent de codage avec le bac à sable d’agent Novita
• Comment les bacs à sable d’agent alimentent une innovation IA sécurisée et évolutive
• Comment utiliser Codex avec les modèles Novita AI