WordPress.com-Agent gegen selbst gehostetes WordPress

WordPress.com hat seinen Agentenzugang mit drei Schutzschichten gebaut, die auf dem Server sitzen: OAuth 2.1 statt Anwendungspasswort, jede Fähigkeit standardmäßig aus, Bestätigung vor jeder Änderung. Eine selbst gehostete WordPress-Installation hat keine dieser Schichten von Haus aus. Wer die Ankündigungen von WordPress.com liest und daraus schließt, sein eigenes WordPress sei genauso abgesichert, zieht den falschen Schluss. Dieser Beitrag gehört zur Betriebsanleitung für KI-Agenten in WordPress.

Was WordPress.com in drei Schritten eingeführt hat

Oktober 2025: Der MCP-Server von WordPress.com liefert Agenten lesenden Zugriff auf Statistiken, Einstellungen und Inhalte.
20.03.2026: Schreibender Zugriff. Claude, ChatGPT, Cursor und andere Clients können Beiträge und Seiten entwerfen, veröffentlichen und bearbeiten, in allen bezahlten Tarifen ohne Aufpreis. Nichts ist standardmäßig eingeschaltet; der Betreiber gibt je Site frei, welche Fähigkeiten aktiv sind. Änderungen verlangen eine ausdrückliche Bestätigung, und bei bereits veröffentlichten Inhalten weist der Dienst darauf hin, dass die Änderung sofort live geht.
02.10.2026: Der hauseigene WordPress-Agent verwaltet Plugins, also aktivieren, aktualisieren und installieren aus dem Chat heraus. Gleichzeitig steht ein WordPress.com-Plugin im Marktplatz von Cursor, mit dem Entwickler ihre Sites aus der Entwicklungsumgebung heraus bedienen.

Die drei Schichten im Einzelnen

OAuth 2.1 statt Anwendungspasswort. Der Agent bekommt kein Passwort, sondern ein Token, das der Betreiber in einem Anmeldedialog freigibt. Das Token ist an einen Umfang gebunden, läuft ab und lässt sich an einer Stelle widerrufen. Ein Anwendungspasswort dagegen ist ein Dauerzugang mit allen Rechten des Benutzers, ohne Ablauf und ohne Umfangsbegrenzung. Der offizielle MCP-Adapter für selbst gehostete Seiten arbeitet mit Anwendungspasswörtern; OAuth bringen bislang nur einzelne Drittanbieter-Plugins wie Cowboy MCP über einen eigenen Connector mit.

Opt-in je Fähigkeit. Bei WordPress.com ist alles aus, bis der Betreiber es einschaltet. Beim offiziellen Adapter ist alles an, was ein Plugin als „public“ markiert hat, sobald der Adapter aktiv ist; die Zugangsprüfung am Server ist standardmäßig „angemeldet“. Eine Freigabeliste je Verbindung gibt es erst mit Plugins wie Agent Abilities for MCP oder über einen eigenen Server, den ein Entwickler mit fester Fähigkeitenliste anlegt.

Bestätigung auf dem Server. WordPress.com verlangt sie laut Anbieter vor jeder Änderung. Auf einer selbst gehosteten Seite sitzt die Bestätigung im Client, also in Claude Desktop, Cursor oder dem Werkzeug des Entwicklers. WordPress sieht sie nicht. Ein Agent, der ohne Rückfrage konfiguriert ist, oder ein Text auf einer Webseite, der den Agenten zu einer Aktion drängt, läuft durch. Serverseitige Bestätigung liefern bislang nur einzelne Plugins, etwa Agent Toolbelt mit einmaligen Bestätigungs-Token für riskante Aktionen.

Was Sie bei sich nachbauen müssen

Umfang begrenzen: eigener Benutzer je Agent mit kleinster Rolle, ein Anwendungspasswort je Client. Anleitung im Beitrag zu Anwendungspasswörtern und Rollen.
Opt-in nachrüsten: ein MCP-Plugin mit Freigabeliste oder ein eigener Server mit fester Fähigkeitenliste; den Standardserver des Adapters abschalten, wenn er nicht gebraucht wird.
Bestätigung auf den Server holen: für Wartung ein Plugin mit Probelauf und Token; für Inhalte zumindest ein Nur-Lesen-Schalter, der bis zur ersten Protokollprüfung aktiv bleibt.
Protokoll: Simple History oder das Aufrufprotokoll des MCP-Plugins.
Ablauf erzwingen: Anwendungspasswörter laufen nicht ab, also ein fester Termin alle drei Monate, an dem sie erneuert oder widerrufen werden.

Was WordPress.com nicht löst

Auch dort arbeitet der Agent mit den Rechten des Kontos, das ihn freigegeben hat. Die Bestätigung schützt vor ungewollten Änderungen, nicht vor gewollten, die sich als Fehler herausstellen. Und die Plugin-Verwaltung aus dem Chat heraus hat dieselbe Lücke wie überall: Ein Update, das durchläuft und danach das Layout zerlegt, ist aus Sicht des Systems erfolgreich. Was dagegen hilft, steht im Beitrag zu Plugin-Updates durch Agenten.

Quellen

Kurz beantwortet

Ist der Agentenzugang bei WordPress.com sicherer als bei meinem Hoster?

Die Zugangsschicht ja: OAuth-Token mit Umfang und Ablauf, Opt-in je Fähigkeit, Bestätigung vor Änderungen. Die Rechte des Kontos und die Folgen von Updates sind dort dieselben wie überall.