MCP, skills ou CLI : placez la limite là où l’agent ne peut pas l’ignorer

Sur un projet IZZY, un agent IA devait consulter une base de données de production. Deux voies étaient réalistes.

La première associait un skill à une CLI. Le skill chargeait la procédure seulement lorsque la tâche l’exigeait : pratique, léger et facile à faire évoluer. Mais, dans cet environnement précis, le shell, le client de base de données et les identifiants disponibles formaient aussi un chemin capable de modifier les données.

La seconde passait par un serveur MCP limité à quelques méthodes de lecture. Elle ajoutait des définitions d’outils et un composant à exploiter, mais réduisait les actions présentées au modèle. Nous avons retenu cette voie et ajouté, dans le harnais de l’agent, des hooks qui refusaient les opérations de mutation sur ce chemin.

La conclusion n’est pas « MCP est sûr, CLI est dangereuse ». Elle est plus concrète :

Pour un système de production ou difficile à restaurer, acceptez un peu de coût technique si cela réduit les capacités mécaniquement accessibles. Pour un état jetable ou facile à reconstruire, privilégiez la simplicité.

Une vraie limite de sécurité doit continuer d’exister même si le modèle décide mal.

La réponse en 60 secondes

MCP, skill et CLI ne sont pas trois protocoles concurrents.

• MCP permet à un serveur d’exposer des outils nommés, avec des entrées et des sorties décrites. Un serveur volontairement étroit peut ne rendre accessibles que quelques opérations.
• Un skill d’agent est un ensemble d’instructions et de ressources chargé à la demande. Il explique la procédure, mais son texte ne constitue pas à lui seul une autorisation imposée à l’environnement d’exécution.
• Une CLI ou une connexion directe est une voie d’exécution. Son pouvoir réel dépend du programme, du shell, du réseau, des fichiers, des identifiants et des droits du système cible.
• Des hooks ou règles dans le harnais de l’agent peuvent refuser une commande ou un appel de manière déterministe. Ils ne protègent que les chemins qu’ils interceptent réellement.

Pour une base locale, jetable et restaurable, skill plus CLI peut être le choix le plus rationnel. Pour des données clients, une production ou une action dont l’erreur coûte cher, préférez une surface d’exécution étroite : outils MCP bornés, API dédiée, proxy ou adaptateur qui impose la même limite.

Les deux approches peuvent se compléter : le skill charge la bonne procédure ; l’outil contraint exécute uniquement l’action autorisée.

Dans cet article

1. Le mauvais débat : comparer trois couches différentes
2. Le choix réel sur une base de production
3. Ce que chaque couche doit réellement contrôler
4. La même décision existe dans tous les outils métier
5. Le coût de contexte ne suffit pas à choisir
6. Décider selon la conséquence et la restauration
7. Cartographier le parcours complet d’une capacité
8. Construire une limite qui refuse par défaut

1. Le mauvais débat : comparer trois couches différentes

Une grande partie des comparatifs oppose MCP, skills et CLI comme s’il s’agissait de trois emballages interchangeables. Cette lecture masque l’endroit où se trouve la décision de sécurité.

La spécification actuelle des outils MCP prévoit des outils découvrables avec un nom, une description et des schémas JSON. Elle demande aussi au serveur de valider les entrées et d’appliquer les contrôles d’accès. MCP structure donc l’exposition d’une capacité ; il ne transforme pas automatiquement chaque serveur en barrière de moindre privilège.

Le guide d’implémentation Agent Skills suit une divulgation progressive : nom et description au démarrage, contenu complet de SKILL.md à l’activation, puis ressources appelées seulement si nécessaire. C’est utile pour ne pas charger en permanence une longue procédure spécialisée.

Mais la phrase « ne jamais exécuter DELETE » reste une consigne. Pour devenir une limite, elle doit être traduite en règle que le modèle ne peut pas lever : commande absente, script borné, identité limitée, proxy, hook, validation indépendante ou refus côté système cible.

