Wer darf was, und wer merkt es? KI-Agenten in WordPress 7.1

Ein KI-Agent darf auf Ihrer WordPress-Seite genau das, was der Benutzer darf, mit dem er sich anmeldet. Und ob jemand seine Arbeit bemerkt, entscheidet sich nicht in WordPress, sondern daran, ob Sie ein Protokoll eingerichtet haben. Das sind die beiden Antworten, um die es in diesem Beitrag geht, und beide haben seit dem Sommer 2026 eine neue Dringlichkeit: Mit WordPress 7.1 vom 19.08.2026 gibt es ein einheitliches Kennzeichen, mit dem Plugins ihre Funktionen für Agenten freigeben. Seit dem 02.10.2026 steht der offizielle MCP-Adapter im Plugin-Verzeichnis von WordPress.org. Am selben Tag hat WordPress.com gemeldet, dass sein Agent Plugins installiert, aktiviert und aktualisiert, und dass Cursor über ein eigenes Marktplatz-Plugin direkt an Sites andockt. WooCommerce liefert seit Version 10.9 vom 23.06.2026 sieben Agentenfähigkeiten für Produkte und Bestellungen im Kern mit.

Die technische Seite ist inzwischen gut beschrieben. Was fehlt, ist die Betriebsanleitung für den Betreiber: Was steht offen, sobald ein Plugin mitspielt? Was bedeutet „public“ in den Metadaten wirklich? Wie legen Sie einen eigenen Agenten-Benutzer an, welche Rechte reichen, wie lesen Sie das Protokoll, was passiert bei einem fehlgeschlagenen Plugin-Update, und wie finden Sie heraus, ob auf Ihrer Seite schon ein Endpunkt erreichbar ist? Ich habe das in den letzten Wochen auf eigenen Installationen und bei WordPress-Projekten meiner Kunden durchgespielt. Stand aller Angaben: 06.10.2026.

Die drei Bausteine, in einem Absatz je Baustein

Die Abilities API steckt seit WordPress 6.9 im Kern. Sie ist ein Verzeichnis: Plugins und der Kern selbst melden dort „Fähigkeiten“ an, jede mit Namen, Beschreibung, Eingabe- und Ausgabeschema, einer Ausführungsfunktion und einer Rechteprüfung. Die Fähigkeit core/get-site-info liefert zum Beispiel Name und Adresse der Seite. Ein Agent kann dieses Verzeichnis lesen und versteht aus der Beschreibung, was er womit erreichen kann. WordPress 7.1 hat die API um Prüf-Hooks, eine Aktion für jeden Aufruf und das einheitliche Kennzeichen „public“ erweitert.

Der MCP-Adapter ist der Übersetzer. Das Model Context Protocol ist der offene Standard, über den Claude, ChatGPT, Cursor und andere Werkzeuge externe Funktionen entdecken und ausführen. Der Adapter nimmt die angemeldeten Fähigkeiten und stellt sie als MCP-Werkzeuge bereit, standardmäßig unter /wp-json/mcp/mcp-adapter-default-server. Er ist ein eigenes Plugin, nicht Teil des Kerns. Version 0.7.0 vom 02.10.2026 ist die erste, die über das Plugin-Verzeichnis installiert werden kann; vorher musste man die Datei von GitHub holen. Voraussetzung ist WordPress 6.9.

Die Clients sind die Agenten selbst: Claude Desktop, Claude Code, Cursor, ChatGPT mit Konnektoren, oder ein Agent, den jemand mit einem Framework gebaut hat. Sie melden sich an Ihrer Seite an wie ein Benutzer und rufen dann nacheinander Werkzeuge auf. Die Bestätigungsfrage, die Sie aus Claude oder Cursor kennen („Darf ich diese Aktion ausführen?“), lebt im Client. WordPress sieht sie nicht und kann sich nicht darauf verlassen.

Was steht standardmäßig offen?

