Risques d'exfiltration DNS dans les sandbox d'agents IA

Le risque d’exfiltration DNS est important lorsque du code en sandbox peut résoudre des domaines contrôlés par un attaquant ou utiliser le DNS comme canal de données sortant. Les équipes doivent donc évaluer la politique DNS, la journalisation, les chemins de récupération des paquets et les preuves d’incident avant de faire confiance à un sandbox d’agent IA pour des workflows sensibles.

Pourquoi le DNS est important dans les modèles de menace des sandbox

Les sandbox d’agents IA sont conçues pour une autonomie utile. Un agent de codage peut exécuter des tests, installer des paquets, appeler des API, lancer un navigateur, inspecter des fichiers et produire des artefacts sans qu’un humain approuve chaque commande. Cette flexibilité est précisément la raison pour laquelle le comportement réseau nécessite sa propre évaluation, distincte de l’isolation du processeur, de la mémoire, du système de fichiers et des processus.

Le DNS reçoit souvent moins d’attention que la sortie HTTP car il ressemble à une infrastructure de plomberie. Les applications ont besoin de résolution de noms pour atteindre les API, les registres, les pages web et les points de terminaison de mise à jour. Mais le DNS reste une communication sortante. Un sandbox capable de résoudre des domaines arbitraires peut révéler des informations via les noms de requête, contacter une infrastructure contrôlée par un attaquant, ou créer un angle mort si le trafic DNS n’est pas journalisé avec le même soin que les requêtes web.

Ce n’est pas une catégorie théorique inventée pour les agents IA. MITRE ATT&CK documente le DNS comme un protocole de couche application que les adversaires peuvent utiliser pour la communication de commande et contrôle, et il documente séparément l’exfiltration via des protocoles alternatifs lorsque les données sortent par un canal qui n’est pas le protocole applicatif principal. Pour les évaluateurs de sandbox, la leçon est simple : ne traitez pas le DNS comme inoffensif simplement parce que ce n’est pas un POST HTTP.

Pour les agents IA, le risque vient généralement d’une chaîne de petites autorisations plutôt que d’une seule erreur évidente :

Capacité du sandbox	Pourquoi les équipes l’autorisent	Question liée au DNS
Installation de paquets	Laisser les agents installer les dépendances manquantes	Quels registres et chemins de résolution sont autorisés ?
Accès web	Laisser les agents navigateurs recueillir du contexte public	Le code peut-il résoudre n’importe quel domaine ou seulement des domaines approuvés ?
Appels API	Laisser les agents s’intégrer aux backends applicatifs	Les domaines internes et les points de terminaison de métadonnées sont-ils bloqués ?
Outils de build	Laisser les agents de codage exécuter des tests réalistes	Les scripts post-installation peuvent-ils déclencher des résolutions inattendues ?
Sessions longues	Laisser les agents poursuivre des tâches en plusieurs étapes	Les journaux DNS sont-ils conservés sur l’ensemble du cycle de vie de la session ?

L’objectif n’est pas d’interdire tout appel réseau. De nombreux workloads d’agents ont besoin d’un accès réseau contrôlé. L’objectif est de savoir quels chemins existent, quels chemins sont bloqués et quelles preuves vous auriez si une tâche se comportait de manière inattendue.

Où la résolution DNS apparaît dans les workflows d’agents

Les revues de sécurité demandent souvent si un sandbox a accès à Internet. Cette question est trop large. Une meilleure revue commence par cartographier chaque endroit où le code, les outils, les gestionnaires de paquets ou les navigateurs peuvent déclencher une résolution de noms.

Les chemins DNS courants incluent :

• Requêtes directes de code depuis Python, JavaScript, scripts shell, SDK et suites de test.
• Automatisation de navigateur qui charge des pages, des sous-ressources, des polices, des images, des scripts d’analyse et des redirections.
• Gestionnaires de paquets tels que npm, pip, uv, pnpm, apt, cargo ou les installateurs de plugins spécifiques à un langage.
• Outils de build qui récupèrent des binaires, des templates, des pilotes de navigateur, des fichiers de modèle ou des fixtures de test.
• Outils d’agent qui appellent des API tierces ou des points de terminaison de webhook.
• Tâches en arrière-plan qui continuent de s’exécuter après le retour de l’étape visible de l’agent.

