Lumos a annoncé MCP Governance le 22 septembre 2026 pour les équipes utilisant Claude Code et Codex. L'entreprise affirme que le produit vérifie les permissions d'un agent IA au moment où il agit et bloque un appel d'outil lorsque la politique ne l'autorise pas. Sa page produit décrit une couverture des serveurs MCP, appels d'outils, commandes bash, modifications de fichiers et usage du navigateur, chaque appel étant enregistré avec l'outil, les entrées, l'identité humaine et la décision de politique.
C'est une actualité produit matérielle parce qu'elle correspond directement à un problème actuel d'entreprise. MCP facilite la connexion d'agents utiles aux systèmes métier. Il donne aussi aux agents un chemin depuis une tâche en langage naturel vers des outils capables de lire, écrire ou modifier l'état. Une revue d'accès après coup peut arriver trop tard.
Ce que Lumos a lancé
Le communiqué indique que MCP Governance est disponible aujourd'hui pour Claude Code et Codex, avec d'autres agents à suivre. Le contrôle fonctionne comme un hook avant chaque appel d'outil plutôt que comme une passerelle qui reroute chaque serveur MCP. Lumos indique que la vérification renvoie allow ou deny et vise une faible latence.
L'argument central est simple: un agent hérite des permissions de la personne qui l'a lancé, puis agit à vitesse machine. L'accès large d'un employé peut donc devenir la surface d'action large d'un agent. Lumos présente MCP Governance comme un moyen de déplacer la décision de contrôle au point situé avant l'exécution.
Lumos a également publié une page produit et un article de blog la même semaine avec plus de détails. Ce sont des sources fournisseur, donc les revendications sur la performance, la couverture et l'impact opérationnel doivent être testées dans l'environnement propre de l'acheteur.
Pourquoi la politique runtime compte
La gouvernance classique des identités peut dire qui a accès. La gouvernance des agents doit aussi demander ce que l'agent fait maintenant avec cet accès. Un développeur peut avoir le droit de modifier des fichiers, d'appeler un script de déploiement ou d'interroger un CRM. Cela ne signifie pas que chaque tâche d'agent doit pouvoir utiliser ces capacités.
La politique runtime peut faire cette distinction. Elle peut bloquer une modification de fichier hors du périmètre de tâche, arrêter un outil d'exécution de code connecté à des systèmes sensibles ou exiger une règle plus étroite pour changer un feature flag de production. Le guide Maetra sur l'excès d'agence utilise le même principe: la disponibilité large des outils ne doit pas devenir une autorité large pour l'agent.
Les preuves à exiger
Un produit qui gouverne les appels d'outils devrait produire des preuves, pas seulement des blocages. Les équipes sécurité et conformité doivent savoir quel serveur MCP a été appelé, par quel agent, pour le compte de qui, dans quelle tâche, avec quel verdict de politique et avec quel effet en aval.
Le guide Maetra des journaux d'audit IA est pertinent ici parce que la revue post-incident dépend du dossier, pas de la catégorie marketing. Si une politique refuse un appel risqué, le dossier doit montrer pourquoi. Si elle autorise un appel, le dossier doit préserver assez de contexte pour prouver que l'action correspondait à la tâche autorisée.
L'inventaire est le contrôle compagnon. Lumos affirme que l'enregistrement des agents seul est insuffisant, et c'est juste. Les équipes ont tout de même besoin de l'inventaire en premier. Le guide Maetra de découverte des agents explique comment relier agent, propriétaire, surface d'outils et historique des changements avant que la politique runtime n'applique les décisions.
Ce qui reste incertain
Le lancement repose principalement sur des documents Lumos et un communiqué distribué. Les sources publiques examinées ici ne vérifient pas indépendamment la latence, les taux de faux positifs, la résistance aux contournements, les résultats clients ou la couverture de chaque configuration MCP locale. Elles ne montrent pas non plus combien de données d'arguments d'outils un acheteur devrait conserver pour la conformité tout en limitant l'exposition de données sensibles.
Ce ne sont pas des raisons d'écarter le lancement. Ce sont les critères d'évaluation. Les acheteurs devraient tester si le hook voit les serveurs MCP ajoutés localement, si les décisions de politique sont explicables, si les exports de preuve sont complets et si le contrôle peut échouer fermé sans casser les flux sûrs.
Analyse Maetra
Lumos MCP Governance montre le déplacement des produits d'agents: de l'inventaire d'agents vers le contrôle au moment de l'action. C'est la bonne direction. Le moment important n'est pas seulement l'enregistrement d'un serveur ou une revue d'accès trimestrielle. Il se situe quand un agent s'apprête à utiliser un accès hérité pour appeler un outil.
Pour les entreprises qui adoptent des agents de code et MCP, la pile de contrôle pratique est claire. Découvrez l'agent et ses outils. Liez l'autorité à la tâche en cours. Vérifiez chaque appel d'outil avant exécution. Conservez le verdict de politique et la preuve d'effet. Puis analysez les motifs dans le temps afin de réduire l'accès large au lieu de seulement le surveiller.