Menu supplémentaire

Achetez MemberPress dès aujourd'hui ! Commencez à être payé pour le contenu que vous créez ! Obtenir MemberPress maintenant
  1. Accueil
  2. Base de connaissances
  3. Documentation pour les développeurs
  4. MCP
  5. Mesures de sécurité relatives aux agents de la plateforme MemberPress AI Foundation

Mesures de sécurité relatives aux agents de la plateforme MemberPress AI Foundation

MemberPress AI Foundation applique quatre mesures de sécurité aux opérations d'écriture du Model Context Protocol (MCP). Ces mesures protègent un site contre toute modification involontaire ou non autorisée lorsqu'un client IA se connecte via le serveur MCP. Elles fonctionnent de manière conjointe. Un simple appel d’écriture peut passer par des vérifications de portée, des valeurs par défaut d’aperçu, une étape de confirmation et le « kill switch » avant de modifier les données.

Ce document explique chaque mesure, ce contre quoi elle protège et comment le serveur MCP la met en œuvre. Deux mesures s'appliquent lorsqu'un client IA appelle un outil : les jetons de confirmation et les paramètres par défaut en mode simulation. Une mesure régit le vocabulaire de portée que transporte un jeton de connexion : les portées granulaires. Une mesure permet à un administrateur d'interrompre instantanément toute écriture destructive : le « kill switch ».

Fonctionnement de la couche de sécurité

Ces quatre mesures correspondent à quatre questions distinctes concernant une opération d'écriture :

MesureNomLa question à laquelle elle répond
AJetons de confirmationQue peut FAIRE un jeton lorsqu'un outil destructeur s'exécute ?
BParamètres par défaut du test à blancQuel est le mode par défaut d'un outil d'écriture lorsqu'il est lancé ?
CPortées granulairesQuelle étendue de vocabulaire un jeton de connexion couvre-t-il ?
DInterrupteur d'arrêt d'urgenceUn administrateur peut-il bloquer d'un seul coup toutes les opérations d'écriture destructrices ?

Les mesures A, B et D s'appliquent au moment de l'appel de l'outil. Le serveur MCP les évalue à l'intérieur de Server::handle_tool_call à chaque requête d'écriture. La mesure C intervient à deux niveaux. Au moment de l'appel d'un outil, le serveur compare la portée requise par l'outil aux portées accordées par le jeton. Au moment de l'émission du jeton, le plafond d'accès par défaut limite les portées attribuées à une nouvelle connexion.

Ces quatre mesures figurent dans le MemberPressAI\MCP espace de noms et s'exécutent côté serveur. Un client IA ne peut pas les contourner en modifiant la formulation de sa requête, car la validation s'effectue une fois que la requête a atteint le serveur, et non au niveau du client.

Mesure A — Jetons de confirmation

Les jetons de confirmation protègent les opérations destructives grâce à un flux obligatoire en deux étapes. Un outil destructif ne peut pas s'exécuter en un seul appel. Le premier appel renvoie un aperçu ainsi qu'un jeton à usage unique ; le deuxième appel doit inclure ce jeton pour pouvoir s'exécuter.

Il existe toutefois une exception limitée : Les actions réversibles ne passent pas par la case « porte ». memberpress_gérer_l'abonnement avec action : " reprendre " et memberpress_gérer_compte_secondaire avec action : " ajouter " annuler plutôt que détruire, et s'exécuter sans jeton. Une seule liste blanche partagée régit l'exemption à la fois au niveau du point de terminaison MCP et de l'interface WordPress Abilities, de sorte que les deux contrôles ne peuvent pas diverger. Tout autre appel destructeur nécessite le jeton.

Six outils sont destructifs et nécessitent ce processus :

OutilFonctionnalités
memberpress_delete_memberSupprime un membre
memberpress_remboursement_transactionRembourse une transaction
memberpress_delete_webhookSupprime un webhook
memberpress_reset_course_progressRéinitialise la progression d'un apprenant dans le cours
memberpress_gérer_compte_secondaireGère un sous-compte d'entreprise
memberpress_gérer_l'abonnementGère un abonnement