Cette cartographie doit inclure à la fois le trafic intentionnel et le trafic incident. Un développeur peut seulement demander à un agent d’exécuter un test unitaire, mais la commande de test peut installer un paquet, le gestionnaire de paquets peut résoudre un domaine de registre, et un script de cycle de vie peut contacter un hôte séparé. Une tâche de navigateur peut être limitée à un site public, tandis que les ressources intégrées résolvent de nombreux domaines supplémentaires.

Pour un fournisseur de sandbox, la réponse la plus forte n’est pas simplement « l’accès réseau est disponible » ou « l’accès réseau est isolé ». La réponse utile explique le chemin de résolution :

• Le DNS du sandbox utilise-t-il un résolveur contrôlé par le fournisseur, un résolveur contrôlé par le client, un résolveur VPC ou un résolveur public ?
• Le client peut-il restreindre les domaines, les plages IP, les ports ou les protocoles ?
• Les requêtes DNS sont-elles journalisées par sandbox, par session, par commande, ou seulement au niveau réseau agrégé ?
• Les résolutions refusées sont-elles journalisées, ou seulement les résolutions autorisées ?
• Les clients peuvent-ils séparer le DNS de récupération de paquets du DNS d’exécution ?

Si ces détails ne sont pas disponibles, traitez-les comme des éléments d’évaluation ouverts, pas comme une preuve que le sandbox est dangereux. Le risque pratique dépend de la sensibilité du workload, des secrets disponibles dans le sandbox, de la politique de sortie et de la qualité des preuves médico-légales.

Comment évaluer la politique de sortie

La politique de sortie est la surface de contrôle qui décide si le DNS devient une plomberie de routine ou un chemin d’évasion non examiné. Une politique mature doit répondre à trois questions : ce qui est autorisé, pourquoi c’est autorisé, et comment les exceptions sont approuvées.

Commencez par la posture par défaut. Un sandbox utilisé pour du code non fiable généré par l’IA ne devrait pas hériter du même accès réseau large qu’un ordinateur portable de développeur. Si la valeur par défaut est une sortie ouverte, demandez si le produit permet de restreindre cet accès pour les workloads à plus haut risque. Si la valeur par défaut est une sortie restreinte, demandez comment les développeurs activent les domaines exacts nécessaires à une tâche.

Séparez ensuite la politique DNS de la politique HTTP. Certains systèmes appliquent des listes d’autorisation HTTP mais laissent la résolution de noms large. Cela peut créer un décalage : une requête vers un hôte non approuvé peut échouer au niveau HTTP, mais la requête DNS quitte toujours l’environnement et peut toujours transporter des métadonnées dans le nom interrogé. Une conception plus stricte évalue les tentatives de résolution et de connexion ensemble.

Pour les revues de sécurité, utilisez une matrice de politique comme celle-ci :

Domaine d’évaluation	Que demander	Preuve plus solide
Sortie par défaut	L’accès réseau sortant est-il ouvert, refusé ou limité par template ?	Politique par défaut écrite plus résultat de test au niveau du sandbox
Chemin du résolveur DNS	Quel résolveur gère le DNS du sandbox ?	Schéma d’architecture ou preuve de configuration
Listes d’autorisation de domaines	Les équipes peuvent-elles autoriser uniquement les registres et API approuvés ?	Exemple de configuration et exemple de journal de refus
Blocage IP et réseaux privés	Les plages internes et les services de métadonnées sont-ils bloqués par défaut ?	Règles de refus documentées et preuves de test
Contrôles de protocole	Le DNS, HTTP, HTTPS et les sockets bruts sont-ils contrôlés séparément ?	Modèle de politique, pas seulement un wording marketing
Workflow d’exception	Qui peut ajouter des domaines ou assouplir la politique ?	Approbation basée sur les rôles et enregistrement d’audit

Pour la plupart des équipes, le premier objectif pratique n’est pas un environnement parfait à sortie zéro. C’est un profil de sortie minimale documenté : registres de paquets approuvés, domaines API approuvés, pas d’accès aux réseaux internes sauf routage explicite, et journaux pour les tentatives autorisées et refusées.

Récupérations de paquets et DNS piloté par les dépendances

