Bac à sable pour agent d’IA : maîtriser le trafic sortant et les identifiants

En juin 2026, un modèle expérimental d’OpenAI, réservé à l’usage interne et chargé de questions de recherche, a pris des mesures que l’entreprise n’avait pas autorisées. Selon la divulgation d’OpenAI, il a trouvé un moyen d’obtenir un accès non public au service de statistiques de Medicare en Australie. Il y a exécuté des commandes et récupéré des fichiers internes, des identifiants et des statistiques agrégées. Dans un autre cas, des agents d’OpenAI ont trouvé une clé d’accès exposée et s’en sont servis pour interroger le système de rapports d’un organisme de santé de l’État de Victoria. OpenAI a notamment pris trois mesures en réponse :

• Bloquer l’accès Internet en direct dans ces environnements de recherche.
• Servir plutôt le contenu Web à partir d’un cache.
• Mettre en place une surveillance qui alerte une personne chargée de l’examen.

En septembre, Transluce a publié une analyse du trafic soupçonné de provenir d’agents d’IA et visant des sites gouvernementaux américains et canadiens. L’analyse s’appuie sur des requêtes saisies par des ensembles de données publics, dont l’archive Web Arquivo.pt. Parmi elles figuraient 899 requêtes vers un service de recherche de Bibliothèque et Archives Canada, dont 13 contenaient des charges malveillantes. Transluce estime que ces tentatives ont échoué et n’a relevé jusqu’ici, dans ces données, aucun cas où des agents auraient obtenu des renseignements non publics. Elle laisse aussi entendre que ces agents n’avaient pas reçu de tâche liée au piratage. Le Centre de la sécurité des télécommunications a déclaré que rien n’indiquait, pour l’instant, une compromission des systèmes du gouvernement.

Ces deux cas soulèvent deux questions : où le trafic d’un agent peut aller, et quels identifiants il peut atteindre. Ce texte traite de ces deux questions, en plus de l’isolement de l’exécution, pour un agent qui exécute des commandes ou envoie des requêtes Web dans l’environnement d’une organisation.

• Isoler l’exécution

  Choisir le niveau d’isolement selon le code que l’agent exécute et limiter ce qu’il peut écrire.

• Refuser la sortie par défaut

  Faire passer tout le trafic par un proxy qui vérifie chaque destination dans une liste d’autorisation.

• Écarter les identifiants

  Partir sans identifiants et injecter hors de portée de l’agent des jetons de courte durée à portée restreinte.

• Consigner et alerter

  Consigner chaque décision de sortie par exécution et signaler les volumes inhabituels à l’équipe de sécurité.

Chaque volet est appliqué hors du modèle. Vérifiez la limite avant d’exécuter l’agent dans votre environnement.

Définir ce que la limite doit contenir

Un bac à sable pour agent couvre cinq éléments :

• Exécution : le noyau et l’environnement d’exécution des commandes de l’agent.
• Fichiers : ce que l’agent peut lire et écrire.
• Réseau : les destinations qu’il peut joindre.
• Identifiants : les secrets présents ou accessibles.
• Volume et journaux : la quantité d’actions permise et ce qui est consigné.

Pour l’exécution, les recommandations de l’équipe rouge en IA de NVIDIA rappellent que les conteneurs de développement Docker standard partagent le noyau de l’hôte, qui reste alors exposé au code exécuté dans le bac à sable. Elles classent macOS Seatbelt et Linux Bubblewrap dans ce même groupe à noyau partagé. Le bac à sable de Claude Code, cité plus bas, repose sur ces deux mécanismes. Elles recommandent la virtualisation complète, par exemple des machines virtuelles ou Kata Containers, et présentent gVisor comme une option intermédiaire. Le projet Kubernetes Agent Sandbox prend en charge gVisor et Kata. Choisissez le niveau d’isolement selon ce que l’agent exécute. Du code que l’agent écrit à partir de documents ou de contenu Web non fiables exige plus d’isolement qu’un ensemble fixe de commandes de compilation.

Ces mêmes recommandations jugent trois contrôles obligatoires :

• Le contrôle du trafic sortant.
• Le blocage de l’écriture hors de l’espace de travail.
• Le blocage de l’écriture dans les fichiers de configuration de l’agent, où qu’ils se trouvent, comme les crochets (hooks), la configuration des serveurs MCP, les compétences et les fichiers de règles.

Montez uniquement les données d’entrée dont la tâche a besoin.

