WPAgently-Dokumentation

Sicherheit, Datenfluss und Lizenzen

Der Verifikations-Layer ist keine pauschale Sicherheitsbehauptung. Er besteht aus konkreten Grenzen, die du hier nachvollziehen kannst.

Safety-Layer

Der Safety-Layer sitzt in der CLI und greift vor und während jeder Pipeline.

  • Bot-nicht-Admin: Vor jeder Pipeline prüft ein Preflight den authentifizierten User (GET /wp/v2/users/me im Editier-Kontext). Trägt er die Rolle administrator oder super_admin, bricht die Engine hart ab, denn ein Zugang mit Administratorrechten wäre im Leak-Fall katastrophal. Fehlt die Editor-Rolle, folgt ein deutlicher Hinweis.
  • Draft-by-default: Alles bleibt Entwurf. --publish und --i-approve drücken nur die gewünschte Freigabe aus. Der aktuelle set-post-status-Writer lehnt den Remote-Statuswechsel mit HTTP 409 und manual_only ab. Veröffentlichung und weitere Statuswechsel erfolgen nach der Prüfung manuell in WordPress.
  • SSRF-Allowlist: Bilder werden nur von öffentlichen http(s)-URLs geholt. Blockiert werden file:// und andere Schemata, localhost, Loopback, Link-Local (inklusive der Cloud-Metadaten-IP 169.254.169.254) und private Netze (RFC 1918, IPv6-ULA). Zusätzlich wird der Host per DNS aufgelöst und jede zurückgegebene IP geprüft (fail-closed); das schützt gegen DNS-Rebinding und Redirects auf interne Ziele.
  • Rate-Limit: Ein Token-Bucket pro Client drosselt ausgehende Requests. Er startet voll (Burst bis 8), danach vier Tokens pro Sekunde; jeder echte HTTP-Request kostet ein Token. Die Drosselung ist rein zeitbasiert, ohne Zufall und ohne Dependencies.
  • Idempotenz: Vor dem Anlegen sucht die Pipeline per Slug (in allen relevanten Status, im Editier-Kontext). Nur kein Treffer erlaubt eine Neuanlage. Genau ein exakter Treffer kann als vorhandenes Ziel dienen. Mehrere oder nicht exakt passende Treffer sind mehrdeutig und führen vor jeder Mutation zum Abbruch. Artikel-Updates sind im aktuellen Companion außerdem manual_only, Landing-Pages folgen der separat deklarierten Update-Semantik von upsert-pattern. Ein stabiler Slug ist deshalb Pflicht.

BYO-Prinzip

Die Zugangsdaten (Site, Bot-User, OAuth-Token oder Application Password) liegen ausschließlich beim Kunden und kommen aus der lokalen Client-Konfiguration oder dem OAuth-Fluss. WordPress speichert widerrufbare OAuth- und Application-Password-Referenzen, aber kein herunterladbares Klartextpasswort. Die CLI speichert den OAuth-Zugang standardmäßig unter ~/.config/wp-agent/credentials.json, alternativ unter dem Pfad aus WP_AGENT_CREDENTIALS_FILE. Auf POSIX-Systemen akzeptiert sie nur ein privates Verzeichnis mit Modus 0700 und eine Datei mit Modus 0600. Die Zugangsdaten werden nicht an WPAgently übertragen. Lizenzaktivierung und tägliche Lizenzprüfung kommunizieren direkt mit Polar. Die Plugins lesen außerdem statische Update-Manifeste und Updatepakete von wpagently.com. Dabei werden keine WordPress-Inhalte oder Zugangsdaten übertragen. Beim optionalen Chat sendet WordPress die Nachricht und die für die Antwort abgerufenen Website-Daten direkt an den vom Kunden konfigurierten KI-Anbieter. WPAgently betreibt dafür keinen Proxy.

Produktions-Hinweis