Fonctionnement du flux à deux appels

  1. Le client IA appelle l'outil de destruction en lui transmettant ses arguments. Le serveur renvoie un aperçu de l'effet ainsi qu'un jeton de confirmation.
  2. Le client IA appelle à nouveau cet outil avec les mêmes arguments, auxquels s'ajoute un confirmer paramètre défini sur la valeur du jeton. Le serveur vérifie le jeton et exécute l'opération.

Le jeton comporte trois mesures de sécurité. Il expire après 60 secondes (le TTL constante dans Jetons de confirmation). Il s'agit d'un jeton à usage unique : le serveur le consomme lors de l'exécution de l'appel. Le serveur l'associe à la combinaison précise du nom de l'outil, des arguments et de l'identifiant de l'utilisateur. Un jeton émis pour une opération ne peut pas autoriser une autre opération.

Justification de la conception, selon l'équipe de développement : “ Le simple fait de transmettre une valeur booléenne ne constitue pas un consentement suffisamment ferme pour une action irréversible. ” Un jeton de confirmation prouve que l'utilisateur a bien consulté l'aperçu spécifique à l'opération en question avant de s'engager.

Important : Les outils de destruction n'acceptent pas un exécuter paramètre. Le flux de jetons de confirmation est le seul moyen de les exécuter. Le passage de exécuter : true n'a aucun effet sur un outil destructeur.

La réponse à la première intervention

Le premier appel renvoie un aperçu de l'effet, à usage unique jeton_de_confirmation, ainsi que la durée de validité restante du jeton. Voici la réponse fournie par un memberpress_remboursement_transaction appel de prévisualisation :

{
  "preview" : {
    "dry_run" : true,
    "action" : "refund_transaction",
    "preview": {
 "transaction_id": 432,
 "amount": "100,00",
 "total": "100,00",
      "user_id": "",
 "product_id": 2332,
 "subscription_listing_may_show_inactive": true,
 "subscription_listing_note": " Si cette transaction était la dernière à avoir alimenté l’abonnement, la liste des abonnements dans l’interface d’administration WordPress affichera l’abonnement comme " Actif : Non " — cette colonne est dérivée du statut de la dernière transaction, et non de l’enregistrement de l’abonnement lui-même. L’enregistrement de l’abonnement reste inchangé, sauf si vous choisissez d’annuler l’abonnement dans le cadre de ce remboursement."
    }
  },
  "confirmation_token": "ct_",
  "expires_in": 60,
  "next_step": "Appelez à nouveau la fonction memberpress_refund_transaction avec les mêmes arguments, en ajoutant le paramètre " confirm " : " ct_ » pour exécuter l'opération."
}

Le jeton arrive dans jeton_de_confirmation. Les expires_in Ce champ indique la durée de vie restante en secondes. Le étape suivante Le champ indique précisément comment procéder. Le bloc interne aperçu.aperçu Cet objet décrit l'effet de l'opération ; ses champs varient selon l'outil. Le liste_des_abonnements_* Les champs présentés ici concernent spécifiquement les remboursements ; les documents « Référence des outils » et « Erreurs » fournissent des informations détaillées sur les réponses relatives aux remboursements.

Lorsqu'un jeton n'est pas valide

Un jeton dont la validité a expiré, qui a déjà été utilisé ou qui est présenté avec des arguments modifiés génère une seule erreur. Le serveur ne fait pas la distinction entre ces trois causes :

{
  "code": -32603,
  "message": "Le jeton de confirmation n'est pas valide, a expiré ou les arguments ont changé. Appelez l'outil sans `confirm` pour obtenir un nouvel aperçu et un nouveau jeton.",
  "data": {
    "mp_error_code": "CONFIRMATION_INVALID"
  },
  "request_id": "req_"
}

Match le data.mp_error_code (CONFIRMATION_NON_VALIDE), et non le JSON-RPC générique -32603 code. La procédure de récupération est toujours la même : relancez l'outil sans confirmer pour obtenir un nouvel aperçu et un nouveau jeton.

Mesure B — Paramètres par défaut du test de simulation

Les outils d'écriture sont configurés par défaut en mode aperçu. Un outil d'écriture ne modifie pas les données à moins que l'appelant ne choisisse explicitement de lancer l'exécution. Cela permet d'éviter qu'un client IA n'exécute une mutation qu'il avait uniquement l'intention d'inspecter.

Les outils d'écriture se présentent sous deux formes :

