# Sécuriser un serveur MCP qui expose un contenu headless à un agent

> Checklist pour qu'un outil MCP donnant accès au contenu WordPress à un agent respecte les mêmes contrôles de capacité qu'une API REST classique.

- Auteur : Clément Hadrot
- Publié le : 2025-09-02
- Mis à jour le : 2025-09-02
- Catégorie : Headless & API
- URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/securiser-serveur-mcp-contenu-headless-agent/

## L’essentiel

- Un serveur MCP hérite des mêmes exigences qu'une API REST classique
- Portée des outils limitée au strict nécessaire par contexte d'usage
- Journal d'audit distinct pour chaque appel d'outil exécuté

« Un serveur MCP expose des outils qu'un client, généralement un agent, peut découvrir et invoquer. » Cette définition, posée depuis la spécification du Model Context Protocol publiée fin 2024, ressemble beaucoup à celle d'une API REST classique, à un détail près : l'appelant n'est plus un développeur qui lit une documentation avant d'écrire son code, mais un modèle de langage qui décide, de façon autonome, quand et comment invoquer chaque outil. Cette différence change la nature du risque, sans changer la nature de la protection à mettre en place.

Cette checklist part d'un cas concret : un serveur MCP développé pour donner à un agent conversationnel un accès en lecture au contenu d'un WordPress headless (articles, produits, fiches pratiques), afin qu'il puisse répondre aux questions des visiteurs d'un site sans halluciner de contenu inexistant. Elle ne traite pas la performance de ce serveur, uniquement les contrôles de sécurité à appliquer avant sa mise en production.

## 1. Ne jamais confondre schéma d'outil et contrôle d'accès réel

Un outil MCP décrit dans son schéma qu'il « recherche des articles par mot-clé » ne garantit en rien qu'il ne retournera pas, par erreur d'implémentation, des articles en statut brouillon ou des métadonnées internes. La vérification des permissions doit se faire côté serveur, à chaque appel, exactement comme pour un endpoint REST :

```
server.tool('search_articles', schema, async ({ query }) => {
  const results = await wpFetch('/wp-json/wp/v2/posts', {
    query,
    status: 'publish', // jamais paramétrable par l'appelant
  });
  return results.filter((post) => !post.meta._interne);
});
```

## 2. Limiter la portée des outils exposés au strict besoin

Un serveur MCP unique ne devrait pas exposer, dans le même contexte, un outil de recherche de contenu public et un outil de gestion des commandes clients : la portée de chaque outil doit correspondre exactement au cas d'usage prévu pour l'agent qui s'y connecte, sans mutualiser des capacités qui n'ont aucune raison de coexister.

> L'essentiel à retenir : Un serveur MCP hérite des mêmes exigences qu'une API REST classique ; Portée des outils limitée au strict nécessaire par contexte d'usage ; Journal d'audit distinct pour chaque appel d'outil exécuté

## 3. Authentifier le serveur MCP, pas seulement l'agent

Le serveur MCP se connecte lui-même à WordPress pour aller chercher les données : cette connexion doit utiliser un compte applicatif dédié, avec des mots de passe d'application WordPress générés spécifiquement, et jamais les identifiants d'un compte administrateur réutilisés par commodité. Ce compte applicatif ne doit disposer que des capacités `read`, sans `edit_posts` ni `publish_posts`.

## 4. Vérifier systématiquement les entrées transmises par l'agent

Un agent peut transmettre à un outil MCP des paramètres construits à partir d'une conversation, potentiellement influencée par un contenu externe malveillant (une page web citée par l'utilisateur, par exemple). Chaque paramètre reçu doit être validé et assaini avant d'atteindre l'API WordPress sous-jacente, exactement comme le préconise l'argument `validate_callback` d'une route REST personnalisée :

- Validation stricte du type et du format de chaque paramètre d'entrée.
- Limitation de la taille des requêtes et du nombre de résultats retournés par appel.
- Rejet explicite de tout paramètre non prévu dans le schéma déclaré, sans tentative d'interprétation permissive.

## 5. Journaliser chaque appel d'outil, avec son contexte

Contrairement à une requête REST classique, un appel d'outil MCP est généralement précédé d'une décision autonome de l'agent, qu'il est précieux de pouvoir rejouer en cas d'incident. Le journal d'audit doit conserver, pour chaque appel : l'identifiant de session de l'agent, l'outil invoqué, les paramètres transmis, et la réponse renvoyée, avec une rétention suffisante pour permettre une investigation a posteriori.

## 6. Prévoir une désactivation d'urgence outil par outil

Si un incident révèle qu'un outil précis est détourné ou mal utilisé par l'agent (par exemple, un volume anormal d'appels sur un outil de recherche, révélateur d'une boucle incontrôlée), il doit être possible de désactiver cet outil précis sans interrompre l'ensemble du serveur MCP, ni les autres agents qui pourraient en dépendre légitimement.

> Un serveur MCP qui expose un contenu WordPress mérite exactement les mêmes égards qu'une API REST publique : mêmes vérifications de capacités, même granularité de permissions, même exigence de journalisation. Le protocole change la forme de l'appel, pas la nature du risque.

## En résumé

La nouveauté du protocole MCP ne doit pas faire oublier les fondamentaux déjà connus de la sécurisation d'une API REST WordPress : compte applicatif dédié à capacités restreintes, validation stricte des entrées, journalisation systématique, et granularité fine dans la désactivation en cas d'incident. La documentation du Model Context Protocol continue d'évoluer rapidement depuis son ouverture fin 2024 ; elle mérite d'être suivie de près avant toute mise en production d'un nouveau serveur.