Connexion
Google défend le modèle de sécurité agentique de Chrome
Dans l’immédiat, prière de bloquer tous les navigateurs IA pour minimiser l’exposition au risque.
Un document Gartner publié la semaine dernière fait cette recommandation aux CISO.
Google n’y est peut-être pas resté insensible. Quelques jours plus tard est en tout cas apparu, sur son blog sécurité, un post consacré à la navigation agentique dans Chrome – expérimentée depuis septembre.
Le groupe américain y met en avant son approche de défense « hybride » mêlant couches déterministe et probabiliste. Il l’accompagne d’un lien vers un autre post, daté de juin et centré sur l’injection de prompts dans Gemini (sur l’application et au sein de Google Workspace).
Ce post évoquait déjà l’approche de défense en couches. Entre autres techniques listées :
- Entraînement de Gemini avec des données antagonistes pour améliorer sa résilience
- Constitution d’un dataset de vulnérabilités pour entraîner des modèles classificateurs capables de détecter des instructions malveillantes
- Ajout d’instructions dans les pour rappeler à Gemini de se concentrer sur les tâches demandées et d’ignorer les éventuelles instructions antagonistes
- Détection et masquage des URL suspectes sur la base de la technologie Safe Browsing
- Demande de confirmation par l’utilisateur pour certaines actions et fourniture d’informations lorsqu’une attaque est bloquée
Paraphase, spotlighting… Des stratégies pour ignorer le contenu problématique
Dans son post sur la navigation agentique dans Chrome, Google se réfère aussi à ses « principes de sécurité pour les agents ». Synthétisés dans un document publié au printemps, ils figurent plus en détail dans un livre blanc sur la sécurité de Gemini 2.5, publié en parallèle. Parmi les stratégies de défense qui y sont présentées, outre celles susmentionnées, il y a la paraphrase, qui consiste à faire réécrire les données entrantes par une IA distincte afin d’invalider les instructions problématiques.
Il y a aussi le spotlighting. Cette technique de prompt engineering implique d’insérer des marqueurs dans les données d’entrée pour permettre au modèle de distinguer les blocs de tokens non fiables. Microsoft y a dédié un article l’an dernier. Il y expose trois variantes « cumulatives » dites délimitation, datamarking et encodage. La première démarque l’emplacement d’un input dans le prompt en y affixant un ou plusieurs tokens spéciaux. La deuxième va plus loin en entrelaçant un token spécial sur l’ensemble du texte. La troisième rend la démarcation encore plus évidente en transformant le texte avec un algo de type base64 ou ROT13.
Une technique d’extraction de flux made in DeepMind
Dans le modèle de sécurité agentique de Chrome, le spotlighting contribue à ce que Google appelle l’user alignment critic. Objectif : assurer que le modèle préfère suivre les instructions utilisateur et système plutôt que celles issues de contenus externes. L’architecture adoptée dans ce cadre s’inspire du pattern dual-LLM. (en complément au modèle principal, planificateur, un modèle secondaire intervient à chaque fois qu’on travaille avec du contenu non fiable). Elle se nourrit aussi d’une technique que DeepMind a appelée CaMeL. Son principe, dans les grandes lignes : extraire explicitement les flux de contrôle et de données depuis les requêtes fiables, de sorte que les données non fiables que récupère le LLM ne peuvent jamais impacter le flux du programme.
Le modèle secondaire mis en œuvre dans Chrome vérifie chaque action après sa planification et détermine si elle sert ou non l’objectif déclaré. Il ne reçoit que des métadonnées, ce qui évite son empoisonnement par le contenu externe. En cas de rejet d’une action, le modèle principal reçoit du feed-back pour reformuler son plan. Si les rejets s’enchaînent, le contrôle peut être donné à l’utilisateur.
Les défenses statiques comme le spotlighting ont leurs limites face aux attaques adaptatives. Dans ce contexte, il est nécessaire de durcir le modèle principal, en s’appuyant sur ses capacités de raisonnement. On touche là à l’autre composante de l’approche « hybride ». Dans ce domaine, en plus des éléments déjà abordés, on peut élaborer des modèles chargés d’analyser les plans d’actions des agents et de prédire le risque de résultats indésirables.
Les règles same-origin adaptées aux agents
Certaines briques fondamentales du modèle de sécurité de Chrome sont perpétuées dans l’agentique. L’isolation de sites en fait partie (les pages liées à des sites distincts sont toujours placées dans des processus distincts, chacun exécuté dans sa propre sandbox). Il en va de même avec les règles d’origine commune (same-origin policy). Elles limitent la façon dont les documents et les scripts d’une certaine origine peuvent interagir avec les ressources d’une autre origine. Par exemple, en bloquant l’utilisation de JavaScript pour accéder à un document dans un iframe ou pour récupérer des données binaires à partir d’une image intersites. Adaptées aux agents, elles ne leur permettent d’accéder qu’à des données dont l’origine a un lien avec la tâche à effectuer ou que l’utilisateur a explicitement partagées.
Pour chaque tâche, une fonction de portillonnage décide quelles origines sont pertinentes. Elles sont alors séparées en deux ensembles, suivis pour chaque session. D’un côté, les origines en lecture seul (Gemini peut en consommer le contenu). De l’autre, celles en lecture-écriture (Gemini peut réaliser des actions, comme cliquer et saisir des caractères). Si l’origine d’un iframe n’est pas sur la liste des éléments pertinents, le modèle n’en voit pas le contenu. Cela s’applique aussi au contenu issu de l’appel d’outils.
Comme dans le cas de l’user alignment critic, les fonctions de portillonnage ne sont pas exposées au contenu externe.
Il est difficile de trouver le bon équilibre du premier coup, admet Google. C’est en ce sens que le mécanisme actuellement implémenté ne suit que l’ensemble lecture-écriture.
Le programme bug bounty de Chrome clarifié pour l’agentique
Lors de la navigation vers certains sites sensibles (contrôle sur la base d’une liste), l’agent demande confirmation à l’utilisateur. Même chose pour la connexion à un compte à partir du gestionnaire de mots de passe Google. Et plus globalement dès lors que le modèle juge avoir à effectuer une action sensible. Il peut alors solliciter la permission ou donner la main à l’utilisateur.
Google en a profité pour mettre à jour les lignes directrices du programme de bug bounty de Chrome. Il y clarifie les vulnérabilités agentiques qui peuvent donner lieu à une récompense.
La plus élevée (20 000 $) vaut pour les attaques qui modifient l’état de comptes ou de données. Par exemple, une injection indirecte de prompt permettant un paiement ou une suppression de compte sans confirmation par l’utilisateur. Ce montant ne sera attribué qu’en cas de fort impact, de reproductibilité sur de nombreux sites, de réussite sur au moins la moitié des tentatives, et d’absence de lien étroit avec le prompt utilisateur.
La récompense maximale est fixée à 10 000 $ pour les attaques qui peuvent engendrer l’exfiltration de données sensibles. Et à 3000 $ pour celles qui contourneraient des éléments de sécurité agentique.
Illustration générée par IA
The post Google défend le modèle de sécurité agentique de Chrome appeared first on Silicon.fr.
