Publié le 9 juin 2026
Vous pouvez utiliser le protocole WebMCP (WebMCP) pour créer et exposer des outils structurés aux agents d'IA s'exécutant dans le navigateur, y compris ceux alimentés par des extensions. Un agent utilise un grand modèle de langage (LLM), des règles, une mémoire et des outils pour exécuter des actions au nom de l'utilisateur.
Comme les LLM traitent tous les textes, instructions et données utilisateur comme une seule séquence de jetons, ils sont susceptibles de faire l'objet d'une injection de prompt indirecte , c'est-à-dire d'une inclusion d'instructions malveillantes par un pirate. Notre équipe a rédigé ce document sur la sécurité des outils pour vous aider à protéger votre site Web et vos utilisateurs contre les acteurs malveillants.
Bien que certains modèles comportent des couches qui traitent l'injection de prompt, il est impossible de garantir la sécurité dans un grand modèle de langage (LLM). Les modèles sont de nature probabiliste. Il est important de se rappeler que des attaques d'injection de prompt répétables ont été menées contre des systèmes d'agents qui utilisent des LLM de pointe, et que la prévalence des attaques sur le Web augmente.
Pour répondre à ces préoccupations, nous avons fourni des conseils préliminaires sur la sécurité pour ceux qui créent des outils avec WebMCP.
Utiliser des suggestions d'annotation
Vous devez ajouter quelques suggestions lorsque vous créez vos outils :
- Utilisez
untrustedContentHintle cas échéant. Si un outil renvoie du contenu généré par l'utilisateur ou des données provenant de sources externes, envisagez d'ajouteruntrustedContentHintà l'outil. Ce champ indique explicitement que la charge utile n'est pas fiable, ce qui permet de protéger l'intégrité de votre site tout en signalant à l'agent que ces données nécessitent une surveillance accrue. - Utilisez le
readOnlyHintsur les outils qui ne modifient pas l'état. Cela permet à l'agent de prendre de meilleures décisions quant au moment où il doit demander des confirmations à l'utilisateur.
Exposer vos outils avec précaution
L'API WebMCP document.modelContext.registerTool n'expose la fonctionnalité de l'outil qu'aux agents. Par défaut, les autres sites Web ou les iFrames d'origine croisée ne peuvent pas observer vos outils ni interagir avec eux.
Vous pouvez fournir un accès à votre outil avec l'
exposedTo option dans
registerTool à un tableau d'origines spécifiques et sécurisées. Cela expose votre outil à ces origines lorsqu'il est intégré à votre site et lorsque votre site est intégré à cette origine.
// https://partner.org
document.modelContext.registerTool({
name: 'my_shared_tool',
description: 'Shared across origins',
// ...
}, {
exposedTo: ['https://trusted.com', 'https://example.com']
});
N'exposez vos outils qu'aux origines auxquelles vous faites confiance. Cela est particulièrement important lorsque les outils gèrent des données utilisateur ou ont un impact sur l'utilisateur.
- Un outil en lecture seule, tel que
getFavoriteProducts, peut révéler des informations sur un utilisateur. Vous ne devez exposer ces outils qu'aux sites Web avec lesquels vous partagerez directement ces données. - Les outils disposant d'un accès en lecture et en écriture agissent au nom d'un utilisateur. Ces outils ne doivent être exposés qu'aux origines que vous décidez de pouvoir faire confiance lorsqu'elles agissent au nom de votre utilisateur. Par exemple, vous pouvez exposer
postCommentàtrustedExample.com, mais pas àevilExample.com.
Définir des budgets de caractères
Pour éviter de rencontrer des garde-fous d'agent, rédigez des descriptions et des sorties d'outils succinctes. Nous vous recommandons les limites de caractères suivantes pour de meilleurs résultats :
- 500 caractères par description d'outil
- 150 caractères par description de paramètre
- 30 caractères par nom d'outil et nom de paramètre
- 1 500 caractères par sortie d'outil individuelle
Il est probable qu'il existe une certaine variation entre les agents, et vous pouvez ajuster vos budgets de caractères en fonction des commentaires des utilisateurs.
Étapes suivantes
Nous poursuivons nos recherches et nos efforts pour créer une infrastructure sécurisée pour le Web agent. Par exemple, une discussion est en cours
sur la gestion du consentement
entre les parties, et le brouillon de spécification inclut
requestUserInteraction()
pour demander de manière asynchrone l'entrée utilisateur lors de l'exécution de l'outil.
Comment comptez-vous implémenter WebMCP dans votre application ? Avez-vous d'autres préoccupations, liées à la sécurité ou non ? Si vous vous inscrivez à l'évaluation d'origine WebMCP, nous aimerions connaître votre expérience :
- Partagez vos commentaires sur la forme de l'API en commentant un problème existant ou en en ouvrant un nouveau dans l'explication WebMCP sur GitHub.
- Si vous avez des commentaires sur l'implémentation de Chrome, signalez un bug Chromium.
- Rejoignez le programme d'aperçu anticipé pour découvrir les nouvelles API et accéder à notre liste de diffusion.
- Consultez l'implémentation de Chrome sur Chrome Status.
Si vous créez un agent, nous vous recommandons de lire Considérations sur la sécurité des agents pour WebMCP.