Die mcp-adapter-Library ist ein Composer-Paket, kein eigenständiges Plugin. Im ursprünglichen Test stammte sie aus einem Host-Plugin (Rank Math bündelt sie). Fürs Produkt bündelt wp-agent-companion die Library inzwischen selbst (vendor/), damit der MCP-Server ohne Fremd-Plugin funktioniert.

Schritt 1: Companion-Plugin installieren (etwa 5 Minuten)

Installiere und aktiviere das Plugin wp-agent-companion auf deiner Seite, genauso wie du jedes andere WordPress-Plugin installierst. „Aktivieren“ heißt: das Plugin im WordPress-Backend einschalten, sodass es zu arbeiten beginnt.

Dieses Companion-Plugin (Companion = Begleiter) ist das Herzstück auf der WordPress-Seite. Es meldet WordPress eine Reihe von „Abilities“ an. Eine Ability ist eine klar abgegrenzte, geprüfte Aktion, die der Assistent ausführen darf, zum Beispiel „einen Beitrag aus Markdown anlegen“. Nach der Aktivierung sind unter anderem diese Abilities angemeldet:

  • wp-agent/create-post-from-markdown (der einzige Writer für neue Artikelinhalte in der verifizierten ARTIKEL-Pipeline; Updates sind derzeit manual_only)
  • wp-agent/upsert-pattern (Landing-Pages aus einzelnen Abschnitten)
  • wp-agent/get-seo-meta (SEO-Angaben provider-neutral lesen; set-seo-meta prüft den Zustand derzeit nur und endet vor jeder Provider-Mutation mit HTTP 409 und manual_only)
  • wp-agent/render-verify (nur lesend: prüft die wirksame Darstellung, Blockstruktur und dokumentierte Providerfallen)
  • wp-agent/refresh-hooks (holt Nacharbeiten nach, die WordPress sonst nur beim Speichern im Editor macht: Permalink-Regeln, Beitrags-Cache, Sitemap)
  • wp-agent/write-theme-file (schreibt eine Datei ins aktive Theme, nur .html, .json und .css)
  • wp-agent/disable-power (Not-Aus-Schalter für das separate Power-Plugin)

Die mit Skills 0.4.86 gebündelte Dokumentation beschreibt den Release-Satz aus Companion 0.4.117, Power 0.6.35 sowie CLI und Skills 0.4.86. Die bestätigte Zählung umfasst 414 Companion-Abilities, 317 im empfohlenen Inhaltsprofil, 440 kombinierte Companion- und Power-Schemas, 414 Companion-Tools und 34 geprüfte öffentliche Pfade. Free stellt exakt 34 eng begrenzte Kern-Abilities ohne Lizenzschlüssel, Site-Limit oder Aufrufslimit bereit. Das Operation Ledger ist eine administrative Funktion ohne Ability und ohne MCP-Vorabgenehmigung. Die übrigen Grenzen stehen in der Roadmap.

Katalogzahlen und reine Quellstandsignaturen belegen nicht von selbst, dass jede Ability in jedem Profil oder Providerzustand verfügbar ist.

Die Capability-Grenzen dieses Release-Satzes gelten unabhängig vom Auslieferungsweg. Das Operation Ledger ist kein MCP-Tool und keine Vorabgenehmigung.

Die vollständige aktuelle Liste steht in der Abilities-Referenz.

Nach der Plugin-Aktivierung ist WPAgently Free sofort nutzbar. Es ist kein Konto und kein Lizenzschlüssel nötig. Wenn du eine Jahreslizenz gekauft hast, öffne Werkzeuge > WPAgently-Lizenz, füge den von Polar erhaltenen Lizenzschlüssel ein und klicke „Lizenz aktivieren“. Die Aktivierung zählt genau diese Website gegen das Site-Limit deines Tarifs und erweitert dieselbe Installation auf die vollständige Companion-Oberfläche. Das Power-Plugin muss zusätzlich separat installiert und aktiviert werden. Seine eigenen serverseitigen Gates bleiben danach weiterhin geschlossen, bis du sie bewusst freischaltest. Ein vorübergehender Ausfall von Polar sperrt eine zuletzt erfolgreich geprüfte bezahlte Lizenz nicht sofort. Die lokale Bestätigung gilt höchstens sieben Tage. Free bleibt davon unabhängig verfügbar.