Un skill peut lancer un script parfaitement isolé. Un serveur MCP peut au contraire exposer un shell générique. Une CLI peut utiliser une identité strictement en lecture. Le nom de l’interface ne tranche donc pas le risque.

2. Le choix réel sur une base de production

Le projet IZZY cherchait à résoudre une tâche simple à formuler : permettre à un agent de retrouver des informations dans une base de production sans lui offrir un chemin commode pour les modifier.

La voie skill plus CLI envisagée

Le skill pouvait imposer une procédure claire :

1. inspecter le schéma utile ;
2. préparer une requête de lecture ;
3. l’exécuter avec le client de base de données ;
4. mettre en forme le résultat ;
5. ne jamais insérer, modifier, supprimer ou altérer de données.

Cette solution avait un avantage évident : la procédure détaillée n’entrait dans le contexte que lorsque l’agent en avait besoin.

Sa faiblesse venait de l’environnement réel. Le même agent disposait d’un shell, d’un programme capable d’opérations plus larges et d’identifiants permettant d’atteindre la base. L’interdiction se trouvait donc dans les instructions du système qui fabriquait aussi la commande.

Si le modèle interprétait mal la tâche, suivait une instruction cachée dans un contenu récupéré ou choisissait une syntaxe inattendue, la consigne n’était pas l’autorité finale.

La voie MCP retenue

Le serveur MCP exposait des méthodes de lecture concrètes. Aucun exécuteur SQL générique ni échappatoire vers un shell n’était disponible par cette surface. Des hooks placés dans le harnais de l’agent examinaient le chemin configuré et refusaient les actions de mutation avant exécution.

Les identifiants restaient dans .env, hors du chat, des prompts et des arguments ou résultats ordinaires des outils. Cela réduit une exposition inutile au modèle, mais ne rend pas le secret invisible. Un agent qui peut lire n’importe quel fichier, inspecter l’environnement d’un processus, exécuter un shell sans restriction ou consulter des journaux trop bavards peut encore l’atteindre. L’OWASP rappelle que les variables d’environnement peuvent être accessibles aux processus et apparaître dans des journaux ou dumps système.

Voici le compromis réel :

Ce cas décrit un seul projet, sans nommer le client. Il ne constitue ni une comparaison de performance ni la preuve que tout serveur MCP serait préférable. Le rôle natif utilisé dans la base n’est pas précisé dans ce retour public. En production, il faut aussi limiter l’identité du système cible : les méthodes MCP et les hooks protègent un chemin, ils ne remplacent pas les droits de la base.

La décision a réduit les capacités de mutation par le chemin d’agent configuré. Elle ne sécurise pas à elle seule les autres clients, identifiants, administrateurs ou défauts d’implémentation.

3. Ce que chaque couche doit réellement contrôler

Une architecture utile distribue les responsabilités au lieu de demander au prompt de tout porter.

Le skill porte le savoir-faire

Le skill doit expliquer : quand utiliser l’outil, quelles données demander, comment vérifier un résultat, quels cas escalader, quelle preuve conserver et quand s’arrêter.

Il est particulièrement adapté à une procédure qui évolue souvent ou qui ne concerne qu’une partie des tâches. Son contenu peut rester lisible, versionné et réutilisable sans occuper tout le contexte.

Sa limite : le modèle interprète cette procédure. Le skill ne doit donc pas être la seule protection d’une opération irréversible ou d’un accès large.

MCP porte un contrat d’outil

Un serveur MCP bien conçu peut centraliser :

• quelques opérations nommées ;
• des paramètres structurés ;
• la validation des ressources et des volumes ;
• le filtrage des résultats ;
• les erreurs, refus et traces ;
• un même contrat pour plusieurs clients compatibles.

Cette couche devient pertinente quand plusieurs agents ont besoin de la même capacité bornée ou quand l’organisation veut maintenir une interface contrôlée plutôt qu’une convention de prompt.

