Liste de vérification des limites d'isolation du bac à sable pour agents IA — Révisions de sécurité

Une révision de l’isolation du bac à sable d’un agent IA doit vérifier la limite d’exécution, l’exposition du système de fichiers, les contrôles des processus et des ressources, la politique réseau et DNS, le comportement de récupération des paquets, la gestion des secrets, les journaux, la capture des artefacts, la sémantique de réinitialisation, les points d’approbation humaine et les hypothèses d’incident avant que le code généré ne soit autorisé à s’exécuter sur des systèmes ou des données réels.

Pourquoi les révisions d’isolation des agents IA sont importantes

Les révisions de bacs à sable traditionnels commencent souvent par une question : ce système peut-il exécuter du code non fiable sans exposer l’hôte ? Les révisions d’agents IA ont besoin de cette question, mais elles nécessitent également une liste de vérification plus large car les agents font plus que d’exécuter un seul script. Ils peuvent cloner des dépôts, installer des paquets, naviguer sur des sites, écrire des fichiers, appeler des API, ouvrir des sessions GUI, réessayer des commandes ayant échoué et transformer la sortie du modèle en actions shell.

Cela modifie le modèle de risque. Un agent de codage peut se comporter comme un ingénieur junior avec un accès terminal. Un agent d’analyse de données peut se comporter comme un utilisateur de notebook qui télécharge des fichiers, récupère des paquets et exporte des graphiques. Un agent navigateur peut se comporter comme un utilisateur avec des cookies, des téléchargements, des captures d’écran et des actions de remplissage de formulaires. Un agent d’apprentissage par renforcement ou d’évaluation peut exécuter la même tâche des milliers de fois, ce qui rend les petites lacunes de sortie, de ressources ou de journalisation importantes à grande échelle.

Utilisez la liste de vérification ci-dessous pour examiner la limite avant de connecter un bac à sable à des dépôts sensibles, des données clients, des API internes, des identifiants privilégiés ou des systèmes de déploiement de production.

Sécurité de la limite d’exécution

Commencez par la limite qui sépare la charge de travail de l’agent de l’hôte et des autres locataires. La révision doit être suffisamment explicite pour qu’un ingénieur en sécurité puisse décrire ce qui échoue si l’agent exécute du code hostile.

Vérifiez :

• Quelle couche d’isolation est utilisée : conteneur, microVM, VM complète, médiation d’appels système de type gVisor, sandboxing Kubernetes ou un autre modèle ?
• Chaque bac à sable obtient-il sa propre limite de noyau, ou partage-t-il le noyau de l’hôte ?
• Les ressources CPU, mémoire, système de fichiers, table des processus, pile réseau et accès aux périphériques sont-elles séparées des autres charges de travail ?
• Le bac à sable peut-il accéder aux sockets du runtime de conteneur, aux espaces de noms de processus de l’hôte, aux chemins de l’hôte, aux services de métadonnées cloud ou aux périphériques privilégiés ?
• Comment les sessions navigateur, les bureaux GUI, les flux VNC et les interpréteurs de code sont-ils placés à l’intérieur de la même limite ?
• Quelle est l’hypothèse documentée d’évasion de l’hôte : confinement, réduction des risques ou une garantie plus forte ?

Évitez d’accepter une déclaration générique de « bac à sable sécurisé » comme réponse complète. Demandez le mécanisme d’isolation concret, ce qui se trouve à l’intérieur de la limite, ce qui se trouve à l’extérieur et quelles hypothèses nécessitent encore des contrôles compensateurs.

Sécurité du système de fichiers et des montages

Les systèmes de fichiers des agents méritent une révision séparée car les agents créent, modifient et exfiltrent souvent des fichiers dans le cadre de leur travail normal. La partie risquée n’est pas seulement l’accès en lecture/écriture ; c’est le transfert accidentel entre les tâches et l’accès implicite aux fichiers de projet que l’utilisateur n’avait pas l’intention de partager.

Vérifiez :

