Risques de sécurité des agents navigateur : guide pratique

Un risque de sécurité des agents navigateur apparaît quand une IA peut lire des pages non fiables puis cliquer, saisir, télécharger, envoyer, se connecter ou appeler des outils. Une instruction cachée dans une page, un e-mail, un document, une publicité ou un ticket peut influencer l'agent sans avoir été écrite par l'opérateur. Si le même agent possède des sessions sensibles ou de larges permissions, une recherche ordinaire peut provoquer une fuite ou une transaction non autorisée.

La bonne réponse ne consiste pas à interdire tous les agents. Il faut séparer lecture et action, isoler les identités, limiter destinations et outils, exiger une approbation pour les conséquences importantes et conserver une trace. Voici un modèle de menace pratique pour recherche, support, tests, opérations et contenu.

Comment apparaît un risque de sécurité des agents navigateur

Un agent associe un modèle, un navigateur et une boucle d'actions. Il observe, décide, agit puis lit le résultat. Certains parcourent uniquement le web public ; d'autres utilisent des cookies, remplissent des formulaires, téléchargent, accèdent à des dossiers ou communiquent avec des connecteurs et serveurs MCP.

Le risque augmente avec autonomie et privilège. Un profil vierge en lecture seule a un impact inférieur à un agent connecté à la messagerie, au cloud, à l'hébergement, à la facturation et aux panneaux administrateurs. Évaluez à la fois la probabilité de manipulation et le dommage maximal disponible.

• Observation : texte, images, structure, fichiers et réponses des outils.
• Interprétation : mélange possible entre objectif légitime et contenu non fiable.
• Action : clic, saisie, envoi, publication, achat, suppression ou configuration.
• Mémoire : une note conservée peut influencer une future mission.
• Outils : les connecteurs étendent le navigateur aux fichiers, données, e-mails et systèmes.

Injection indirecte par le contenu web

Le prompt injection indirect est le danger central. Une page peut demander au modèle d'ignorer la mission, de révéler une donnée, de visiter un domaine ou d'utiliser un outil. Le message peut être visible, placé dans un texte d'accessibilité, un document ou la réponse d'une intégration compromise.

Un filtre de mots suspects ne suffit pas, car contenu utile et instructions malveillantes utilisent le même langage naturel. Traitez toute source externe comme donnée non fiable, séparez-la des règles système et empêchez la manipulation du modèle de déclencher directement une action importante. La défense doit contenir une injection réussie.

Sessions, cookies et secrets

Un profil peut contenir cookies authentifiés, saisie automatique, mots de passe, historique et extensions. Si l'agent visite une page hostile dans le profil administratif, celle-ci peut exploiter une session existante ou le persuader de transmettre une information par formulaire ou URL.

Utilisez un profil dédié, sans historique personnel, avec uniquement le compte nécessaire. Ne placez pas de clés API ou mots de passe bruts dans le prompt. Préférez des identifiants courts et limités, injectés seulement pour une destination approuvée. Journalisez leur utilisation sans enregistrer leur valeur.

Autonomie excessive et transactions indésirables

Un agent peut prendre une décision techniquement valide mais indésirable : envoyer au mauvais destinataire, accepter un réglage irréversible, publier une donnée privée, acheter ou supprimer. Le problème vient souvent d'une autorité supérieure au besoin ou d'un objectif ambigu.

Classez les actions. Lire une page publique peut être automatique. Préparer une réponse peut l'être, alors que l'envoi exige une revue. Facturation, utilisateurs, domaines, DNS, hébergement, production et données clients doivent afficher la cible et la charge exacte avant une approbation explicite.

• Lecture : consultation publique et extraction avec faible privilège.
• Brouillon : préparation de texte ou de champs sans soumission.
• Écriture réversible : brouillon ou enregistrement temporaire avec retour clair.
• Effet externe : envoi, publication, achat, invitation ou changement d'accès avec approbation.
• Destruction : suppression, rotation de secrets, DNS et déploiement avec contrôle maximal.

Risques liés aux fichiers

Un fichier téléchargé peut exploiter une autre application, contenir du contenu actif ou influencer un modèle plus tard. Un upload peut révéler un document voisin avec des données client. Le sélecteur de fichiers est sensible quand plusieurs noms se ressemblent.

