La liste des jetons actifs sur un serveur MCP interne comptait neuf entrées ; la liste des prestataires sous contrat au même moment n’en comptait que huit. Cette différence d’une unité, repérée lors d’un audit trimestriel de routine, a suffi à révéler un jeton d’accès resté actif sept mois après la fin de la mission pour laquelle il avait été créé.
Ce cas mérite d’être détaillé, car il illustre un angle mort fréquent dans la gestion des accès accordés à des prestataires externes sur des outils d’automatisation encore récents comme un serveur MCP : la création d’un accès fait l’objet d’une procédure suivie, sa révocation beaucoup moins souvent.
Le contexte : un serveur MCP interne pour la maintenance
Le serveur en question exposait un ensemble d’outils MCP destinés à un agent de maintenance, capable de vérifier l’état de plugins, de purger un cache ou de signaler une extension obsolète sur plusieurs sites gérés par l’équipe. Chaque prestataire externe intervenant ponctuellement recevait un jeton d’accès personnel, généré au début de sa mission.
La mission concernée portait sur un audit ponctuel de performance, réalisée par un prestataire externe sur une durée prévue de trois semaines. Le jeton généré à cette occasion n’a jamais été supprimé une fois la mission terminée.
Comment l’audit l’a mis au jour
L’audit trimestriel de sécurité comparait systématiquement deux listes : celle des jetons actifs enregistrés côté serveur MCP, et celle des contrats de prestation en cours tenue par l’équipe administrative. Un jeton figurant sur la première liste sans contrat correspondant sur la seconde constitue, par construction, un accès qui aurait dû être révoqué.
- Liste des jetons actifs extraite directement de la table de stockage du serveur MCP
- Liste des prestataires sous contrat tenue indépendamment par l’équipe administrative
- Comparaison manuelle des deux listes, sans outil automatisé au moment de cet audit
- Un écart d’une seule entrée a suffi à déclencher une vérification approfondie
Ce que le jeton oublié permettait réellement
Sur les sept mois où le jeton est resté actif, aucun appel n’a été enregistré dans les journaux du serveur MCP le concernant — ce qui a limité l’impact réel de cet oubli à un risque théorique plutôt qu’à un incident avéré. Mais le risque restait réel : ce jeton donnait accès à des outils capables de purger un cache ou de signaler une extension obsolète sur l’ensemble des sites gérés par l’équipe, sans qu’aucune limite de portée n’ait été fixée au moment de sa création.
Le processus mis en place après l’audit
La correction a consisté à instaurer une procédure de fin de mission écrite, incluant systématiquement la révocation du jeton MCP comme étape obligatoire, au même titre que la restitution du matériel ou la désactivation d’un compte utilisateur classique.
function wpm_revoquer_jeton_mcp( string $identifiant_jeton ): bool {
$jetons = get_option( 'wpm_mcp_jetons_actifs', array() );
if ( ! isset( $jetons[ $identifiant_jeton ] ) ) {
return false;
}
unset( $jetons[ $identifiant_jeton ] );
update_option( 'wpm_mcp_jetons_actifs', $jetons );
error_log( sprintf( '[mcp] Jeton revoque : %s', $identifiant_jeton ) );
return true;
}Cette fonction a été intégrée à une checklist de fin de mission, déclenchée dès que le contrat administratif d’un prestataire passe au statut clos, plutôt que d’être laissée à la mémoire de la personne ayant créé l’accès initial.
Ce que cet incident a changé dans notre pratique
Sur nos projets suivants, tout jeton MCP créé pour un prestataire externe porte désormais une date d’expiration fixée dès sa création, plutôt que de dépendre uniquement d’une révocation manuelle ultérieure.
Cette date d’expiration automatique, ajoutée depuis à notre gestion des accès, réduit fortement le risque qu’un futur oubli produise le même écart, sans supprimer pour autant l’utilité de l’audit trimestriel croisé, qui reste le filet de sécurité en cas d’exception non couverte par la règle générale.
En résumé
Un jeton d’accès à un serveur MCP créé pour un prestataire externe ne se révoque jamais tout seul. Seul un audit croisé régulier entre les accès actifs et les contrats en cours, complété par une date d’expiration fixée dès la création, réduit durablement ce risque.
