MemberPress AI Foundation wendet bei Schreibvorgängen im Rahmen des Model Context Protocol (MCP) vier Sicherheitsmaßnahmen an. Diese Maßnahmen schützen eine Instanz vor unbeabsichtigten oder unbefugten Änderungen, wenn sich ein KI-Client über den MCP-Server verbindet. Sie wirken zusammen. Ein einzelner Schreibaufruf durchläuft möglicherweise Bereichsprüfungen, Standardwerte in der Vorschau, eine Bestätigungssperre und den Kill-Switch, bevor er Daten ändert.
In dieser Anleitung werden die einzelnen Maßnahmen erläutert, wovor sie schützen und wie der MCP-Server sie durchsetzt. Zwei Maßnahmen greifen, wenn ein KI-Client ein Tool aufruft: Bestätigungstoken und Dry-Run-Standardwerte. Eine Maßnahme regelt, welches Bereichsvokabular ein Verbindungstoken enthält: granulare Bereiche. Eine Maßnahme ermöglicht es einem Administrator, jeden schädlichen Schreibvorgang sofort zu stoppen: der Kill-Switch.
So funktioniert die Sicherheitsschicht
Die vier Kennzahlen beziehen sich auf vier unterschiedliche Fragen zu einem Schreibvorgang:
| Maßnahme | Name | Die Frage, die damit beantwortet wird |
|---|---|---|
| A | Bestätigungstoken | Was kann ein Token tun, wenn ein destruktives Tool ausgeführt wird? |
| B | Standardwerte für Testläufe | In welchem Modus wird ein Schreibwerkzeug standardmäßig aufgerufen? |
| C | Detaillierte Geltungsbereiche | Welchen Geltungsbereich hat das Vokabular eines Verbindungstokens? |
| D | Not-Aus-Schalter | Kann ein Administrator jeden schädlichen Schreibvorgang sofort unterbinden? |
Die Maßnahmen A, B und D werden zum Zeitpunkt des Tool-Aufrufs ausgeführt. Der MCP-Server wertet sie innerhalb von Server::handle_tool_call bei jeder Schreibanforderung. Maßnahme C greift an zwei Stellen ein. Zum Zeitpunkt des Tool-Aufrufs gleicht der Server den vom Tool benötigten Geltungsbereich mit den durch das Token gewährten Geltungsbereichen ab. Zum Zeitpunkt der Token-Ausstellung begrenzt die standardmäßige Zugriffsobergrenze, welche Geltungsbereiche eine neue Verbindung erhält.
Alle vier Maßnahmen sind in der MemberPressAI\MCP Namensraum und werden serverseitig ausgeführt. Ein KI-Client kann diese nicht umgehen, indem er eine Anfrage anders formuliert, da die Überprüfung erst erfolgt, nachdem die Anfrage den Server erreicht hat, und nicht bereits auf dem Client.
Maßnahme A – Bestätigungs-Token
Bestätigungstoken schützen destruktive Vorgänge durch einen obligatorischen Ablauf mit zwei Aufrufen. Ein destruktives Tool kann nicht mit einem einzigen Aufruf ausgeführt werden. Der erste Aufruf gibt eine Vorschau sowie ein Einmal-Token zurück; der zweite Aufruf muss dieses Token enthalten, um ausgeführt zu werden.
Es gibt eine einzige, eng gefasste Ausnahme: Umkehrbare Aktionen überspringen das Tor. memberpress_manage_subscription mit Aktion: "Fortsetzen" und memberpress_manage_sub_account mit Aktion: "Hinzufügen" Rückgängig machen statt löschen, und ohne Token ausführen. Eine einzige gemeinsame Zulassungsliste regelt die Ausnahmeregelung sowohl auf dem MCP-Endpunkt als auch auf der WordPress-Funktionsoberfläche, sodass die beiden Kontrollpunkte nicht auseinanderdriften können. Jeder andere destruktive Aufruf erfordert das Token.
Sechs Werkzeuge sind destruktiv und erfordern diesen Ablauf:
| Werkzeug | Was es bewirkt |
|---|---|
memberpress_delete_member | Löscht ein Mitglied |
memberpress_refund_transaction | Storniert eine Transaktion |
memberpress_delete_webhook | Löscht einen Webhook |
memberpress_reset_course_progress | Setzt den Kursfortschritt eines Teilnehmers zurück |
memberpress_manage_sub_account | Verwaltet ein Unterkonto des Unternehmens |
memberpress_manage_subscription | Verwaltet ein Abonnement |
So funktioniert der „Two-Call“-Ablauf
- Der KI-Client ruft das Löschwerkzeug mit seinen Argumenten auf. Der Server gibt eine Vorschau des Ergebnisses sowie ein Bestätigungstoken zurück.
- Der KI-Client ruft dasselbe Tool erneut mit denselben Argumenten sowie einem
bestätigen.Der Parameter wird auf den Wert des Tokens gesetzt. Der Server überprüft das Token und führt den Vorgang aus.
Das Token verfügt über drei Schutzmaßnahmen. Es läuft nach 60 Sekunden (das TTL Konstante in Bestätigungstoken). Es handelt sich um ein Einmal-Token – der Server verbraucht es bei der Ausführung des Aufrufs. Der Server bindet es an die genaue Kombination aus Tool-Name, Argumenten und Benutzer-ID. Ein für einen Vorgang ausgegebenes Token kann keinen anderen Vorgang autorisieren.
Die Begründung des Entwicklungsteams für dieses Design lautet: “Die bloße Übergabe eines booleschen Werts reicht als Einwilligung für eine Aktion, die nicht rückgängig gemacht werden kann, nicht aus.” Ein Bestätigungstoken belegt, dass der Aufrufer die spezifische Vorschau für den jeweiligen Vorgang gesehen hat, bevor er diesen bestätigt hat.
Die Erstreaktion
Der erste Aufruf liefert eine Vorschau des Effekts, die nur einmal verwendet werden kann Bestätigungs-Token, sowie die verbleibende Gültigkeitsdauer des Tokens. Im Folgenden finden Sie die Antwort von einem memberpress_refund_transaction Vorschau-Anruf:
{
"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": "Wenn dies die letzte Transaktion war, auf der das Abonnement basierte, wird das Abonnement in der WP-Admin-Liste "Abonnements" als \"Aktiv: Nein\" angezeigt – diese Spalte leitet sich vom Status der letzten Transaktion ab, nicht vom Abonnementdatensatz selbst. Der Abonnementdatensatz bleibt unverändert, es sei denn, Sie haben im Rahmen dieser Rückerstattung die Kündigung des Abonnements gewählt."
}
},
"confirmation_token": "ct_",
"expires_in": 60,
"next_step": "Rufen Sie `memberpress_refund_transaction` erneut mit denselben Argumenten sowie dem Parameter `confirm: \"ct_\"` auf, um den Vorgang auszuführen."
}
Das Token kommt in Bestätigungs-Token. Die expires_in Das Feld gibt die verbleibende Lebensdauer in Sekunden an. Das nächster_Schritt Das Feld gibt genau vor, wie die Ausführung erfolgen soll. Das innere Vorschau.Vorschau Das Objekt beschreibt die Wirkung der Operation; seine Felder variieren je nach Werkzeug. Das Abonnement_Angebot_* Die hier angezeigten Felder beziehen sich speziell auf Rückerstattungen – Einzelheiten zu Rückerstattungsantworten finden Sie in den Dokumenten „Tools-Referenz“ und „Fehler“.
Wenn ein Token ungültig ist
Ein Token, dessen Gültigkeit abgelaufen ist, das bereits verwendet wurde oder das mit geänderten Argumenten übermittelt wird, führt zu einem einzigen Fehler. Der Server unterscheidet nicht zwischen diesen drei Ursachen:
{
"code": -32603,
"message": "Das Bestätigungstoken ist ungültig, abgelaufen oder die Argumente haben sich geändert. Rufen Sie das Tool ohne `confirm` auf, um eine neue Vorschau und ein neues Token zu erhalten.",
"data": {
"mp_error_code": "CONFIRMATION_INVALID"
},
"request_id": "req_"
}
Spiel am data.mp_error_code (BESTÄTIGUNG_UNGÜLTIG), nicht das generische JSON-RPC -32603 Code. Der Wiederherstellungspfad ist immer derselbe: Rufen Sie das Tool erneut auf, ohne bestätigen. um eine aktuelle Vorschau und ein neues Token zu erhalten.
Maßnahme B – Standardwerte für Testläufe
Schreibwerkzeuge sind standardmäßig auf „Vorschau“ eingestellt. Ein Schreibwerkzeug ändert keine Daten, es sei denn, der Aufrufer gibt ausdrücklich die Zustimmung zur Ausführung. Dies schützt davor, dass ein KI-Client eine Änderung durchführt, die eigentlich nur zur Überprüfung gedacht war.
Schreibwerkzeuge lassen sich in zwei Formen unterteilen:
Zerstörungsfreie Schreibvorgänge (9 Werkzeuge) mit sich führen ausführen Parameter. Das Tool zeigt standardmäßig eine Vorschau an und gibt eine Vorschau-Nutzlast zurück, ohne diese dauerhaft zu speichern. Die Übergabe von ausführen: true leitet den Betrieb in Echtzeit. Zu diesen Tools gehören memberpress_create_member, memberpress_update_member, memberpress_create_coupon, memberpress_create_subscriptionund memberpress_create_webhookund andere.
Destruktive Schreibvorgänge (6 Werkzeuge) keines von beiden mit sich führen ausführen noch einen veralteten Testparameter. Sie werden standardmäßig in der Vorschau angezeigt und erfordern die Ausführung des Bestätigungs-Token-Ablaufflusses nach „Measure A“. Der Zwei-Aufruf-Gate ist ihr einziger Ausführungsmechanismus.
Durch diese Unterteilung kann ein Leser das Risikoniveau eines Tools anhand seiner Parameter erkennen. Ein Tool mit ausführen ist reversibel; ein Werkzeug ohne ausführen und eine Bestätigungsanforderung ist kontraproduktiv.
Die Form der zerstörungsfreien Vorschau
Ein nicht-destruktives Schreibwerkzeug, das ohne ausführen: true gibt eine flache Vorschau-Nutzlast zurück. Im Folgenden finden Sie die Antwort von einem memberpress_create_member Vorschau-Anruf:
{
"dry_run": true,
"action": "create_member",
"preview": {
"email": "mcp-preview-test@example.com",
"username": "mcppreviewtest",
"first_name": "MCP",
"last_name": "PreviewTest"
},
"validation": "passed"
}
Dieser Umschlag ist flach: Trockenlauf, Aktion, Vorschauund Validierung befindet sich auf der obersten Ebene, und es gibt kein Bestätigungstoken. Dies unterscheidet sich von einer destruktiven Vorschau, bei der die Vorschau Das Objekt ist eine Ebene tiefer verschachtelt (Vorschau.Vorschau) und ein Bestätigungs-Token ist vorhanden. Das Validierung Das Feld gibt an, ob die in der Vorschau angezeigte Eingabe bei der Ausführung die Validierung bestehen würde.
Maßnahme C – Detaillierte Anwendungsbereiche
Verbindungstoken verfügen über bestimmte Gültigkeitsbereiche und gewähren keinen pauschalen Zugriff. Ein Token, dessen Gültigkeitsbereich auf das Lesen von Mitgliedern beschränkt ist, kann keine Abrechnungsdaten schreiben. Dadurch wird der Wirkungsbereich einer einzelnen Verbindung genau auf die Vorgänge beschränkt, die im Rahmen ihres Gültigkeitsbereichs zulässig sind.
Begriffsbestand zum Thema „Scope“
Der MCP-Server definiert die folgenden Bereiche in ScopeMatcher:
| Umfang | Zuschüsse |
|---|---|
lesen | Lesezugriff auf alle Daten über Lesetools |
write:content | Schreibzugriff auf Inhalte: Zugriffsregeln und Gutscheine |
Schreibe: Mitglieder | Schreibzugriff auf Elemente |
Schreiben: Rechnungsstellung | Schreibzugriff auf die Abrechnung: Abonnementverwaltung und Rückerstattungen von Transaktionen |
write:imports | Schreibzugriff auf Member-Importe |
Schreiben: Webhooks | Schreibzugriff auf Webhooks und E-Mail-Erinnerungen |
Schreiben: Kurse | Schreibzugriff auf Kursfunktionen |
vollständig | Alle Schreibbereiche (erfüllen eine beliebige spezifische schreiben:* Anforderung) |
Die lesen Der Geltungsbereich ist bei jedem Token implizit gegeben. Der Server gleicht den vom Tool benötigten Geltungsbereich vor der Weiterleitung mit den dem Token gewährten Geltungsbereichen ab, und zwar über Server::current_token_has_scope.
Der Geltungsbereich allein ist nicht die einzige Hürde. Jedes Schreib-Tool gibt zudem die WordPress-Fähigkeit an, die es benötigt (zum Beispiel, Benutzer anlegen oder Benutzer bearbeiten), und der Server überprüft diese Berechtigung vor der Weiterleitung. Ein Token mit vollständig Der Bereich kann weiterhin keine Benutzer anlegen, wenn dem Token-Besitzer die Benutzer anlegen Fähigkeit. Die beiden Prüfungen geben unterschiedliche Fehlermeldungen aus, wobei die Scope-Prüfung zuerst ausgeführt wird: Ein fehlender Scope führt zu einem Fehler mit SCOPE_INSUFFICIENT; eine fehlende Funktion führt zu einem Fehler mit FÄHIGKEIT_UNZUREICHEND.
Standard-Zugriffsobergrenze
Die Standard-Zugriffsobergrenze begrenzt den Umfang der Berechtigungen, die der Server für eine neue Verbindung vergeben kann. Ein Administrator legt diese über die “Maximale Zugriffsebene für neue Verbindungen” Einstellung auf der MCP-Einstellungen Registerkarte. Die Obergrenze legt den maximalen Umfang fest, den jedes neue Token abdeckt, unabhängig davon, was der verbundene Client anfordert.
Für diese Einstellung gibt es zwei Optionen: Nur Lesen und Voller Zugriff.
Bei der Einstellung auf Nur Lesen, blendet der Assistent die Kontrollkästchen für den Schreibzugriff vollständig aus – sie werden nicht ausgegraut angezeigt – und der Server beschränkt jede neue Verbindung auf den Lesezugriff. Im Schritt „Zugriff“ des Assistenten wird nur der stets gewährte Lesezugriff angezeigt, zusammen mit folgendem Hinweis:
Der Website-Administrator hat die maximale Zugriffsebene auf „Nur Lesen“ festgelegt. Für neue Verbindungen können keine Schreibberechtigungen vergeben werden, bis diese Einstellung in den MCP-Einstellungen angehoben wird.
Bei der Einstellung auf Voller Zugriff, im Schritt „Zugriff“ des Assistenten werden die Kontrollkästchen für den Schreibbereich angezeigt, die bereits vorab aktiviert sind, und der Administrator deaktiviert diejenigen, die für eine Verbindung nicht erforderlich sind. Eine neue Verbindung erhält dann Schreibrechte in dem Umfang, den die WordPress-Berechtigungen des sich verbindenden Benutzers zulassen.
Die Obergrenze wird serverseitig an vier Pfaden zur Token-Ausstellung durchgesetzt. Eine manuell erstellte Anfrage kann die Assistentenoberfläche nicht umgehen, um einen größeren Geltungsbereich anzufordern:
- Erstellung von Zauberer-Token;
- OAuth
/autorisieren; - OAuth
/tokenAustausch; - Dynamische Client-Registrierung (RFC 7591).
Die Obergrenze ist eine Erweiterung des Geltungsbereichsvokabulars und kein eigenständiger Mechanismus. Sie existiert nur, weil Maßnahme C die Geltungsbereiche definiert, für die sie gilt.
Maßnahme D – Not-Aus-Schalter
Mit dem Kill-Switch kann ein Administrator jeden schädlichen Schreibvorgang sofort unterbinden. Ist er aktiviert, lehnt der Server jeden Aufruf eines schädlichen Tools ab und gibt die WRITES_PAUSED Fehler, unabhängig von den Gültigkeitsbereichen des aufrufenden Tokens oder einem gültigen Bestätigungstoken.
Ein Administrator stellt den Schalter von der Mit MCP verbundene Clients Admin-Seite. Das Steuerelement ist ein Alle Schreibvorgänge anhalten Schaltfläche. Solange destruktive Schreibvorgänge aktiv sind, zeigt die Seite diesen Status an:
Destruktive Schreibvorgänge sind aktiv – Rückerstattungen, Stornierungen, Löschungen und Massenimporte werden für alle verbundenen Clients vorübergehend ausgesetzt. Lese-Tools funktionieren weiterhin.
Die Einstellung bleibt auch nach dem Speichern der regulären Einstellungen erhalten, sodass sie bei einer routinemäßigen Aktualisierung der Einstellungen nicht automatisch deaktiviert wird. Der Server protokolliert admin.writes_paused und admin.writes_resumed Ereignisse im Prüfprotokoll, wenn der Schalter seinen Zustand ändert.
Der Kill-Switch ist die umfassendste Maßnahme. Die Maßnahmen A, B und C schränken einzelne Vorgänge ein; der Kill-Switch hebt sie alle in einem einzigen Schritt bei schädlichen Aufrufen außer Kraft. Er ist die geeignete Reaktion, wenn ein Administrator den Verdacht hat, dass sich eine Verbindung unerwartet verhält, und alle schädlichen Aktivitäten vor der Untersuchung unterbinden möchte.
Die Antwort „WRITES_PAUSED“
Solange der Kill-Switch aktiv ist, schlägt jeder Aufruf eines destruktiven Tools mit dieser Antwort fehl, unabhängig von den Gültigkeitsbereichen des aufrufenden Tokens oder einem etwaigen gültigen Bestätigungstoken:
{
"code": -32603,
"message": "Destruktive Schreibvorgänge wurden von einem Administrator angehalten. Versuchen Sie es später erneut oder wenden Sie sich an den Standortbetreiber.",
"data": {
"mp_error_code": "WRITES_PAUSED"
},
"request_id": "req_"
}
Der Schalter steuert den gesamten Pfad für destruktive Schreibvorgänge: Selbst der erste (Vorschau-)Aufruf eines destruktiven Tools gibt WRITES_PAUSED, sodass der Bestätigungsablauf nicht beginnen kann. Wie bei allen Tool-Fehlern erfolgt der Abgleich anhand von data.mp_error_code (WRITES_PAUSED), nicht die allgemeine -32603.
Verwandte Funktionen
Die Möglichkeiten von WordPress
Ab WordPress 6.9 registriert die AI Foundation Tools auch über die WordPress-Abilities-API, die über den WordPress.org-MCP-Adapter bereitgestellt wird. Dabei handelt es sich um eine zweite programmatische Schnittstelle, die auf dieselben zugrunde liegenden Vorgänge zugreift wie der MCP-Endpunkt, wobei es drei technische Unterschiede gibt:
- Vorschau-Steuerelement. Schreibvorgänge auf der „Abilities“-Oberfläche legen eine
TrockenlaufParameter: Standardmäßig wird eine Vorschau angezeigt, und der Aufrufer übergibtdry_run: falseum live zu laufen – wobei der MCP-Endpunktausführen: truestattdessen; - Schreibgate. Der Schreibzugriff über die „Abilities“-Oberfläche wird über die
mpai_use_mcp_writeFähigkeit; - Umfang. Die Oberfläche erfasst die Kernwerkzeugfamilien; Zusatzwerkzeugoberflächen werden ausschließlich über MCP bereitgestellt.
Das Sicherheitsmodell bleibt unverändert: Die Oberfläche erzwingt dieselben WordPress-Berechtigungsanforderungen pro Tool, destruktive Operationen erfordern denselben Bestätigungs-Token-Ablauf (einschließlich derselben Ausnahme für rückgängig machbare Aktionen), und der Kill-Switch unterbricht das Schreiben destruktiver Fähigkeiten ebenso wie das Schreiben von MCP-Daten. Der Zugriff auf die Operationen über ein anderes Protokoll führt nicht zu einer Lockerung der Sicherheitsvorkehrungen.
Aktivitätsprotokoll
Das Aktivitätsprotokoll erfasst Ereignisse des MCP-Tools zu Prüfungs- und Fehlerbehebungszwecken. Es befindet sich auf dem Mit MCP verbundene Clients Registerkarte und listet jede Veranstaltung in vier Spalten auf: Zeit, Kunde, Werkzeugund Ergebnis. Die Ergebnis Die Spalte zeigt den gespeicherten Ergebniscode für jeden Aufruf an — Erfolg, Fehler, Bestätigung erforderlich, Bestätigung_ungültig, Bestätigung_Rennen_verloren, scope_insufficient, Fähigkeit_unzureichend, Schreiben_unterbrochen, sowie eine kleine Gruppe von Fehlercodes für die Vorschau und die Codierung.
Das Protokoll macht den Ablauf der destruktiven Bestätigung nachvollziehbar: die Aufrufprotokolle der Vorschau eines destruktiven Tools Bestätigung erforderlich, sowie die Ausführungsprotokolle Erfolg — Die beiden Aufrufe lassen sich unterscheiden. Sowohl die Vorschau als auch die Live-Ausführung eines nicht-destruktiven Tools werden protokolliert Erfolg; Aufrufargumente werden bewusst nie protokolliert, sodass im Protokoll nicht festgehalten wird, ob ausführen wurde verabschiedet. Wie lange Einträge aufbewahrt werden, richtet sich nach der Aufbewahrung von Protokollen Einstellung auf der MCP-Einstellungen Registerkarte (Standard 30 Tage).
Ein Hinweis zum Verhalten von KI-Clients
Einige MCP-Clients führen den Bestätigungsablauf mit zwei Aufrufen automatisch durch, ohne den Bestätigungsschritt für den Benutzer sichtbar zu machen. Ein Client kann eine Vorschau anzeigen und den zweiten Aufruf dann intern ausführen, sodass der Vorgang scheinbar in einem Schritt abläuft. Dies ist ein clientseitiges Workflow-Verhalten und stellt keine Lücke in der Sicherheitsschicht dar. Der Server erzwingt weiterhin die Anforderung der zwei Aufrufe, und der Client übermittelt beim zweiten Aufruf ein gültiges Token.
Um das Bestätigungsfenster direkt zu beobachten, verwenden Sie ein Tool, das jeden Aufruf explizit ausführt, wie beispielsweise Postman oder curl. Ein Client, der den Ablauf abstrahiert, verbirgt die beiden Aufrufe, doch der Server benötigt weiterhin beide.
Zugehörige Dokumentation
- MemberPress AI Foundation – Überblick und Einrichtungsanleitung — Was die AI Foundation ist, wie man sie installiert und wie man AI-Clients damit verbindet;
- MemberPress AI Foundation MCP-Tools – Referenz — den vollständigen Werkzeugkatalog, einschließlich der Angabe, welche Werkzeuge zerstörend sind und welchen Anwendungsbereich die einzelnen Werkzeuge erfordern;
- MemberPress AI Foundation MCP – Fehler und Fehlerbehebung — der vollständige Fehlerkatalog, einschließlich
WRITES_PAUSEDundFÄHIGKEIT_UNZUREICHEND; - AI-Clients mit MemberPress verbinden — wie der Server bei der Einrichtung Verbindungen herstellt und Bereiche zuweist.