Weniger, als die Schlagzeilen vermuten lassen, aber mehr, als viele Betreiber wissen. Der Kern selbst bringt drei Fähigkeiten mit: core/get-site-info, core/get-user-info und core/get-environment-info. Alle drei lesen nur, alle drei sind seit 7.1 als „public“ gekennzeichnet. Sie sind über die REST-Schnittstelle unter /wp-json/wp-abilities/v1/abilities erreichbar, aber nur für angemeldete Benutzer. Ein anonymer Aufruf bekommt eine Fehlermeldung, keine Daten. Ein MCP-Endpunkt existiert ohne Adapter-Plugin nicht.

Sobald Plugins ins Spiel kommen, ändert sich das Bild in drei Stufen:

Plugins mit eigenen Fähigkeiten. WooCommerce registriert seit 10.9 sieben Fähigkeiten: Produkte abfragen, anlegen, ändern und löschen, Bestellungen abfragen, Bestellstatus ändern, Bestellnotiz hinzufügen. Jede hat eine eigene Rechteprüfung, die auf dem Rechtesystem von WooCommerce aufsetzt. Daneben gibt es noch den älteren, WooCommerce-eigenen MCP-Endpunkt unter /wp-json/woocommerce/mcp, der über den Schalter „WooCommerce MCP“ unter Einstellungen → Erweitert → Funktionen freigegeben wird und sich mit REST-API-Schlüsseln anmeldet; seit 10.9 gilt er als Übergangsweg. Die sieben neuen Fähigkeiten laufen über den gemeinsamen WordPress-Adapter. Plugins wie Simple History und WPForms registrieren ebenfalls Fähigkeiten; Elementor bringt mit seiner MCP-Beta einen eigenen Weg mit.
Der offizielle Adapter. Ist er aktiv, legt er beim Laden automatisch einen Standardserver an und veröffentlicht darüber jede Fähigkeit, die meta.public oder meta.mcp.public auf wahr gesetzt hat. Die Zugangsprüfung für den Server ist standardmäßig nur „ist angemeldet“. Welcher Benutzer das ist und was er darf, entscheidet dann jede Fähigkeit selbst.
Drittanbieter-MCP-Plugins. Hier wird es weit. Cowboy MCP (Version 1.7.0, Stand 06.10.2026) nennt über 200 Werkzeuge, darunter Plugins und Themes installieren, Dateien in wp-content schreiben, Datenbank-Befehle und WP-CLI-Kommandos. Agent Abilities for MCP (Version 1.7.9) bietet 179 kuratierte Fähigkeiten mit Freigabelisten je Verbindung. WSP MCP wirbt mit über 200 Werkzeugen. Diese Plugins gehen weit über den Kern hinaus, bringen aber teils eigene Schlüssel, eigene Protokolle und eigene Schutzmechanismen mit.

Die Zwischenbilanz: Ohne Plugin passiert auf einer selbst gehosteten Seite nichts. Mit dem Adapter oder einem der MCP-Plugins kann ein Agent alles ausführen, was der angemeldete Benutzer darf und was ein Plugin als Fähigkeit freigegeben hat. Das kann vom Lesen des Seitentitels bis zum Löschen von Produkten reichen.

Was „public“ bedeutet, und was nicht

Das Kennzeichen aus WordPress 7.1 hat drei Ebenen, und die Reihenfolge ist wichtig:

meta.public sagt: Diese Fähigkeit ist für externe Clients gedacht, also REST, MCP-Adapter, Agenten. Fehlt die Angabe, gilt „nicht öffentlich“.
meta.show_in_rest regelt die REST-Schnittstelle allein und hat Vorrang vor dem allgemeinen Kennzeichen. Ein Plugin kann also „public“ setzen und REST trotzdem ausschließen.
meta.mcp.public regelt den MCP-Kanal auf dieselbe Weise. Steht dort ausdrücklich „falsch“, bleibt die Fähigkeit im Adapter unsichtbar, auch wenn sie sonst öffentlich ist.

