MCP vs CLI : Que se passe-t-il lorsque votre agent IA ne trouve pas le connecteur

Lorsqu’un agent IA doit agir sur une machine, la voie propre est le Model Context Protocol (MCP). Un serveur MCP expose un ensemble défini d’outils, l’agent les appelle, et vous pouvez raisonner sur ce qu’il est autorisé à faire car la liste est courte et écrite. Ensuite, l’agent a besoin de quelque chose sans connecteur, comme un système de tickets interne ou une application métier que personne n’a touchée depuis 2012, et l’histoire change. Un agent déterminé à finir sa tâche cherche une autre porte, et cette porte est presque toujours la ligne de commande.

La plupart des discussions en ligne sur MCP vs CLI portent sur les coûts des jetons, OAuth, et la gestion des identifiants, ce sont des sujets légitimes. Très peu s’interrogent sur ce que le point de terminaison exécutera réellement une fois que l’agent quitte le chemin MCP, et c’est la partie dont les administrateurs informatiques doivent s’occuper.

MCP vs CLI

Les deux approches donnent à un agent des niveaux de pouvoir très différents. Avec MCP, l’agent reçoit une liste définie d’outils et rien d’autre. Avec une CLI, l’agent contrôle un shell, et un shell possède tous les droits de l’utilisateur connecté. Le mode code, le modèle plus récent présenté ci-dessous, se comporte comme le côté CLI de cette ligne lorsqu’il s’exécute sur un bureau géré, car l’agent écrit son propre programme et la machine l’exécute.

Cette différence explique pourquoi les développeurs aiment la CLI (elle utilise peu de jetons et les agents connaissent des outils comme git et docker) et pourquoi les équipes de sécurité préfèrent MCP (une liste courte est plus facile à auditer et OAuth offre une authentification centrale). Les deux camps ont raison. Ce que personne ne règle, c’est ce qui empêche un agent d’exécuter quelque chose que personne n’a approuvé une fois que il sort de la liste des outils.

Les agents reviennent à la CLI

Supposons qu’un développeur demande à un agent d’extraire des données de ce système de ticketing. Sans connecteur, l’agent écrit un script, télécharge un binaire d’aide et enchaîne quelques commandes, et personne n’a approuvé quoi que ce soit parce que la gouvernance de votre MCP ne l’a jamais vu. L’agent a complètement quitté le monde MCP. Cela ressemble à un film de braquage où l’équipe de sécurité a passé des mois sur le coffre principal tandis que l’équipe est entrée par le quai de chargement ; l’équipe ici est un logiciel bien intentionné, et le quai est tout aussi ouvert.

Le mécanisme de secours est également silencieux, car un journal MCP ne contient aucun enregistrement d'une PowerShell command que l'agent a exécutée de manière autonome.

L'exécution de code avec MCP place le code écrit par l'agent sur vos endpoints

Le MCP lui-même évolue. Au lieu d’appeler un outil à la fois et de renvoyer chaque résultat au modèle, les agents passent en mode code : l’agent écrit un petit programme qui appelle les outils MCP, filtre et combine les résultats, puis exécute l’ensemble. Anthropic a décrit ce schéma dans son blog d’ingénierie, et l’intérêt est évident, car un script peut effectuer vingt appels d’outils sans passer chaque résultat par le modèle. Cela économise des tokens et rend les agents plus performants, donc cette approche gagne du terrain.

Il place également du code réel, écrit par l’agent, sur vos endpoints. L’exécution de code avec MCP déplace la question de contrôle de quels outils l’agent peut appeler à quels programmes l’endpoint exécutera, et un programme est aussi fiable que celui qui l’a écrit. Certaines configurations exécutent ce code dans un sandbox, et un sandbox aide beaucoup. Un bureau Windows ou Mac géré n’est généralement pas un sandbox, et si la machine exécute tout ce qu’elle reçoit, votre liste d’outils approuvés n’est qu’une suggestion, car le code de l’agent peut contourner le serveur MCP aussi facilement que le traverser.

Ce qu’un shell rogue ou script agent peut faire avec les droits d’administrateur local

Les dégâts dépendent des droits que l'agent emprunte. Sous un administrateur local, le mode de secours CLI a un contrôle total de la machine, il peut donc installer des logiciels ou désactiver les protections sans demander à personne. L'agent d'un utilisateur standard peut toujours exécuter un exécutable que personne n'a examiné, soit par erreur, soit parce qu'une injection de commande cachée dans un document qu'il a lu lui a ordonné de le faire.

Appliquer des limites là où le code s’exécute

De nombreuses équipes essaient de maîtriser l’agent lui-même avec des invites système, des garde-fous et des politiques en langage clair. Cela aide, mais cela se passe côté IA, et un agent peut être confus ou manipulé. La solution fiable est d’imposer des limites là où le code s’exécute, pour que le résultat reste sûr, quoi que tente l’agent. Le point de terminaison est la partie de la pile que l’IT possède déjà, et c’est là que PolicyPak fonctionne.

Comment PolicyPak gère MCP vs CLI : moindre privilège et allowlisting

PolicyPak aborde le problème sous deux angles, le premier étant le principe du moindre privilège. PolicyPak Least Privilege Manager supprime les droits d’administrateur local des utilisateurs et accorde les droits d’administrateur uniquement aux applications et tâches spécifiques qui en ont besoin, sur Windows et Mac. Un agent qui revient à la CLI sous un utilisateur standard ne peut pas installer de pilotes ni manipuler les outils de sécurité, et les exceptions que vous avez accordées restent limitées aux applications que vous avez nommées.

Le second est la liste blanche. PolicyPak SecureRun fonctionne à partir de la propriété du fichier : les exécutables introduits par des utilisateurs standard, ou par un agent agissant comme tel, ne s’exécutent pas à moins qu’un compte de confiance ne les possède, comme votre outil de déploiement logiciel ou un administrateur. Cela importe pour le mode code. Lorsqu’un agent écrit un script ou dépose un binaire d’aide, SecureRun ne fait pas confiance au fichier et le bloque, ce qui explique aussi pourquoi il fonctionne comme prévention du ransomware en un clic. Vous obtenez une liste blanche globale sans maintenance hash par hash et sans retirer les outils que vous utilisez déjà.

Les agents peuvent continuer à utiliser MCP partout où un connecteur existe. Lorsqu’il n’y en a pas, le repli CLI s’exécute sur une machine où l’utilisateur n’a pas de droits administrateur et le fichier que l’agent vient d’écrire n’a pas de propriétaire de confiance, et cela reste vrai lorsque l’exécution de code avec MCP est la norme.