Wer merkt, was der Agent tut? Protokolle für KI-Agenten in WordPress: Simple History, Kern-Hook, Plugin-Logs, Server-Logs

WordPress führt kein Protokoll. Ein KI-Agent, der nachts zwanzig Seiten umschreibt und drei Plugins aktualisiert, hinterlässt nur das, was jede Änderung hinterlässt: Revisionen, geänderte Daten, neue Versionsnummern. Wer das war, mit welchem Werkzeug und in welcher Reihenfolge, steht nirgends. Seit WordPress 7.1 gibt es immerhin einen vorgesehenen Haken dafür, aber ohne Plugin hängt daran nichts. Dieser Beitrag gehört zur Betriebsanleitung für KI-Agenten in WordPress und beantwortet die zweite ihrer beiden Fragen.

Quelle 1: der Haken im Kern

Mit 7.1 feuert die Aktion wp_ability_invoked zu Beginn jeder Ausführung einer Fähigkeit aus der Abilities API. Das Core-Team nennt als Zweck ausdrücklich Protokollierung und Telemetrie und warnt im selben Atemzug davor, rohe Eingaben mitzuschreiben, weil sie Zugangsdaten oder personenbezogene Daten enthalten können. Für Betreiber heißt das: Der Kern stellt den Anschluss bereit, das Protokoll selbst kommt aus einem Plugin oder aus ein paar Zeilen Code, die ein Entwickler in ein Must-Use-Plugin legt. Der Haken sieht nur Aufrufe über die Abilities API. Ein Agent, der die klassische REST-Schnittstelle oder WP-CLI benutzt, geht an ihm vorbei.

Quelle 2: Simple History

Das Aktivitätsprotokoll Simple History ist für die meisten Seiten, die ich betreue, die praktikable Lösung, weil es ohne Konfiguration arbeitet. Seit Version 5.27.0 erkennt es, ob eine Aktion von einem KI-Werkzeug ausgelöst wurde, und zeigt neben dem Benutzer ein Symbol und den Namen des Agenten. Die Erkennung stützt sich laut Dokumentation auf sechs Signale, von zuverlässig bis weich: Aufrufe über die Abilities API, eine signierte Kopfzeile verifizierter Agenten, eine Kopfzeile von MCP-Clients wie Cursor oder Claude Code, der User-Agent, eine Umgebungsvariable bei WP-CLI-Aufrufen und ein Auffangmuster für neue Werkzeuge. Der User-Agent lässt sich fälschen, das sagt der Hersteller selbst.

Seit 5.28.0 vom 19.05.2026 protokolliert das Plugin außerdem Änderungen über WP-CLI und die REST-Schnittstelle an Beiträgen, Benutzern, Medien, Menüs, Widgets und Einstellungen, also genau die Wege, die Agenten nehmen. Der angemeldete Benutzer bleibt der Verantwortliche im Protokoll; das Agenten-Etikett sagt, wie die Aktion zustande kam, nicht wer sie wollte. Das ist die richtige Darstellung, denn der Agent handelt im Auftrag dessen, der ihm das Anwendungspasswort gegeben hat.

Quelle 3: das Protokoll des MCP-Plugins

Wer ein MCP-Plugin einsetzt, hat damit meist ein eigenes Aufrufprotokoll, und das ist genauer als jedes Aktivitätsprotokoll, weil es die Absicht sieht und nicht nur das Ergebnis:

• Agent Abilities for MCP zeichnet jeden Aufruf auf, abgelehnte eingeschlossen, mit Benutzer oder Verbindung und den Namen der übergebenen Parameter, ohne deren Inhalt.
• Agent Toolbelt speichert Aufrufer, Benutzer, eine Prüfsumme der Eingabe und das Ergebnis, 90 Tage lang, und markiert verweigerte Versuche als „denied“.
• Cowboy MCP protokolliert jeden Werkzeugaufruf, jeden Fehler und jede Anmeldung, 30 Tage lang, filterbar nach Schlüssel und Werkzeug.

Der offizielle MCP-Adapter selbst protokolliert nicht. Er bringt eine Schnittstelle für Beobachtung mit, an die ein Entwickler eigene Zähler und Protokolle hängen kann; ohne diese Arbeit bleibt er stumm.

Quelle 4: Anwendungspasswörter und Server-Logs

Die Tabelle der Anwendungspasswörter im Benutzerprofil ist das einfachste Frühwarnsystem: „Zuletzt verwendet“ und „Letzte IP“ je Passwort. Ein Blick pro Woche zeigt, ob ein Zugang aktiv ist, der es nicht sein sollte. Das Zugriffsprotokoll des Webservers, das viele Hoster bereitstellen, ergänzt die Sicht um Zeitpunkt, Pfad und Herkunft jeder Anfrage an /wp-json/mcp/ oder /wp-json/wp-abilities/. Es ist das einzige Protokoll, das auch fehlgeschlagene Anmeldeversuche zeigt.

Die Lücke, die bleibt

Keine dieser Quellen zeigt, was ein Agent gelesen hat. Lesende Fähigkeiten verändern nichts, also tauchen sie in Aktivitätsprotokollen nicht auf. Wer wissen will, ob ein Agent Kundendaten aus WooCommerce oder Benutzerlisten abgefragt hat, braucht das Aufrufprotokoll des MCP-Plugins oder den Haken im Kern mit eigener Protokollierung. Für Seiten mit personenbezogenen Daten ist das kein Detail: Eine Abfrage ist eine Verarbeitung, und ein Agent, der mit Redakteursrechten die Kommentare samt E-Mail-Adressen liest, hat Daten verarbeitet, ohne dass es jemand sieht. Wie die Zugänge selbst sauber eingerichtet werden, steht im Beitrag zu Anwendungspasswörtern und Rollen.

Quellen

• Make WordPress Core: Abilities API improvements in WordPress 7.1 (31.07.2026)
• Simple History: AI agent detection
• Simple History 5.28.0 released (19.05.2026)

Kurz beantwortet

Protokolliert WordPress Agentenaktionen von selbst?

Nein. Seit 7.1 gibt es den Haken wp_ability_invoked, aber ohne Plugin oder eigenen Code wird nichts gespeichert.

Welches Plugin reicht für eine normale Firmenseite?

Simple History ab Version 5.27, weil es Agentenaktionen ohne Konfiguration kennzeichnet und seit 5.28 auch Änderungen über REST und WP-CLI erfasst.

Sehe ich, welche Daten ein Agent gelesen hat?

Nur im Aufrufprotokoll eines MCP-Plugins oder über eigene Protokollierung am Kern-Haken. Aktivitätsprotokolle zeigen nur Änderungen.