Eine WordPress-Berechtigungstestmatrix für KI-Agenten erstellen

Eine Berechtigungsmatrix muss für jede KI-Identität sowohl erlaubte als auch verweigerte WordPress-Aktionen belegen und darf nicht lediglich vorgesehene Rollen auflisten oder eine erfolgreiche Anfrage zeigen.

KI ist hier vor allem als Beweisorganisator, Vergleichs-Engine und Entwurfsassistent nützlich. Sie kann eine komplexe WordPress-Aufgabe leichter prüfbar machen, aber keine fehlende Autorität schaffen, nicht beobachtete Fakten zertifizieren oder eine Empfehlung stillschweigend in eine Handlungserlaubnis verwandeln.

In einem Satz: Eine Berechtigungsmatrix muss für jede KI-Identität sowohl erlaubte als auch verweigerte WordPress-Aktionen belegen und darf nicht lediglich vorgesehene Rollen auflisten oder eine erfolgreiche Anfrage zeigen.

Was Sie mit diesem Leitfaden erreichen

Erstellen Sie eine ausführbare Matrix, die Identitäten, Fähigkeiten, Objekte, Zustände und erwartete Ergebnisse mit reproduzierbaren positiven und negativen Beweisen verknüpft.

• Eine Berechtigungsmatrix nach Identität und Aktion mit exakten erwarteten Antworten.
• Positive, negative, Objekteigentums- und Zustandsübergangs-Fixtures.
• Eine Unterscheidung zwischen Authentifizierungsfehler, Autorisierungsverweigerung, Validierungsfehler und nicht unterstützter Fähigkeit.
• Eine Regressionssuite für geschützte Modi und benutzerdefinierte Fähigkeiten.

Das fertige Artefakt muss für die entscheidungsverantwortliche Person verständlich und für jemanden reproduzierbar sein, der nicht am ursprünglichen Prompt beteiligt war. Eine flüssige Antwort reicht nicht. Jede wesentliche Schlussfolgerung benötigt eine Quelle, einen Umfang und einen Verifizierungsweg. Wenn die Beweise etwas nicht belegen können, ist die richtige Ausgabe ein explizit Unbekanntes oder eine testbare Hypothese.

Vorzubereitende Beweise und Eingaben

• Die aktuellen Abdeckungsverträge für Rollen, Fähigkeiten und WP Agent Control.
• Registrierte REST-Routen oder Fähigkeiten und ihre Berechtigungs-Callbacks.
• Dedizierte Testbenutzer und sichere WordPress-Fixtures.
• Erwartete Ergebnisse auf HTTP-, Tool- oder Anwendungsebene.
• Einen Plan zur sauberen Umgebungsrücksetzung und Beweisaufbewahrung.

Entfernen Sie Anmeldedaten, geheime Werte und nicht verwandte persönliche Informationen, bevor Sie einem Assistenten Beweise bereitstellen. Bewahren Sie die Kennungen, Versionen, Zeitstempel, Locale, Einheiten und Quellbezeichnungen, die zur Interpretation des Rests nötig sind. Ein Screenshot ohne URL, Zustand oder Datum kann nützlicher Kontext sein, ist aber selten ausreichende Autorität für eine Produktionsentscheidung.

Beginnen Sie nicht mit einer breiten Anfrage wie „prüfe dies“, „behebe dies“ oder „verbessere dies“. Definieren Sie die Entscheidung, die die Arbeit unterstützen soll, die eingeschlossene Population, die für jedes Feld maßgebliche Quelle, erlaubte Vorgänge und weiterhin verbotene Aktionen. Die Planungs- oder Forschungsphase sollte ein lokales Repository, eine isolierte Fixture oder exportierte Beweise verwenden und benötigt keinen Produktionszugriff auf WordPress.

Rollenabsicht ist kein Berechtigungsbeweis

Die Matrix muss den tatsächlichen Endpunkt, die Fähigkeit oder die WordPress-Aktion im jeweiligen Objektzustand ausführen.

Eine Verweigerung braucht eine Klassifizierung

401, 403, Validierungsfehler und nicht unterstützte Vorgänge haben unterschiedliche Bedeutungen. Nur „fehlgeschlagen“ aufzuzeichnen, verdeckt die tatsächlich getestete Kontrolle.

Objekt und Zustand sind wichtig

Eine Identität kann ihren eigenen Entwurf bearbeiten, aber nicht den Beitrag eines anderen Autors, oder einen Entwurf aktualisieren, aber keine veröffentlichte Seite. Testen Sie die relevanten Grenzen.

Beobachtung, Schlussfolgerung und Autorität getrennt halten

Eine kontrollierte Prüfung sollte mindestens vier Zustände unterscheiden:

1. Beobachtet: direkt in einem benannten Datensatz, einer Datei, Antwort, gerenderten Seite oder ausgeführten Test vorhanden.
2. Abgeleitet: eine plausible, durch Beweise gestützte, aber nicht direkt festgestellte Interpretation.
3. Empfohlen: eine vorgeschlagene menschliche Entscheidung oder nächste Aktion.
4. Autorisiert und verifiziert: eine separat genehmigte Änderung, die ausgeführt und anschließend anhand der Akzeptanzkriterien geprüft wurde.

