Sécurité de l'outil WebMCP

Julia Pagnucco
Julia Pagnucco
LinkedIn
Alexandra Klepper
Alexandra Klepper
GitHub Bluesky

Publié le 9 juin 2026, dernière mise à jour le 1er juillet 2026

Explicatif Web Extensions État de Chrome Intention
GitHub Essai Origin Trial Essai d'origine Afficher Intention de tester

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, de la 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 indications d'annotation

Vous devez ajouter quelques indications lorsque vous créez vos outils :

  • Utilisez untrustedContentHint le cas échéant. Si un outil renvoie du contenu généré par l'utilisateur (CGU) ou des données provenant de sources externes, envisagez d'ajouter untrustedContentHint à 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 readOnlyHint sur les outils qui ne changent pas d'é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

await 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 jugez fiables lorsque vous agissez 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. Pour de meilleurs résultats, nous vous recommandons les limites de caractères suivantes :

  • 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'essai d'origine WebMCP, nous aimerions connaître votre expérience :

Si vous créez un agent, nous vous recommandons de lire les considérations relatives à la sécurité des agents pour WebMCP.