Managed WordPress gegen KI-Agenten-Zugriff

Ein Hoster kann einen KI-Agenten aussperren, bremsen, protokollieren und ihm die Möglichkeit nehmen, Plugins zu installieren. Er kann nicht erkennen, ob der Agent gewollt ist, und er kann nicht sehen, was der Agent vorhat. Das ist die Arbeitsteilung, auf die es hinausläuft, seit WordPress 7.1 vom 19.08.2026 und der offizielle MCP-Adapter vom 02.10.2026 Agenten zum normalen Bestandteil einer Installation machen: Der Hoster sichert den Zugangsweg und die Infrastruktur, der Kunde entscheidet über Benutzer, Rechte, Werkzeuge und Freigaben. Wer Managed WordPress bucht und glaubt, damit sei das Thema erledigt, irrt. Wer glaubt, der Hoster könne nichts tun, irrt ebenfalls. Dieser Beitrag ist der Teil der Betriebsanleitung für KI-Agenten in WordPress, der die Hoster-Seite vollständig durchgeht: Schicht für Schicht, mit den konkreten Stellschrauben, den Fragen an den Anbieter und der Liste dessen, was beim Kunden bleibt. Stand: 06.10.2026.

Warum das Thema beim Hoster landet

Drei Entwicklungen haben den Agentenzugriff aus der Entwicklerecke in den Betrieb geholt. Die Abilities API steckt seit WordPress 6.9 im Kern und wurde mit 7.1 um das einheitliche Kennzeichen „public“, Prüf-Hooks und eine Aktion je Aufruf erweitert. Der MCP-Adapter, der diese Fähigkeiten für Claude, Cursor, ChatGPT und andere Clients erreichbar macht, liegt seit dem 02.10.2026 als Version 0.7.0 im Plugin-Verzeichnis und ist damit für jeden Kunden einen Klick entfernt. Und WordPress.com hat am selben Tag gemeldet, dass sein Agent Plugins installiert, aktiviert und aktualisiert. Dazu kommen Drittanbieter-Plugins mit über 200 Werkzeugen bis hinunter zu Dateizugriff und Datenbankbefehlen. Für einen Hoster heißt das: Auf seinen Servern laufen ab sofort Installationen, in denen ein externes Programm mit Administratorrechten arbeitet, ohne dass ein Mensch jede Aktion sieht. Das ist kein neuer Angriffsvektor, denn die REST-Schnittstelle und Anwendungspasswörter gibt es seit Jahren. Neu sind die Reichweite und die Geschwindigkeit, mit der ein Agent Dinge tut, die früher Handarbeit waren.

Die Zugangswege, die ein Hoster kennt

Ein Agent erreicht eine WordPress-Installation über wenige, bekannte Pfade, und genau diese Begrenztheit ist der Hebel des Hosters:

/wp-json/mcp/ für den offiziellen Adapter, standardmäßig /wp-json/mcp/mcp-adapter-default-server, dazu eigene Server unter demselben Namensraum.
/wp-json/wp-abilities/v1/ für die Abilities API selbst, über die Fähigkeiten auch ohne MCP ausgeführt werden können.
/wp-json/woocommerce/mcp für den älteren WooCommerce-Endpunkt, der seit 10.9 als Übergangsweg gilt.
Die klassische REST-Schnittstelle unter /wp-json/wp/v2/, über die viele Agenten Beiträge, Seiten und Medien direkt bearbeiten.
Eigene Namensräume von Drittanbieter-Plugins, erkennbar in der Übersicht unter /wp-json/.
WP-CLI über SSH, wenn der Hoster Shell-Zugang anbietet; der Adapter bringt dafür einen eigenen Transport mit.

Die Anmeldung läuft in fast allen Fällen über ein Anwendungspasswort im HTTP-Header, bei Drittanbieter-Plugins über eigene Schlüssel oder OAuth, bei WP-CLI über den Systembenutzer. Das ist die Grundlage für alles Weitere: Ein Hoster, der diese Pfade und Anmeldewege kennt, kann sie gezielt behandeln, ohne die Website selbst zu berühren.