Entscheidend ist der Satz, den das Core-Team dazu selbst betont: „public“ steuert nur Sichtbarkeit und Erreichbarkeit. Es macht eine Fähigkeit nicht ausführbar. Jede Fähigkeit muss ihre eigene Rechteprüfung mitbringen, die bei jedem Aufruf gegen den aktuellen Benutzer läuft. Eine öffentliche Fähigkeit mit der Prüfung „darf Optionen verwalten“ bleibt für einen Redakteur gesperrt. Umgekehrt gilt: Eine Fähigkeit, deren Autor die Prüfung schlampig gebaut hat, ist mit „public“ für jeden angemeldeten Benutzer erreichbar.

Dazu kommen drei Hinweise, die der Plugin-Autor je Fähigkeit mitgibt: readonly (liest nur), destructive (zerstört oder löscht) und idempotent (ein zweiter Aufruf ändert nichts mehr). Die REST-Schnittstelle leitet daraus sogar die HTTP-Methode ab: Lesende Fähigkeiten laufen über GET, schreibende über POST, zerstörende über DELETE. Der Agent sieht diese Hinweise und kann sie für seine Rückfragen nutzen. Nur: Es sind Angaben des Plugin-Autors, keine Garantien von WordPress. Eine als „readonly“ markierte Fähigkeit, die trotzdem schreibt, hält niemand auf.

Wer darf was: der Agent ist ein Benutzer

Das ist die wichtigste Regel, und sie macht vieles einfacher. Ein Agent hat in WordPress keine eigene Identität. Er meldet sich mit einem Benutzerkonto an, und zwar in fast allen Fällen über ein Anwendungspasswort. Damit erbt er die Rolle dieses Kontos. Ein Agent mit dem Anwendungspasswort eines Administrators darf alles, was ein Administrator darf, und zwar ohne jede Rückfrage auf Seiten von WordPress. Ein Agent mit dem Konto eines Redakteurs darf Beiträge und Seiten bearbeiten, aber keine Plugins installieren.

Daraus folgt mein Standardvorgehen, das ich inzwischen bei jeder Einrichtung durchziehe:

Eigenen Benutzer anlegen. Benutzer → Neu hinzufügen, Benutzername etwa „agent-claude“ oder „agent-cursor“, eine E-Mail-Adresse, die Sie kontrollieren, und die kleinste Rolle, die für die geplante Aufgabe reicht. Für Textarbeit ist das „Autor“ (eigene Beiträge) oder „Redakteur“ (alle Inhalte). Niemals das persönliche Konto eines Menschen und niemals das Admin-Konto.
Anwendungspasswort erzeugen. Im Profil dieses Benutzers, Abschnitt „Anwendungspasswörter“, einen Namen eintragen, der den Client benennt, und „Neues Anwendungspasswort hinzufügen“ klicken. Das Passwort wird genau einmal angezeigt. Es funktioniert nur über HTTPS. Pro Client ein eigenes Passwort, damit Sie einzeln widerrufen können.
Client verbinden. Beim offiziellen Adapter trägt der Client die Adresse https://ihre-domain.de/wp-json/mcp/mcp-adapter-default-server, den Benutzernamen und das Anwendungspasswort ein; für Claude Desktop und Cursor gibt es ein kleines Hilfsprogramm von Automattic, das die Verbindung herstellt. Bei Drittanbieter-Plugins läuft die Anmeldung oft über einen eigenen Schlüssel aus den Plugin-Einstellungen.
Einen Testlauf mit Leseaufgaben. „Nenne mir Titel und Datum der letzten fünf Beiträge.“ Danach ins Protokoll schauen (dazu gleich mehr), erst dann schreibende Aufgaben erlauben.

Welche Rolle für welche Aufgabe? Für Inhalte reicht Redakteur. Für Kommentare moderieren reicht Redakteur. Für Mediendateien reicht Autor, wenn der Agent nur eigene Uploads verwaltet. Für WooCommerce-Produkte braucht es Shop-Manager. Und jetzt der heikle Teil: Für Plugin-Updates, Plugin-Installationen und Einstellungen braucht es in WordPress die Administratorrolle, denn die Rechte update_plugins, install_plugins und manage_options hängen an ihr. Es gibt in WordPress keine Zwischenstufe „darf aktualisieren, aber nicht löschen“.

