Comment créer une matrice de test des autorisations WordPress pour les agents IA

Une matrice d’autorisations doit prouver les actions WordPress à la fois autorisées et refusées pour chaque identité IA, et non simplement énumérer les rôles prévus ou démontrer une requête réussie.

L’IA est ici surtout utile comme organisateur de preuves, moteur de comparaison et assistant de rédaction. Elle peut rendre une tâche WordPress complexe plus facile à examiner, mais elle ne peut pas créer une autorité manquante, certifier des faits qu’elle n’a pas observés ou transformer silencieusement une recommandation en autorisation d’agir.

En une phrase : une matrice d’autorisations doit prouver les actions WordPress à la fois autorisées et refusées pour chaque identité IA, et non simplement énumérer les rôles prévus ou démontrer une requête réussie.

Ce que ce guide vous aide à accomplir

Construire une matrice exécutable qui relie les identités, capacités, objets, états et résultats attendus à des preuves positives et négatives reproductibles.

• Une matrice d’autorisations identité par action avec les réponses attendues exactes.
• Des fixtures positives, négatives, de propriété des objets et de transition d’état.
• Une distinction entre échec d’authentification, refus d’autorisation, échec de validation et capacité non prise en charge.
• Une suite de régression pour les modes protégés et les capacités personnalisées.

L’artefact final doit être compréhensible par la personne responsable de la décision et reproductible par une personne qui n’a pas participé au prompt initial. Une réponse fluide ne suffit pas. Toute conclusion importante exige une source, un périmètre et un chemin de vérification. Lorsque les preuves ne permettent pas d’établir un élément, la sortie correcte est un inconnu explicite ou une hypothèse vérifiable.

Preuves et entrées à préparer

• Les contrats de couverture actuels des rôles, capacités et de WP Agent Control.
• Les routes REST ou capacités enregistrées et leurs rappels de contrôle des autorisations.
• Des utilisateurs de test dédiés et des fixtures WordPress sûres.
• Les résultats attendus aux niveaux HTTP, outil ou application.
• Un plan de réinitialisation d’environnement propre et de conservation des preuves.

Avant de fournir des preuves à un assistant, retirez les identifiants, valeurs secrètes et renseignements personnels non pertinents. Conservez les identifiants, versions, horodatages, paramètres régionaux, unités et étiquettes de source nécessaires pour interpréter ce qui reste. Une capture d’écran sans URL, état ou date peut être un contexte utile, mais elle est rarement une autorité suffisante pour une décision de production.

Ne commencez pas par une demande générale telle que « révisez ceci », « corrigez ceci » ou « améliorez ceci ». Définissez la décision que le travail doit soutenir, la population incluse, la source qui fait autorité pour chaque champ, les opérations permises et les actions qui restent interdites. L’étape de planification ou de recherche doit utiliser un dépôt local, une fixture isolée ou des preuves exportées et ne requiert pas d’accès à WordPress en production.

L’intention du rôle n’est pas une preuve d’autorisation

La matrice doit exercer le point de terminaison, la capacité ou l’action WordPress réel dans l’état d’objet pertinent.

Un refus doit être classifié

401, 403, les erreurs de validation et les opérations non prises en charge ont des significations différentes. N’enregistrer que « échec » masque le contrôle réellement testé.

L’objet et l’état comptent

Une identité peut modifier son propre brouillon, mais pas l’article d’un autre auteur, ou mettre à jour un brouillon, mais pas une page publiée. Testez les limites pertinentes.

Garder séparées observation, inférence et autorité

Un examen contrôlé doit distinguer au moins quatre états :

1. Observé : présent directement dans un enregistrement, fichier, réponse, page rendue ou test exécuté nommé.
2. Inféré : une interprétation plausible étayée par des preuves, mais non établie directement.
3. Recommandé : une décision humaine ou prochaine action proposée.
4. Autorisé et vérifié : une modification approuvée séparément, exécutée puis vérifiée par rapport aux critères d’acceptation.

