Serveurs MCP pour l’IAM : lesquels peuvent créer des utilisateurs, lesquels se limitent à la lecture

Une demande classique adressée à un administrateur : « Crée un utilisateur, ajoute-le au groupe Engineering et révoque son accès dans une semaine. » Pour un agent d’IA, c’est une seule phrase. Pour un système d’IAM, ce sont plusieurs opérations d’administration, chacune susceptible de provoquer un incident. L’auteur d’un article publié sur Habr a comparé ce que les fournisseurs proposent déjà via le Model Context Protocol. Le constat est nuancé.

Les capacités de chacun au 9 novembre 2026

L’auteur a examiné la documentation officielle et les listes d’outils. Il n’a pas soumis les tenants à des tests de charge : il s’agit donc d’une comparaison des capacités annoncées, et non d’un audit indépendant.

Okta : son serveur open source auto-hébergé est en disponibilité générale depuis février 2026 et peut créer et modifier des utilisateurs et des groupes. Il propose des scopes OAuth, le filtrage des outils et la validation des actions destructrices via MCP Elicitation. La version hébergée est encore en Early Access.

Microsoft MCP Server for Enterprise : en préversion publique et en lecture seule, avec trois outils pour les requêtes GET de Graph et le schéma.

PingOne Remote MCP Server : en Early Access, il permet de créer, modifier et supprimer des utilisateurs, mais le fournisseur lui-même déconseille d’activer ces fonctions en production. Son activation pour un environnement donne accès à tous les outils autorisés par le rôle.

JumpCloud : création, suspension et suppression d’utilisateurs, modification des groupes, révocation des sessions OAuth et événements dans Directory Insights.

Auth0 : le serveur automatise les applications, les API, les Actions et les journaux, mais son catalogue ne propose pas de gestion des utilisateurs et des groupes. Pour « créer le compte d’un collaborateur », cette différence est fondamentale.

Dans les ressources officielles, Keycloak intervient comme serveur d’autorisation pour des serveurs MCP tiers, et non comme système à administrer. Pour administrer l’annuaire, il faudra utiliser un serveur communautaire et examiner séparément son modèle de contrôle d’accès.

Cinq vérifications plutôt qu’un décompte des outils

1. Ce qui est activé par défaut. Mieux vaut que le serveur soit désactivé ou en lecture seule tant qu’un administrateur n’a pas accordé davantage de droits. La granularité des permissions après activation compte également.
2. L’identité au nom de laquelle l’agent agit. Un accès OAuth associé à l’administrateur et à ses rôles facilite davantage l’audit qu’une clé API partagée stockée dans des variables d’environnement.
3. Le contrôle des droits à chaque appel. Masquer les outils superflus dans tools/list est utile, mais ne constitue pas une autorisation. Le contrôle doit aussi intervenir lors de tools/call : la liste peut être périmée et un appel peut être construit manuellement.
4. Ce que l’humain valide exactement. Chez Okta, si le client ne peut pas afficher la boîte de dialogue Elicitation, le serveur renvoie du JSON que le modèle doit interpréter. La frontière de confiance diffère alors de celle d’une page de confirmation générée par le système d’IAM lui-même à partir d’une opération enregistrée.
5. L’identification de l’agent dans les journaux. Il faut pouvoir déterminer quel client a déclenché la modification et qui l’a validée. Ping consigne dans son journal d’audit à la fois le user_id de l’administrateur et le client_id du serveur MCP.

L’injection de prompt reste un risque à part entière : le nom d’un groupe ou un attribut utilisateur peut contenir une instruction destinée au modèle. Les résultats des outils ne doivent pas être considérés comme des commandes fiables ; c’est au serveur de limiter les permissions.

Une validation, une opération

L’auteur développe issuerd et le précise explicitement. Dans son projet, le serveur conserve les valeurs canoniques de tool et arguments ; la personne effectue une nouvelle authentification et voit une page construite à partir des données du serveur. Après validation CIBA, le client reçoit un jeton DPoP de courte durée, sans jeton de rafraîchissement. Toute substitution de l’id, des arguments ou du realm est rejetée, et la répétition du même appel renvoie le résultat enregistré sans effectuer une seconde suppression.

Ce mécanisme ne fait pas partie du standard MCP. Il exige un client compatible avec DPoP et CIBA, et issuerd ne prend en charge ni l’administration entre realms ni le M2M sans intervention humaine.

Que faire en pratique ?

La spécification MCP Authorization 2026-07-28, avec OAuth 2.1 et Resource Indicators, explique comment le client obtient l’accès au serveur MCP. Elle ne définit pas comment une personne valide la suppression d’un utilisateur précis.

La liste de vérifications de l’auteur : commencer avec un tenant de test et un mode lecture seule, confronter le contenu réel de tools/list à la tâche, définir un rôle doté des permissions minimales, préférer une identité déléguée à un secret partagé, exiger une nouvelle validation pour les suppressions et les rôles privilégiés, isoler les actions MCP dans les journaux d’audit et répéter à l’avance la procédure de révocation des accès de l’agent. Les mentions Early Access et « déconseillé en production » font partie de la décision d’architecture ; ce ne sont pas de simples notes en petits caractères.

Les contrôles doivent être placés là où le modèle ne peut pas les réécrire : dans les rôles, les scopes, l’audience du jeton, la page de confirmation côté serveur et les journaux d’audit. Le vieux problème du confused deputy, ou mandataire confus, n’a pas disparu : l’intermédiaire sait simplement désormais expliquer ses actions avec éloquence.