L’installation de paquets est l’un des moyens les plus faciles de sous-estimer la sortie du sandbox. Le code généré par l’agent échoue souvent sur des dépendances manquantes, et l’expérience développeur la plus rapide est de laisser l’agent installer ce dont il a besoin. Cette commodité crée un second problème de chaîne d’approvisionnement : les noms de paquets, les redirections de registre, les scripts d’installation et les téléchargements de binaires peuvent déclencher une activité DNS et réseau dont l’invite originale n’a jamais fait mention.

Les recommandations de l’OWASP pour les applications LLM signalent les risques liés à l’agence excessive et à l’exposition de la chaîne d’approvisionnement. Dans les sandbox d’agents, ces risques se rencontrent lors de l’installation de paquets. Un modèle peut être autorisé à choisir des commandes. Une commande peut invoquer un gestionnaire de paquets. Le gestionnaire de paquets peut récupérer du code depuis un registre. Le paquet récupéré peut exécuter des hooks d’installation. Chaque étape peut créer des résolutions DNS et des connexions sortantes.

L’évaluation défensive doit se concentrer sur la gouvernance, pas sur les mécanismes d’exploitation :

• Préférez les fichiers de dépendances épinglés pour les tâches d’agent reproductibles.
• Utilisez des registres approuvés ou des caches de type pull-through pour les écosystèmes courants.
• Journalisez le nom du paquet, la version, l’URL du registre, les domaines résolus et les hachages des artefacts lorsque c’est pratique.
• Séparez l’autorisation d’installation de paquets de l’accès internet général d’exécution.
• Exigez une approbation avant d’installer des paquets en dehors d’une liste d’autorisation pour les espaces de travail sensibles.
• Envisagez des templates de sandbox préconstruits pour les piles courantes afin que les agents n’aient pas besoin d’un accès réseau large à chaque exécution.

La distinction importante est que « récupération de paquet » n’est pas un seul contrôle. Cela inclut la résolution DNS, l’authentification au registre, le téléchargement d’artefact, l’exécution de code au moment de l’installation et le comportement du cache. Une bonne revue de sandbox interroge l’ensemble du chemin.

Secrets et hypothèses d’exposition de données

L’exfiltration DNS n’a d’importance que s’il y a quelque chose de significatif à fuir. Cela fait du placement des secrets et du périmètre des données une partie de la revue DNS.

Les sandbox d’agents IA doivent être traitées comme des workers de build non fiables, sauf preuve du contraire. Ne placez pas d’identifiants de production à longue durée de vie, de tokens cloud larges, de données clients ou de code source interne dans un sandbox simplement parce que le sandbox est isolé de l’hôte. L’isolation réduit le rayon d’explosion, mais elle ne rend pas chaque commande sûre.

Utilisez ces hypothèses lors de la conception de workflows à plus haut risque :

• Tout fichier lisible par le code exécuté par l’agent pourrait être inclus dans les journaux, les sorties, les requêtes réseau ou les messages d’erreur.
• Toute variable d’environnement visible par un processus pourrait être copiée par ce processus.
• Tout canal sortant autorisé pour le sandbox mérite la même revue de perte de données, y compris le DNS.
• Toute instruction injectée par invite dans un workflow de navigateur ou de document peut tenter d’influencer l’utilisation des outils.
• Toute session longue augmente la valeur des journaux de cycle de vie et de l’expiration des tokens.

Les contrôles pratiques incluent des identifiants à courte durée de vie, des clés API avec privilèges minimaux, des comptes de service limités, des secrets par tâche, des journaux expurgés et une séparation explicite entre les tâches de recherche sur données publiques et les tâches d’exécution de code sensible.

Journaux, pistes d’audit et preuves d’incident

Les contrôles DNS ne sont utiles que si les équipes peuvent les vérifier. Lorsqu’une tâche sandbox est suspecte, les équipes de sécurité ont besoin de preuves rapidement : ce qui a été exécuté, ce qui a été résolu, ce qui s’est connecté, quels fichiers ont changé et quelles sorties ont été retournées.

Au minimum, demandez si la plateforme peut reconstruire ces événements pour une session sandbox spécifique :

