« Cet agent tourne dans un conteneur isolé, il ne peut rien casser. » Cette affirmation, entendue régulièrement lors de la mise en place d’un agent IA connecté à un site WordPress, contient une confusion fréquente entre deux problèmes distincts : l’isolation de l’environnement d’exécution, et la portée des permissions accordées au jeton que cet agent utilise pour agir sur le site distant.
Un conteneur isolé protège effectivement le serveur qui héberge l’agent contre une compromission qui se propagerait au système hôte. Il ne protège absolument pas le site WordPress distant contre les actions que l’agent peut déclencher légitimement via son jeton d’accès, aussi limité que semble son environnement d’exécution local.
Ce que la sandbox protège réellement
Un environnement d’exécution isolé — conteneur, machine virtuelle dédiée, environnement sans accès réseau sortant non contrôlé — limite l’impact d’une compromission du code de l’agent lui-même : si le processus de l’agent est détourné, l’attaquant reste enfermé dans cet environnement local. C’est une protection réelle et nécessaire.
Mais cette protection ne s’étend jamais au site WordPress distant que l’agent contacte via une API REST ou un serveur MCP. Depuis le point de vue du site distant, l’agent isolé et un agent qui tournerait en clair sur le serveur de production présentent exactement la même identité : celle du jeton d’application ou du compte de service qui leur a été attribué.
Ce que révèle un audit de portée
Un audit typique de la portée réelle d’un jeton d’agent, réalisé plusieurs mois après sa mise en place initiale, fait remonter des constats récurrents :
- Un jeton créé avec le rôle administrateur « pour éviter les blocages pendant les tests », jamais restreint ensuite une fois l’agent passé en production
- Des capacités accordées largement au-delà des abilities réellement exposées à l’agent au quotidien
- Aucune expiration ni révision planifiée depuis la création initiale du jeton
Pourquoi cette dérive se produit presque systématiquement
Au moment de la mise en place, réduire la portée d’un jeton au strict nécessaire demande un effort d’analyse (quelles fonctions l’agent appellera-t-il réellement) que la pression du calendrier pousse souvent à reporter. Le jeton large fonctionne immédiatement, sans erreur de permission à déboguer, ce qui décourage tout retour en arrière une fois l’agent en production. Le resserrement de portée, qui devrait suivre une phase de stabilisation, n’a lieu que rarement, faute d’être planifié dès le départ comme une étape à part entière du projet.
Un compte de service dédié n’est pas une portée limitée
Créer un compte WordPress distinct pour l’agent, plutôt que de réutiliser un compte administrateur existant, constitue une bonne pratique nécessaire mais insuffisante. Ce compte de service doit lui-même recevoir un rôle personnalisé, avec des capacités listées explicitement, plutôt que le rôle administrateur par défaut réattribué par facilité.
add_role('agent_lecture_catalogue', 'Agent IA — lecture catalogue', [
'read' => true,
'edit_posts' => false,
'lire_catalogue_produits' => true, // capacité personnalisée dédiée
]);
Auditer, pas seulement configurer une fois
La portée d’un jeton doit être revue à intervalle régulier, pas uniquement au moment de sa création. Une commande WP-CLI personnalisée, exécutée mensuellement, qui liste les capacités effectivement accordées à chaque compte de service et les compare à une liste de référence documentée, permet de détecter une dérive de portée avant qu’elle ne devienne un problème.
Un environnement isolé qui exécute un agent avec un jeton administrateur n’a résolu qu’une partie du problème : l’isolation protège le contenant, pas ce que le contenu est autorisé à faire ailleurs.
En résumé
L’isolation d’exécution d’un agent IA reste une précaution utile, mais elle ne dispense jamais d’un travail distinct et tout aussi rigoureux sur la portée du jeton qu’il utilise. Un audit régulier de cette portée, comparée à un besoin documenté, révèle presque toujours un écart entre ce qui a été accordé par commodité initiale et ce qui reste réellement nécessaire une fois l’agent stabilisé en production.
