Un agent connecté à un serveur MCP avec un compte administrateur complet peut techniquement tout faire sur un site, alors qu’il n’a besoin, dans les faits, que de trois ou quatre actions précises pour remplir sa mission. Cet écart entre les droits accordés et les droits réellement utilisés constitue le point de départ d’une architecture par matrice de permissions, plutôt que par rôle unique.
Cette approche consiste à décomposer les droits d’un agent en une grille croisant chaque outil MCP disponible avec la capacité WordPress précise qu’il requiert, rendant visible d’un seul coup d’œil ce que l’agent peut réellement faire, sans avoir à parcourir le code de chaque callback.
Le problème du rôle unique
Attribuer un rôle WordPress classique — administrateur, éditeur — à un compte technique utilisé par un agent simplifie la configuration initiale, mais élargit ses droits à l’ensemble de ce que ce rôle autorise, bien au-delà des quelques outils que l’agent appelle réellement. Un agent de modération de commentaires, par exemple, n’a aucune raison de disposer d’un rôle capable de modifier les réglages du site.
Construire la matrice outil par outil
La matrice associe, pour chaque outil MCP exposé, la capacité WordPress minimale strictement nécessaire à son exécution, plutôt qu’un rôle global. Cette grille se construit en listant d’abord tous les outils disponibles, puis en déterminant, pour chacun, la capacité la plus restrictive qui permette encore son fonctionnement correct.
| Outil MCP | Capacité requise | Portée additionnelle |
|---|---|---|
| lister_commentaires_en_attente | moderate_comments | aucune |
| approuver_commentaire | moderate_comments | score de confiance supérieur à 0,8 |
| creer_brouillon | edit_posts | catégorie actualités uniquement |
| purger_cache | manage_options | limité à un cache d’objet, pas aux réglages |
Un compte technique par matrice, pas par rôle
Chaque agent dispose d’un compte technique dédié, dont les capacités sont ajustées précisément pour correspondre à la ligne la plus large de sa propre matrice, plutôt que d’hériter d’un rôle WordPress prédéfini pensé pour un utilisateur humain.
function wpm_creer_compte_agent( string $nom_agent, array $capacites_requises ): int {
$utilisateur_id = wp_insert_user( array(
'user_login' => 'agent-' . $nom_agent,
'role' => 'sans_role_par_defaut',
) );
$utilisateur = new WP_User( $utilisateur_id );
foreach ( $capacites_requises as $capacite ) {
$utilisateur->add_cap( $capacite );
}
return $utilisateur_id;
}Ce que la matrice rend visible immédiatement
- Chaque outil et la capacité exacte qui lui est associée, sans ambiguïté
- Les portées additionnelles qui restreignent encore l’usage d’une capacité large
- Les outils qui partagent une même capacité, utile pour évaluer l’impact d’un retrait
- Les écarts entre ce qui est documenté et ce que le code applique réellement, lors d’une revue
Maintenir la matrice à jour
La matrice perd toute sa valeur si elle n’est pas mise à jour à chaque ajout d’outil MCP. La pratique retenue consiste à faire de la mise à jour de la matrice une étape obligatoire de la revue de code, au même titre que l’ajout d’un test unitaire, plutôt qu’une documentation annexe rédigée après coup.
Sur nos projets, la matrice de permissions se relit en quelques minutes lors d’un audit, alors qu’un audit du code dispersé sur douze outils différents prendrait facilement une demi-journée.
Limites de cette approche
Une matrice de permissions ne remplace pas une vérification de portée fine à l’intérieur même du callback — comme une catégorie ou un statut de publication autorisé — qui doit continuer d’être codée explicitement. La matrice documente l’intention et sert de référence pour l’audit, sans se substituer au contrôle d’accès effectivement exécuté par le code.
Notre verdict
Une matrice de permissions, croisant chaque outil MCP avec sa capacité minimale requise, offre une lisibilité et un niveau de contrôle qu’un rôle WordPress unique ne peut pas égaler pour un agent dont les besoins réels restent volontairement restreints.