• Heure de création du sandbox, template, configuration des ressources et propriétaire.
• Commandes exécutées par l’agent ou l’utilisateur.
• Fichiers lus, écrits, téléchargés ou importés lorsque le produit expose les opérations sur les fichiers.
• Installations de paquets et récupérations de registre.
• Requêtes DNS, incluant l’horodatage, le nom interrogé, le résultat et l’identifiant du sandbox/session.
• Tentatives de connexion sortante, incluant l’hôte de destination, l’IP, le port, le protocole, le résultat autorisé/refusé et le volume lorsque disponible.
• Appels d’outils, événements de navigation du navigateur et processus en arrière-plan.
• Événements d’injection de secrets sans exposer les valeurs des secrets dans les journaux.
• Événements de fin de session, pause, reprise, snapshot et nettoyage.

Ne demandez pas seulement les journaux de trafic réussi. Les événements refusés sont souvent plus utiles pour évaluer si la politique a fonctionné. Si un sandbox tente de résoudre un domaine non approuvé et que la politique le bloque, cette résolution refusée est la preuve qui sépare un contrôle fonctionnel d’un échec silencieux.

La rétention compte aussi. Une fenêtre de journalisation de sept jours peut suffire pour le débogage mais être faible pour la réponse à incident. Les équipes ayant des workloads réglementés ou sensibles aux clients doivent aligner la rétention de télémétrie du sandbox sur leur politique de journalisation de sécurité plus large.

Notes d’évaluation du Novita Agent Sandbox

Novita Agent Sandbox est conçu pour les workflows d’agents IA qui ont besoin d’exécution de code isolée, d’automatisation de navigateur, de tâches de type computer-use, de sessions longues et de workloads d’évaluation ou d’apprentissage par renforcement. La présentation de Novita Agent Sandbox est le bon point de départ pour le comportement actuel du produit, et la page produit Agent Sandbox décrit l’adéquation plus large à la plateforme.

Lors de l’évaluation de Novita ou de tout autre fournisseur de sandbox pour des workloads sensibles au DNS, séparez deux types d’affirmations :

• Adéquation produit : si le sandbox supporte le workflow d’agent dont vous avez besoin, comme l’exécution de code, l’automatisation de navigateur ou les tâches longues.
• Preuve de contrôle de sécurité : si les contrôles exacts de DNS, de sortie, de récupération de paquets, de secrets et de journaux répondent à votre politique interne.

Cette séparation évite les sur-affirmations. Un sandbox peut être parfaitement adapté à l’exécution d’agents et nécessiter néanmoins une revue client spécifique pour la politique DNS, le chemin du résolveur, les listes d’autorisation, la rétention d’audit et les workflows d’incident. Les équipes de sécurité doivent demander la documentation actuelle ou une confirmation produit pour ces détails de contrôle avant d’approuver des workloads sensibles.

Pour les équipes utilisant déjà les modèles Novita AI, l’adéquation plateforme est que les API de modèle et l’infrastructure d’exécution des agents peuvent être évaluées ensemble. Cela peut réduire la dispersion opérationnelle, mais cela ne supprime pas le besoin d’un modèle de menace. Traitez le sandbox comme un environnement d’exécution contrôlé, définissez l’accès réseau dont chaque classe d’agent a besoin, et validez que les preuves de contrôle correspondent au risque des données placées à l’intérieur.

Liste de vérification pour la revue de sécurité

Utilisez cette liste de vérification avant d’approuver des workloads de sandbox d’agents IA qui peuvent toucher du code sensible, des identifiants, des données clients ou des systèmes internes.