• Le système de fichiers par défaut est-il vide, basé sur un modèle ou préchargé avec des fichiers de projet ?
• Quels chemins sont accessibles en écriture par l’agent, et lesquels sont en lecture seule ?
• Des répertoires hôtes, des montages de dépôt, des clés SSH, des caches de paquets, des profils de navigateur ou des fichiers de configuration cloud sont-ils montés dans le bac à sable ?
• L’agent peut-il traverser des liens symboliques ou des montages bind vers des chemins non intentionnels ?
• L’accès aux fichiers est-il limité par bac à sable, par utilisateur, par projet ou par organisation ?
• Les fichiers téléchargés sont-ils supprimés, conservés, instantanés ou rendus disponibles pour les sessions ultérieures ?
• Les fichiers et les diffs générés sont-ils consultables avant de quitter le bac à sable ?

Pour les agents de codage, le modèle le plus sûr est généralement un espace de travail de projet restreint, une exportation explicite des artefacts et aucun accès ambiant aux répertoires personnels du développeur ou aux magasins d’identifiants partagés.

Contrôles des processus et des ressources

Un agent peut créer accidentellement une bombe de processus, bloquer une construction, remplir un disque, exécuter un serveur en arrière-plan ou réessayer continuellement une commande coûteuse. Les contrôles de ressources transforment ces échecs en échecs limités.

Vérifiez :

• Des limites de CPU, mémoire, disque, descripteurs de fichiers, nombre de processus et de temps d’exécution sont-elles appliquées ?
• Existe-t-il une durée maximale (temps réel) pour les commandes et les sessions ?
• Des processus en arrière-plan peuvent-ils survivre après la fin d’une commande ?
• Les processus fils sont-ils tués lorsque le bac à sable est arrêté ou réinitialisé ?
• L’agent peut-il ouvrir des ports d’écoute, et si oui, ces ports sont-ils exposés uniquement via un mécanisme de prévisualisation explicite ?
• Les grandes sorties stdout/stderr sont-elles tronquées, diffusées ou stockées ?
• Les échecs de quota sont-ils visibles par l’appelant plutôt que réessayés silencieusement ?

Pour les flux de travail d’agents de production, les limites doivent faire partie du contrat API, pas seulement un concept de facturation. L’équipe de sécurité doit savoir ce qui se produit lorsqu’un agent atteint une limite et si l’échec laisse un état partiel derrière lui.

Contrôles réseau et de sortie

La politique réseau est l’endroit où de nombreuses révisions de bacs à sable deviennent trop vagues. Certaines charges de travail d’agents ont besoin d’un accès Internet ; d’autres ne devraient pas l’avoir par défaut. La bonne réponse dépend du fait que le bac à sable exécute des tests, navigue sur des pages publiques, récupère des paquets, appelle des API internes ou traite des données sensibles.

Vérifiez :

• L’accès Internet sortant est-il activé par défaut ?
• L’accès réseau peut-il être désactivé par bac à sable, par modèle ou par projet ?
• Des listes d’autorisation de sortie sont-elles disponibles pour les domaines, les plages IP, les ports ou les protocoles ?
• L’accès aux points de terminaison de métadonnées cloud est-il bloqué ?
• Le bac à sable peut-il atteindre des VPC privés, des services internes, des bases de données ou des systèmes de déploiement ?
• Le trafic navigateur, le trafic CLI, le trafic du gestionnaire de paquets et les connexions socket directes sont-ils régis par la même politique ?
• Les requêtes sortantes sont-elles journalisées avec l’horodatage, la destination, le contexte du processus ou de la commande, et le statut de la réponse ?

Traitez la sortie de l’agent comme la sortie du système de construction. Si l’agent peut installer des paquets, télécharger des artefacts, appeler des webhooks ou naviguer sur des sites arbitraires, la révision doit couvrir à la fois le code malveillant et le comportement piloté par injection d’invite.

Risques DNS et d’accès aux paquets

Le DNS et les gestionnaires de paquets sont faciles à négliger car ils semblent être de la plomberie d’infrastructure. Pour les agents, ils font partie de la surface d’exécution. Un script généré peut encoder des données dans des requêtes DNS, récupérer un paquet typosquatté ou extraire un script d’une URL qui n’a jamais été examinée.

