Ajoutez WebMCP à votre site Web et vous remettez aux agents IA en visite un ensemble d’outils nommés à appeler. Ces mêmes outils peuvent être utilisés pour retourner les agents contre ceux qui les ont envoyés. Le site des développeurs de Chrome contient désormais des conseils de sécurité pour WebMCP, et une grande partie est écrite pour les sites Web exposant les outils plutôt que pour les entreprises qui créent les agents. Préparez votre site Web pour un agent avec WebMCP, et vous avez également ouvert une surface d’attaque, et la fermer est votre travail, pas celui de l’agent.
Depuis deux ans, la conversation sur la préparation des agents porte sur l’accès : un agent peut-il accéder à votre contenu, lire votre page, finaliser votre paiement ? WebMCP est la version dans laquelle vous arrêtez d’espérer qu’un agent découvre votre site Web à partir du balisage et commencez à lui fournir des outils nommés à appeler. C’est le protocole le plus utile, et c’est la direction dans laquelle évolue la couche de protocole du Web agent. C’est également là qu’être lisible pour un agent et être sûr pour un agent cessent d’être la même propriété.
Chrome nommé deux façons dont les agents sont piratés via WebMCP
Les conseils de sécurité des agents de Chrome décrivent deux vecteurs d’attaque, et tous deux arrivent via les outils exposés par un site Web. Le premier est le manifeste malveillant. Selon les termes de Chrome, « les sites Web peuvent contenir des définitions d’outils avec des instructions cachées, dans les noms d’outils, les paramètres ou les descriptions, conçues pour détourner l’agent. » La description d’un outil est un texte que l’agent lit pour décider comment utiliser l’outil. Une description peut donc contenir une instruction que l’agent n’a jamais été censé suivre.
Le deuxième vecteur est celui que la plupart des sites Web cibleront réellement, et il ne nécessite aucun site Web malveillant. Chrome appelle cela une sortie contaminée : « Les réponses des outils en temps réel provenant de sites par ailleurs dignes de confiance peuvent inclure des instructions malveillantes dans le cadre de données tierces, telles que des commentaires d’utilisateurs. » Un outil sur votre propre site Web qui renvoie vos critiques de produits, vos fils de commentaires, vos messages sur le forum ou vos réponses d’assistance renvoie le texte écrit par d’autres personnes. Si l’une de ces personnes a inséré une instruction dans un avis, votre outil légitime l’a transmise à l’agent comme si elle venait de vous. La charge utile est votre propre contenu généré par l’utilisateur et vous l’avez invité.
Cela fonctionne à cause de quelque chose qui n’est pas un bug et qui ne sera pas corrigé. « Les LLM traitent tous les textes, instructions et données utilisateur comme une seule séquence de jetons », indique le guide, de sorte que le modèle ne peut pas séparer de manière fiable la partie que vous considérez comme des données de la partie qu’un attaquant entendait comme une commande. C’est pourquoi Chrome déclare que « la nature probabiliste des LLM rend impossible la garantie de la sécurité à l’intérieur du modèle lui-même ». Il s’agit du même problème d’injection rapide qui n’a pas de solution claire à l’intérieur du modèle, qui porte désormais un protocole. WebMCP offre à cette attaque une voie de diffusion propre et structurée via les outils que vous avez publiés volontairement.
Rendre un site Web prêt pour les agents implique désormais de le rendre sécurisé pour les agents
Les directives de Chrome imposent cette obligation au site Web, et pas seulement à l’agent. Le document sur la sécurité des outils de Chrome s’ouvre sur une ligne destinée directement à quiconque expose les outils : « N’exposez vos outils qu’à des origines auxquelles vous faites confiance. Ceci est particulièrement important lorsque les outils gèrent les données utilisateur ou ont un impact sur l’utilisateur. » Cette ligne est écrite pour celui qui expédie l’outil. Cela veut dire toi.
Les défenses sont concrètes et ce sont des annotations que vous attachez aux outils que vous expédiez. untrustedContentHint « qualifie explicitement la charge utile de non fiable, pour aider à protéger l’intégrité de votre site tout en signalant à l’agent que ces données nécessitent un examen plus approfondi », et Chrome indique quand l’utiliser : « Si un outil renvoie du contenu généré par l’utilisateur (UGC) ou des données de source externe, envisagez d’ajouter le untrustedContentHint à l’outil. » readOnlyHint marque un outil qui ne change pas d’état, ce qui « permet à l’agent de prendre de meilleures décisions quant au moment où demander des confirmations aux utilisateurs ». exposedTo restreint un outil à un éventail d’origines auxquelles vous faites confiance, écrites dans l’enregistrement lui-même :
document.modelContext.registerTool({...}, {
exposedTo: ['https://trusted.com']
});
Chrome limite également les budgets de caractères, une description d’outil à 500 caractères et une sortie d’outil unique à environ 1 500, et ajoute un requestUserInteraction() chemin pour confirmer une action avant qu’elle ne se déclenche. Prenons l’exemple évident, un outil qui transmet les avis sur les produits à un agent commercial. Le sécuriser n’est pas un travail exotique : marquez sa sortie avec untrustedContentHintensemble readOnlyHint parce qu’il lit plutôt qu’il n’achète, et limite exposedTo aux origines que vous servez réellement. Rien de tout cela n’est le travail de l’agent. C’est le travail de l’auteur de l’outil, qui dans la plupart des équipes est constitué des responsables du Web, du CRO ou du marketing qui ajoutent WebMCP pour paraître actuel, et non des responsables de la sécurité qui lisent les modèles de menace. C’est dans cet écart que les choses tournent mal. Marquer lequel de vos contenus est constitué de données et non de commandes fait désormais partie de l’expédition d’un outil, de la même manière que la désinfection des entrées fait désormais partie de l’expédition d’un formulaire.
Adoptez WebMCP, mais modélisez d’abord les menaces pour chaque outil
Il vaut mieux confier à un agent des outils explicites et appelables que de lui faire deviner votre site Web à partir du DOM, et cette fonctionnalité en vaut la peine. Rien de tout cela n’est une raison pour éviter WebMCP. Le point est plus étroit et plus ennuyeux que « nouveau protocole, nouveau danger » : la capacité arrive avec une facture attachée, et la facture est la vôtre.
La ligne est donc simple. N’exposez pas un outil à un agent que vous n’avez pas modélisé comme vous le feriez pour un point de terminaison d’API publique. Pour chaque outil que vous êtes sur le point d’enregistrer, répondez à une question avant sa livraison : quel contenu non fiable cela peut-il renvoyer et l’avez-vous marqué ? Si vous ne pouvez pas répondre à cette question, l’outil n’est pas prêt, quel que soit le reste de votre site Web prêt pour l’agent.
WebMCP est en avance. Il se trouve dans un essai d’origine Chrome, la spécification est toujours en évolution et la plupart des sites Web n’ont exposé aucun outil. C’est le moment idéal pour décider que Agent Safe fait partie de Agent Ready, avant que le premier outil que vous expédiez ne se révèle être celui qui remet à un agent vos avis et tout ce que quelqu’un a caché à l’intérieur.
Plus de ressources :
Cet article a été initialement publié sur No Hacks.
