Un agent connecté à une route REST personnalisée hérite-t-il des mêmes droits que le compte qui a généré son jeton d’accès ? La réponse, dans la configuration par défaut de WordPress, est oui — et c’est précisément ce qui doit alerter avant de brancher un agent IA en lecture-écriture sur une route métier. Cette checklist ne traite pas de la conception fonctionnelle de l’agent lui-même, mais de la vérification qu’il n’hérite pas, par facilité, de droits plus larges qu’un compte de service dédié n’en accorderait.
Le scénario à risque
Un développeur, pour tester rapidement une intégration d’agent conversationnel avec une route REST de gestion des commandes, génère un jeton d’application depuis son propre compte administrateur. L’intégration fonctionne, passe en recette, puis en production sans jamais revenir sur ce choix initial pris pour aller vite. L’agent dispose alors, via ce jeton, de l’ensemble des capacités du compte administrateur d’origine — bien au-delà de la lecture et de l’écriture sur les commandes, seul périmètre réellement nécessaire à sa mission.
La checklist de vérification
- Identifier le compte réellement associé au jeton utilisé par l’agent — s’il s’agit d’un compte humain nominatif, en particulier un compte administrateur, la connexion doit être considérée comme non conforme.
- Créer un compte de service dédié, avec un rôle personnalisé ne portant que les capacités strictement nécessaires à la route REST concernée.
- Vérifier la fonction
permission_callbackde chaque route exposée à l’agent, en s’assurant qu’elle vérifie explicitement une capacité précise plutôt qu’un simpleis_user_logged_in()trop permissif. - Confirmer que la révocation du jeton de l’agent n’affecte aucun autre accès, ce qui n’est possible que si le compte est réellement dédié et non partagé avec un usage humain.
- Documenter la portée exacte du compte de service dans un registre interne, avec la date de création et le responsable de la connexion.
Un exemple de permission_callback correctement resserrée
register_rest_route('domaine/v1', '/commandes/(?P<id>\d+)', array(
'methods' => array('GET', 'PATCH'),
'callback' => 'domaine_gerer_commande',
'permission_callback' => function ($requete) {
$utilisateur = wp_get_current_user();
return in_array('agent_commandes', (array) $utilisateur->roles, true)
&& current_user_can('gerer_commandes_agent');
},
));
Cette vérification refuse la requête à tout compte ne portant pas précisément le rôle attendu, y compris un compte administrateur légitime mais non prévu pour cet usage précis, ce qui évite qu’une confusion de jeton n’ouvre accidentellement l’accès à un autre compte que celui de l’agent.
Comparer les deux configurations
| Configuration | Jeton lié à | Impact d’une fuite du jeton |
|---|---|---|
| Compte administrateur personnel | Un développeur nominatif | Accès complet à l’administration du site |
| Compte de service dédié | Un rôle restreint à une route précise | Accès limité à la lecture-écriture des commandes |
Pourquoi cette étape est souvent sautée
Créer un compte de service dédié demande quelques minutes de plus qu’utiliser un compte déjà existant, et cette différence paraît négligeable au moment du développement initial. Le coût réel apparaît plus tard : lorsqu’il faut révoquer l’accès de l’agent sans perturber le développeur dont le compte a servi de raccourci, ou lorsqu’un audit de sécurité ne parvient pas à distinguer les actions de l’agent de celles du compte humain dans les journaux d’activité.
Ce que change un compte de service au quotidien
Une fois le compte dédié en place, la maintenance devient nettement plus simple à suivre dans la durée. Un changement de mot de passe du développeur, par exemple, n’a plus aucune incidence sur le fonctionnement de l’agent, puisque son jeton ne dépend plus de ce compte personnel. De la même façon, si le développeur quitte l’équipe ou change de poste, la désactivation de son compte administrateur ne coupe plus, par effet de bord, une intégration en production dont plus personne ne se souvenait qu’elle dépendait de ce compte précis.
Cette séparation facilite aussi les audits périodiques : il suffit de filtrer les journaux d’activité par identifiant du compte de service pour isoler exactement les actions effectuées par l’agent, sans avoir à démêler ce qui relève d’un usage humain de ce qui relève d’un appel automatisé passé par la même session. Sur un site où plusieurs intégrations coexistent, cette lisibilité fait souvent la différence entre une investigation rapide et une reconstitution laborieuse après coup.
En résumé
Brancher un agent IA sur une route REST métier sans compte de service dédié revient à lui prêter, sans le vouloir, tous les droits du compte qui a généré son jeton. La création d’un compte restreint, associé à une capacité précise et vérifié explicitement dans chaque permission_callback, referme cette confusion avant qu’elle ne devienne un incident.