Vérifiez :

• Le trafic DNS suit-il la même politique de sortie que HTTP et HTTPS ?
• Les requêtes DNS sont-elles journalisées, filtrées ou forcées via des résolveurs contrôlés ?
• Les gestionnaires de paquets peuvent-ils atteindre les registres publics par défaut ?
• Les registres de paquets sont-ils sur liste blanche, proxy, mis en cache ou épinglés ?
• Les noms, versions, URLs, hachages et modifications des fichiers de verrouillage des paquets installés sont-ils capturés ?
• L’agent peut-il exécuter des scripts d’installation, des hooks post-installation ou des étapes de construction de paquets arbitraires ?
• Existe-t-il une porte de révision avant que de nouvelles dépendances ne soient persistées dans un modèle ou un flux de travail de production ?

Si l’accès aux paquets est requis, privilégiez les versions épinglées, les fichiers de verrouillage, les listes d’autorisation de registre et les journaux qui permettent aux réviseurs de reconstruire ce qui a été téléchargé et exécuté.

Gestion des secrets

Les secrets sont généralement le moyen le plus rapide pour qu’une limite de bac à sable devienne inutile. Si un agent voit un jeton large, il peut fuiter des données sans s’échapper de l’hôte.

Vérifiez :

• Les secrets sont-ils injectés uniquement lorsqu’une tâche en a explicitement besoin ?
• Les secrets sont-ils limités au bac à sable, à la tâche, au dépôt, à l’environnement et à la durée de vie ?
• Les secrets peuvent-ils être lus à partir de variables d’environnement, de fichiers, de l’historique du shell, des listes de processus, des journaux, des captures d’écran ou du stockage du navigateur ?
• Les journaux et les artefacts sont-ils expurgés avant le stockage ou l’exportation ?
• Des jetons à courte durée de vie sont-ils utilisés à la place d’identifiants à longue durée de vie ?
• L’agent peut-il accéder aux clés SSH au niveau utilisateur, aux identifiants Git, aux identifiants cloud, aux cookies du navigateur ou aux clés API de l’hôte ?
• L’accès aux secrets est-il visible dans les journaux d’audit ?

Une règle pratique : si un humain ne collerait pas un identifiant dans un travail de construction non fiable, ne le donnez pas à un agent autonome sans une portée plus étroite et une journalisation plus forte.

Journaux et pistes d’audit

Les équipes de sécurité ont besoin de plus que le succès ou l’échec. Elles doivent savoir quel code a été exécuté, quels fichiers ont été modifiés, quels appels réseau ont eu lieu et quelles sorties ont été produites.

Vérifiez :

• Les invocations de commandes sont-elles journalisées avec les arguments, le répertoire de travail, le code de sortie, l’heure de début et la durée ?
• Les lectures, écritures, suppressions, téléchargements, téléversements et modifications de permissions de fichiers sont-ils enregistrés ?
• Les installations de paquets et les récupérations externes sont-elles journalisées ?
• Les actions du navigateur, les captures d’écran, les téléchargements et les soumissions de formulaires sont-ils capturés le cas échéant ?
• Les appels API, les invocations d’outils et les transitions modèle-outil sont-ils corrélés à la même session ?
• Les journaux sont-ils résistants à la falsification depuis l’intérieur du bac à sable ?
• Quelle est la période de conservation, et qui peut accéder aux journaux ?

Pour les flux de travail réglementés ou d’entreprise, la piste d’audit doit prendre en charge à la fois le débogage et la reconstruction post-incident. Une transcription partielle du terminal n’est généralement pas suffisante.

Capture et révision des artefacts

Les agents créent des sorties utiles : diffs, résultats de tests, rapports, captures d’écran, fichiers générés, URLs de prévisualisation et ensembles de données. La gestion des artefacts doit rendre ces sorties consultables sans exposer plus d’état que nécessaire.

Vérifiez :