La sortie d’IA commence habituellement dans les trois premiers états. Elle ne devient pas autorisée simplement parce qu’elle est détaillée, cohérente en interne ou techniquement convaincante. Préservez cette distinction dans les tableaux, rapports, tickets et études de cas publiques.

Un flux de travail sûr

1. Inventorier les identités, profils, routes, capacités, objets et états.
2. Définir le résultat attendu d’autorisation ou de refus et la justification pour chaque cellule importante.
3. Créer des fixtures isolées avec des ID stables et des procédures de réinitialisation.
4. Exécuter les cas autorisés et conserver les preuves exactes de la requête et du résultat.
5. Exécuter les cas interdits, mal formés et hors périmètre.
6. Examiner tout écart sans élargir les autorisations pour faire réussir le test.
7. Ajouter les cas vérifiés à la couverture de régression automatisée lorsque c’est pratique.
8. Ne publier qu’une matrice assainie et révoquer les identités temporaires.

Cette séquence place délibérément une revue responsable entre l’analyse et l’implémentation. Si une étape ultérieure exige un accès plus large, créez une nouvelle tâche, une nouvelle identité ou un changement d’autorisation explicite. Ne mettez pas discrètement à niveau l’identité analytique parce qu’elle a atteint une limite correcte.

Recette de prompt

Remplacez chaque valeur entre crochets avant d’utiliser le prompt. Ne collez pas de mots de passe, clés API, témoins d’authentification, dossiers clients privés ou renseignements personnels non pertinents.

Vous examinez [TASK SCOPE] pour [SITE, REPOSITORY OR DATASET] en utilisant uniquement les preuves fournies.

Objectif :
Construisez une matrice exécutable qui relie les identités, capacités, objets, états et résultats attendus à des preuves positives et négatives reproductibles.

Retournez les champs suivants :
- Identité
- Profil
- Objet
- État
- Action
- Route ou capacité
- Résultat attendu
- État attendu
- Résultat observé
- Preuve
- Décision
- Version

Règles :
1. Utilisez des identités de test dédiées et des fixtures hors production.
2. Testez les actions à la fois autorisées et interdites.
3. Conservez les classes de réponse et les corps d’erreur exacts après assainissement.
4. Ne réinterprétez pas un refus inattendu comme une autorisation d’accorder plus d’accès.
5. Ne publiez pas d’identifiants ni de détails sensibles de points de terminaison.

Pour chaque constat :
- identifiez la source, l’enregistrement, l’URL, le fichier, la ligne, l’ID d’objet, l’état ou la ligne de jeu de données exacts ;
- conservez les dates, versions, unités, paramètres régionaux, identifiants et dénominateurs ;
- séparez observation, inférence, recommandation et inconnu ;
- indiquez quelles preuves n’étaient pas disponibles ;
- ne modifiez pas WordPress, le code source, les données commerciales, les analyses, les systèmes externes ou le contenu publié.

Pourquoi ce prompt est structuré ainsi

Le prompt établit un contrat de preuve avant de demander des recommandations. Il rend les données manquantes visibles, réduit la probabilité qu’un modèle complète un enregistrement incomplet avec un texte plausible et produit une sortie qui peut être examinée systématiquement. Les champs structurés facilitent aussi la comparaison d’exécutions répétées ou la transmission d’un sous-ensemble approuvé à un flux d’implémentation ultérieur.

Une implémentation de production peut ajouter un schéma JSON, des entrées d’outils typées ou une validation automatisée. Ces mécanismes améliorent la cohérence, mais ils n’établissent pas que les preuves sources sont vraies, complètes ou actuelles. Une revue humaine et une vérification propre au système demeurent nécessaires.

Limite d’accès recommandée

Utilisez aucun accès à WordPress pendant l’étape de planification ou de recherche pour l’étape décrite dans ce guide. Les capacités exactes disponibles pour une identité doivent découler de la version de produit installée, du contrat de couverture publié et de la méthode de connexion réellement utilisée.