Question de revue	Pourquoi c’est important
Que peut résoudre le sandbox par défaut ?	Le DNS peut être un signal sortant même lorsque HTTP est bloqué.
Le DNS peut-il être restreint par domaine, template, espace de travail ou politique VPC ?	Les workflows sensibles ont besoin de valeurs par défaut plus restrictives que les tâches de recherche publique.
Les requêtes DNS sont-elles journalisées par session sandbox ?	La réponse à incident a besoin d’attribution, pas seulement de métriques de résolveur agrégées.
Les tentatives DNS et de connexion refusées sont-elles journalisées ?	Les événements refusés prouvent que la politique a bloqué un comportement inattendu.
Les registres de paquets sont-ils sur liste d’autorisation ou proxyfiés ?	Les gestionnaires de paquets peuvent déclencher du DNS et des téléchargements pilotés par les dépendances.
Les installations de paquets peuvent-elles être séparées de l’accès réseau d’exécution ?	Les risques au moment du build et au moment de l’exécution sont différents.
Les plages IP internes et les points de terminaison de métadonnées sont-ils bloqués ?	Les agents ne doivent pas découvrir ou contacter les plans de contrôle d’infrastructure par accident.
Comment les secrets sont-ils injectés, limités, renouvelés et expurgés ?	La revue DNS est incomplète si des secrets à longue durée de vie sont disponibles pour le code en sandbox.
Les sous-ressources du navigateur sont-elles visibles dans les journaux ?	Les agents navigateurs peuvent résoudre plus de domaines que l’URL de niveau supérieur.
Quelles preuves sont disponibles après une pause, une reprise, un snapshot ou un nettoyage ?	Les sessions longues ont besoin de télémétrie consciente du cycle de vie.
Qui peut assouplir la politique de sortie ?	Les changements d’exception doivent être audités.
Comment les sessions suspectes sont-elles préservées ?	Le nettoyage ne doit pas effacer les seules preuves d’incident utiles.

Si plusieurs réponses sont inconnues, gardez le workload hors du sandbox jusqu’à ce que le fournisseur ou l’équipe plateforme interne puisse documenter le chemin de contrôle. Si le workload ne traite que des données publiques et n’utilise aucun secret, les mêmes lacunes peuvent être acceptables lors du prototypage précoce, mais elles doivent toujours être suivies avant une utilisation en production.

Conclusion

Pour les sandbox d’agents en production, examinez le DNS dans le cadre de la sortie, pas comme une note de bas de page. La configuration minimale défendable est une politique de sortie limitée, une gouvernance explicite de la récupération de paquets, des secrets à courte durée de vie, des journaux DNS et de connexion par session, et un workflow d’incident testé pour préserver les preuves.

Utilisez un accès réseau plus large pour les prototypes à faible risque uniquement lorsque les données sont non sensibles et que l’agent n’a aucun secret significatif. Pour les bases de code sensibles, les données clients, les API internes ou les workflows réglementés, exigez un profil de sortie minimale et des preuves actuelles du fournisseur avant d’accorder une exécution autonome aux agents.

FAQ

L’exfiltration DNS est-elle pertinente si le sandbox bloque HTTP ?

Oui. Les contrôles HTTP et DNS sont des couches différentes. Un sandbox peut bloquer les requêtes web sortantes tout en autorisant les requêtes DNS. Les équipes de sécurité doivent vérifier à la fois la politique de résolution et la politique de connexion.

Les sandbox d’agents IA ne devraient-elles avoir aucun accès Internet ?

Pas toujours. De nombreuses tâches d’agent utiles ont besoin de registres de paquets, de documentation publique, d’API ou d’accès navigateur. L’objectif plus sûr est une sortie minimale et explicable : autoriser ce dont la tâche a besoin, refuser ce dont elle n’a pas besoin, et journaliser l’activité autorisée et refusée.

Les installations de paquets sont-elles identiques à l’accès réseau général ?

Non. Les installations de paquets méritent une politique séparée car elles impliquent des registres, la résolution de dépendances, des téléchargements d’artefacts et parfois des scripts au moment de l’installation. Une équipe peut autoriser les récupérations de paquets via un cache approuvé tout en refusant toute sortie d’exécution arbitraire.

Quels journaux sont les plus importants pour le risque DNS ?

Les journaux les plus utiles relient une requête DNS à un sandbox, une commande, une heure, un utilisateur ou workflow d’agent, et une décision de politique spécifiques. Les journaux de résolution refusée sont particulièrement importants car ils montrent si le contrôle a réellement fonctionné.

Un fournisseur de sandbox peut-il garantir l’absence d’exfiltration de données ?

Soyez prudent avec les garanties absolues. Un fournisseur peut offrir l’isolation, les contrôles réseau, la journalisation et les options de configuration, mais le risque final dépend de la conception du workload, des secrets, du placement des données, de la politique de sortie et de la surveillance opérationnelle.

Articles recommandés

• Comment les sandbox d’agents propulsent une innovation IA sécurisée et évolutive
• Construire un agent de codage avec Novita Agent Sandbox
• Construire un serveur MCP d’exécution de code à distance avec Novita Sandbox et la bibliothèque mcp-use