Wenn Sie einem Agenten Wartungsaufgaben übertragen wollen, haben Sie drei Wege. Erstens: Sie geben ihm ein Admin-Anwendungspasswort und vertrauen auf die Rückfragen des Clients. Das ist der Weg, den ich nicht empfehle, weil die Rückfrage im Client sitzt und ein Fehler im Prompt oder ein manipulierter Webseiteninhalt, den der Agent liest, sie aushebeln kann. Zweitens: Sie bauen mit einem Rollen-Plugin eine eigene Rolle, die genau die nötigen Rechte hat, etwa update_plugins ohne delete_plugins und ohne edit_files. Das funktioniert, ist aber Handarbeit und muss bei jedem Plugin-Wechsel nachgezogen werden. Drittens: Sie nehmen ein Plugin, das Wartungsaufgaben als abgesicherte Fähigkeiten anbietet. Agent Toolbelt (Version 1.5.1 vom 06.09.2026) ist das konsequenteste Beispiel, das ich gefunden habe: Jede schreibende Aktion läuft zuerst als Probelauf, hochriskante Aktionen wie Plugin-Updates brauchen ein einmaliges Bestätigungs-Token, das nach 15 Minuten verfällt, und die Aktionen mit hohem Risiko sind nach der Installation abgeschaltet, bis Sie sie einzeln freigeben. Die Rechteprüfung läuft trotzdem gegen den Benutzer; das Plugin ersetzt sie nicht, es ergänzt sie um eine zweite Hürde, die auf dem Server sitzt und nicht im Client.

Wie Sie prüfen, ob Ihre Seite schon einen Endpunkt hat

Das ist die Frage, die mir Kunden am häufigsten stellen, seit das Thema in der Presse ist. Sie lässt sich in zehn Minuten beantworten, ganz ohne Entwickler.

Die REST-Übersicht lesen. Rufen Sie https://ihre-domain.de/wp-json/ im Browser auf. Die Antwort ist eine lange Textdatei. Suchen Sie darin nach namespaces. Steht in dieser Liste wp-abilities/v1, ist die Abilities API aktiv; das ist ab WordPress 6.9 immer der Fall. Steht dort ein Eintrag, der mit mcp/ beginnt, läuft der offizielle Adapter oder ein Plugin, das denselben Namensraum nutzt. Drittanbieter-Plugins verwenden eigene Namensräume, deshalb lohnt der nächste Schritt.
Die Plugin-Liste durchgehen. Alles, was „MCP“, „Agent“, „AI Connector“ oder „Abilities“ im Namen trägt, zählt. Dazu Plugins mit eingebauten Agentenfunktionen: Elementor seit der MCP-Beta vom September, Divi 5 mit seinen AI Agents, WooCommerce ab 10.9, Uncanny Automator mit Agentenfunktion.
Die Fähigkeiten auflisten. Als Administrator angemeldet, öffnen Sie https://ihre-domain.de/wp-json/wp-abilities/v1/abilities. Sie sehen jede Fähigkeit, die für REST freigegeben ist, mit Namen, Beschreibung und den Hinweisen readonly, destructive und idempotent. Was dort steht, kann ein Agent mit einem passenden Konto ausführen.
Die Anwendungspasswörter zählen. Gehen Sie jeden Benutzer mit Administrator-, Redakteurs- oder Shop-Manager-Rolle durch und öffnen Sie dessen Profil. Die Tabelle „Anwendungspasswörter“ zeigt Name, Erstelldatum, letzte Verwendung und die IP-Adresse der letzten Verwendung. Jeder Eintrag, den Sie nicht zuordnen können, wird widerrufen. Ein Passwort, das seit Monaten nicht benutzt wurde, ebenfalls.
Bei WordPress.com gesondert prüfen. Dort läuft die Verbindung über den MCP-Server von WordPress.com mit OAuth 2.1, nicht über Anwendungspasswörter. Welche Fähigkeiten freigegeben sind, sehen Sie in den Einstellungen Ihrer Site; laut WordPress.com ist alles standardmäßig aus und muss je Site eingeschaltet werden.

Wer merkt es: das Protokoll