Ce qui doit rester hors de cette tâche

• Modifications d’autorisations
• Repli vers Full Power
• Tests de production
• Réécriture des résultats attendus après exécution
• Garanties de sécurité non prises en charge

Une action refusée peut constituer une preuve utile que la limite de contrôle fonctionne. Ne répondez pas à un refus attendu en accordant un compte administrateur large ou Full Power. Déterminez d’abord si l’action relève du mandat actuel. Si oui, créez une étape autorisée séparément avec la capacité la plus restreinte requise.

Comment WP Agent Control s’intègre

Ce guide décrit un travail général dans WordPress, sans promettre qu’Agent Control peut modifier chaque objet ou intégration abordé. Dans le parcours guidé, commencez par les pages publiques. Les opérations sur les plugins, thèmes, utilisateurs, réglages, fichiers, suppressions, WooCommerce, ACF et constructeurs ne sont pas des tâches guidées natives. Utilisez des outils et permissions qualifiés séparément au besoin.

Obtenez des informations structurées sur le site et examinez des pages publiées après la connexion. Cette lecture publique ne nécessite aucune tâche temporaire. Vous pouvez aussi consulter les pages publiques sans le plugin ; Agent Control ajoute un accès structuré et la continuité vers du travail WordPress autorisé.

Connecter votre IA : docs first profile · Voir les fonctions et la compatibilité : coverage

Liste de vérification

• ☐ La tâche, la population, la période, l’environnement et la décision sont explicites.
• ☐ Chaque observation importante est liée à une preuve exacte ou étiquetée comme hypothèse.
• ☐ Les ID, URL, versions, dates, unités, paramètres régionaux et dénominateurs stables sont conservés.
• ☐ Les preuves manquantes et les limites de couverture restent visibles.
• ☐ L’identité analytique ou de recherche n’a effectué aucune mutation interdite.
• ☐ Un responsable qualifié a examiné les implications de sécurité, d’accessibilité, juridiques, commerciales ou de publication lorsque pertinent.
• ☐ Toute implémentation a un mandat, un niveau d’accès, un plan de sauvegarde et un plan de vérification distincts.
• ☐ Les identités temporaires, fixtures et preuves sensibles sont révoquées, réinitialisées ou éliminées après la tâche.

Modes d’échec courants

• Démonstration de réussite uniquement : la matrice prouve qu’une action fonctionne, mais jamais que les actions interdites échouent.
• Substitut du nom de rôle : les résultats attendus sont copiés à partir des étiquettes de rôle sans tester les capacités filtrées ou personnalisées.
• Contamination de fixture : un test modifie l’état de l’objet et invalide les résultats ultérieurs.
• Aplatissement des refus : tous les échecs sont traités comme équivalents, ce qui masque les défauts d’authentification ou de validation.

Un échec transversal récurrent est la dérive d’autorisations : la tâche initiale rencontre une limite, et l’opérateur élargit l’accès avant de déterminer si l’opération manquante est nécessaire, prise en charge ou sûre. Cela détruit la valeur probante du refus et rend les résultats ultérieurs difficiles à attribuer.

Note avancée

Une matrice d’autorisations gouvernée peut être générée à partir du graphe d’autorité déclaré, mais la déclaration ne reste qu’une attente tant que des preuves exécutées ne confirment pas chaque cellule importante. Les autorisations inattendues sont des défauts ; les refus attendus constituent une preuve du produit.

Guides connexes

• Quel niveau d’accès WordPress devriez-vous donner à une IA ?
• Guide de l’API Abilities de WordPress pour les flux de travail avec l’IA
• Comment exposer une Ability WordPress personnalisée par MCP
• Comment créer un plan de test WordPress avec l’IA

Prochaine étape

Poursuivez avec le guide de soutien le plus pertinent et utilisez le guide des niveaux d’accès avant toute tâche authentifiée. Lorsque l’accès WordPress temporaire n’est plus requis, terminez en révoquant l’identité.