Elle crée aussi un service supplémentaire à déployer, corriger, surveiller et arrêter. Un intermédiaire qui concentre plusieurs accès devient lui-même une cible importante. Et un outil nommé run_query qui accepte n’importe quelle chaîne SQL n’est pas automatiquement étroit.

La spécification d’autorisation MCP concerne les transports HTTP qui choisissent de l’implémenter ; l’autorisation reste optionnelle dans MCP, et les transports stdio récupèrent normalement leurs identifiants dans l’environnement. OAuth ne prouve donc ni la bonne ressource, ni la bonne action, ni la bonne catégorie de données.

La CLI porte l’exécution existante

Une CLI permet de réutiliser immédiatement des outils maîtrisés par les ingénieurs. Elle est observable, reproductible et facile à combiner. Pour un environnement local ou un travail temporaire, c’est souvent la voie la plus honnête.

Le problème ne vient pas de la CLI « par définition ». Une CLI ne peut faire que ce que son programme et son identité autorisent. Le risque apparaît avec la combinaison suivante : shell généraliste, programmes capables de mutation, identifiants larges, réseau vers la production et absence de refus indépendant.

Dans ce cas, ajoutez une vraie limite : sandbox, liste de commandes autorisées, proxy, identité restreinte, adaptateur spécialisé ou hooks du harnais.

Les hooks imposent une règle sur un chemin précis

Un hook peut bloquer un appel, vérifier des paramètres ou demander une validation avant exécution. Contrairement à une phrase dans un skill, sa décision ne dépend pas de l’accord du modèle.

Il faut toutefois documenter son point d’interception. Si l’agent peut atteindre le même système par un second shell, un autre plugin ou un identifiant hérité, ce chemin contourne le hook. En cas de panne ou d’ambiguïté, la règle doit refuser l’action, journaliser le refus et être testée avec des syntaxes alternatives.

4. La même décision existe dans tous les outils métier

La base de données rend la différence visible, mais la question s’applique à presque tous les outils opérationnels :

Donnons-nous à l’agent quelques capacités utiles, ou une surface d’exécution générale accompagnée de recommandations ?

La lecture n’est pas sans risque. Elle peut révéler des informations confidentielles, mélanger plusieurs clients, extraire trop de données ou déclencher une requête coûteuse. Elle réduit le risque d’intégrité ; elle ne supprime ni la confidentialité, ni la disponibilité, ni l’exposition des résultats.

Pour les organisations françaises qui traitent des données personnelles, cette nuance est importante. La note exploratoire CNIL–Conseil de l’IA et du Numérique sur l’IA agentique souligne que la connexion à de multiples services, la mémoire persistante et l’action au nom de l’utilisateur augmentent les flux de données et complexifient les responsabilités. La note ne crée pas à elle seule une nouvelle règle, mais elle confirme qu’un accès en lecture peut déjà élargir fortement le périmètre de traitement.

L’OWASP AI Agent Security Cheat Sheet recommande de limiter les outils, de distinguer lecture et écriture, d’autoriser explicitement les opérations sensibles et de ne pas confier l’autorisation au seul résultat du modèle.

5. Le coût de contexte ne suffit pas à choisir

Le coût existe. Les noms, descriptions et schémas des outils MCP peuvent occuper du contexte, surtout lorsqu’un client expose de nombreux outils simultanément. Les skills utilisent justement une divulgation progressive pour charger les instructions complètes seulement au moment utile.

Il serait pourtant imprudent d’en déduire que MCP « pollue toujours le contexte » ou qu’une CLI serait toujours moins chère.

Le protocole MCP n’impose pas une seule manière de présenter les outils au modèle. Un client peut les filtrer, les activer dynamiquement ou placer une couche de découverte devant eux. Inversement, un agent utilisant une CLI peut consommer beaucoup de contexte en lisant l’aide, interprétant une sortie libre et réparant des commandes en échec.

