Outils et protocoles d'action

Sécuriser les MCP utilisés par un agent IA

MCP simplifie l'exposition d'outils et de ressources à un agent. Il ne supprime ni la vérification du serveur et de l'outil, ni le contrôle des paramètres, ni l'autorisation de l'action, ni l'observation de son effet.

Donner un outil à un agent, c'est lui donner une capacité d'action.

Voir l'architecture complète

Par Sécurité Agentique · Publié le 28 septembre 2026

Ce qu'un agent voit lorsqu'il découvre un outil

Avec MCP, l'agent interroge un serveur, reçoit la liste de ses outils avec leur description et leur schéma, puis choisit lequel appeler et construit les arguments. Le choix repose en grande partie sur le texte de la description.

Ce que l'agent reçoit lors de la découverte (exemple simplifié)

server: crm-tools
tool: exportCRM
description: "Exporte des opportunités
  vers une destination."
inputSchema:
  fields:      string[]
  filter:      string
  destination: string

Serveur: Qui expose l'outil. Est-il approuvé, authentifié ?
Outil: Le nom que l'agent choisira.
Description: Lue par le modèle pour décider. Donnée interprétée, donc surface d'attaque.
Schéma et paramètres: Ce que l'agent peut remplir, et donc détourner.
Réponse: Revient dans le contexte de l'agent après l'appel.

Une description d'outil n'est pas de la documentation pour un humain : c'est une donnée que le modèle interprète pour décider de ses actions.

Les risques MCP

Tool poisoning: Une instruction glissée dans la description ou le schéma oriente l'agent. Voir tool poisoning.
Serveur usurpé: Un serveur se présente sous le nom d'un serveur approuvé.
Description trompeuse: L'outil fait plus, ou autre chose, que ce qu'il annonce.
Paramètre détourné: L'agent, influencé, remplit un argument avec une valeur non prévue : destination, filtre vide, tous les champs.
Outil trop puissant: Un outil générique (exécuter une requête, un script) couvre bien plus que la mission.
Résultat malveillant: La réponse de l'outil contient une instruction, comme un document RAG piégé (voir sécuriser le RAG).
Serveur non approuvé: Ajouté par un développeur ou un utilisateur hors de tout inventaire.
Chaîne excessive: Une succession de tool calls, chacun anodin, produit un effet que personne n'a validé.
Outil qui encapsule une API: L'outil appelle une API avec son propre token ; les contrôles de sécurisation des API restent nécessaires derrière lui.

Deux questions différentes

Question 1

Cet outil et cet appel présentent-ils un risque de sécurité ?

Fonction ·: inspection, agent security, runtime security
Exemple technologique ·: AccuKnox

Un outil sain peut être interdit : exportCRM est légitime, mais Hermes n'a pas à exporter pour un stagiaire.

Question 2

Hermes a-t-il le droit d'effectuer cette action ?

Fonction ·: autorisation (PEP + PDP)
Exemple technologique ·: Axiomatics

Une action normalement autorisée peut être bloquée : l'export quotidien vers Reporting est permis, mais la description de l'outil vient d'être modifiée pour ajouter une destination.

Les deux contrôles sont complémentaires. L'inspection ne connaît pas la mission de Hermes ni les droits d'Alice ; l'autorisation ne lit pas la description de l'outil pour y chercher une instruction cachée.

Architecture MCP avec défense en profondeur

Selon l'architecture, la couche d'inspection et le PEP peuvent être un même composant (une gateway MCP qui inspecte et consulte le PDP) ou des composants distincts. Le principe ne change pas : aucun appel n'atteint le serveur sans avoir été inspecté et autorisé, et aucune réponse ne revient à l'agent sans inspection. Le rôle exact du PEP et du PDP est détaillé dans autorisation fine des agents IA.

Exemple : l'outil « Export CRM »

L'outil exportCRM accepte trois paramètres : fields, filter, destination.

Exemple illustratif · tool call exportCRM

Appel 1

Agent: Hermes
Outil: exportCRM
fields: id, amount, status
destination: reporting.corporate

✓ PERMIT

Appel 2

Agent: Hermes
Outil: exportCRM
fields: all (attribut modifié)
destination: external-storage.example (attribut modifié)

✕ DENY

Même outil, même agent. Les paramètres diffèrent, la décision aussi. Une allowlist d'outils seule aurait laissé passer les deux appels.

Contrôler plus que le nom de l'outil

Autoriser exportCRM sans regarder ses arguments revient à autoriser tous les exports possibles. Une politique utile peut porter sur :

outil
arguments
ressource ciblée
volume
destination
utilisateur à l'origine
agent
environnement
moment
finalité