Schicht 1: Webserver und Firewall

Die erste Schicht sitzt vor WordPress und wirkt unabhängig von Plugins, Benutzern und Passwörtern. Fünf Maßnahmen sind hier möglich, und ein Managed-Anbieter sollte jede davon auf Kundenwunsch anbieten:

Pfade sperren. /wp-json/mcp/ und /wp-json/wp-abilities/ am Webserver oder in der Web Application Firewall blockieren. Für Kunden, die keinen Agenten wollen, ist das die sauberste Lösung, weil sie auch dann greift, wenn ein Kunde später versehentlich ein MCP-Plugin aktiviert. Die klassische REST-Schnittstelle bleibt dabei unberührt, denn an ihr hängen Editor, Apps und viele Plugins.
Auf Adressen beschränken. Die Pfade nur für bestimmte IP-Adressen öffnen, etwa die des Büros oder eines festen Servers, auf dem der Agent läuft. Für Agenten aus der Cloud mit wechselnden Adressen taugt das nicht; für einen selbst betriebenen Agenten auf einem festen Server ist es die stärkste Einzelmaßnahme.
Drosseln. Anfragen an REST-Endpunkte je Adresse und Minute begrenzen. Das bremst Massenänderungen und Passwortversuche auf Anwendungspasswörter, ohne eine einzelne berechtigte Aktion zu verhindern. Die Schwelle muss so liegen, dass ein Agent, der zwanzig Seiten nacheinander liest, nicht ausgesperrt wird; Sperren nach Fehlversuchen sind wichtiger als Sperren nach Menge.
Anmeldeversuche begrenzen. Fehlgeschlagene Anmeldungen mit Anwendungspasswort zählen wie fehlgeschlagene Logins. Viele Login-Schutzmechanismen sehen nur das Anmeldeformular; die REST-Anmeldung muss ausdrücklich einbezogen werden.
Firewall-Regeln prüfen. Hier liegt eine Falle in der Gegenrichtung: Firewalls, die auf Muster in Anfragen reagieren, treffen Agenten häufiger als Browser, weil Agenten strukturierte Eingaben mit JSON-Körper schicken und eigene User-Agents tragen. Ein Hoster, der Agenten erlaubt, muss seine Regeln so einstellen, dass gewollte Agenten nicht an einer generischen Bot-Sperre scheitern. Kopfzeilen signierter Agenten, wie sie Simple History bereits auswertet, geben Firewalls künftig eine verlässlichere Grundlage als der User-Agent.

Schicht 2: PHP-Konfiguration und wp-config

Die zweite Schicht ist die, die Managed-Anbieter ohnehin kontrollieren, und sie enthält den wirksamsten Einzelschalter gegen Plugin-Installationen durch Agenten. Die Konstante DISALLOW_FILE_MODS in der wp-config.php nimmt WordPress die Rechte zum Installieren, Aktualisieren und Löschen von Plugins und Themes, und zwar für jeden Benutzer, auch für Administratoren und damit für jeden Agenten, der mit einem Administratorkonto arbeitet. Hoster, die Updates zentral einspielen, setzen sie häufig schon. Für Kunden, die Agenten für Inhalte zulassen, aber keine Plugin-Änderungen aus dem Chat heraus wollen, ist das die passende Einstellung. Die schwächere Variante DISALLOW_FILE_EDIT sperrt nur den Datei-Editor im Backend, nicht die Installation.

Dazu kommt die Pflege der PHP-Version und der Fehlerprotokolle. Ein Agent, der ein Plugin aktualisiert, löst bei einem schweren PHP-Fehler die automatische Rücksicherung des Kerns aus, die es seit WordPress 6.6 für automatische Updates gibt. Was dabei passiert ist, steht im PHP-Fehlerprotokoll, und das sollte der Kunde einsehen können. WordPress.com hat am 02.10.2026 PHP- und Webserver-Protokolle auch für die kleineren Tarife freigeschaltet; das ist ein Maßstab, an dem sich deutsche Managed-Anbieter messen lassen müssen.