Une prépublication contrôlée de 2026 sur MCP et CLI a observé des comparaisons de coût instables selon sept harnais d’agent, cinq modèles et une seule tâche logicielle. L’effet du harnais dominait. Parce que l’étude porte sur une tâche et reste une prépublication, elle ne permet pas de classer universellement les interfaces.

Mesurez donc votre système configuré :

• contexte présent avant le début de la tâche ;
• appels, erreurs et nouvelles tentatives ;
• résultat contrôlé dans le système cible ;
• latence et coût de calcul ;
• coût des tâches inachevées ;
• charge de développement et d’exploitation ;
• conséquence d’une seule défaillance de la limite.

Dans notre cas de production, nous avons accepté le coût MCP car il achetait une surface de mutation plus petite. Pour une base locale que l’équipe peut supprimer et reconstruire sans conséquence, ce compromis perd beaucoup de son intérêt.

6. Décider selon la conséquence et la restauration

Commencez par la pire action que le chemin configuré peut réellement terminer.

Le NCSC britannique formule ce principe au niveau du système : plus l’autonomie et l’impact potentiel augmentent, plus les contrôles doivent être forts. Ses recommandations demandent de ne pas dépendre du prompt seul et d’examiner ensemble sandbox, réseau, identifiants, données, supervision et arrêt d’urgence.

La voie peut évoluer. Une CLI peut être parfaite pendant la preuve de concept sur un état jetable. Quand le même processus atteint la production, plusieurs utilisateurs ou des données personnelles, un serveur ou adaptateur plus étroit peut devenir le plus petit investissement responsable.

7. Cartographier le parcours complet d’une capacité

Avant de choisir l’interface, dessinez le chemin qui relie l’intention de l’utilisateur à la conséquence métier.

Nous utilisons une carte du parcours de capacité de l’agent en sept champs :

Cette carte tient dans une revue d’architecture et fournit des éléments directement testables. Surtout, elle révèle les fausses limites.

Si « ne pas supprimer » apparaît seulement dans la couche d’instructions, l’interdiction reste consultative. Si le même shell sans restriction peut lire le secret et contourner le hook, la frontière des identifiants est faible. Si un outil en lecture renvoie toute la table clients, la frontière du résultat reste large même si aucune donnée n’est modifiée.

Pour gérer l’accès dans le temps, reliez cette décision au guide IZZY sur le cycle de vie des accès et autorisations des agents IA. Pour les actions à conséquences, utilisez le modèle de contrôles avant de laisser un agent agir. La présente méthode choisit le chemin d’accès ; ces deux guides organisent ensuite les droits et l’autonomie autour de lui. Si l’agent a besoin de données représentatives de la production plutôt que d’un accès direct à celle-ci, les instantanés, répliques et récupération contrôlée peuvent faire disparaître la question.

8. Construire une limite qui refuse par défaut

Une fois le parcours visible, implémentez la voie la plus petite capable de terminer la tâche.

1. Séparer les actions autorisées, interdites et soumises à validation

Évitez « accès à la base » ou « gérer le CMS ». Écrivez : lire ces schémas, consulter ces fiches, préparer ce brouillon, publier cette révision précise, ne rien supprimer.

2. Retirer les échappatoires génériques des chemins sensibles

Trois méthodes de lecture accompagnées de execute_any_command ne forment pas une surface étroite. Cherchez les shells, le code arbitraire, le SQL générique, les clients HTTP sans restriction, les traversées de fichiers et les identifiants hérités qui recréent une voie plus large.

3. Réduire aussi les droits du système cible

La base, le cloud, le CRM ou le CMS doit refuser les pouvoirs inutiles. Une interface étroite devant un identifiant administrateur fait dépendre la sécurité d’une seule couche.

4. Garder les secrets hors des prompts, paramètres, résultats et journaux ordinaires