KI-Ausgaben beginnen üblicherweise in den ersten drei Zuständen. Sie werden nicht autorisiert, nur weil sie detailliert, intern konsistent oder technisch überzeugend sind. Bewahren Sie diese Unterscheidung in Tabellen, Berichten, Tickets und öffentlichen Fallstudien.

Ein sicherer Workflow

1. Identitäten, Profile, Routen, Fähigkeiten, Objekte und Zustände inventarisieren.
2. Für jede wesentliche Zelle das erwartete Zulassungs- oder Verweigerungsergebnis und die Begründung definieren.
3. Isolierte Fixtures mit stabilen IDs und Rücksetzverfahren erstellen.
4. Erlaubte Fälle ausführen und exakte Anfrage- und Ergebnisbeweise aufbewahren.
5. Verbotene, fehlerhafte und nicht zum Umfang gehörende Fälle ausführen.
6. Jede Abweichung untersuchen, ohne Berechtigungen zu erweitern, damit der Test besteht.
7. Verifizierte Fälle, wo praktikabel, der automatisierten Regressionsabdeckung hinzufügen.
8. Nur eine bereinigte Matrix veröffentlichen und temporäre Identitäten widerrufen.

Diese Reihenfolge platziert bewusst eine verantwortliche Prüfung zwischen Analyse und Implementierung. Benötigt eine spätere Phase breiteren Zugriff, erstellen Sie eine neue Aufgabe, eine neue Identität oder eine explizite Berechtigungsänderung. Stufen Sie die analytische Identität nicht stillschweigend hoch, weil sie eine korrekte Grenze erreicht hat.

Prompt-Rezept

Ersetzen Sie vor der Verwendung des Prompts jeden Wert in eckigen Klammern. Fügen Sie keine Passwörter, API-Schlüssel, Authentifizierungs-Cookies, privaten Kundendatensätze oder nicht verwandten persönlichen Informationen ein.

Sie prüfen [TASK SCOPE] für [SITE, REPOSITORY OR DATASET] und verwenden nur die bereitgestellten Beweise.

Ziel:
Erstellen Sie eine ausführbare Matrix, die Identitäten, Fähigkeiten, Objekte, Zustände und erwartete Ergebnisse mit reproduzierbaren positiven und negativen Beweisen verknüpft.

Geben Sie folgende Felder zurück:
- Identität
- Profil
- Objekt
- Zustand
- Aktion
- Route oder Fähigkeit
- Erwartetes Ergebnis
- Erwarteter Status
- Beobachtetes Ergebnis
- Beweis
- Bewertung
- Version

Regeln:
1. Verwenden Sie dedizierte Testidentitäten und Nicht-Produktions-Fixtures.
2. Testen Sie sowohl erlaubte als auch verbotene Aktionen.
3. Bewahren Sie nach der Bereinigung genaue Antwortklassen und Fehlerkörper.
4. Deuten Sie eine unerwartete Verweigerung nicht als Erlaubnis, mehr Zugriff zu gewähren.
5. Veröffentlichen Sie keine Anmeldedaten oder sensiblen Endpunktdetails.

Für jeden Befund:
- identifizieren Sie die genaue Quelle, den Datensatz, die URL, Datei, Zeile, Objekt-ID, den Zustand oder die Datensatzzeile;
- bewahren Sie Daten, Versionen, Einheiten, Locale, Kennungen und Nenner;
- trennen Sie Beobachtung, Schlussfolgerung, Empfehlung und Unbekanntes;
- geben Sie an, welche Beweise nicht verfügbar waren;
- ändern Sie weder WordPress noch Quellcode, Handelsdaten, Analysen, externe Systeme oder veröffentlichte Inhalte.

Warum dieser Prompt so strukturiert ist

Der Prompt schafft einen Beweisvertrag, bevor Empfehlungen angefordert werden. Er macht fehlende Daten sichtbar, verringert die Wahrscheinlichkeit, dass ein Modell einen unvollständigen Datensatz mit plausibler Prosa ergänzt, und erzeugt eine systematisch prüfbare Ausgabe. Strukturierte Felder erleichtern auch den Vergleich wiederholter Läufe oder die Übergabe einer genehmigten Teilmenge an einen späteren Implementierungsworkflow.

Eine Produktionsimplementierung kann JSON-Schema, typisierte Tooleingaben oder automatisierte Validierung ergänzen. Diese Mechanismen verbessern die Konsistenz, belegen jedoch nicht, dass die Quellbeweise wahr, vollständig oder aktuell sind. Menschliche Prüfung und systemspezifische Verifizierung bleiben erforderlich.

Empfohlene Zugriffsgrenze

Verwenden Sie für die in diesem Leitfaden beschriebene Phase keinen WordPress-Zugriff während der Planungs- oder Forschungsphase. Die für eine Identität verfügbaren genauen Fähigkeiten müssen aus der installierten Produktversion, dem veröffentlichten Abdeckungsvertrag und der tatsächlich verwendeten Verbindungsmethode stammen.