• Quels artefacts sont exportés automatiquement, et lesquels nécessitent une sélection explicite ?
• Les réviseurs peuvent-ils inspecter les fichiers générés avant qu’ils ne soient validés, téléchargés ou envoyés à un autre service ?
• Les artefacts sont-ils analysés pour détecter les secrets, les logiciels malveillants, les types de fichiers dangereux ou la taille inattendue ?
• Les téléchargements du navigateur sont-ils stockés séparément des diffs de code source et des résultats de test ?
• Les artefacts peuvent-ils être liés à la commande, à l’étape de l’agent et à la session du bac à sable exacts qui les ont produits ?
• Les artefacts sont-ils conservés après la suppression du bac à sable, et peuvent-ils être purgés ?

L’objectif est de préserver les preuves utiles tout en évitant un deuxième canal de fuite de données via les journaux, les captures d’écran, les archives ou les bundles générés.

Contrôles du cycle de vie et de la réinitialisation

Les sessions d’agents peuvent être de courte durée, de longue durée, mises en pause, reprises, instantanées ou clonées à partir de modèles. Chaque mode de cycle de vie modifie la limite.

Vérifiez :

• Chaque bac à sable est-il créé frais, repris d’un état ou cloné à partir d’un modèle ?
• Quelles données survivent à la pause, la reprise, l’instantané, la création de modèle et la suppression ?
• Les fichiers temporaires, les caches de paquets, l’historique du shell, les cookies du navigateur et les bases de données locales sont-ils effacés lors de la réinitialisation ?
• Une session compromise peut-elle empoisonner un modèle réutilisable ?
• Existe-t-il une durée de vie maximale de session ?
• Les bacs à sable arrêtés sont-ils vraiment terminés, ou des tâches en arrière-plan peuvent-elles continuer ?
• La même tâche peut-elle être reproduite à partir d’un environnement propre ?

La capacité de réinitialisation est également importante pour les charges de travail d’évaluation et d’apprentissage par renforcement. Si chaque essai commence à partir d’un état légèrement différent, les conclusions de sécurité et le comportement du modèle deviennent plus difficiles à fiabiliser.

Contrôles d’approbation humaine

L’approbation humaine n’est pas seulement une fonctionnalité UX. C’est un plan de contrôle pour les actions qui traversent les limites de confiance.

Vérifiez :

• Quelles actions peuvent s’exécuter de manière autonome, et lesquelles nécessitent une approbation ?
• Les invites d’approbation sont-elles suffisamment spécifiques pour montrer la commande, les fichiers, la destination, la portée des identifiants et l’effet attendu ?
• Les politiques peuvent-elles exiger une approbation pour les installations de paquets, l’accès réseau externe, les écritures dans le dépôt, les commandes de déploiement ou l’accès aux secrets ?
• Les approbations sont-elles journalisées avec l’utilisateur, l’horodatage, l’action et la commande résultante ?
• Les approbations peuvent-elles être limitées dans le temps et liées à une tâche au lieu d’accorder une large autorisation future ?
• Existe-t-il un chemin de contournement (« break-glass »), et est-il audité ?

Utilisez l’approbation humaine pour les actions irréversibles ou à fort impact : suppression de fichiers, écriture dans des branches de production, appel d’API de déploiement, accès aux données clients et modification des modèles de bac à sable.

Hypothèses de réponse aux incidents

Aucune révision de bac à sable n’est complète sans se demander ce qui se produit lorsqu’une limite échoue ou qu’un flux de travail se comporte de manière inattendue. Ceci est particulièrement important pour les systèmes d’agents car une action risquée peut être causée par la sortie du modèle, une injection d’invite, une compromission de dépendance ou des bogues logiciels ordinaires.

Vérifiez :

• Qui est responsable du triage lorsqu’un bac à sable est suspecté de fuiter des données ou d’exécuter du code hostile ?
• Les bacs à sable peuvent-ils être tués, mis en quarantaine ou bloqués par projet ou organisation ?
• La sortie réseau peut-elle être désactivée rapidement ?
• Les journaux et les artefacts sont-ils conservés pour enquête ?
• Les modèles, caches de paquets et instantanés affectés sont-ils invalidés ?
• Les identifiants sont-ils automatiquement révoqués ou via un runbook documenté ?
• Existe-t-il une distinction claire entre un problème de confinement de bac à sable et un problème de politique d’agent ?