Écritures non destructives (9 outils) avoir sur soi un exécuter paramètre. L'outil génère par défaut un aperçu et renvoie une charge utile d'aperçu sans la sauvegarder. En transmettant exécuter : true gère l'opération en temps réel. Ces outils comprennent notamment memberpress_create_member, memberpress_update_member, memberpress_create_coupon, memberpress_create_subscriptionet memberpress_create_webhookentre autres.

Écritures destructrices (6 outils) ne porter ni l'un ni l'autre exécuter ni un paramètre de simulation hérité. Ils s’affichent par défaut en aperçu et nécessitent l’exécution du flux de jetons de confirmation « Measure A ». Le mécanisme à deux appels constitue leur seul moyen d’exécution.

Cette distinction permet au lecteur de déterminer le niveau de risque d'un outil à partir de ses paramètres. Un outil avec exécuter est réversible ; un outil qui n'a pas exécuter et l'obligation de confirmation est néfaste.

Remarque : Ce document décrit le point de terminaison MCP (/wp-json/mp-mcp/v1/mcp). Les outils d'écriture sur le point de terminaison MCP n'exposent pas de simulation paramètre. Les outils non destructifs utilisent exécuter; les outils destructeurs utilisent le flux de jetons de confirmation. Il n'existe aucun autre moyen d'effectuer une écriture via MCP. L'interface « Capacités » de WordPress permet d'effectuer les mêmes opérations selon un mécanisme différent — voir Les possibilités de WordPress se révèlent ci-dessous.

La forme de prévisualisation non destructive

Un outil d'écriture non destructif appelé « sans » exécuter : true renvoie une charge utile d'aperçu au format plat. Voici la réponse obtenue à partir d'un memberpress_create_member appel de prévisualisation :

{
  "dry_run" : true,
  "action" : "create_member",
  "preview" : {
    "email" : "mcp-preview-test@example.com",
    "username": "mcppreviewtest",
    "first_name": "MCP",
    "last_name": "PreviewTest"
  },
  "validation": "passed"
}

Cette enveloppe est plate : simulation, action, aperçuet validation se trouve au niveau supérieur, et il n'y a pas de jeton de confirmation. Cela diffère d'un aperçu destructif, où le aperçu l'objet est imbriqué un niveau plus bas (aperçu.aperçu) et un jeton_de_confirmation est présent. Le validation Ce champ indique si la saisie prévisualisée serait validée lors de l'exécution.

Mesure C — Champs d'application détaillés

Les jetons de connexion sont associés à des périmètres d'accès spécifiques plutôt qu'à un accès illimité. Un jeton dont le périmètre d'accès est limité à la lecture des membres ne permet pas d'écrire des données de facturation. Cela limite la portée d'une connexion donnée aux seules opérations autorisées par son périmètre d'accès.

Vocabulaire relatif au champ d'application

Le serveur MCP définit les portées suivantes dans ScopeMatcher:

Champ d'applicationSubventions
lireAccès en lecture à toutes les données via des outils de lecture
écrire : contenuDroit d'écriture sur le contenu : règles d'accès et coupons
écrire : membresAccès en écriture aux membres
écrire : facturationDroit d'écriture sur la facturation : gestion des abonnements et remboursements des transactions
écrire : importationsAccès en écriture aux importations de membres
écrire : webhooksDroit d'écriture sur les webhooks et les rappels par e-mail
écrire : coursAccès en écriture aux opérations liées aux cours
completToutes les portées d'écriture (répond à toute condition spécifique écrire :* (condition)

Les lire La portée est implicite pour chaque jeton. Le serveur compare la portée requise par un outil aux portées accordées au jeton avant la distribution via Server::current_token_has_scope.

La portée n'est pas le seul critère. Chaque outil de rédaction déclare également la capacité WordPress dont il a besoin (par exemple, create_users ou modifier_utilisateurs), et le serveur vérifie cette capacité avant l'envoi. Un jeton avec complet Le scope ne peut toujours pas créer d'utilisateurs si le propriétaire du jeton ne dispose pas de l'autorisation create_users capacité. Les deux portes renvoient des erreurs distinctes, et la porte de portée s'exécute en premier : une portée manquante entraîne une erreur avec SCOPE_INSUFFISANT; une fonctionnalité manquante entraîne un échec avec CAPACITÉ_INSUFFISANTE.