Choisissez le mécanisme de gestion des secrets adapté au déploiement, limitez les processus qui peuvent les récupérer, organisez leur rotation et testez leur révocation. .env peut être une solution locale pratique ; il ne remplace ni l’isolation du processus ni un gestionnaire de secrets quand les conséquences exigent davantage.

5. Valider hors du modèle

Contrôlez l’outil appelé, ses paramètres, la ressource, le type d’opération, le volume et la validation éventuelle. Les hooks peuvent refuser dans le harnais ; les fonctions de traitement, proxies et systèmes cibles doivent placer la règle au plus près de la conséquence.

6. Limiter aussi les résultats

Restreignez les champs, objets, périodes, volumes et valeurs sensibles. Traitez les réponses des outils et contenus récupérés comme des entrées non fiables avant leur retour dans le contexte du modèle.

7. Conserver des preuves attribuables

Enregistrez l’identité demandeuse, la version de l’agent, l’action tentée, la cible, la décision de politique et le résultat sans journaliser d’identifiants ni de données inutiles. La transcription du modèle n’est pas, à elle seule, une piste d’audit complète.

8. Tester les refus et contournements

Essayez l’opération interdite avec d’autres syntaxes et d’autres outils disponibles. Testez les paramètres mal formés, commandes encodées, demandes indirectes, gros résultats, nouvelles tentatives, délais dépassés et l’indisponibilité du service de politique. En cas de doute, le système doit refuser, pas revenir silencieusement vers la voie large.

9. Tester l’arrêt

Identifiez le serveur, jeton, processus, réseau, travail planifié et session à interrompre. La révocation reste incomplète si l’agent peut continuer avec un identifiant hérité ou un autre client.

Conclusion : l’interface n’est pas la limite de sécurité

MCP peut exposer une petite surface de capacités. Il peut aussi exposer un shell sans restriction. Un skill peut rendre une procédure CLI claire, légère et reproductible. Son texte ne peut pas, seul, retirer des commandes et des identifiants de l’environnement de l’agent.

Décidez depuis la conséquence vers l’interface.

Si l’état est jetable et la restauration triviale, skill plus CLI peut être le meilleur compromis. Si l’agent atteint une production ou un système difficile à récupérer, réduisez ce qui est mécaniquement invocable, retirez les chemins alternatifs et imposez la même décision sur plusieurs couches.

Le modèle hybride est souvent le plus robuste : un skill charge la procédure au bon moment ; un outil MCP ou service borné n’exécute que les capacités que cette procédure est autorisée à demander.

Questions fréquentes

Sources, méthode et limites

Sources techniques, officielles et primaires vérifiées le 28 août 2026 :

• Model Context Protocol : outils
• Model Context Protocol : autorisation
• Agent Skills : ajout du support des skills
• Spécification Agent Skills
• OWASP AI Agent Security Cheat Sheet
• OWASP Secrets Management Cheat Sheet
• CNIL et Conseil de l’IA et du Numérique : note sur l’IA agentique et les données personnelles
• NCSC : gestion du cyberrisque de l’IA agentique
• Alier Forment et al. : comparaison contrôlée MCP/CLI, prépublication

Le cas d’accès à une base de production est un retour de projet IZZY de première main, désidentifié. Aucun résultat client, incident ou gain comparatif de performance n’est revendiqué. Le retour public ne précise pas la configuration du rôle natif de la base de données.

Des comparatifs récents de praticiens ont servi uniquement à évaluer la saturation du sujet et le vocabulaire employé, pas à étayer les affirmations de sécurité ou de demande. Aucun volume de recherche n’a pu être vérifié, et aucune conclusion universelle sur les tokens, la latence ou le taux de réussite n’est formulée.

Ce contenu fournit des orientations générales de produit et d’ingénierie. Il ne constitue ni un test d’intrusion, ni une revue de sécurité de base de données, ni une analyse de conformité, ni un avis juridique. Tout accès à des identifiants de production, données personnelles ou confidentielles, écritures et actions à fort impact doit être examiné dans l’architecture réelle par les responsables compétents.