Schicht 3: das Must-Use-Plugin des Hosters

Das ist die Schicht, die in der Diskussion meist fehlt, obwohl sie Managed-Anbietern längst vertraut ist. Viele Hoster liefern eigene Must-Use-Plugins aus, etwa für Caching, Objekt-Cache oder Staging. Ein solches Plugin läuft vor allen anderen, lässt sich vom Kunden nicht deaktivieren und ist damit der richtige Ort für drei Stellschrauben, die WordPress und der Adapter ausdrücklich vorsehen:

Standardserver des Adapters abschalten, bis der Kunde ihn freigibt. Der Filter mcp_adapter_create_default_server auf „falsch“ sorgt dafür, dass der Adapter nach der Installation keinen Server anlegt. Der Kunde oder sein Entwickler legt dann einen eigenen Server mit fester Fähigkeitenliste und eigener Zugangsprüfung an. Das ist das Opt-in-Modell von WordPress.com, nachgebaut mit einer Zeile.
Anwendungspasswörter je Rolle steuern. Mit wp_is_application_passwords_available_for_user kann der Hoster Anwendungspasswörter für Administratoren sperren und nur für Rollen wie Redakteur oder Shop-Manager erlauben. Ein Agent kann dann nie mit Administratorrechten arbeiten, egal, wer ihm welches Passwort gibt. Mit wp_is_application_passwords_available lässt sich der Weg auf Kundenwunsch komplett schließen.
Den Kern-Haken an das Hoster-Protokoll anbinden. Die Aktion wp_ability_invoked aus 7.1 feuert zu Beginn jeder Ausführung einer Fähigkeit. Ein Must-Use-Plugin, das dort Benutzer, Fähigkeit, Zeitpunkt und Herkunft in das zentrale Protokoll des Hosters schreibt, liefert dem Kunden ein Audit-Log, das er selbst nicht manipulieren kann. Die Eingaben selbst gehören nicht hinein; das Core-Team warnt ausdrücklich vor dem Mitschreiben roher Daten.

Alle drei Stellschrauben greifen in WordPress, nicht am Webserver, und genau deshalb sehen sie, was die Firewall nicht sieht: welcher Benutzer, welche Fähigkeit, welcher Zeitpunkt. Ein Hoster, der das anbietet, hat gegenüber dem reinen Pfadblocker einen echten Vorsprung. Er muss es nur als Leistung benennen und dem Kunden den Schalter dafür geben, denn ohne Freigabe des Kunden darf ein Hoster die Funktionsweise einer Installation nicht verändern.

Schicht 4: Sicherung, Staging, Wiederherstellung

Für Agentenbetrieb ist das wichtiger als jede Firewall-Regel, weil es die Fehler auffängt, die keine Regel verhindert: das Update, das sauber durchläuft und danach das Layout zerlegt; die Massenänderung an fünfzig Produkten mit einem falschen Preisfeld; der Agent, der auf Anweisung „alte Beiträge aufräumen“ zu viel aufräumt. Der Kern rollt nur technisch gescheiterte Updates zurück, nicht Folgeschäden. Vier Dinge zählen:

Tägliche Sicherungen, besser stündliche Datenbanksicherungen für Shops, mit Aufbewahrung über mindestens zwei Wochen.
Gezielte Wiederherstellung einzelner Dateien oder Tabellen statt der ganzen Seite. Eine Komplettrücksicherung setzt auch Bestellungen und Kommentare seit dem Sicherungszeitpunkt zurück.
Eine Staging-Umgebung, die sich mit einem Klick aus der Live-Seite erzeugen lässt, damit ein Agent Updates und Massenänderungen zuerst dort ausführt.
Eine dokumentierte Wiederherstellungszeit. „Wir haben Backups“ ist keine Angabe; „Datei oder Tabelle in zehn Minuten, ganze Seite in einer Stunde“ ist eine.

Was der Hoster nicht sehen kann

