Sandboxes sécurisés pour agents de code et identifiants éphémères

Les agents de code exécutent des combinaisons non fiables de contenu de dépôt, sorties d'outils, scripts de packages et commandes générées par le modèle. Un sandbox n'est pas seulement un conteneur de développement pratique. C'est la frontière d'application qui limite l'impact d'une instruction erronée, d'une injection de prompt dans un artefact du dépôt, du comportement malveillant d'une dépendance ou d'un agent qui emprunte une voie dangereuse.

Ce guide traite de l'environnement d'exécution des agents de livraison logicielle. Il ne remplace ni la modélisation des menaces applicatives ni les contrôles de sécurité LLM de production. La discussion d'OpenAI de février 2026 sur le harness engineering et les travaux d'Anthropic sur les environnements d'agents font tous deux de l'environnement périphérique un élément déterminant ; pour le travail de livraison sensible à la sécurité, cet environnement nécessite une isolation applicable.

Commencer par un modèle de menace

Listez les actifs qu'un agent pourrait affecter : dépôts source, exécuteurs CI, registres de packages, clés de signature, plans de contrôle cloud, données de préproduction, données de production, API internes et informations clients. Considérez ensuite les chemins vers ces actifs. L'agent peut suivre du texte non fiable provenant d'une issue, d'un README, d'une page web, d'un commentaire de code, d'une fixture de test, d'une réponse d'outil ou d'un message d'erreur généré.

Associez les contrôles à des risques réalistes :

• Injection de prompt et contenu de dépôt hostile : n'accordez pas aux outils l'autorité suggérée par le contenu qu'ils lisent.
• Divulgation d'informations sensibles : empêchez les secrets d'entrer dans le système de fichiers, le contexte, les journaux, les traces, les prompts et les pull requests.
• Autonomie excessive : exigez une approbation explicite pour les actions destructrices, les écritures externes, les changements de privilèges ou les déploiements.
• Compromission de la chaîne d'approvisionnement : limitez l'installation de packages, vérifiez la provenance lorsque disponible et isolez l'exécution des builds.
• Épuisement des ressources : plafonnez CPU, mémoire, disque, nombre de processus, durée de bout en bout, transfert réseau et tentatives modèle/outils.

Le Top 10 OWASP pour les LLM et l'IA générative est un catalogue de risques utile, mais appliquez-le à l'autorité réelle de votre agent plutôt que de traiter une liste de contrôle comme une preuve de sûreté.

Provisionner un espace de travail isolé par exécution

Créez un nouvel espace de travail, une nouvelle branche et une nouvelle identité d'exécution pour chaque tâche. Montez uniquement les chemins de dépôt nécessaires à la tâche, utilisez un utilisateur non root et une image de base en lecture seule lorsque c'est possible. Détruisez l'espace de travail à la fin de l'exécution après avoir conservé les artefacts approuvés tels que le diff, le rapport de test et les métadonnées de trace.

Évitez les répertoires personnels partagés, les caches d'outils partagés contenant des identifiants et les volumes de longue durée entre locataires ou frontières de confiance. L'état partagé peut divulguer des données et faire réussir une évaluation pour la mauvaise raison. Un cache peut être acceptable lorsqu'il est vérifié pour son intégrité, ne contient aucun secret et ne peut pas être modifié par une exécution non fiable.

L'isolation du sandbox doit couvrir plus qu'une frontière de conteneur. Définissez des listes d'autorisation du système de fichiers, des limites de processus et de ressources, ainsi qu'une politique réseau de refus par défaut. N'autorisez que le registre de packages, le point de terminaison du contrôle de source, le service de test ou le magasin d'artefacts requis par la tâche, avec des noms d'hôte et chemins explicites là où votre plateforme le permet.

Utiliser des identifiants éphémères à périmètre étroit

N'injectez jamais de jeton d'accès personnel étendu et durable ni de clé cloud dans l'environnement d'un agent. Émettez une identité de charge de travail de courte durée juste avant l'action qui l'exige. Liez-la à la tâche, au dépôt, à la branche ou pull request, à l'audience, à l'opération et à l'expiration. Révoquez-la ou laissez-la expirer à la fin de l'exécution.

Les périmètres appropriés comprennent notamment l'accès en lecture seule à un seul dépôt, l'autorisation de téléverser un artefact de test ou celle d'ouvrir une pull request depuis une branche désignée. Les identifiants pour les données de production, l'administration de toute l'organisation, la signature ou la publication de packages sans restriction ne doivent pas être accessibles à un agent de code généraliste.