Das Plugin richtet nach der Aktivierung automatisch einen eigenen MCP-Server unter der Adresse <site>/wp-json/wp-agent/mcp ein. Öffne danach im Backend WPAgently > Übersicht. Dort zeigt die Einrichtungs-Karte zunächst PHP-, WordPress-, HTTPS- und Staging-Voraussetzungen und führt anschließend zum passenden Verbindungsschritt für deinen Client. Sie überträgt dabei keine Zugangsdaten. Mit dem Profil Nur lesen kannst du einen Agenten verbinden, ohne ihm schreibende Werkzeuge anzubieten. Der zusätzliche Domain Lock gehört zur bezahlten Lizenz.

Für den aktuellen Builder-Katalog gilt ausschließlich die Referenz. Sie beschreibt den Release-Satz 0.4.117/0.6.35/0.4.86 und seine Grenzen. Das Inhaltsprofil bleibt ohne das breitere Design- oder Vollzugriffsprofil nutzbar.

Bei dynamischen Builderdaten folgt dein Client immer dem Schema aus tools/list. Native Blockattribute und Supports verwenden den geschlossenen, integritätsgebundenen Umschlag {format,json,sha256,bytes}. Elementor- und Beaver-Builder-Dokumente verwenden bewusst den getrennten Umschlag {json,sha256,bytes}. Sende keine rohen JSON-Objekte an diese Felder. Werte, die die Grenze des jeweiligen Providerpfads überschreiten oder nicht in seinen öffentlichen Vertrag passen, werden abgelehnt, nicht still abgeschnitten.

Ab WordPress 7.0 kannst du zusätzlich den integrierten Chat unter WPAgently > Chat und Vorschau verwenden. Richte dafür zuerst unter Einstellungen > Connectors deinen eigenen KI-Anbieter ein. Der Chat recherchiert ausschließlich über die freigegebenen lesenden Abilities. Schreibende Vorschläge werden als Plan angezeigt und erst nach deiner einzelnen Freigabe unter dem gewählten Redakteur ausgeführt. Nachrichten und gelesene Website-Daten gehen direkt von WordPress an deinen KI-Anbieter, nicht über einen WPAgently-KI-Proxy. Die Vorschau erlaubt nur Pfade derselben Website und deaktiviert Seitenskripte sowie Formulare. Mit Element auswählen kannst du einen sichtbaren Seitenbereich anklicken und als begrenzten Kontext für deine nächste Nachricht übernehmen. Die Auswahl führt keinen CSS-Selektor aus und wird vom Modell ausdrücklich als nicht vertrauenswürdiger Website-Inhalt behandelt.

Für sichtbare Arbeiten im Gutenberg- oder Elementor-Editor öffnest du WPAgently > Live-Editor, wählst den dedizierten Redakteur und startest den Arbeitsbereich. Der Assistent kann danach über die bestehende MCP-Verbindung Seiten öffnen und ihre bestätigte Editor-Arbeitsfläche verwenden. Gutenberg-Änderungen erscheinen zunächst nur im Browser und werden erst durch den getrennt bestätigten Speicherbefehl dauerhaft. Elementor-Änderungen werden nach deiner Einzelbestätigung über den geprüften serverseitigen Elementor-Pfad mit Konfliktschutz, Revision und Rückleseprüfung ausgeführt. Beende die Sitzung nach der Arbeit. Bricks, Breakdance und Oxygen besitzen weiterhin keine bestätigte visuelle Laufzeit-Arbeitsfläche.

Geschafft, wenn: das Plugin als „Aktiv“ angezeigt wird und Werkzeuge > WPAgently-Lizenz den Status „Free aktiv“ oder „Bezahlt“ meldet. Alles Weitere prüfen wir in Schritt 5 automatisch nach.