Serveur MCP d'EmDash : ce qu'un agent peut faire de votre contenu
Avant de brancher un agent sur un site en production : quelles opérations sont exposées, comment les restreindre par jeton et par rôle, et ce qui doit rester hors de portée.
Brancher un agent sur un CMS soulève une question que le tutoriel de mise en route n’aborde jamais : une fois connecté, qu’est-ce qu’il peut casser ? Le guide du serveur MCP intégré explique comment l’activer. Celui-ci traite de ce qu’il faut décider avant de le laisser tourner sur un site qui reçoit du public.
Une précision de méthode d’abord, comme sur tout ce site : nous sommes indépendants du projet EmDash et de Cloudflare. La liste exacte des opérations exposées par le serveur MCP est susceptible de changer à chaque version ; nous indiquons donc où la lire dans votre propre installation plutôt que de la recopier ici, où elle serait fausse dans trois mois.
Le modèle de permission d’un serveur MCP, en une minute
Le protocole n’invente pas de système de droits. Il en emprunte un.
Un serveur MCP expose trois familles de capacités : des outils (des actions), des ressources (des données lisibles) et des prompts (des modèles d’instruction). L’agent ne peut appeler que ce que le serveur déclare, et le serveur n’exécute que ce que son identité l’autorise à faire.
D’où la règle centrale, et elle est plus simple qu’il n’y paraît : un serveur MCP agit avec les droits du jeton qu’on lui a donné, pas avec ceux de la personne qui parle à l’agent. Si vous lui confiez un jeton d’administrateur, l’agent est administrateur — quelles que soient les précautions prises côté modèle.
Trois questions en découlent, et ce sont les seules qui comptent.
- Quelles opérations le serveur expose-t-il réellement ?
- Avec quelle identité s’exécute-t-il ?
- Qu’est-ce qui reste impossible même avec un jeton valide ?
1. Inventorier ce qui est exposé
Ne partez pas de la documentation, partez de votre installation. Un serveur MCP est introspectable par construction : il publie la liste de ses outils, leurs paramètres et leur description.
Trois façons de l’obtenir, de la plus fiable à la plus rapide.
- Interroger le serveur lui-même. Un client MCP quelconque, connecté à votre instance, affiche la liste des outils déclarés. C’est l’inventaire réel de votre version, pas celui d’une autre.
- Lire la déclaration dans le code. Cherchez dans le dépôt l’endroit où les outils sont enregistrés auprès du serveur. C’est là que se lisent les paramètres réellement acceptés, y compris ceux que la documentation omet.
- Lire les notes de version. Un outil ajouté entre deux versions mineures élargit la surface d’action de tous les agents déjà connectés, sans aucune action de votre part.
Classez ensuite ce que vous trouvez en trois colonnes, parce que le risque n’est pas du tout le même.
| Catégorie | Exemples typiques | Risque |
|---|---|---|
| Lecture | lister des contenus, lire une entrée, chercher | Fuite d’information, y compris de brouillons |
| Écriture réversible | créer un brouillon, modifier un champ, téléverser un média | Corrections possibles, historique à vérifier |
| Écriture irréversible ou publique | publier, dépublier, supprimer, modifier une URL, changer un rôle | Aucun rattrapage silencieux |
La troisième colonne est la seule qui mérite une décision explicite. Tout le reste se corrige.
2. Donner au serveur l’identité la plus faible possible
C’est ici que se joue l’essentiel, et c’est une décision d’infrastructure, pas de prompt.
Créez un compte de service dédié. Jamais votre compte personnel, jamais un compte partagé. Un compte par usage, avec un nom qui dit à quoi il sert : les journaux d’audit deviennent lisibles, et la révocation ne casse rien d’autre.
Attribuez-lui le rôle minimal qui permet la tâche. Si l’agent rédige des brouillons, un rôle de contributeur suffit — il n’a pas besoin de publier. Le système de rôles d’EmDash est décrit dans notre guide sur les rôles et permissions, et c’est lui qui fait la loi : le serveur MCP ne peut pas accorder plus que ce que le rôle permet.
Limitez la durée de vie du jeton. Un jeton sans expiration est un jeton qui finira dans un historique de terminal, une variable d’environnement de CI ou une capture d’écran.
Séparez les environnements. Un agent qui travaille sur la préproduction n’a aucune raison de détenir un jeton de production. C’est la protection la plus efficace de toutes, parce qu’elle ne dépend d’aucune vigilance au moment de l’usage.
3. Ce qui doit rester hors de portée, et pourquoi
Trois opérations méritent d’être refusées par principe à un agent, même supervisé.
La publication en fin de chaîne. Un agent peut préparer, structurer, corriger, proposer. La mise en ligne est le point où une erreur devient publique, indexable et parfois citée ailleurs. Garder ce geste humain ne coûte que quelques secondes par article.
La modification d’une adresse publiée. C’est le dégât le plus coûteux et le moins visible : une URL qui change perd son classement et casse les liens entrants, sans qu’aucune alerte ne se déclenche. C’est aussi ce que nous rappelons dans le guide des redirections lors d’une migration depuis WordPress.
La gestion des utilisateurs et des rôles. Un agent capable d’élever un compte peut annuler toutes les limites décrites plus haut. Cette opération doit rester manuelle, quel que soit le confort perdu.
Le contrôle qui ne dépend pas de l’agent
Une bonne règle de sécurité ne suppose jamais que le modèle « comprendra » l’instruction. Quatre garde-fous tiennent sans lui.
- La sauvegarde vérifiée. Avant de brancher quoi que ce soit, assurez-vous de pouvoir restaurer — et de l’avoir déjà fait une fois pour de vrai. Le tutoriel de sauvegarde et restauration détaille le test qui manque presque toujours.
- L’historique des versions de contenu. Il transforme une écriture ratée en incident de cinq minutes.
- Les journaux. Savoir quel jeton a fait quoi, et quand, est ce qui permet de trancher entre « l’agent a mal fait » et « quelqu’un a mal demandé ».
- La validation humaine des actions destructrices, côté client MCP. La plupart des clients savent demander une confirmation avant d’exécuter un outil : c’est un réglage, pas une option théorique.
Le cas particulier du contenu venu de l’extérieur
Un point souvent oublié, et propre aux agents : le contenu que l’agent lit peut contenir des instructions. Un commentaire, un formulaire, un brouillon importé, une page récupérée sur le web peuvent porter un texte qui s’adresse au modèle plutôt qu’au lecteur.
La parade n’est pas de faire confiance au modèle, mais de considérer toute donnée lue comme non fiable, et de la tenir à l’écart des décisions. En pratique, cela se traduit par une seule règle d’architecture : les droits d’écriture ne doivent jamais être conditionnés par ce que l’agent a lu. C’est aussi ce qui justifie, concrètement, de ne pas lui laisser la publication.
La check-list avant de connecter la production
- J’ai la liste des outils exposés par ma version, obtenue depuis mon instance.
- J’ai un compte de service dédié, avec un rôle minimal, distinct de mon compte.
- Le jeton expire, et je sais où il est stocké.
- La préproduction et la production ont des jetons différents.
- Publication, changement d’URL et gestion des rôles restent hors du périmètre de l’agent.
- J’ai testé une restauration de sauvegarde, pas seulement la sauvegarde.
- Les journaux permettent d’attribuer une action à un jeton.
Tant qu’un de ces points manque, l’agent travaille sur la préproduction. Ce n’est pas de la prudence excessive : c’est ce qui fait la différence entre un outil de productivité et un incident à expliquer à un client.