Plafond d'accès par défaut

Le plafond d'accès par défaut limite les portées que le serveur peut attribuer à une nouvelle connexion. Un administrateur le configure via le fichier “ Niveau d'accès maximal pour les nouvelles connexions ” réglage sur le Paramètres MCP onglet. Ce plafond détermine la portée maximale de tout nouveau jeton, quelle que soit la requête du client qui s'y connecte.

Ce paramètre propose deux options : Lecture seule et Accès complet.

Lorsqu'il est réglé sur Lecture seule, l'assistant masque complètement les cases à cocher relatives à la portée d'écriture — elles n'apparaissent pas en gris — et le serveur limite chaque nouvelle connexion à la portée de lecture. L'étape « Accès » de l'assistant n'affiche que la portée de lecture, qui est toujours accordée, accompagnée de la remarque suivante :

L'administrateur du site a défini le niveau d'accès maximal sur « Lecture seule ». Aucune nouvelle connexion ne pourra disposer de droits d'écriture tant que ce niveau n'aura pas été relevé dans les paramètres MCP.

Lorsqu'il est réglé sur Accès complet, l'étape « Accès » de l'assistant affiche les cases à cocher relatives aux droits d'écriture, qui sont cochées par défaut, et l'administrateur décoche celles dont une connexion n'a pas besoin. Une nouvelle connexion se voit alors attribuer des droits d'écriture à hauteur de ce que permettent les capacités WordPress de l'utilisateur qui se connecte.

La limite est appliquée côté serveur au niveau des quatre voies d'émission de jetons. Une requête personnalisée ne peut pas contourner l'interface de l'assistant pour demander une portée plus large :

  1. Création d'un jeton d'assistant ;
  2. OAuth /autoriser;
  3. OAuth /token échange ;
  4. Enregistrement dynamique des clients (RFC 7591).

Important : Le plafond s'applique uniquement au moment de l'émission. Le resserrement du plafond n'affecte pas la portée des jetons déjà émis. Pour restreindre la portée d'une connexion existante, il convient de la révoquer et d'en émettre une nouvelle.

Le plafond constitue une extension du vocabulaire des portées, et non un mécanisme distinct. Il n'existe que parce que la mesure C définit les portées auxquelles il s'applique.

Mesure D — « Kill Switch »

Le « kill switch » permet à un administrateur d'interrompre instantanément toute opération d'écriture destructive. Lorsqu'il est activé, le serveur rejette tout appel à un outil destructeur et renvoie le ÉCRITURE_SUSPENDUE erreur, quels que soient les champs d'application du jeton d'appel ou l'existence d'un jeton de confirmation valide.

Un administrateur bascule l'interrupteur de la position Clients connectés à MCP page d'administration. Le contrôle est un Suspendre toutes les opérations d'écriture bouton. Tant que les écritures destructives sont actives, la page affiche cet état :

Les opérations d'écriture destructrices sont actives — Les remboursements, annulations, suppressions et importations en masse sont suspendus pour tous les clients connectés. Les outils de lecture continuent de fonctionner.

Ce paramètre est conservé lors des sauvegardes régulières des paramètres ; ainsi, une mise à jour de routine des paramètres ne le désactive pas sans avertissement. Le serveur enregistre admin.writes_paused et admin.writes_resumed enregistre les événements dans le journal d'audit lorsque le commutateur change d'état.

Le « kill switch » est la mesure la plus radicale. Les mesures A, B et C limitent certaines opérations spécifiques ; le « kill switch », quant à lui, les annule toutes d'un seul coup en cas d'appels destructeurs. C'est la réponse appropriée lorsqu'un administrateur soupçonne qu'une connexion se comporte de manière inhabituelle et souhaite mettre fin à toute activité destructrice avant de mener une enquête.

Remarque : Le « kill switch » suspend uniquement les écritures destructives. Les outils de lecture et les aperçus d'écriture non destructifs continuent de fonctionner tant qu'il est actif.

La réponse WRITES_PAUSED

Tant que le « kill switch » est actif, tout appel à un outil destructeur échoue avec cette réponse, quels que soient les champs d'application du jeton appelant ou l'existence d'un jeton de confirmation valide :