Was außerhalb dieser Aufgabe bleiben muss

• Berechtigungsänderungen
• Full-Power-Rückfall
• Produktionstests
• Umschreiben erwarteter Ergebnisse nach der Ausführung
• Nicht unterstützte Sicherheitsgarantien

Eine verweigerte Aktion kann nützlicher Beweis sein, dass die Kontrollgrenze funktioniert. Reagieren Sie nicht auf eine erwartete Verweigerung, indem Sie ein breit angelegtes Administratorkonto oder Full Power gewähren. Bestimmen Sie zuerst, ob die Aktion überhaupt zum aktuellen Mandat gehört. Falls ja, erstellen Sie eine separat autorisierte Phase mit der engsten erforderlichen Fähigkeit.

Wie WP Agent Control passt

Dies ist ein allgemeiner WordPress-Arbeitsablauf. Er verspricht nicht, dass Agent Control alle beschriebenen Objekte oder Integrationen bearbeiten kann. Beginnen Sie im geführten Ablauf mit öffentlichen Seiten. Aktionen für Plugins, Themes, Benutzer, Einstellungen, Dateien, Löschungen, WooCommerce, ACF und Page Builder sind keine nativen geführten Aufgaben. Prüfen Sie dafür gesondert geeignete Werkzeuge und Berechtigungen.

Rufen Sie nach der Verbindung strukturierte Websiteinformationen ab und untersuchen Sie ausgewählte veröffentlichte Seiten. Dafür ist keine temporäre Aufgabe nötig. Öffentliche Seiten lassen sich auch ohne das Plugin besuchen; Agent Control ergänzt strukturierten Zugriff und den Übergang zu autorisierten WordPress-Arbeiten.

Ihre KI verbinden: docs first profile · Funktionen und Kompatibilität ansehen: coverage

Verifizierungscheckliste

• ☐ Aufgabe, Population, Zeitraum, Umgebung und Entscheidung sind explizit.
• ☐ Jede wesentliche Beobachtung ist mit genauen Beweisen verknüpft oder als Hypothese gekennzeichnet.
• ☐ Stabile IDs, URLs, Versionen, Daten, Einheiten, Locales und Nenner sind erhalten.
• ☐ Fehlende Beweise und Abdeckungsgrenzen bleiben sichtbar.
• ☐ Die analytische oder Forschungsidentität hat keine verbotene Mutation durchgeführt.
• ☐ Ein qualifizierter Verantwortlicher hat gegebenenfalls Sicherheits-, Barrierefreiheits-, Rechts-, Handels- oder Release-Auswirkungen geprüft.
• ☐ Jede Implementierung hat ein separates Mandat, Zugriffslevel, Backup und einen Verifizierungsplan.
• ☐ Temporäre Identitäten, Fixtures und sensible Beweise werden nach der Aufgabe widerrufen, zurückgesetzt oder entsorgt.

Häufige Fehlermodi

• Nur-Erfolg-Demonstration: Die Matrix beweist, dass eine Aktion funktioniert, aber nie, dass verbotene Aktionen fehlschlagen.
• Rollenname als Ersatz: Erwartete Ergebnisse werden aus Rollenbezeichnungen kopiert, ohne gefilterte oder benutzerdefinierte Fähigkeiten zu testen.
• Fixture-Kontamination: Ein Test verändert den Objektzustand und entwertet spätere Ergebnisse.
• Verweigerungsnivellierung: Alle Fehler werden als gleichwertig behandelt; dadurch werden Authentifizierungs- oder Validierungsfehler verborgen.

Ein wiederkehrender übergreifender Fehler ist Berechtigungsdrift: Die anfängliche Aufgabe trifft auf eine Grenze, und der Operator erweitert den Zugriff, bevor festgestellt wird, ob der fehlende Vorgang notwendig, unterstützt oder sicher ist. Das zerstört den Beweiswert der Verweigerung und macht spätere Ergebnisse schwer zuzuordnen.

Erweiterte Anmerkung

Eine gesteuerte Berechtigungsmatrix kann aus dem deklarierten Autoritätsgraphen erzeugt werden, doch bleibt die Deklaration lediglich eine Erwartung, bis ausgeführte Beweise jede wesentliche Zelle bestätigen. Unerwartete Zulassungen sind Fehler; erwartete Verweigerungen sind Produktbeweis.

Verwandte Leitfäden

• Welche WordPress-Zugriffsstufe sollten Sie einer KI geben?
• Leitfaden zur WordPress Abilities API für KI-Workflows
• So stellen Sie eine benutzerdefinierte WordPress Ability über MCP bereit
• Einen WordPress-Testplan mit KI erstellen

Nächster Schritt

Fahren Sie mit dem relevantesten unterstützenden Leitfaden fort und verwenden Sie vor jeder authentifizierten Aufgabe den Leitfaden zu Zugriffsstufen. Wenn temporärer WordPress-Zugriff nicht mehr benötigt wird, schließen Sie mit dem Widerruf der Identität ab.