WordPress führt von Haus aus kein Protokoll über Aktionen. Ein Agent, der um drei Uhr nachts zwanzig Seiten ändert, hinterlässt nur das, was jede Änderung hinterlässt: Revisionen bei Beiträgen, ein geändertes Datum, eine neue Plugin-Version. Wer das war, steht nirgends. Mit 7.1 gibt es im Kern immerhin einen Haken dafür: Die Aktion wp_ability_invoked wird zu Beginn jeder Ausführung einer Fähigkeit ausgelöst, ausdrücklich für Protokollierung und Telemetrie. Nur hängt an diesem Haken ohne Plugin nichts.

Drei Wege, das zu ändern, in der Reihenfolge, in der ich sie einsetze:

Simple History. Das Aktivitätsprotokoll erkennt seit Version 5.27.0, ob eine Aktion von einem KI-Werkzeug ausgelöst wurde, und zeigt neben dem Benutzer den Namen des Agenten. Das zuverlässigste Signal ist die Abilities API selbst; dazu kommen Kopfzeilen, die MCP-Clients mitschicken, der User-Agent und eine Kennung für WP-CLI-Aufrufe. Seit 5.28.0 vom 19.05.2026 protokolliert das Plugin auch Änderungen über WP-CLI und REST an Beiträgen, Benutzern, Medien, Menüs und Einstellungen, also genau die Wege, die Agenten nehmen. Der angemeldete Benutzer bleibt als Verantwortlicher eingetragen; das Agenten-Etikett sagt, wie die Aktion zustande kam. Für die meisten Seiten, die ich betreue, ist das die Lösung, weil sie ohne Konfiguration läuft.
Das Protokoll des MCP-Plugins. Agent Abilities for MCP zeichnet jeden Aufruf auf, auch abgelehnte, mit Benutzer oder Verbindung und den Namen der übergebenen Parameter, aber ohne deren Inhalt. Agent Toolbelt hält Aufrufer, Benutzer, Eingabe-Prüfsumme und Ergebnis 90 Tage lang vor. Cowboy MCP protokolliert jeden Werkzeugaufruf, jeden Fehler und jede Anmeldung, 30 Tage lang. Diese Protokolle sind genauer als Simple History, weil sie die Absicht sehen, nicht nur das Ergebnis.
Die Tabelle der Anwendungspasswörter. Die Spalten „Zuletzt verwendet“ und „Letzte IP“ sind das einfachste Frühwarnsystem. Ein Blick pro Woche reicht, um zu sehen, ob ein Passwort aktiv ist, das es nicht sein sollte.

Was keines dieser Werkzeuge leistet: Es zeigt Ihnen nicht, was der Agent gelesen hat. Lesende Fähigkeiten tauchen im Aktivitätsprotokoll nicht auf, weil sie nichts ändern. Wer wissen will, ob ein Agent Kundendaten aus WooCommerce abgefragt hat, braucht das Aufrufprotokoll des MCP-Plugins oder ein Zugriffsprotokoll des Webservers, das der Hoster bereitstellt.

Was bei einem fehlgeschlagenen Plugin-Update passiert

Seit WordPress 6.3 sichert der Kern bei einem manuellen Plugin- oder Theme-Update die alte Version und stellt sie wieder her, wenn das Update selbst fehlschlägt. Seit 6.6 gilt das auch für automatische Updates: Löst die neue Version einen schweren PHP-Fehler aus, holt WordPress die alte zurück. Das ist die gute Nachricht, und sie gilt auch, wenn ein Agent das Update anstößt, denn er nutzt dieselben Kernfunktionen.