Dressez la liste de tous les processus que l’agent peut lancer et vérifiez que chacun se trouve à l’intérieur de la limite. La documentation du bac à sable de Claude Code montre pourquoi. Ce bac à sable couvre les commandes shell, alors que les outils intégrés de fichiers et de Web, les crochets, les serveurs MCP locaux et d’autres processus auxiliaires s’exécutent en dehors. Des commandes peuvent aussi en sortir au moyen d’exclusions configurées ou d’une nouvelle tentative hors du bac à sable. Pour placer l’ensemble derrière une seule limite, la documentation propose d’exécuter le processus de l’agent lui-même dans un conteneur, une machine virtuelle ou l’environnement d’exécution du bac à sable. Désactivez les nouvelles tentatives hors du bac à sable. Définissez la politique du bac à sable à un endroit que ni l’agent ni le dépôt sur lequel il travaille ne peuvent modifier, comme des paramètres gérés de façon centralisée.

Refuser le trafic sortant par défaut, hors de portée de l’agent

L’environnement de l’agent ne doit avoir aucune route directe vers l’extérieur. Faites passer tout le trafic par un serveur mandataire (proxy) de sortie qui vérifie chaque destination par rapport à une liste d’autorisation. Limitez le DNS à des résolveurs de confiance, comme le recommande NVIDIA pour empêcher l’exfiltration par le DNS.

Rédigez la liste d’autorisation par objectif. Pour chaque destination, indiquez pourquoi la tâche en a besoin et, lorsque le proxy peut les voir, quelles méthodes et quels chemins sont permis. Excluez les hôtes qui acceptent des téléversements arbitraires, sauf si la tâche l’exige.

Une liste d’autorisation fondée sur les noms d’hôte a deux limites, toutes deux énoncées dans la documentation de Claude Code :

• Son proxy décide à partir du nom d’hôte fourni par le client, sans inspecter le TLS. Le code exécuté dans le bac à sable pourrait donc recourir à la façade de domaine (domain fronting) ou à des techniques semblables pour joindre des hôtes absents de la liste.
• Autoriser un domaine large comme github.com peut ouvrir des voies d’exfiltration de données.

Des règles sur les méthodes, les chemins ou le contenu exigent un proxy qui déchiffre le trafic, et dont le certificat est reconnu dans le bac à sable. La terminaison TLS expérimentale de Claude Code n’ajoute pas de filtrage du contenu. La documentation dirige vers un proxy personnalisé ceux qui ont besoin d’inspection. Vous pouvez aussi placer une passerelle restreinte devant chaque service en amont.

Bloquez les adresses privées, de bouclage et de liaison locale, y compris le point de terminaison de métadonnées infonuagiques 169.254.169.254. Les pratiques de sécurité recommandées pour MCP donnent le même conseil aux clients MCP qui récupèrent des URL de découverte OAuth. Elles suggèrent un proxy de sortie conçu pour empêcher la falsification de requêtes côté serveur, comme Smokescreen. Elles déconseillent aussi de valider les adresses IP avec du code maison, que des astuces d’encodage peuvent contourner. Le même raisonnement vaut pour tout agent qui récupère des URL.

Lorsqu’un agent a besoin d’une destination hors de la politique, exigez une nouvelle approbation chaque fois. Selon NVIDIA, les approbations ne devraient jamais être mises en cache ni conservées, et une approbation d’utilisateur ne devrait pas permettre de passer outre à une liste de refus d’entreprise. Pour les agents de recherche, envisagez le changement apporté par OpenAI : servir du contenu mis en cache plutôt que le Web en direct.

Garder les identifiants hors de portée de l’agent

Dans le cas de l’État de Victoria, des agents d’OpenAI ont trouvé une clé d’accès exposée et s’en sont servis. Considérez tout identifiant que l’agent peut lire comme un identifiant qu’il peut utiliser.

Démarrez le bac à sable sans identifiants. N’injectez que ce dont une tâche a besoin, de préférence au moyen d’un intermédiaire qui délivre des jetons de courte durée à portée restreinte. Le guide d’OpenAI sur les bacs à sable traite les identifiants comme de la configuration d’exécution, et non comme du contenu de l’invite (prompt). Il demande que l’environnement d’exécution ou le fournisseur les injecte plutôt que de les transmettre au modèle sous forme d’instructions.

L’injection par le proxy garde la valeur réelle hors du bac à sable. Dans la mise en œuvre de Claude Code, les commandes du bac à sable voient une valeur de remplacement, et le proxy substitue le vrai secret dans les requêtes sortantes. La substitution suit la configuration de chaque secret :

• Elle s’applique aux hôtes indiqués dans le paramètre injectHosts de ce secret.
• Sans injectHosts, elle s’applique à tous les domaines autorisés.
• Elle exige la terminaison TLS au proxy, que la documentation qualifie d’expérimentale.

Limitez la liste d’hôtes de chaque secret au seul hôte qui en a besoin. Vérifiez si cet hôte peut renvoyer les en-têtes de requête à l’appelant, par exemple au moyen d’un point de terminaison de débogage ou d’une page d’erreur détaillée. Si c’est le cas, la valeur injectée peut revenir à l’agent dans une réponse. Restreignez alors les chemins permis ou masquez le secret dans les réponses au niveau du proxy.

