{"id":81432,"date":"2026-07-14T12:09:29","date_gmt":"2026-07-14T16:09:29","guid":{"rendered":"https:\/\/memberpress.com\/docs\/ai-foundation-safety-measures\/"},"modified":"2026-07-14T12:09:29","modified_gmt":"2026-07-14T16:09:29","slug":"ai-foundation-safety-measures","status":"publish","type":"ht_kb","link":"https:\/\/memberpress.com\/fr\/docs\/ai-foundation-safety-measures\/","title":{"rendered":"Mesures de s\u00e9curit\u00e9 relatives aux agents de la plateforme MemberPress AI Foundation"},"content":{"rendered":"

MemberPress AI Foundation enforces four safety measures on Model Context Protocol (MCP) write operations. These measures protect a site from unintended or unauthorized changes when an AI client connects through the MCP server. They operate together. A single write call can pass through scope checks, preview defaults, a confirmation gate, and the kill switch before it changes data.<\/p>\n\n\n\n

This reference explains each measure, what it protects against, and how the MCP server enforces it. Two measures act when an AI client calls a tool: confirmation tokens and dry-run defaults. One measure governs what scope vocabulary a connection token carries: granular scopes. One measure lets an administrator halt every destructive write instantly: the kill switch.<\/p>\n\n\n\n

How the Safety Layer Works<\/a><\/h2>\n\n\n\n

The four measures map to four distinct questions about a write operation:<\/p>\n\n\n\n

Mesure<\/th>Nom<\/th>The question it answers<\/th><\/tr><\/thead>
A<\/td>Confirmation tokens<\/td>What may a token DO when a destructive tool runs?<\/td><\/tr>
B<\/td>Dry-run defaults<\/td>What mode does a write tool default to when called?<\/td><\/tr>
C<\/td>Granular scopes<\/td>What scope vocabulary does a connection token carry?<\/td><\/tr>
D<\/td>Kill switch<\/td>Can an administrator halt every destructive write at once?<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Measures A, B, and D act at tool-call time. The MCP server evaluates them inside Server::handle_tool_call<\/code><\/strong> on every write request. Measure C acts in two places. At tool-call time, the server matches a tool's required scope against the token's granted scopes. At token-issuance time, the default access ceiling caps what scopes a new connection receives.<\/p>\n\n\n\n

All four measures live in the MemberPressAI\\MCP<\/code><\/strong> namespace and run server-side. An AI client cannot bypass them by crafting a request differently, because enforcement happens after the request reaches the server, not in the client.<\/p>\n\n\n\n

Measure A \u2014 Confirmation Tokens<\/a><\/h2>\n\n\n\n

Confirmation tokens protect destructive operations with a mandatory two-call flow. A destructive tool cannot run on a single call. The first call returns a preview plus a single-use token; the second call must include that token to execute.<\/p>\n\n\n\n

One narrow exemption applies: reversible actions skip the gate.<\/strong> memberpress_g\u00e9rer_l'abonnement<\/code> avec action : \" reprendre \"<\/code> et memberpress_g\u00e9rer_compte_secondaire<\/code> avec action : \" ajouter \"<\/code> undo rather than destroy, and execute without a token. A single shared allowlist drives the exemption on both the MCP endpoint and the WordPress Abilities surface, so the two gates cannot drift apart. Every other destructive call requires the token.<\/p>\n\n\n\n

Six tools are destructive and require this flow:<\/p>\n\n\n\n

Outil<\/th>What it does<\/th><\/tr><\/thead>
memberpress_delete_member<\/code><\/strong><\/td>Deletes a member<\/td><\/tr>
memberpress_remboursement_transaction<\/code><\/strong><\/td>Refunds a transaction<\/td><\/tr>
memberpress_delete_webhook<\/code><\/strong><\/td>Deletes a webhook<\/td><\/tr>
memberpress_reset_course_progress<\/code><\/strong><\/td>Resets a learner's course progress<\/td><\/tr>
memberpress_g\u00e9rer_compte_secondaire<\/code><\/strong><\/td>Manages a corporate sub-account<\/td><\/tr>
memberpress_g\u00e9rer_l'abonnement<\/code><\/strong><\/td>Manages a subscription<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

How the Two-Call Flow Works<\/a><\/h3>\n\n\n\n
    \n
  1. The AI client calls the destructive tool with its arguments. The server returns a preview of the effect plus a confirmation token.<\/li>\n\n\n\n
  2. The AI client calls the same tool again with the same arguments plus a confirmer<\/code><\/strong> parameter set to the token value. The server verifies the token and executes the operation.<\/li>\n<\/ol>\n\n\n\n

    The token carries three protections. It expires after 60 seconds<\/strong> (the TTL<\/code><\/strong> constant in ConfirmationTokens<\/code><\/strong>). It is single-use \u2014 the server consumes it on the executing call. The server binds it to the exact combination of tool name, arguments, and user ID. A token issued for one operation cannot authorize a different one.<\/p>\n\n\n\n

    The design rationale, from the development team: \u201cjust passing a boolean isn't strong enough consent for an action you can't undo.\u201d A confirmation token proves the caller saw the specific preview for the specific operation before committing to it.<\/p>\n\n\n\n

    Important :<\/strong> Destructive tools do not accept an ex\u00e9cuter<\/code><\/strong> parameter. The confirmation token flow is the only way to run them. Passing ex\u00e9cuter : true<\/code><\/strong> has no effect on a destructive tool.<\/p>\n\n\n\n

    The First-Call Response<\/a><\/h3>\n\n\n\n

    The first call returns a preview of the effect, a single-use jeton_de_confirmation<\/code><\/strong>, and the token's remaining lifetime. The following is the response from a memberpress_remboursement_transaction<\/code><\/strong> preview call:<\/p>\n\n\n\n

    {\n  \"preview\": {\n    \"dry_run\": true,\n    \"action\": \"refund_transaction\",\n    \"preview\": {\n      \"transaction_id\": 432,\n      \"amount\": \"100.00\",\n      \"total\": \"100.00\",\n      \"user_id\": \"\",\n      \"product_id\": 2332,\n      \"subscription_listing_may_show_inactive\": true,\n      \"subscription_listing_note\": \"If this was the latest transaction backing the subscription, the WP admin Subscriptions list will show the subscription as \\\"Active: No\\\" \u2014 that column is derived from the latest transaction's status, not the subscription record itself. The subscription record is unchanged unless you chose to cancel the subscription as part of this refund.\"\n    }\n  },\n  \"confirmation_token\": \"ct_\",\n  \"expires_in\": 60,\n  \"next_step\": \"Call memberpress_refund_transaction again with the same arguments plus confirm: \\\"ct_\\\" to execute.\"\n}<\/code><\/pre>\n\n\n\n
    The token arrives in jeton_de_confirmation<\/code><\/strong>. Les expires_in<\/code><\/strong> field gives the remaining lifetime in seconds. The next_step<\/code><\/strong> field states exactly how to execute. The inner preview.preview<\/code><\/strong> object describes the operation's effect; its fields vary by tool. The subscription_listing_*<\/code><\/strong> fields shown here are refund-specific \u2014 the Tools Reference and Errors documents cover refund response detail.<\/p>\n\n\n\n
    When a Token Is Invalid<\/a><\/h3>\n\n\n\n
    A token that has expired, has already been used, or is presented with changed arguments fails with a single error. The server does not distinguish the three causes:<\/p>\n\n\n\n
    {\n  \"code\": -32603,\n  \"message\": \"Confirmation token is invalid, expired, or arguments have changed. Call the tool without `confirm` to receive a fresh preview and token.\",\n  \"data\": {\n    \"mp_error_code\": \"CONFIRMATION_INVALID\"\n  },\n  \"request_id\": \"req_\"\n}<\/code><\/pre>\n\n\n\n
    Match on data.mp_error_code<\/code><\/strong> (CONFIRMATION_INVALID<\/code><\/strong>), not the generic JSON-RPC -32603<\/code><\/strong> code. The recovery path is always the same: call the tool again without confirmer<\/code><\/strong> to receive a fresh preview and a new token.<\/p>\n\n\n\n
    Measure B \u2014 Dry-Run Defaults<\/a><\/h2>\n\n\n\n
    Write tools default to preview. A write tool does not change data unless the caller explicitly opts in to execute. This protects against an AI client running a mutation it only intended to inspect.<\/p>\n\n\n\n
    Write tools fall into two shapes:<\/p>\n\n\n\n
    Non-destructive writes (9 tools)<\/strong> carry an ex\u00e9cuter<\/code><\/strong> parameter. The tool previews by default and returns a preview payload without persisting. Passing ex\u00e9cuter : true<\/code><\/strong> runs the operation live. These tools include memberpress_create_member<\/code><\/strong>, memberpress_update_member<\/code><\/strong>, memberpress_create_coupon<\/code><\/strong>, memberpress_create_subscription<\/code><\/strong>et memberpress_create_webhook<\/code><\/strong>entre autres.<\/p>\n\n\n\n
    Destructive writes (6 tools)<\/strong> carry neither ex\u00e9cuter<\/code><\/strong> nor a legacy dry-run parameter. They preview by default and require the Measure A confirmation token flow to execute. The two-call gate is their only execute mechanism.<\/p>\n\n\n\n
    This split means a reader can tell a tool's risk level from its parameters. A tool with ex\u00e9cuter<\/code><\/strong> is reversible; a tool with no ex\u00e9cuter<\/code><\/strong> and a confirmation requirement is destructive.<\/p>\n\n\n\n
    Remarque :<\/strong> This document describes the MCP endpoint (\/wp-json\/mp-mcp\/v1\/mcp<\/code>). Write tools on the MCP endpoint do not expose a dry_run<\/code><\/strong> parameter. Non-destructive tools use ex\u00e9cuter<\/code><\/strong>; destructive tools use the confirmation token flow. There is no other way to run a write through MCP. The WordPress Abilities surface reaches the same operations with different mechanics \u2014 see The WordPress Abilities Surface<\/a><\/strong> ci-dessous.<\/p>\n\n\n\n
    The Non-Destructive Preview Shape<\/a><\/h3>\n\n\n\n
    A non-destructive write tool called without ex\u00e9cuter : true<\/code><\/strong> returns a flat preview payload. The following is the response from a memberpress_create_member<\/code><\/strong> preview call:<\/p>\n\n\n\n
    {\n  \"dry_run\": true,\n  \"action\": \"create_member\",\n  \"preview\": {\n    \"email\": \"mcp-preview-test@example.com\",\n    \"username\": \"mcppreviewtest\",\n    \"first_name\": \"MCP\",\n    \"last_name\": \"PreviewTest\"\n  },\n  \"validation\": \"passed\"\n}<\/code><\/pre>\n\n\n\n
    This envelope is flat: dry_run<\/code><\/strong>, action<\/code><\/strong>, aper\u00e7u<\/code><\/strong>et validation<\/code><\/strong> sit at the top level, and there is no confirmation token. It differs from a destructive preview, where the aper\u00e7u<\/code><\/strong> object is nested one level deeper (preview.preview<\/code><\/strong>) and a jeton_de_confirmation<\/code><\/strong> is present. The validation<\/code><\/strong> field reports whether the previewed input would pass validation on execute.<\/p>\n\n\n\n
    Measure C \u2014 Granular Scopes<\/a><\/h2>\n\n\n\n
    Connection tokens carry specific scopes rather than blanket access. A token scoped to read members cannot write billing data. This limits the blast radius of any single connection to exactly the operations its scopes permit.<\/p>\n\n\n\n
    Scope Vocabulary<\/a><\/h3>\n\n\n\n
    The MCP server defines the following scopes in ScopeMatcher<\/code><\/strong>:<\/p>\n\n\n\n
    Champ d'application<\/th>Subventions<\/th><\/tr><\/thead>
    lire<\/code><\/strong><\/td>Read access to all data through read tools<\/td><\/tr>
    \u00e9crire : contenu<\/code><\/strong><\/td>Write access to content: access rules and coupons<\/td><\/tr>
    \u00e9crire : membres<\/code><\/strong><\/td>Write access to members<\/td><\/tr>
    \u00e9crire : facturation<\/code><\/strong><\/td>Write access to billing: subscription management and transaction refunds<\/td><\/tr>
    \u00e9crire : importations<\/code><\/strong><\/td>Write access to member imports<\/td><\/tr>
    \u00e9crire : webhooks<\/code><\/strong><\/td>Write access to webhooks and email reminders<\/td><\/tr>
    \u00e9crire : cours<\/code><\/strong><\/td>Write access to course operations<\/td><\/tr>
    complet<\/code><\/strong><\/td>All write scopes (satisfies any specific \u00e9crire :*<\/code><\/strong> requirement)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Les lire<\/code><\/strong> scope is implicit on every token. The server matches a tool's required scope against the token's granted scopes before dispatch through Server::current_token_has_scope<\/code><\/strong>.<\/p>\n\n\n\n
    Scope alone is not the only gate. Each write tool also declares the WordPress capability it requires (for example, create_users<\/code><\/strong> ou modifier_utilisateurs<\/code><\/strong>), and the server enforces that capability before dispatch. A token with complet<\/code><\/strong> scope still cannot create users if the token owner lacks the create_users<\/code><\/strong> capability. The two gates return distinct errors, and the scope gate runs first: a missing scope fails with SCOPE_INSUFFISANT<\/code><\/strong>; a missing capability fails with CAPACIT\u00c9_INSUFFISANTE<\/code><\/strong>.<\/p>\n\n\n\n
    Default Access Ceiling<\/a><\/h3>\n\n\n\n
    The default access ceiling caps the scopes the server can issue to a new connection. An administrator sets it through the \u201cMaximum access level for new connections\u201d<\/strong> setting on the MCP Settings<\/strong> tab. The ceiling determines the maximum scope any new token carries, regardless of what the connecting client requests.<\/p>\n\n\n\n
    The setting has two options: Read Only<\/strong> et Full Access<\/strong>.<\/p>\n\n\n\n
    When set to Read Only<\/strong>, the wizard hides the write-scope checkboxes entirely \u2014 they are not shown greyed out \u2014 and the server caps every new connection at read scope. The wizard's Access step shows only the always-granted read scope, with this notice:<\/p>\n\n\n\n
    \n
    Site administrator has set the maximum access level to Read Only. New connections cannot be issued write scopes until this is raised in MCP Settings.<\/p>\n<\/blockquote>\n\n\n\n
    When set to Full Access<\/strong>, the wizard's Access step shows the write-scope checkboxes, pre-checked, and the administrator unchecks any a connection does not need. A new connection then receives write scopes up to what the connecting user's WordPress capabilities allow.<\/p>\n\n\n\n
    The ceiling enforces server-side at four token-issuance paths. A hand-crafted request cannot bypass the wizard interface to request a wider scope:<\/p>\n\n\n\n
      \n
    1. Wizard token creation;<\/li>\n\n\n\n
    2. OAuth \/authorize<\/code><\/strong>;<\/li>\n\n\n\n
    3. OAuth \/token<\/code><\/strong> exchange;<\/li>\n\n\n\n
    4. Dynamic client registration (RFC 7591).<\/li>\n<\/ol>\n\n\n\n
      Important :<\/strong> The ceiling applies at issuance time only. Tightening the ceiling does not narrow scopes on tokens already issued. To narrow an existing connection, revoke it and issue a new one.<\/p>\n\n\n\n
      The ceiling is an extension of the scope vocabulary, not a separate mechanism. It exists only because Measure C defines the scopes it caps.<\/p>\n\n\n\n
      Measure D \u2014 Kill Switch<\/a><\/h2>\n\n\n\n
      The kill switch lets an administrator halt every destructive write instantly. When active, the server refuses every destructive tool call and returns the \u00c9CRITURE_SUSPENDUE<\/code><\/strong> error, regardless of the calling token's scopes or any valid confirmation token.<\/p>\n\n\n\n
      An administrator toggles the switch from the MCP Connected Clients<\/strong> admin page. The control is a Pause all writes<\/strong> button. While destructive writes are active, the page shows this status:<\/p>\n\n\n\n
      \n
      Destructive writes are active \u2014 Pauses refunds, cancellations, deletions, and bulk imports for every connected client. Read tools keep working.<\/p>\n<\/blockquote>\n\n\n\n
      The setting persists across regular settings saves, so a routine settings update does not silently turn it off. The server records admin.writes_paused<\/code><\/strong> et admin.writes_resumed<\/code><\/strong> events to the audit log when the switch changes state.<\/p>\n\n\n\n
      The kill switch is the broadest measure. Measures A, B, and C constrain individual operations; the kill switch overrides all of them for destructive calls in a single action. It is the appropriate response when an administrator suspects a connection is behaving unexpectedly and wants to stop all destructive activity before investigating.<\/p>\n\n\n\n
      Remarque :<\/strong> The kill switch pauses destructive writes only. Read tools and non-destructive write previews continue to function while it is active.<\/p>\n\n\n\n
      The WRITES_PAUSED Response<\/a><\/h3>\n\n\n\n
      While the kill switch is active, every destructive tool call fails with this response, regardless of the calling token's scopes or any valid confirmation token:<\/p>\n\n\n\n
      {\n  \"code\": -32603,\n  \"message\": \"Destructive writes are paused by an administrator. Try again later or contact the site owner.\",\n  \"data\": {\n    \"mp_error_code\": \"WRITES_PAUSED\"\n  },\n  \"request_id\": \"req_\"\n}<\/code><\/pre>\n\n\n\n
      The switch gates the entire destructive-write path: even the first (preview) call of a destructive tool returns \u00c9CRITURE_SUSPENDUE<\/code><\/strong>, so the confirmation flow cannot begin. As with all tool errors, match on data.mp_error_code<\/code><\/strong> (\u00c9CRITURE_SUSPENDUE<\/code><\/strong>), not the generic -32603<\/code><\/strong>.<\/p>\n\n\n\n
      Related Capabilities<\/a><\/h2>\n\n\n\n
      The WordPress Abilities Surface<\/a><\/h3>\n\n\n\n
      On WordPress 6.9 and later, AI Foundation also registers tools through the WordPress Abilities API, exposed via the WordPress.org MCP Adapter. This is a second programmatic surface that reaches the same underlying operations as the MCP endpoint, with three mechanical differences:<\/p>\n\n\n\n