- Pourquoi les agents de navigation et d'utilisation de l'ordinateur ont besoin d'un sandbox
- Que faut-il isoler dans une session de navigation
- Comment gérer les cookies, les comptes et les informations d'identification
- Comment contenir les téléchargements, les fichiers et les données du presse-papiers
- Comment journaliser les actions DOM, les captures d'écran et les pistes de relecture
- Comment définir les limites réseau, d'approbation et de réinitialisation
- Comment Novita Agent Sandbox s'inscrit dans cette évaluation
- Liste de contrôle du sandbox de navigation et d'utilisation de l'ordinateur
- FAQ
- Articles recommandés
Les sandbox de navigation et d’utilisation de l’ordinateur doivent isoler les sessions, le système de fichiers et les téléchargements, les informations d’identification, les cookies, l’accès réseau, les actions d’outils, les captures d’écran et enregistrements, les journaux et l’état de réinitialisation afin que les agents IA ne puissent pas étendre silencieusement leur périmètre de confiance lors de l’exploitation de sites web, d’applications et de fichiers.
Pourquoi les agents de navigation et d’utilisation de l’ordinateur ont besoin d’un sandbox
Les agents de navigation et d’utilisation de l’ordinateur sont différents des chatbots ordinaires. Ils ne se contentent pas de répondre à une question ; ils cliquent, tapent, téléchargent des fichiers, lisent des pages web, remplissent des formulaires et parfois opèrent dans un environnement complet de type bureau. Cela fait de l’environnement d’exécution une partie du modèle de sécurité.
Un assistant textuel peut produire une mauvaise réponse. Un agent de navigation ou d’utilisation de l’ordinateur peut prendre une mauvaise action. Il peut soumettre un formulaire, divulguer un cookie de session dans un journal, télécharger un fichier dangereux, écraser un espace de travail, suivre une injection de prompt cachée dans une page web, ou utiliser une information d’identification dans un contexte où elle ne devrait pas être disponible.
Le sandbox est l’endroit où ces actions sont contraintes. Il devrait répondre à des questions pratiques telles que :
- Dans quel compte le navigateur est-il connecté ?
- Quels fichiers l’agent peut-il lire ou écrire ?
- Quels domaines l’agent peut-il contacter ?
- Quels cookies et jetons persistent après la tâche ?
- Quels clics, commandes, captures d’écran et modifications de fichiers peuvent être examinés ultérieurement ?
- Qu’est-ce qui est détruit lorsque la tâche se termine ?
L’objectif n’est pas de faire croire qu’un sandbox élimine tous les risques. L’objectif est de rendre l’environnement d’exploitation de l’agent étroit, observable et réinitialisable. Lorsqu’un modèle ou un outil prend une mauvaise décision, le rayon d’explosion doit être limité à la session et aux ressources que vous avez intentionnellement exposées.
Que faut-il isoler dans une session de navigation
Commencez par le profil du navigateur. Un agent de navigation ne doit pas utiliser le profil de navigation quotidien d’un développeur, ses extensions personnelles, ses mots de passe enregistrés, ses cookies persistants ou un répertoire de téléchargement non géré. Attribuez à chaque tâche, utilisateur ou flux de travail sa propre limite de profil, sauf s’il existe une raison délibérée de partager l’état.
Au minimum, évaluez si le sandbox sépare :
| Limite | Ce qui peut mal tourner sans cela | Ce qu’il faut vérifier |
|---|---|---|
| Profil du navigateur | L’agent hérite de connexions, extensions, cookies, remplissage automatique ou historique de navigation non liés. | Profils par tâche ou par utilisateur, règles de persistance explicites, contrôles d’extension. |
| Cycle de vie de la session | L’état d’une tâche précédente modifie le résultat de la tâche suivante. | Création de nouvelle session, restauration d’instantané, nettoyage et comportement d’expiration. |
| Onglets et fenêtres | L’agent lit ou clique sur du contenu dans le mauvais contexte. | Délimitation des onglets, suivi de la fenêtre active et journaux d’événements. |
| Stockage du navigateur | LocalStorage, IndexedDB, le cache et les service workers persistent un état sensible. | Réinitialisation du stockage, règles d’exportation et nettoyage par domaine. |
| Téléchargements | Les fichiers du web atterrissent dans un répertoire partagé. | Dossier de téléchargement isolé, politique de type de fichier, workflow d’analyse des logiciels malveillants si nécessaire. |
Traitez le navigateur comme un espace de travail, pas comme une simple interface utilisateur jetable. Les applications web modernes conservent un état significatif dans les cookies, le stockage local, les caches, les service workers, les requêtes en arrière-plan et les fichiers téléchargés. Si le sandbox ouvre seulement une fenêtre de navigateur mais ne définit pas ce qui arrive à cet état, la limite d’isolation est incomplète.
Pour les environnements d’utilisation de l’ordinateur, le même principe s’étend au-delà du navigateur. L’agent peut interagir avec un terminal, un gestionnaire de fichiers, un éditeur de documents, un serveur de prévisualisation local ou une application GUI. Cet environnement nécessite un répertoire personnel délimité, des points de montage clairs et un moyen de séparer les artefacts de tâche des éléments internes de l’exécution.
Comment gérer les cookies, les comptes et les informations d’identification
Les cookies et les comptes connectés sont souvent la partie la plus sensible de l’automatisation du navigateur. Un agent de navigation avec une session valide peut effectuer tout ce que le compte est autorisé à faire, même si le modèle ne voit jamais le mot de passe en clair.
Utilisez un compte séparé pour le travail de l’agent lorsque c’est possible. Le compte doit avoir les autorisations minimales nécessaires pour le flux de travail, et le sandbox doit indiquer clairement si les cookies sont injectés, créés lors de la connexion, persistés entre les exécutions ou détruits après la fin.
La gestion des informations d’identification nécessite une règle plus stricte : ne donnez jamais à l’agent des secrets généraux simplement parce qu’un site web pourrait les demander. Préférez les jetons délimités et limités dans le temps, les informations d’identification par flux de travail, et l’accès intermédié où l’agent appelle un outil spécifique plutôt que de lire un secret brut. Si un secret doit être disponible à l’intérieur du sandbox, décidez s’il apparaît comme une variable d’environnement, un fichier monté, une information d’identification de navigateur ou une capacité exclusive à un outil.
Surveillez ces anti-modèles :
- Un profil de navigateur partagé avec des cookies personnels ou administrateur.
- Des secrets collés dans une page par le modèle sans approbation.
- Des clés API disponibles pour tous les outils dans le sandbox.
- Des cookies de session capturés dans des captures d’écran pleine page ou des journaux de débogage.
- Le remplissage automatique de formulaire activé pour les comptes de production.
- Des informations d’identification à longue durée de vie laissées dans des fichiers téléchargés, l’historique du shell ou le stockage du navigateur.
Les recommandations de l’OWASP pour les applications LLM mettent en évidence l’injection de prompt et l’agence excessive comme des risques récurrents dans les systèmes d’agents. Pour les agents de navigation, ces risques rencontrent directement le web : une page peut contenir des instructions qui tentent d’influencer le modèle, et le modèle peut avoir des outils qui effectuent des actions réelles. L’isolation vous donne une deuxième ligne de défense lorsque le suivi des instructions ne suffit pas.
Comment contenir les téléchargements, les fichiers et les données du presse-papiers
Les téléchargements sont une limite de confiance. Un agent de navigation peut enregistrer des PDF, des feuilles de calcul, des archives, des captures d’écran, des factures, des artefacts de build ou des fichiers exécutables. Ces fichiers doivent atterrir dans un répertoire appartenant au sandbox, pas dans un dossier de bureau partagé ou un espace de travail de production.
Une politique de téléchargement pratique devrait couvrir :
- Types de fichiers autorisés et taille maximale des fichiers.
- Si les fichiers téléchargés peuvent être ouverts automatiquement.
- Si les fichiers peuvent être téléchargés vers un autre site.
- Comment les fichiers sont analysés, hachés ou journalisés.
- Quels fichiers sont exportés du sandbox à la fin de l’exécution.
- Comment les fichiers temporaires sont supprimés.
Pour les agents d’utilisation de l’ordinateur, les limites de fichiers sont encore plus importantes car l’agent peut créer ou modifier des fichiers locaux dans le cadre de la tâche. Un agent de codage peut éditer un référentiel. Un agent de données peut créer des graphiques. Un agent de navigation peut télécharger un CSV, le transformer et télécharger un résultat. Chaque chemin doit être explicite : où les entrées arrivent, où les fichiers de travail résident, où les sorties approuvées sont exportées, et ce qui est effacé.
L’accès au presse-papiers mérite sa propre décision. Il est pratique pour l’automatisation GUI, mais il peut aussi déplacer du texte sensible entre des applications non liées. Si l’agent peut lire le presse-papiers, il peut voir un jeton copié par un humain quelques secondes plus tôt. S’il peut écrire dans le presse-papiers, il peut affecter la prochaine action de collage de l’humain. Dans les flux de travail sensibles, rendez l’accès au presse-papiers local à la session ou exigez une approbation explicite avant de franchir la frontière humain-sandbox.
L’interaction avec l’écran a un problème similaire. Les agents d’utilisation de l’ordinateur travaillent à partir de captures d’écran, d’arbres d’accessibilité ou d’état d’interface utilisateur rendu. Les captures d’écran peuvent inclure des données privées, des noms de compte, des jetons, du texte de document ou des enregistrements clients. Décidez si les captures d’écran sont conservées, anonymisées, diffusées à un fournisseur de modèle ou stockées pour relecture. Ne les traitez pas comme des images de débogage inoffensives.
Comment journaliser les actions DOM, les captures d’écran et les pistes de relecture
Un sandbox de navigation devrait rendre les actions vérifiables. Lorsqu’un agent clique sur un bouton ou soumet un formulaire, une équipe de sécurité ou un développeur devrait pouvoir reconstruire ce qui s’est passé sans deviner à partir du résultat final.
Pour l’automatisation du navigateur, les journaux utiles incluent :
- URL et origine visitée.
- Sélecteur DOM ou cible d’accessibilité utilisé pour chaque action.
- Texte tapé, avec anonymisation des secrets.
- Événements de soumission de formulaire.
- Téléchargements démarrés et terminés.
- Requêtes réseau au niveau du domaine ou du point d’accès.
- Erreurs de console et erreurs de page.
- Points de contrôle de capture d’écran avant ou après les étapes sensibles.
Pour l’automatisation d’utilisation de l’ordinateur, ajoutez les appels d’outils, les démarrages de processus, les commandes shell, les lectures et écritures de fichiers, les changements de focus de fenêtre et les artefacts exportés. Le journal doit distinguer ce que le modèle a demandé, ce que la couche d’automation a exécuté et ce que l’environnement a renvoyé. Cette distinction est importante lors du débogage d’injection de prompt, de comportement d’interface utilisateur instable ou d’un bogue d’encapsulation d’outil.
La relecture est utile, mais elle change la question de la conservation des données. Une piste de relecture complète peut inclure des captures d’écran, du texte de page, du contenu de formulaire, des noms de fichiers, des sorties de terminal et des informations d’identification, sauf si l’anonymisation est intégrée. Décidez à l’avance qui peut accéder aux relectures, combien de temps elles sont conservées et si les valeurs sensibles sont masquées avant le stockage.
Le niveau de détail approprié dépend du flux de travail. Un agent public de surveillance des prix peut avoir besoin de journaux légers. Un agent qui touche aux comptes clients, aux pages de facturation, aux consoles d’infrastructure ou aux outils internes a besoin de pistes d’audit plus solides et de contrôles de conservation plus stricts.
Comment définir les limites réseau, d’approbation et de réinitialisation
L’accès réseau est l’endroit où un sandbox de navigation peut s’étendre silencieusement. Une tâche peut commencer avec un site web, puis charger des scripts tiers, suivre des redirections, appeler des API, télécharger des paquets ou atteindre des domaines internes. Si le sandbox a un accès sortant large, l’agent peut déplacer des données vers des endroits que le propriétaire de l’application n’attendait pas.
Pour les agents de navigation et d’utilisation de l’ordinateur, considérez :
- Listes blanches de domaines pour les destinations web attendues.
- Blocages pour les services de métadonnées internes et les plages de réseau privé.
- Politique distincte pour les registres de paquets, le stockage d’objets et la recherche web.
- Journalisation DNS lorsque la revue de sécurité l’exige.
- Journaux de trafic sortant pouvant être liés à une session et une tâche.
L’approbation humaine devrait se situer en amont des actions difficiles à annuler ou ayant une signification juridique. Les exemples incluent la soumission d’achats, l’envoi de messages, la modification des paramètres de compte, la suppression de fichiers, la rotation des informations d’identification, l’invitation d’utilisateurs, l’ouverture de tickets de support ou le téléchargement de données clients. L’événement d’approbation doit capturer ce que l’agent a l’intention de faire, la page ou le fichier impliqué, et l’action exacte approuvée.
Le comportement de réinitialisation est la dernière limite. Un bon sandbox devrait rendre évident ce qui se passe lorsque une tâche se termine :
| État | Question de réinitialisation |
|---|---|
| Cookies du navigateur | Sont-ils détruits, persistés ou sauvegardés ? |
| Stockage du navigateur | Le cache, le stockage local, IndexedDB et l’état du service worker sont-ils effacés ? |
| Téléchargements | Les fichiers sont-ils supprimés, conservés pour examen ou exportés vers un emplacement contrôlé ? |
| Informations d’identification | Les jetons sont-ils révoqués, rotés ou retirés de l’environnement ? |
| Journaux et relecture | Qu’est-ce qui est conservé, anonymisé et pour combien de temps ? |
| Accès réseau | Les listes blanches temporaires ou les identifiants de proxy sont-ils supprimés ? |
| Système de fichiers | L’espace de travail est-il effacé, instantané ou réutilisé ? |
Les sessions persistantes sont utiles pour les agents de longue durée, mais la persistance doit être intentionnelle. Si un profil de navigateur, un système de fichiers ou un état de processus survit entre les exécutions, documentez pourquoi il persiste et qui peut le réinitialiser.
Comment Novita Agent Sandbox s’inscrit dans cette évaluation
Le Novita Agent Sandbox est conçu pour exécuter des charges de travail d’agents IA dans des environnements cloud isolés. La page produit décrit la prise en charge de l’exécution de code, de l’utilisation du navigateur, de l’utilisation de l’ordinateur, des sessions persistantes, de la visualisation en direct des sessions et des modèles réutilisables. La documentation de démarrage rapide de Novita Agent Sandbox montre comment les développeurs peuvent créer un sandbox, exécuter des commandes, travailler avec des fichiers et gérer un sandbox via des SDK.
Ces capacités rendent Novita pertinent lorsque vous évaluez des agents de navigation, des agents de codage, des workflows d’analyse de données et des agents de longue durée. L’évaluation doit toujours être spécifique à votre modèle de menace. Avant d’utiliser un fournisseur de sandbox pour une automatisation sensible de navigation ou d’utilisation de l’ordinateur, confirmez le comportement exact dont vous avez besoin concernant les profils de navigateur, les cookies, l’injection d’identifiants, le trafic réseau sortant, la conservation des captures d’écran, l’exportation de fichiers, les journaux et la sémantique de réinitialisation.
Pour les équipes qui utilisent déjà les modèles Novita AI, l’avantage pratique est l’adéquation opérationnelle : l’inférence et l’exécution des agents peuvent être planifiées au sein de la même plateforme de construction au lieu d’être traitées comme des décisions d’infrastructure distinctes. Gardez les affirmations du produit séparées des hypothèses de sécurité, cependant. Un sandbox peut fournir une isolation utile et des contrôles de cycle de vie, mais votre application a toujours besoin de comptes à privilèges minimaux, d’identifiants délimités, de portes d’approbation et de règles d’audit pour les actions que votre agent effectue.
Liste de contrôle du sandbox de navigation et d’utilisation de l’ordinateur
Utilisez cette liste de contrôle avant de donner à un agent l’accès à un vrai site web, compte ou espace de travail de type bureau.
| Domaine | Question d’évaluation |
|---|---|
| Session | Chaque tâche obtient-elle un profil de navigateur ou un espace de travail isolé ? |
| Comptes | L’agent utilise-t-il un compte à privilège minimal plutôt que le compte principal d’un humain ? |
| Cookies | Les cookies sont-ils délimités, persistés intentionnellement et effacés lors de la réinitialisation ? |
| Informations d’identification | Les secrets sont-ils délimités, limités dans le temps, anonymisés dans les journaux et indisponibles pour les outils non liés ? |
| Téléchargements | Les fichiers restent-ils dans un répertoire appartenant au sandbox jusqu’à ce qu’ils soient explicitement exportés ? |
| Presse-papiers | L’agent peut-il lire ou écrire dans le presse-papiers humain, ou seulement dans un presse-papiers local à la session ? |
| Captures d’écran | Les captures d’écran sont-elles conservées, anonymisées et contrôlées par accès ? |
| Actions DOM | Les clics, le texte tapé, les formulaires, les sélecteurs et les origines de page sont-ils journalisés ? |
| Appels d’outils | Pouvez-vous séparer l’intention du modèle de l’action d’outil exécutée ? |
| Réseau | Les domaines, les plages privées, les registres de paquets et le comportement DNS sont-ils contrôlés ? |
| Approbation | Quelles actions nécessitent une étape de confirmation humaine ? |
| Réinitialisation | Qu’est-ce qui est exactement effacé, conservé, révoqué ou instantané après l’exécution ? |
| Examen d’incident | Pouvez-vous reconstruire ce qui s’est passé à partir des journaux, fichiers, événements réseau et relecture ? |
FAQ
Quelle est la différence entre un sandbox de navigation et un sandbox d’utilisation de l’ordinateur ?
Un sandbox de navigation limite ce qu’un navigateur web peut faire : quels profils, cookies et stockage sont disponibles, quels domaines le navigateur peut contacter et quels téléchargements sont autorisés. Un sandbox d’utilisation de l’ordinateur est plus large et couvre un environnement complet de type bureau — accès au terminal, gestionnaires de fichiers, applications GUI et processus locaux en plus du navigateur. Les deux partagent les mêmes préoccupations fondamentales concernant la réinitialisation, la journalisation, la délimitation des identifiants et les comptes à privilèges minimaux, mais les environnements d’utilisation de l’ordinateur nécessitent des décisions supplémentaires concernant les répertoires montés, l’accès au presse-papiers, les données d’écran et l’isolation des processus.
Ai-je besoin d’un profil de navigateur séparé pour chaque tâche d’agent ?
Dans la plupart des cas, oui. Partager un profil entre les tâches signifie qu’une tâche peut voir les cookies, connexions, mots de passe enregistrés et stockage du navigateur laissés par une autre. Les profils par tâche sont le moyen le plus simple d’empêcher le transfert d’état non intentionnel. Si votre flux de travail nécessite une persistance de session — par exemple, un agent de longue durée qui reprend là où il s’est arrêté — rendez la persistance explicite et documentez exactement quel état est transféré et pourquoi.
Les agents IA peuvent-ils gérer en toute sécurité les informations d’identification à l’intérieur d’un sandbox ?
Les informations d’identification sont plus sûres à l’intérieur d’un sandbox que dans un environnement non contrôlé, mais le sandbox seul ne rend pas la gestion des identifiants sûre. Les principaux risques sont la surexposition (donner à l’agent plus d’accès que la tâche ne le nécessite), la fuite (informations d’identification apparaissant dans les journaux, captures d’écran ou sortie de débogage) et la persistance (jetons ou cookies restant disponibles après la fin de la tâche). Préférez les informations d’identification délimitées et limitées dans le temps ; intermédez l’accès via des appels d’outils étroits plutôt que des secrets bruts ; et confirmez que les journaux et captures d’écran anonymisent les valeurs sensibles avant le stockage.
Que se passe-t-il si un agent IA télécharge un fichier malveillant ?
La politique de téléchargement du sandbox détermine le rayon d’explosion. Si les téléchargements sont isolés dans un répertoire appartenant au sandbox, que l’ouverture automatique est désactivée et que des restrictions de type de fichier sont en place, un fichier téléchargé ne peut pas s’exécuter automatiquement ni atteindre le système de fichiers plus large. Sans ces contrôles, un fichier malveillant pourrait s’exécuter, atteindre des répertoires partagés ou être téléchargé ailleurs avant qu’un humain ne l’examine. Traitez les téléchargements comme des entrées potentiellement non fiables et définissez des politiques explicites pour les types de fichiers autorisés, s’ils peuvent être ouverts dans le sandbox et comment ils sont analysés ou journalisés.
Comment détecter l’injection de prompt dans un agent de navigation ?
L’injection de prompt à partir d’une page web est difficile à détecter de manière fiable au niveau du modèle. Le sandboxing est l’un des principaux contrôles défensifs car il limite ce que l’agent peut faire même si une instruction malveillante est suivie. Les signaux pratiques incluent des appels d’outils ou des navigations inattendus, des actions en dehors du domaine prévu, des soumissions de formulaire inhabituelles et des tentatives de récupération ou de transmission d’informations d’identification ou de données de session. De bons journaux d’actions DOM — enregistrant quelle page a été visitée, quels sélecteurs ont été ciblés et quel texte a été tapé — facilitent la reconstruction pour savoir si une page a influencé le comportement de l’agent.
Utiliser un sandbox signifie-t-il que mon agent est sécurisé ?
Un sandbox réduit le rayon d’explosion mais n’élimine pas le risque. Il limite ce que l’agent peut atteindre et ce qui survit à une réinitialisation, mais il n’empêche pas les mauvaises décisions du modèle, les informations d’identification mal configurées ou les vulnérabilités au niveau de l’application. La sécurité dépend de contrôles en couches : comptes à privilèges minimaux, informations d’identification délimitées, portes d’approbation pour les actions irréversibles, journaux d’audit capturant l’intention du modèle et les actions exécutées, et examen humain avant que les flux de travail sensibles n’atteignent la production. Un sandbox est une couche, pas la réponse complète.
Combien de temps les captures d’écran et les données de relecture doivent-elles être conservées ?
La conservation dépend de la sensibilité du flux de travail et de vos exigences d’audit. Pour les agents qui touchent à des données personnelles, des systèmes de facturation, des comptes clients ou des outils internes, une fenêtre de conservation définie avec des contrôles d’accès et l’anonymisation des valeurs sensibles (jetons, contenu de formulaire, informations d’identification visibles) est une base de référence raisonnable. Pour les flux de travail à faible sensibilité, une conservation plus courte ou une journalisation sommaire peut être appropriée. Décidez avant le déploiement qui peut accéder aux relectures, combien de temps elles sont conservées et comment elles sont supprimées. Évitez de traiter les captures d’écran comme des artefacts de débogage inoffensifs — elles contiennent souvent plus de données sensibles que les journaux structurés.
Quelles actions d’agent devraient toujours nécessiter une approbation humaine ?
Les actions difficiles à annuler ou ayant une signification juridique sont les candidats les plus évidents : achats, modifications des paramètres de compte, suppressions de fichiers, rotation des informations d’identification, invitations d’utilisateurs, soumissions de tickets de support et téléchargements de données clients ou réglementées. Au-delà de celles-ci, envisagez d’exiger une approbation pour toute action en dehors du champ d’application initial de la tâche de l’agent, toute action sur un domaine ou un compte non anticipé au début de l’exécution, et tout téléchargement ou exécution de fichiers que la tâche n’exigeait pas explicitement. L’événement d’approbation doit enregistrer ce que l’agent avait l’intention de faire et ce que l’humain a explicitement confirmé.