Ein Agent, der sich mit einem gültigen Anwendungspasswort anmeldet, sieht für den Webserver aus wie jede andere berechtigte Anfrage. Der Hoster weiß nicht, ob der Redakteur das Passwort an Claude gegeben hat oder ob es aus einem gestohlenen Passwortmanager stammt. Auf der Webserver-Schicht weiß er nicht, ob die Fähigkeit, die gerade läuft, lesend oder löschend ist; das steht in den Metadaten des Plugins, nicht in der Anfrage. Er kann die Rückfrage, die im Chatfenster des Bedieners erscheint, weder erzwingen noch prüfen, denn sie lebt im Client auf dem Rechner des Kunden. Und er kann nicht beurteilen, ob eine Aktion fachlich richtig war: Ob der Agent den richtigen Beitrag gelöscht hat, weiß nur der Kunde.

Daraus folgt die Grenze des Modells: Der Hoster kann die Tür halten, sperren, protokollieren und im Notfall den Zustand von gestern zurückholen. Wer einen Schlüssel bekommt und was damit geschieht, entscheidet der Kunde.

Das Modell von WordPress.com als Maßstab

WordPress.com ist Hoster und Plattform in einem und zeigt, was möglich ist, wenn ein Anbieter beide Seiten kontrolliert: Die Verbindung läuft über OAuth 2.1 statt über Anwendungspasswörter, also mit Token, die Umfang und Laufzeit haben und sich an einer Stelle widerrufen lassen; jede Fähigkeit ist standardmäßig aus und wird je Site freigeschaltet; Änderungen verlangen laut Anbieter eine ausdrückliche Bestätigung. Seit dem 02.10.2026 kommen Plugin-Verwaltung aus dem Chat, ein Plugin im Marktplatz von Cursor und einsehbare Server-Protokolle dazu. Ein klassischer Managed-Hoster kann OAuth nicht in den Kern einbauen, aber die drei Schichten darunter, Opt-in über das Must-Use-Plugin, Rollenbeschränkung für Anwendungspasswörter und Protokoll am Kern-Haken, sind mit Bordmitteln erreichbar. Was WordPress.com dabei nicht löst, gilt überall: Der Agent arbeitet mit den Rechten des Kontos, das ihn freigegeben hat, und ein durchgelaufenes Update mit Folgeschäden bleibt bestehen. Den Vergleich im Einzelnen zieht der Beitrag zum WordPress.com-Agenten gegen selbst gehostetes WordPress.

Die Fragen an Ihren Hoster

Können Sie /wp-json/mcp/ und /wp-json/wp-abilities/ für meine Seite sperren oder auf IP-Adressen beschränken, und wie schnell?
Gibt es eine Drosselung für REST-Anfragen, zählt sie fehlgeschlagene Anmeldungen mit Anwendungspasswort, und greift sie auch bei angemeldeten Anfragen?
Setzen Sie DISALLOW_FILE_MODS, und kann ich das je Seite ein- oder ausschalten?
Bieten Sie ein Must-Use-Plugin an, das den Standardserver des MCP-Adapters sperrt, Anwendungspasswörter für Administratoren verhindert oder Fähigkeitsaufrufe in Ihr Protokoll schreibt?
Bekomme ich Zugriffs- und PHP-Fehlerprotokolle, wie lange reichen sie zurück, und sehe ich darin fehlgeschlagene Anmeldungen?
Wie lange dauert eine Rücksicherung aus dem Tagesbackup, und kann ich einzelne Dateien oder Tabellen zurückholen statt der ganzen Seite?
Gibt es eine Staging-Umgebung, auf die ich einen Agenten zuerst loslassen kann?
Greift Ihre Firewall in REST-Anfragen ein, etwa durch das Blockieren von JSON-Körpern oder bestimmten User-Agents, und würde sie damit auch meinen gewollten Agenten aussperren?
Bei Shell-Zugang: Können Sie WP-CLI für bestimmte Systembenutzer sperren, damit ein Agent nicht über den Umweg Kommandozeile arbeitet?

Die Antworten gehören in die Leistungsbeschreibung, nicht in ein Ticket. Ein Anbieter, der sie nicht geben kann, hat sich mit dem Thema noch nicht beschäftigt; das ist im Oktober 2026 keine Katastrophe, aber ein Grund, nachzufragen, bevor der erste Agent angeschlossen wird.

