Guide de sécurité

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

Limitez ce qu'un agent de code peut atteindre et modifier, puis rendez chaque action privilégiée attribuable, de courte durée et vérifiable.

Publié le: 14 juil. 2026
Mis à jour le: 15 juil. 2026
Temps de lecture: 14 min de lecture

Sur cette page

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 d'une dépendance ou d'une action dangereuse de l'agent. Ce guide couvre 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 même discipline qui rend un orchestrateur d'edge managé digne de confiance à grande échelle — une politique appliquée de façon cohérente à travers les fournisseurs, chaque décision observable plutôt que supposée — s'applique aux sandboxes pour agents de code : l'autorité doit être délimitée, appliquée et prouvée à la frontière, pas simplement demandée poliment dans un prompt.

Modéliser l'autorité, pas seulement le prompt

Dressez la liste des 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é.

Prenons un scénario représentatif chez Acme Shop, un e-commerçant fictif : la tâche ACME-1842 demande à un agent de corriger une validation manquante du champ pays dans services/checkout-api. Le dépôt contient un commentaire suggérant d'interroger un service fiscal de production pour vérifier le correctif — une entrée non fiable, au même titre que le reste du contenu du dépôt. La tâche n'a besoin que d'un double de test synthétique pour le fournisseur fiscal, pas de données de production ni d'identifiants cloud étendus.

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 le traiter comme une preuve de sûreté en soi.

Adapter l'isolation d'exécution d'agent au niveau de risque

L'isolation d'exécution d'agent n'est pas un réglage unique : les sandboxes pour agents de code doivent faire correspondre le mécanisme d'isolation à ce que la tâche exécute réellement.

Conteneurs à espaces de noms : les moins coûteux et les plus rapides ; adaptés aux tâches de lecture, d'écriture et de lint qui n'exécutent aucun code du dépôt.
Interception du noyau en espace utilisateur : réimplémente les appels système en espace utilisateur, ce qui réduit ce qu'un processus compromis peut atteindre ; convient aux suites de tests exécutées contre un jeu de dépendances figé.
MicroVM par exécution : chaque exécution reçoit son propre noyau jetable, si bien qu'une faille d'évasion de conteneur ne peut atteindre ni l'hôte ni une exécution voisine. Réservez ce niveau aux scripts de build ou de test et au code de package non revu — c'est le cas d'ACME-1842, puisque l'installation des dépendances et les tests exécutent tous deux du code que la politique n'a pas écrit ; la lecture initiale du dépôt et la génération du diff peuvent en revanche rester dans un conteneur à espaces de noms plus léger.

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.

Pour ACME-1842, l'espace de travail checkout-api ne monte en lecture-écriture que services/checkout-api/**, avec package.json et le fichier de verrouillage en lecture seule ; tout le reste, y compris services/payments-api et les répertoires d'infrastructure, reste hors de portée quelle que soit l'instruction contenue dans le dépôt ou le prompt.

É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.

Émettre des identifiants éphémères pour agents via un courtier

N'injectez jamais de jeton d'accès personnel étendu et durable ni de clé cloud dans l'environnement d'un agent. Les identifiants éphémères pour agents suivent le même principe que la politique de sandbox par tâche décrite plus haut : un courtier d'identité échange l'identité de charge de travail de courte durée de l'exécution — attestée à partir du digest de l'image et des métadonnées de la tâche, jamais intégrée en dur dans l'image — contre un identifiant limité à exactement l'opération autorisée, lié à la tâche, au dépôt, à la branche ou pull request, à l'audience et à l'opération, émis juste avant qu'il ne soit nécessaire et révoqué ou expiré dès la fin de l'exécution.

Le périmètre et l'expiration limitent ce qu'un identifiant volé peut faire, mais pas ce qu'un agent peut être manipulé pour faire avec un identifiant valide : un contenu qui ne peut pas atteindre directement le service fiscal en production peut inciter l'agent à coller l'identifiant dans un message de commit, un canal autorisé transportant une charge que la politique n'a jamais inspectée. Défendez-vous au niveau de la couche d'application — identifiants bruts hors du contexte du modèle, filtrage des formes de jetons avant toute sortie réseau, et liaison de l'identifiant à l'exécution pour qu'une valeur capturée ne puisse pas être rejouée ailleurs.

La dérive de périmètre reste invisible tant que personne ne l'agrège

Le journal de refus d'un seul sandbox paraît anodin isolément. C'est en agrégeant les événements d'audit de tous les sandboxes et courtiers d'identité que ressortent les schémas qui comptent : une identité limitée à l'ouverture de pull requests qui écrit des chaînes ressemblant à des jetons dans des messages de commit, ou le même hôte autorisé en silence par trois plateformes d'agents différentes. C'est la visibilité multi-fournisseurs que la couche MYO d'Optimi est conçue pour révéler ; elle ne remplace aucune décision de périmètre prise par un courtier, elle les rend observables à travers tous les fournisseurs orchestrés.

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 — exactement le périmètre accordé à l'identité d'ACME-1842. 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.

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 les consignes des contrôles appliqués