Moindre privilège pour les outils

Exposer à Hermes tous les outils disponibles « au cas où » élargit ce qu'un contenu injecté peut lui faire faire. Le moindre privilège s'applique à plusieurs niveaux :

Allowlist d'outils: Seuls les outils de la mission sont présentés au modèle.
Capabilities ciblées: Préférer exportOpportunitiesToReporting à runQuery.
Actions limitées: Lecture seule par défaut, écriture sur des objets précis.
Identité dédiée: Un compte par agent et par serveur, jamais un compte partagé.
Tokens courts: Durée et audience limitées pour réduire l'usage d'un token volé.
Validation humaine: Pour les effets irréversibles : paiement, suppression, envoi externe.

Observer le runtime

Une décision légitime peut conduire à une activité anormale : l'outil est compromis, une dépendance est piégée, ou l'enchaînement d'appels dérive. L'autorisation porte sur la demande ; elle ne voit pas ce que fait ensuite le processus du serveur MCP.

Multiplication d'appels: Boucle ou balayage inhabituel.
Processus inattendu: Shell lancé par un serveur d'export.
Accès fichiers: Lecture de clés ou de fichiers système.
Réseau inhabituel: Connexion vers une destination inconnue.
Tentative d'élévation: Changement de privilèges, montage, capacités noyau.

La sécurité runtime observe et restreint ce comportement au niveau du workload ; l'autorisation décide des actions. Ensemble, elles couvrent la demande et son exécution ; les signaux qu'elles produisent servent à détecter un agent qui sort de son périmètre. Les autres chemins de Hermes sont décrits dans l'architecture complète.

FAQ

Questions fréquentes

MCP est-il sécurisé par défaut ?

MCP est un protocole : il standardise la façon dont un agent découvre et appelle des outils et des ressources. Il ne décide pas quels serveurs sont dignes de confiance, quels outils un agent doit voir ni quels paramètres sont acceptables. Ces contrôles relèvent de l'architecture qui entoure le protocole.

Qu'est-ce que le tool poisoning ?

L'insertion, dans la description, le schéma ou les métadonnées d'un outil, d'un contenu conçu pour influencer l'agent : instruction cachée, consigne d'appeler un autre outil, de transmettre un fichier ou d'ajouter un paramètre. L'agent lit la description pour choisir ses outils ; elle devient donc une entrée non fiable.

Comment sécuriser un serveur MCP ?

N'autoriser que des serveurs approuvés et identifiés, inspecter les descriptions et leurs changements, limiter les outils exposés, donner au serveur une identité et des tokens restreints à sa fonction, valider les arguments des appels, inspecter les résultats et observer le comportement du workload qui l'exécute.

Comment contrôler les outils visibles par un agent ?

Par une allowlist appliquée avant la présentation des outils au modèle : un tool broker ou une gateway MCP ne transmet à l'agent que les outils prévus pour sa mission. Un outil que l'agent ne voit pas ne peut pas être choisi, même par un contenu injecté.

Peut-on appliquer du PBAC à MCP ?

Oui. Chaque tool call est une demande d'action : sujet (utilisateur et agent), action (l'outil), ressource et paramètres, contexte. Un PEP dans la gateway MCP ou le tool broker peut soumettre cette demande à un PDP et appliquer une politique PBAC ou ABAC.

Où placer un PEP avec MCP ?

Entre l'agent et les serveurs MCP : gateway MCP, proxy d'outils ou tool broker du framework d'agent. Pour les actions à effet métier, un second PEP peut rester devant l'API ou l'application ciblée par l'outil, au cas où le serveur MCP serait contourné.

Comment limiter les paramètres d'un tool call ?

En validant le schéma (types, valeurs admises) puis en soumettant les arguments significatifs à la politique : champs demandés, filtre, volume, destination. Une validation de schéma vérifie la forme ; seule une décision d'autorisation vérifie que la valeur est acceptable pour ce sujet et ce contexte.

Quelle différence entre MCP security et autorisation ?

La sécurité MCP qualifie le risque technique : serveur usurpé, description piégée, argument malveillant, résultat hostile, comportement anormal. L'autorisation décide si cet agent, pour cet utilisateur, peut effectuer cette action avec ces paramètres. Un outil sain peut être interdit ; une action autorisée peut être bloquée si l'outil est compromis.

Continuer l'exploration

Votre agent possède-t-il plus de pouvoir que sa mission ne l'exige ?

Nous pouvons cartographier ses données, outils, API et actions pour identifier les points de contrôle réellement utiles.

Étudier mon architecture