La révision doit se terminer par un modèle de menace écrit et un court runbook. Même si la décision finale est « approuvé uniquement pour les charges de travail non sensibles », cette limite est utile.

Comment Novita Agent Sandbox s’intègre

Novita Agent Sandbox est conçu pour le code généré par IA, les flux de travail navigateur, l’utilisation de l’ordinateur, les évaluations, les environnements d’apprentissage par renforcement et les tâches de longue durée. La page produit décrit des bacs à sable isolés, un démarrage en sous-seconde, des sessions persistantes, la visualisation de sessions en direct via VNC, une tarification à l’utilisation, des modèles et la prise en charge de systèmes de fichiers isolés. Le guide de démarrage rapide de Novita Agent Sandbox montre la création de bac à sable via SDK, l’exécution de commandes, la liste de fichiers et l’arrêt du bac à sable.

Ces capacités peuvent prendre en charge de nombreux flux de travail de cette liste de vérification, mais les critères d’évaluation et les affirmations sur le produit doivent rester séparés. Lorsque votre équipe examine Novita Agent Sandbox, ou tout autre runtime d’agent, confrontez la configuration en direct que vous prévoyez d’utiliser aux contrôles ci-dessus : limite, fichiers, limites de processus, réseau, DNS, récupérations de paquets, secrets, journaux, artefacts, cycle de vie, approbation et réponse aux incidents.

Pour les équipes d’ingénierie utilisant déjà les API de modèle Novita AI, associer l’inférence de modèle à l’exécution dans un bac à sable peut réduire la prolifération des plateformes pour les charges de travail d’agents. Pour une utilisation de production sensible à la sécurité, effectuez toujours une révision spécifique à la charge de travail avant de connecter le bac à sable à des dépôts privés, des ensembles de données sensibles, des services internes ou des identifiants de déploiement.

Conclusion

Approuvez un bac à sable pour agent IA uniquement après que la révision peut répondre clairement à trois questions : qu’est-ce qui est isolé, qu’est-ce qui peut encore quitter la limite, et quelles preuves restent si quelque chose tourne mal. Si ces réponses sont vagues, limitez le bac à sable aux charges de travail non sensibles jusqu’à ce que les contrôles manquants soient documentés et testés.

FAQ

Que doit vérifier une équipe de sécurité en premier lors d’une révision de bac à sable pour agent IA ?

Commencez par la limite d’exécution, l’exposition du système de fichiers et les paramètres réseau par défaut. Ces trois contrôles déterminent si un code hostile peut atteindre l’hôte, les fichiers sensibles ou des destinations externes avant même d’aborder les détails spécifiques au flux de travail comme les approbations et l’exportation d’artefacts.

Un bac à sable basé uniquement sur des conteneurs est-il suffisant pour les agents de codage autonomes ?

Cela dépend de la charge de travail et des données auxquelles il peut accéder. Un conteneur peut être acceptable pour les tâches de faible sensibilité avec des montages restreints, une politique de sortie stricte, des identifiants à courte durée de vie et une journalisation solide, mais les équipes de sécurité doivent prendre cette décision à partir de contrôles documentés plutôt que du seul mot « conteneur ».

Pourquoi le DNS et l’accès aux paquets doivent-ils être examinés séparément de la sortie générale ?

Parce que les agents installent souvent des dépendances et résolvent des hôtes externes dans le cadre de leur fonctionnement normal. Les requêtes DNS et les récupérations de paquets peuvent devenir à la fois un chemin d’exfiltration de données et un risque pour la chaîne d’approvisionnement si elles ne sont pas journalisées, filtrées ou restreintes.

Articles recommandés :

• Comment les bacs à sable pour agents propulsent une innovation IA sécurisée et évolutive
• Construire un agent de codage avec le bac à sable pour agents de Novita
• Novita vs E2B : La comparaison ultime des bacs à sable pour agents pour développeurs et entreprises