« Ne lisez pas les secrets », « n'appelez pas la production » et « ne fusionnez pas » sont des consignes de prompt. Elles peuvent aider un agent à choisir une voie sûre ; elles ne peuvent bloquer ni un appel système, ni un paquet réseau, ni un échange de jeton, ni une mise à jour de branche.

Les contrôles appliqués sont les montages et listes d'autorisation du système de fichiers, l'exécution non-root, les limites de ressources, la sortie réseau en refus par défaut, les vérifications d'audience et de périmètre de l'identité, la validation côté serveur des outils, la protection de branche et les frontières d'approbation : ils n'éliminent pas tous les risques ni toutes les erreurs de configuration, mais ils réduisent l'autorité disponible et rendent les refus observables.

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.

L'installation de dépendances est elle-même un contrôle appliqué, pas une simple consigne pour l'agent : un script de cycle de vie peut exécuter du code dès qu'un manifeste est installé. Désactivez par défaut les scripts exécutés à l'installation et résolvez les packages à partir d'un fichier de verrouillage figé par hachage plutôt que d'une plage de versions. Pour ACME-1842, cela signifie que l'installation des dépendances s'exécute dans la microVM dédiée décrite plus haut, avec les scripts de cycle de vie désactivés sauf revue explicite d'un package donné.

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

L'installation de packages et l'exécution de tests restent de l'exécution de code : 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 que le reste de la tâche. Ne rendez pas les identifiants de services de production disponibles uniquement parce qu'un test d'intégration est pratique — c'est exactement le piège que tend à ACME-1842 le commentaire suggérant un appel au service fiscal en production.

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.

Un événement d'audit isolé prouve rarement un problème par lui-même ; un périmètre demandé en boucle, ou une fois contre un hôte inattendu, est un signal qui n'apparaît qu'en agrégat. Conservez des métadonnées structurées, jamais la valeur de l'identifiant, et signalez les exécutions qui s'écartent du profil attendu.

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 : l'agent doit recevoir un refus concis et actionnable plutôt qu'une voie de contournement. Pour ACME-1842, une tentative d'atteindre le service fiscal de production échoue car cet hôte n'est pas dans la liste d'autorisation de sortie réseau ; une tentative de demander une audience de production échoue car le courtier n'accepte que l'audience et le périmètre étroit de la tâche.

Ne répondez à aucun de ces refus en ajoutant une entrée large à la liste d'autorisation, en exportant un jeton personnel de longue durée ou en désactivant la politique. Conservez l'identifiant de tâche, la version de la politique, la classification de la requête et l'identifiant de trace : un opérateur pourra ainsi décider si la fixture est erronée, si la tâche a besoin d'un autre flux approuvé, ou si la requête était réellement dangereuse. Un refus qui révèle en fait un manque légitime suit le même processus de changement revu que toute autre modification de politique, jamais une autorisation accordée en direct pour débloquer une exécution bloquée.

Validez le comportement du sandbox dans quatre directions : positive (la tâche checkout-api n'écrit que dans son espace de travail, atteint le double de test fiscal, téléverse un artefact et ouvre une pull request avec son identité de courte durée), négative (une lecture de fichier de production, une modification de l'infrastructure ou un appel à l'hôte fiscal réel est refusé et classé sans journaliser de secret), d'échec (une identité expirée pendant un téléversement arrête l'exécution, conserve le diff et le rapport de test, signale l'expiration, et ne retente jamais avec une autre identité), et d'exfiltration (une fixture qui copie une chaîne canari ressemblant à un identifiant dans un message de commit doit être filtrée avant la sortie réseau, avec un événement distinct journalisé).

La récupération reste elle-même délimitée : renouvelez uniquement la même permission liée à la tâche via le courtier si la tâche reste valide, ou détruisez l'espace de travail et recommencez — y compris lorsqu'une identité expire en cours d'écriture, plutôt que de reprendre sur une sortie partielle. 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 avant d'accorder de nouveau 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.
Faites correspondre le mécanisme d'isolation d'exécution d'agent (conteneur à espaces de noms, interception noyau en espace utilisateur, microVM) au risque réel de la tâche.
Refusez par défaut l'accès au système de fichiers, la sortie réseau et les effets externes.
Émettez des identifiants éphémères pour agents via un courtier attesté, 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.
Désactivez par défaut les scripts d'installation de dépendances et résolvez les packages par hachage figé.
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, et surveillez les schémas visibles seulement en agrégat.

Références faisant autorité

Alignez isolation, identité et visibilité sur toute votre flotte d'agents

Parlez avec Optimi de l'extension d'un standard cohérent de sandboxes pour agents de code, d'identifiants éphémères et de visibilité MYO à travers vos pipelines CI et vos fournisseurs edge, dans le cadre de la Suite Optimi Performance, Sécurité et Visibilité.

Discuter de la sécurité des sandboxes d'agents