Utilisez un courtier d'identité ou une identité de charge de travail émise par la CI plutôt que de stocker un jeton dans un gestionnaire de secrets et de le copier dans chaque sandbox. Journalisez l'émission et l'utilisation sans enregistrer la valeur de l'identifiant. Si une tâche exige un accès élevé, imposez une étape d'approbation distincte, montrez le périmètre et la durée précis, et consignez l'identité qui approuve.

Séparer l'autorité de lecture, écriture, exécution et réseau

Ne regroupez pas toutes les capacités dans un shell avec des identifiants étendus. Modélisez les outils comme des permissions distinctes :

• Accès en lecture au dépôt pour l'investigation.
• Accès en écriture à l'espace de travail limité à une branche de tâche.
• Exécution de commandes avec limites de CPU, mémoire, processus, durée et système de fichiers.
• Accès réseau aux packages ou au contrôle de source limité par la politique de sortie.
• Effets externes, tels que publier dans un outil de suivi des issues ou créer une release, derrière une frontière d'approbation.

Validez les paramètres des outils côté serveur. Une liste d'autorisation de chemins, une règle de branche, un modèle de commande ou une API typée protège plus sûrement que de demander à un modèle de se souvenir d'une politique. Traitez les commandes shell et les URL contrôlées par le modèle comme des entrées non fiables du plan de contrôle.

Gérer les dépendances et données de test en sécurité

L'installation de packages et l'exécution de tests sont de l'exécution de code. Verrouillez les dépendances, utilisez des miroirs internes ou une vérification de provenance lorsque cela se justifie, et exécutez les scripts d'installation dans le même environnement contraint. Ne rendez pas les identifiants de services de production disponibles uniquement parce qu'un test d'intégration est pratique.

Préférez des données de test synthétiques ou désidentifiées. Lorsqu'un accès de préproduction contrôlé est inévitable, utilisez un locataire dédié, un jeu de données réduit, des limites de débit et une identité de courte durée. Empêchez les sorties de test d'envoyer des enregistrements, jetons d'accès ou données personnelles dans les transcriptions d'agents et la télémétrie. La suppression est un filet de sécurité, pas une raison de surexposer les données.

Conserver des preuves d'audit sans retenir les secrets

Consignez l'identifiant de tâche, la version de l'environnement, le commit de base, le digest d'image, les décisions de politique, les requêtes d'outils, les périmètres approuvés, les commandes, les codes de sortie, les chemins modifiés et les résultats de validation. Corrélez ces enregistrements avec les preuves de CI et de pull request. Définissez une rétention et des contrôles d'accès adaptés à la sensibilité du code et des métadonnées opérationnelles.

Capturez les prompts du modèle, le code source, la sortie des commandes et les paramètres des outils uniquement dans le cadre d'une politique de confidentialité documentée. Préférez les hachages, identifiants, classifications et extraits bornés lorsque la capture complète exposerait des données clients ou des secrets. Testez la suppression avec des valeurs canari délibérées et incluez le stockage des traces dans la planification de réponse aux incidents.

Répondre aux échecs de politique en sécurité

Une demande de sortie réseau refusée, un identifiant expiré, un chemin bloqué ou un dépassement de budget est un résultat attendu, non un signal pour contourner le contrôle. Renvoyez une raison concise et la voie d'escalade approuvée. Arrêtez l'exécution si elle ne peut pas se poursuivre en sécurité et conservez assez de preuves pour qu'un opérateur décide si la tâche, la politique ou la configuration du dépôt doit évoluer.

Faites tourner tout identifiant soupçonné d'exposition, invalidez l'image ou le cache de sandbox affecté, enquêtez sur la trace et évaluez les actions en aval. Répétez ce flux avant d'accorder aux agents l'accès à des dépôts précieux ou des systèmes de préproduction.

Liste de contrôle du sandbox

• Créez des espaces de travail, branches et identités isolés à chaque exécution.
• Refusez par défaut l'accès au système de fichiers, la sortie réseau et les effets externes.
• Utilisez des identifiants de courte durée, liés à la tâche, avec audiences et opérations étroitement définies.
• Gardez les secrets de production, l'autorité de signature et l'administration cloud étendue hors des environnements d'agents généralistes.
• Limitez ressources et tentatives pour contenir la consommation malveillante comme accidentelle.
• Traitez dépendances, fixtures et scripts de test comme des entrées d'exécution non fiables.
• Auditez les décisions de politique et les résultats tout en minimisant la capture de traces sensibles.

Références faisant autorité

• OpenAI: Harness engineering: leveraging Codex in an agent-first world, February 11, 2026
• Anthropic: Building Effective AI Agents
• OWASP Top 10 for LLM and GenAI
• OWASP Secrets Management Cheat Sheet
• NIST SP 800-207: Zero Trust Architecture