{
  "code" : -32603,
  "message" : "Les écritures destructives ont été suspendues par un administrateur. Veuillez réessayer plus tard ou contacter le propriétaire du site.",
  "data": {
    "mp_error_code": "WRITES_PAUSED"
  },
  "request_id": "req_"
}

Ce commutateur contrôle l'ensemble du chemin d'écriture destructive : même le premier appel (aperçu) d'un outil destructif renvoie ÉCRITURE_SUSPENDUE, ce qui empêche le processus de confirmation de démarrer. Comme pour toutes les erreurs liées aux outils, il faut vérifier la correspondance avec data.mp_error_code (ÉCRITURE_SUSPENDUE), et non le générique -32603.

Les possibilités de WordPress se révèlent

À partir de WordPress 6.9, AI Foundation enregistre également des outils via l’API WordPress Abilities, accessible par l’intermédiaire de l’adaptateur MCP de WordPress.org. Il s’agit d’une deuxième interface de programmation qui donne accès aux mêmes opérations sous-jacentes que le point de terminaison MCP, avec trois différences techniques :

  • Commande d'aperçu. Les opérations d'écriture sur la surface « Abilities » exposent un simulation paramètre : l'aperçu est activé par défaut, et l'appelant transmet dry_run : false pour une exécution en direct — où le point de terminaison MCP utilise exécuter : true au lieu de cela ;
  • Écriture dans la porte. L'accès en écriture via l'interface « Abilities » est soumis à des restrictions sur le mpai_use_mcp_write capacité ;
  • Couverture. La surface répertorie les familles d'outils principales ; les surfaces d'outils complémentaires ne sont accessibles que via MCP.

Le modèle de sécurité reste inchangé : la surface impose les mêmes exigences en matière de capacités WordPress par outil, les opérations destructrices nécessitent le même processus de jeton de confirmation (y compris la même exemption pour les actions réversibles), et le « kill switch » suspend les écritures destructrices des capacités de la même manière qu’il suspend les écritures MCP. Le fait d’accéder à ces opérations via un protocole différent n’assouplit en rien ces contraintes.

Journal d'activité

Le journal d'activité consigne les événements liés à l'outil MCP à des fins d'audit et de dépannage. Il se trouve dans le Clients connectés à MCP onglet et présente chaque événement sous forme de tableau à quatre colonnes : Temps, Client, Outilet Résultat. Les Résultat Cette colonne indique le code de résultat enregistré pour chaque appel — succès, erreur, confirmation_requise, confirmation_non_valide, confirmation_course_perdue, scope_insuffisant, capacité_insuffisante, écriture_suspendue, ainsi qu'une petite série de codes d'erreur liés à la prévisualisation et à l'encodage.

Le journal permet de garantir la traçabilité du processus de confirmation des opérations destructrices : journaux des appels de prévisualisation d'un outil destructeur confirmation_requise, ainsi que ses journaux d'exécution succès — ces deux appels sont distincts. L'aperçu et l'exécution en temps réel d'un outil non destructif génèrent tous deux des journaux succès; les arguments des appels ne sont délibérément jamais consignés dans le journal ; ainsi, celui-ci n'indique pas si exécuter a été adoptée. La durée de conservation des données est régie par la Conservation des journaux réglage sur le Paramètres MCP onglet (par défaut 30 jours).

Remarque sur le comportement des clients IA

Certains clients MCP effectuent automatiquement le processus de confirmation en deux appels sans afficher l'étape de confirmation à l'utilisateur. Un client peut afficher un aperçu, puis effectuer le deuxième appel en interne, de sorte que l'opération semble s'exécuter en une seule étape. Il s'agit d'un comportement du flux de travail côté client, et non d'une faille dans la couche de sécurité. Le serveur continue d'imposer l'exigence des deux appels, et le client fournit un jeton valide lors du deuxième appel.

Pour observer directement la porte de confirmation, utilisez un outil qui envoie chaque requête de manière explicite, tel que Postman ou boucle. Un client qui abstrait le flux masque ces deux appels, mais le serveur a toujours besoin des deux.

Cet article a-t-il été utile ?

Articles connexes

fille de l'ordinateur

Achetez MemberPress dès aujourd'hui !

Commencez à être payé pour le contenu que vous créez.