Utilisez un dossier temporaire dédié, autorisez seulement les formats nécessaires, analysez les téléchargements et empêchez leur exécution. Affichez chemin local et destination avant tout envoi. Nettoyez après revue, mais conservez les preuves si un incident est suspecté. Ne montez jamais tout le dossier personnel dans le bac à sable.

Chaîne d'approvisionnement des outils et MCP

Un connecteur ou serveur MCP élargit la frontière de confiance. Sa description peut être trompeuse, une dépendance compromise ou sa réponse hostile. Vérifiez éditeur, code ou documentation, permissions, destinations, mises à jour et conservation des données avant installation.

Exposez une petite liste d'opérations typées plutôt qu'un shell général. Validez les paramètres hors du modèle, contrôlez locataire et objet au moment de l'exécution, et appliquez limites de débit et de budget. L'agent ne doit pas pouvoir connecter un nouvel outil ou agrandir ses droits.

Mémoire empoisonnée et fuite entre missions

Si l'agent conserve des résumés, une page malveillante peut influencer une mission ultérieure. Une note empoisonnée semble fiable parce qu'elle vient de la mémoire. Un stockage partagé peut aussi mélanger deux clients ou projets.

Conservez provenance et niveau de confiance, séparez les espaces, expirez les notes faibles et faites valider tout contenu externe avant de le transformer en règle durable. Ne stockez pas de secret en mémoire longue. Utilisez un contexte propre pour une mission sensible.

Architecture sécurisée pour un agent navigateur

Établissez un modèle de menace avec données, comptes, outils, domaines, actions et pire conséquence. Exécutez le navigateur dans un environnement isolé, un profil dédié et un réseau restreint. Utilisez une liste de domaines quand le parcours est prévisible et bloquez réseaux locaux, métadonnées cloud et systèmes internes inutiles.

Séparez planification et politique. Le modèle propose ; un code déterministe vérifie destination, méthode, paramètres, identité, budget et approbation. Présentez une prévisualisation lisible avant les actes importants. Enregistrez source, URL, proposition, décision, approbation et résultat tout en masquant les secrets.

• Isolation : conteneur, profil et stockage temporaire propres à la mission.
• Moindre privilège : comptes et outils limités avec identifiants courts.
• Réseau : domaines autorisés et blocage des adresses internes.
• Validation déterministe : schémas, autorisations, budgets et débit hors du modèle.
• Approbation humaine : destinataire, valeur, fichier et conséquence clairement affichés.
• Audit : trace des décisions avec données sensibles expurgées.

Tester les défenses avant la production

Créez des pages adverses avec instructions contradictoires, faux avertissements, texte caché, boutons trompeurs et demandes de secrets. Testez changements de domaine, téléchargements, uploads, connexion, achats répétés et erreurs d'outils. Vérifiez que l'agent s'arrête et que le contenu ne peut modifier la politique.

Employez des comptes et données synthétiques. Simulez fuite de session, écriture erronée et mémoire empoisonnée. La revue couvre modèle, navigateur, connecteurs, hébergement, identité, logs et procédure humaine. Un nouveau modèle ne corrige pas une autorisation trop large.

Protéger WordPress et l'hébergement

Ne donnez pas à un agent de recherche une session cPanel, registrar, facturation ou administrateur WordPress. Utilisez un flux séparé, exigez une approbation pour chaque écriture et sauvegardez la production. Le guide du moindre privilège WordPress explique comment éviter le rôle Administrateur lorsque des droits plus fins suffisent.

Les clients VavaHost peuvent séparer recherche publique et administration, puis utiliser SSL et les contrôles de leur plan. Consultez les offres VavaHost, dont le sous-domaine hébergé gratuit pour des essais contrôlés, et le guide SSL. HTTPS protège le transport mais ne rend pas une page fiable pour un agent autonome.

Points clés

• Web non fiable : une page peut manipuler l'agent sans instruction de l'opérateur.
• Impact réduit : isolez profils, comptes, fichiers, réseau, outils et mémoire.
• Plan séparé : validez toute conséquence hors du modèle.
• Approbation précise : affichez cible, charge et résultat avant l'action.
• Injection réussie : testez si les barrières contiennent malgré tout le dommage.
• Preuves : journaux et provenance permettent enquête et récupération.

Le principal risque de sécurité des agents navigateur vient de l'association entre contenu non fiable et autorité excessive. Isolez l'identité, accordez uniquement les capacités de la mission, placez des barrières déterministes devant les effets externes et testez comme si une injection devait finir par réussir.