Die schlechte Nachricht: Der Kern erkennt nur technisches Scheitern. Ein Update, das sauber durchläuft und danach das Layout zerlegt, einen Shortcode ins Leere laufen lässt oder die Kasse eines Shops stillstehen lässt, ist aus Sicht von WordPress erfolgreich. Ein Mensch würde das beim nächsten Seitenaufruf sehen. Ein Agent, der fünf Updates nacheinander durchführt, sieht es nicht, es sei denn, er prüft die Seite danach selbst. Genau das tun die Wartungs-Plugins: Agent Toolbelt legt vor dem Update eine Sicherung an, prüft nach dem Update, ob die Seite antwortet, und stellt bei einem Fehler automatisch zurück; Updates von Plugins, die nur aus einer Datei bestehen, verweigert es, weil keine Sicherung möglich ist. Cowboy MCP arbeitet mit Datenbank-Prüfpunkten und einem Änderungsjournal, aus dem sich einzelne Schritte zurücknehmen lassen.

Meine Regel für Kundenseiten: Ein Agent darf Updates vorschlagen und im Probelauf zeigen, was er tun würde. Ausführen darf er sie nur mit einem Werkzeug, das vorher sichert und danach prüft, und nur auf Seiten, bei denen eine Staging-Umgebung oder ein Hoster-Backup vom selben Tag existiert. Für Shops gilt das doppelt.

Was WordPress.com anders macht, und warum das für Sie zählt

WordPress.com hat seinen Agentenzugang anders gebaut als die selbst gehostete Welt. Seit dem 20.03.2026 können Claude, ChatGPT und Cursor dort Inhalte anlegen und bearbeiten, seit dem 02.10.2026 verwaltet der hauseigene WordPress-Agent auch Plugins. Die Verbindung läuft über OAuth 2.1, jede Fähigkeit ist standardmäßig aus und wird je Site freigeschaltet, und WordPress.com sagt, dass Änderungen eine ausdrückliche Bestätigung brauchen. Das sind drei Schutzschichten, die auf dem Server sitzen.

Auf einer selbst gehosteten Seite haben Sie diese Schichten nicht automatisch. Ein Anwendungspasswort ist ein Dauerzugang ohne Rückfrage und ohne Ablaufdatum. Zwei-Faktor-Plugins sichern die Anmeldung im Browser; die Anmeldung per Anwendungspasswort läuft an ihnen vorbei. Der offizielle Adapter prüft am Eingang nur, ob jemand angemeldet ist. Die Bestätigung sitzt im Client, also auf dem Rechner desjenigen, der den Agenten bedient. Wer diese Schichten will, muss sie selbst nachbauen: eigener Benutzer mit kleiner Rolle, Wartungs-Plugin mit Probelauf und Token, Protokoll, und bei Bedarf eine eigene Zugangsprüfung für den Adapter, mit der ein Entwickler den Standardserver auf bestimmte Rollen oder Schlüssel beschränkt. Der Adapter sieht das vor: Der Standardserver lässt sich über einen Filter abschalten, und ein eigener Server kann mit einer festen Liste von Fähigkeiten und einer eigenen Rechteprüfung angelegt werden.

Was Ihr Hoster beisteuern kann, ist überschaubar, aber nicht nichts: den Pfad /wp-json/mcp/ auf Anfrage sperren oder auf bestimmte IP-Adressen begrenzen, Anfragen an die REST-Schnittstelle drosseln, Zugriffsprotokolle bereitstellen und tägliche Sicherungen mit kurzen Wiederherstellungszeiten anbieten. Ob Ihr Hoster das tut, steht selten in der Leistungsbeschreibung. Fragen Sie nach, bevor Sie den ersten Agenten anschließen.

Wenn Sie keinen Agenten wollen

Auch das ist eine legitime Entscheidung, und sie lässt sich sauber umsetzen. Anwendungspasswörter lassen sich für die gesamte Installation abschalten; dafür gibt es im Kern den Filter wp_is_application_passwords_available, den ein Entwickler oder ein Sicherheits-Plugin auf „falsch“ setzt. Danach kann sich kein externes Programm mehr über diesen Weg anmelden, auch keine legitime Anbindung wie eine App oder ein Newsletter-Werkzeug, das prüfen Sie vorher. Der MCP-Adapter und die Drittanbieter-Plugins bleiben einfach deinstalliert. Die Abilities API selbst bleibt im Kern, ist aber ohne angemeldeten Benutzer nicht erreichbar und ohne Plugins, die Fähigkeiten registrieren, weitgehend leer.