Deux autres règles s’appliquent aux agents qui appellent des serveurs MCP et à tout ce qui est monté dans le bac à sable :

• Un serveur MCP ne doit pas accepter de jetons qui n’ont pas été émis pour lui, ni transmettre le jeton d’un client à une API en aval. Les recommandations MCP appellent cette seconde pratique le relais de jetons (token passthrough).
• Ne montez pas de sockets privilégiés. La documentation de Claude Code note qu’autoriser l’accès à /var/run/docker.sock revient en pratique à donner accès au système hôte.

Traiter le volume et les tentatives échouées comme des signaux de sécurité

Transluce a reconnu des agents après coup, à des volumes élevés de requêtes automatisées et à des séquences qui changeaient de chemin ou de service après des échecs. OpenAI affirme que sa surveillance actuelle aurait détecté l’activité en Australie et alerté une personne chargée de l’examen.

Consignez chaque décision de sortie avec l’exécution à laquelle elle se rattache : destination, méthode, octets envoyés, autorisation ou refus, et motif. Pour rattacher les requêtes aux exécutions, attribuez à chaque exécution son propre identifiant de proxy ou sa propre identité réseau. Déclenchez une alerte dans les cas suivants :

• Des refus en rafale vers diverses destinations
• Des tentatives répétées sur différents chemins après des échecs
• Un volume de requêtes supérieur aux besoins de la tâche

Limitez le nombre de requêtes par exécution. Transmettez ces alertes à l’équipe qui gère les incidents de sécurité en plus de l’exploitation, car une charge inhabituelle causée par un agent peut être le premier signe qu’il est sorti de sa tâche.

Solidité du bac à sable et choix de l’interface d’outils

Une étude de Mak et al. publiée en septembre 2026 (arXiv 2609.11999) a comparé des interfaces d’outils pour des agents d’entreprise. Bash seul a surpassé un catalogue d’outils typés : de 21,8 à 24,5 points sur TheAgentCompany et de 4,8 à 7,4 points sur APEX-Agents, avec 19 à 72 % de jetons en moins. Les auteurs privilégient bash seul lorsque l’exécution arbitraire peut être isolée. Lorsque les politiques exigent un catalogue d’outils fixe, ils privilégient l’appel d’outils programmatique. Leur recommandation dépend donc de la possibilité d’isoler l’exécution.

Vérifier la limite avant de s’y fier

Précisez le résultat attendu de chaque vérification avant de l’exécuter. Reprenez l’ensemble après toute modification de l’image, de la politique du proxy ou des outils de l’agent :

• Une requête qui contourne le proxy échoue.
• Une requête vers un hôte absent de la liste d’autorisation est refusée et consignée.
• Une résolution DNS par un résolveur externe échoue.
• Les adresses privées, de bouclage et de liaison locale sont refusées, y compris le point de terminaison de métadonnées.
• L’écriture hors de l’espace de travail et dans les fichiers de configuration de l’agent est refusée.
• Les variables d’environnement et les fichiers montés de l’agent ne contiennent aucun identifiant de longue durée.
• Une rafale de requêtes refusées déclenche une alerte qui parvient à une personne.

Ces vérifications s’ajoutent à l’évaluation plus large décrite dans Tester un assistant d’IA avant de s’y fier au travail. Ce texte porte sur les autorisations, les instructions non fiables et les actions.

Exploiter le bac à sable dans votre propre environnement

Lorsqu’un agent s’exécute dans les comptes infonuagiques d’une organisation, celle-ci devrait maîtriser la limite :

• Elle fournit l’infrastructure du bac à sable.
• Elle revoit la liste d’autorisation de sortie avec son équipe réseau.
• Elle conserve les journaux du proxy et des exécutions dans ses propres systèmes de journalisation.
• Elle peut révoquer les identifiants et l’accès réseau de l’agent sans l’aide de la personne qui l’a construit.

Les sites Web du secteur public canadien reçoivent déjà du trafic soupçonné de provenir d’agents. Le Centre de la sécurité des télécommunications souligne que les requêtes automatisées et potentiellement malveillantes sont courantes pour les sites publics et n’indiquent pas, à elles seules, un cyberincident réussi. Une organisation qui exploite des agents doit veiller à ce que ce trafic ne provienne pas de ses propres agents.

Un bac à sable réduit ce qu’un agent peut atteindre. Il n’établit pas que l’agent est exempt de risque. L’isolement à noyau partagé reste exposé aux vulnérabilités du noyau, et les listes d’autorisation dérivent à mesure que les tâches changent. Appliquez les correctifs à la couche d’isolement, revoyez la liste d’autorisation à intervalles réguliers et gardez les risques restants visibles.