Was beim Kunden bleibt

Alles, was Rechte und Absicht betrifft, liegt in WordPress und damit beim Kunden, und daran ändert kein Hoster etwas:

Benutzerkonten und Rollen: ein eigener Benutzer je Agent mit der kleinsten passenden Rolle, nie das Administratorkonto. Die Anleitung steht im Beitrag zu Anwendungspasswörtern und Rollen.
Anwendungspasswörter: eines je Client, regelmäßig durchgesehen, unbekannte und ungenutzte widerrufen.
Die Wahl des MCP-Plugins und seiner Schutzmechanismen: Freigabelisten, Nur-Lesen-Schalter, Probelauf, Bestätigungs-Token, Rücksicherung. Der Vergleich steht im Beitrag zu den MCP-Plugins im Vergleich.
Die Entscheidung, welche Fähigkeiten überhaupt freigegeben werden, und die Reihenfolge: erst lesend, Protokoll prüfen, dann schreibend.
Das Aktivitätsprotokoll im Backend und die Routine, es zu lesen.
Der Umgang mit Daten: Ein Agent, der Kommentare, Bestellungen oder Benutzerlisten liest, verarbeitet personenbezogene Daten, und zwar über einen Anbieter, der nicht der Hoster ist. Ob dafür ein Vertrag zur Auftragsverarbeitung mit dem Anbieter des Agenten nötig ist, klärt der Kunde mit seinem Datenschutzbeauftragten oder Anwalt; der Hoster kann diese Frage nicht beantworten, weil er den Agenten nicht kennt.
Die Freigabe von Updates: Zahlungs-, Versand- und Steuer-Plugins in Shops bleiben beim Menschen mit Testbestellung, wie im Beitrag zu Plugin-Updates durch Agenten beschrieben.

Eine Arbeitsteilung, die funktioniert

Der Hoster hält die Tür: Pfade, Drosselung, DISALLOW_FILE_MODS, Must-Use-Plugin mit Opt-in und Protokoll, Sicherung und Staging. Der Kunde vergibt die Schlüssel: Benutzer, Rollen, Passwörter, Werkzeug, Freigaben, Routine. Beides zusammen ergibt ein Modell, das dem von WordPress.com nahekommt, ohne dass jemand seine Installation dorthin umziehen müsste. Was fehlt, ist auf beiden Seiten dasselbe: dass es ausgesprochen, vereinbart und in die Leistungsbeschreibung geschrieben wird. Für Kunden, die das mit ihrem Hoster klären wollen, ist die Fragenliste oben der Anfang. Für Hoster, die das anbieten wollen, sind die drei Stellschrauben im Must-Use-Plugin der Punkt, an dem sie sich vom reinen Pfadblocker absetzen können.

Quellen

Kurz beantwortet

Kann mein Hoster KI-Agenten komplett aussperren?

Den Zugangsweg ja: Sperren der MCP- und Abilities-Pfade am Webserver, dazu per Must-Use-Plugin Anwendungspasswörter für alle oder für Administratoren sperren. Zugriffe über die klassische REST-Schnittstelle bleiben, solange Anwendungspasswörter aktiv sind.

Erkennt der Hoster, ob ein Agent berechtigt ist?

Nein. Eine Anfrage mit gültigem Anwendungspasswort ist für den Webserver eine berechtigte Anfrage. Rechte und Absicht liegen in WordPress und damit beim Kunden.

Was ist die wichtigste Hoster-Leistung für Agentenbetrieb?

Tagesbackup mit schneller, gezielter Rücksicherung und eine Staging-Umgebung. Dahinter der Schalter DISALLOW_FILE_MODS gegen Plugin-Installationen aus dem Chat und ein Must-Use-Plugin, das den MCP-Standardserver erst nach Freigabe anlegt.

Managed WordPress gegen KI-Agenten-Zugriff: Was ein Hoster absichern kann, was er nicht sehen kann und was beim Kunden bleibt