Die Prüfliste zum Abhaken

REST-Übersicht unter /wp-json/ gelesen: Namensräume wp-abilities/v1 und mcp/… notiert.
Plugin-Liste auf MCP-, Agenten- und Abilities-Plugins durchgesehen, inklusive Builder und WooCommerce.
Liste der Fähigkeiten unter /wp-json/wp-abilities/v1/abilities als Administrator aufgerufen und die Einträge mit destructive markiert.
Anwendungspasswörter aller Benutzer mit erweiterten Rechten geprüft, unbekannte und ungenutzte widerrufen.
Für jeden gewünschten Agenten ein eigener Benutzer mit kleinster Rolle und einem eigenen Anwendungspasswort.
Kein Admin-Anwendungspasswort an einen Agenten; Wartungsaufgaben nur über ein Plugin mit Probelauf, Bestätigung und Rücksicherung.
Simple History oder das Protokoll des MCP-Plugins aktiv, einmal pro Woche gelesen.
Erster Einsatz nur lesend, Protokoll geprüft, dann schreibend.
Backup vom selben Tag und Staging vorhanden, bevor ein Agent Updates ausführt.
Hoster gefragt: Sperre oder IP-Beschränkung für /wp-json/mcp/, Drosselung, Zugriffsprotokolle.
Bei WordPress.com: Freigaben je Site geprüft, nicht benötigte Fähigkeiten aus.
Termin in drei Monaten: Passwörter, Protokoll und Plugin-Versionen erneut prüfen; der Adapter trägt noch eine Versionsnummer unter 1.0 und ändert sich schnell.

Meine Einschätzung

Die Steckdose ist da, und sie ist gut gebaut. Die Abilities API mit Rechteprüfung je Fähigkeit und den Hinweisen auf lesende und zerstörende Aktionen ist ein besseres Fundament, als es die meisten Agentenanbindungen anderer Systeme haben. Was fehlt, ist die Betriebsdisziplin drumherum, und die liegt beim Betreiber. Ich sehe in Kundenprojekten drei typische Fehler: das Admin-Anwendungspasswort im Client, kein Protokoll, und die Annahme, die Rückfrage im Chatfenster sei eine Sicherung. Alle drei sind an einem Nachmittag zu beheben.

Wer das Thema von der anderen Seite angehen will, also die eigene Website für lesende Agenten und KI-Suchen gut aufbereiten, findet die Grundlagen im Beitrag über die Website als Datenquelle für KI-Agenten. Für Shops ergänzt der Beitrag zu WooCommerce-Produkten für KI-Assistenten die Lese-Seite dessen, was hier auf der Schreib-Seite beschrieben ist.

Die Serie: neun Vertiefungen

Dieser Beitrag ist die Übersicht. Jedes Teilthema hat einen eigenen Beitrag mit allen Einzelheiten:

Quellen

Kurz beantwortet

Kann ein KI-Agent meine WordPress-Seite ohne mein Zutun verändern?

Nein. Er braucht ein Benutzerkonto Ihrer Seite, in der Regel mit Anwendungspasswort, und ein Plugin, das Fähigkeiten freigibt. Ohne beides kann er höchstens lesen, was ohnehin öffentlich ist.

Welche Rolle sollte der Agenten-Benutzer haben?

Die kleinste, die für die Aufgabe reicht: Autor oder Redakteur für Inhalte, Shop-Manager für Produkte. Administratorrechte nur über ein Wartungs-Plugin mit Probelauf, Bestätigung und Rücksicherung, nie als nacktes Anwendungspasswort.

Woran erkenne ich, dass ein Agent auf meiner Seite gearbeitet hat?

Am Aktivitätsprotokoll, etwa Simple History, das Agentenaktionen seit Version 5.27 kennzeichnet, am Aufrufprotokoll des MCP-Plugins und an den Spalten „Zuletzt verwendet“ und „Letzte IP“ in der Tabelle der Anwendungspasswörter.

Wer darf was, und wer merkt es? KI-Agenten in WordPress 7.1: Die Betriebsanleitung für Seitenbetreiber