Des outils MCP contrôlés pour les agents IA

Le Model Context Protocol (MCP) facilite la connexion d’un modèle ou d’un agent à des outils. Le protocole, à lui seul, ne décide pas si l’agent doit être autorisé à exécuter une opération particulière, sur quelle ressource, et avec quelles conséquences. La couche applicative doit encore appliquer ces limites.

Si un agent peut utiliser le MCP pour lire un rapport, modifier une configuration, commencer à dépenser de l’argent ou supprimer une ressource, nous le considérons comme un client API privilégié. L’invite décrit l’intention. La passerelle impose les limites.

En pratique, nous concevons cette frontière autour de sept principes.

1. Séparer l’identité de l’opérateur des identifiants du système cible

Un agent agit au nom de quelqu’un. Nous devons donc répondre à au moins deux questions distinctes :

• qui a demandé cette opération et que peut‑il faire dans Brillnet ?
• comment Brillnet s’authentifie‑t‑il auprès du fournisseur externe ?

Ces deux points ne sont pas identiques.

Dans notre outil interne Brillnet Ads MCP, l’opérateur transite par la couche d’autorisation de Brillnet, tandis que les appels à Google utilisent une identité de service distincte. Le jeton du fournisseur est à courte durée de vie et n’est pas renvoyé via le MCP comme donnée pour le modèle.

Le modèle n’a pas besoin de connaître un identifiant pour accomplir une tâche autorisée. Il ne peut pas non plus coller accidentellement cet identifiant dans une réponse s’il ne l’a jamais reçu.

Règle

Un secret doit être disponible uniquement pour le composant qui doit l’utiliser, et non pour toute la chaîne d’exécution.

2. Exprimer les permissions par opération, pas seulement par nom d’agent

Un rôle tel que marketing-agent est facile à lire, mais à lui seul il indique très peu sur ce que le système autorisera réellement.

Il est plus utile de séparer les permissions par conséquence :

read
→ rapports et récupération

write
→ création ou modification d’une ressource

operate
→ activation d’une conséquence opérationnelle, comme la dépense ou la publication

destructive
→ suppression, détachement, révocation ou tout autre changement difficile à inverser

Un agent peut disposer de read sans write. Il peut avoir write pour préparer une campagne mais pas operate, ce qui l’empêche d’activer cette campagne. La suppression peut exiger à la fois write + destructive.

Les noms n’ont pas besoin d’être exactement ceux‑ci. L’essentiel est la distinction entre préparer un changement et activer sa conséquence.

Lire : Moindre privilège pour les agents IA

3. Les valeurs par défaut sûres doivent fonctionner sans aide du modèle

Si l’omission d’un paramètre peut déclencher une action, la valeur par défaut est dangereuse.

Dans notre Brillnet Ads MCP interne, une nouvelle campagne reste PAUSED lorsqu’aucun statut n’est fourni explicitement. Le détail paraît minime, mais la règle est cruciale : l’absence d’information n’est pas un consentement à commencer à dépenser.

Le même schéma s’applique ailleurs :

• document sans statut → brouillon, pas publication ;
• nouvel utilisateur sans rôle → aucun accès, pas rôle par défaut ;
• intégration sans destination confirmée → aucune synchronisation ;
• ressource ambiguë → erreur, pas le « record le plus probable » ;
• approbation manquante pour une action à haut risque → arrêt, pas nouvelle tentative.

Une valeur par défaut sûre doit rester sûre même si le modèle hallucine, omet un champ ou comprend mal l’intention.

4. Les opérations à fort impact nécessitent une porte séparée

Un agent peut préparer un changement techniquement correct qui reste néanmoins une mauvaise décision métier.

Dépenser un budget, publier du contenu, envoyer un message à un client, modifier des accès ou supprimer des données engendre des conséquences qui dépassent la session de l’agent. L’approbation doit donc être un événement indépendant.

Au minimum, un aperçu d’approbation doit afficher :

• le système cible et la ressource ;
• le type d’opération ;
• les paramètres matériels du changement ;
• la conséquence attendue ;
• si l’opération est réversible ;
• qui approuve.

« Continuer ? » ne suffit pas. La personne doit savoir exactement ce qui est approuvé.

Lire : Quand un agent IA doit‑il nécessiter une approbation humaine ?

5. Un nouveau essai ne doit pas dupliquer silencieusement une écriture

Les systèmes agentiques effectuent de nombreux appels API. Les erreurs réseau, les dépassements de délai et les nouvelles tentatives sont normaux. Le problème apparaît lorsque la répétition de la même opération crée une seconde ressource ou exécute un second paiement, une seconde publication ou un second message.

Lorsque l’opération le permet, nous utilisons une clé d’idempotence. La passerelle reconnaît la même tentative et empêche une écriture dupliquée incontrôlée.

Cela doit être combiné avec un read‑after‑write :

l’agent demande un changement
↓
la passerelle valide et exécute l’écriture
↓
le système cible répond
↓
la passerelle lit l’état résultant de la ressource
↓
l’opérateur voit cet état résultant

Un fournisseur renvoyant HTTP 200 n’est alors plus la seule preuve que le système se trouve dans l’état attendu.

6. Une passerelle brute ne doit pas devenir une porte dérobée

Les API volumineuses créent une tentation pratique : au lieu de construire un outil dédié pour chaque point d’accès, exposer une capacité REST plus générale.

Cela peut être raisonnable, mais uniquement si le chemin général hérite des mêmes contrôles.

Chez Brillnet, la méthode, le point d’accès et les caractéristiques de la requête sont classés avant exécution. Une requête de bas niveau ne contourne pas les portées fonctionnelles requises ni le contrôle supplémentaire pour les opérations destructrices.

L’anti‑pattern ressemble à ceci :

outils MCP sûrs
→ limités et validés

raw_http_request
→ peut appeler n’importe quel endpoint avec un jeton d’accès complet

Dans ce design, les contrôles précédents sont largement cosmétiques. Le chemin le plus large définit la véritable frontière de sécurité.

7. La trace d’audit enregistre la décision et le résultat, pas les secrets

Notre outil interne consigne les métadonnées de la requête et les résultats dans une chaîne d’audit append‑only contrôlée en intégrité. Les identifiants, en‑têtes d’autorisation et identifiants personnels bruts sont exclus.

Cette distinction est importante. Une trace d’audit doit permettre de reconstituer une action, pas de dupliquer le contexte de sécurité dans un autre magasin de données.

Pour une opération d’agent, nous voulons généralement connaître :

• l’ID de la requête/tâche ;
• l’identité de l’opérateur et de l’agent ;
• l’outil et la classe d’opération ;
• la ressource cible ;
• la décision d’autorisation ;
• l’ID d’approbation si une approbation était requise ;
• le résultat du fournisseur/backend ;
• l’état observé après une écriture ;
• la version de la politique ou de la configuration appliquée.

Lire : Traces d’audit des agents IA

Exemple d’architecture : un agent pour Google Ads

Notre cas interne est volontairement étroit. L’outil n’est utilisé que pour les comptes Google Ads détenus par Brillnet. Il ne s’agit pas d’un service d’agence et il ne reçoit pas d’accès aux comptes publicitaires des clients.

Le flux peut être simplifié ainsi :

opérateur Brillnet
↓
identité + profil + portées
↓
agent / modèle
↓
appel d’outil MCP
↓
passerelle : validation + classification + politique d’approbation
↓
jeton fournisseur à courte durée de vie
↓
API Google Ads
↓
normalisation + masquage
↓
read‑after‑write / résultat
↓
trace d’audit

Le contrôle le plus important ne se trouve pas dans le modèle. Il réside dans la couche entre l’intention et l’exécution.

Anti‑patterns à l’apparence pratique

Un jeton administrateur unique pour chaque agent

Cela simplifie le prototype. Plus tard, il devient difficile de limiter l’impact d’une erreur ou de prouver qu’un agent aurait dû pouvoir accéder à une ressource.

« Le modèle demandera à l’utilisateur si l’action est risquée »

Cela délègue la décision de sécurité au même composant dont les erreurs le contrôle est censé contenir.

Journaliser l’invite complète et la réponse comme trace d’audit

Une conversation n’est pas un enregistrement opérationnel d’audit. Elle peut aussi contenir des informations qui ne doivent pas être copiées dans le système de journalisation.

Réessayer automatiquement chaque erreur

Toutes les erreurs ne sont pas transitoires. Toutes les écritures ne sont pas idempotentes. Une nouvelle tentative non classifiée peut augmenter les dommages.

Un endpoint universel avec accès complet « pour les futures fonctionnalités »

Si un outil large peut contourner les outils contraints, l’outil large devient le véritable modèle d’autorisation.

Checklist de révision du serveur MCP

Avant la mise en production, je vérifierais au moins :

• L’identité de l’opérateur est‑elle connue pour chaque appel ?
• Les identifiants du système cible sont‑ils cachés au modèle ?
• Les permissions read, write, operate et destructive peuvent‑elles être séparées ?
• L’autorisation restreint‑elle la ressource/locataire/compte ainsi que la fonction ?
• L’omission d’un paramètre conduit‑elle à un état sûr ?
• Les opérations financières, externes et destructrices ont‑elles une approbation indépendante ?
• Les nouvelles tentatives d’écriture sont‑elles contrôlées ?
• La ressource cible est‑elle relue après une écriture ?
• Tout gateway de bas niveau utilise‑t‑il les mêmes règles d’autorisation ?
• La trace d’audit exclut‑elle les jetons, secrets et données personnelles brutes ?
• Les chemins de fichiers arbitraires et les charges utiles non limitées sont‑ils rejetés ?
• L’accès de l’agent ou de l’opérateur peut‑il être révoqué de façon centrale ?

MCP 2026‑07‑28 modifie le protocole, pas le besoin de contrôles applicatifs

La version 2026-07-28 du MCP a introduit, parmi d’autres changements, un cœur de protocole sans état et un renforcement supplémentaire de l’autorisation. Ces changements facilitent la mise à l’échelle et la compréhension de la couche de communication. Ils ne décident pas de la politique métier d’un déploiement : si un agent peut dépenser 5 000 PLN, supprimer un compte ou envoyer un message à 10 000 personnes.

L’application doit toujours appliquer cette décision.

Qui a besoin de ce modèle de conception

Les propriétaires de processus, les développeurs et les examinateurs de sécurité ont besoin de cette frontière. Les agents de fabrication peuvent rédiger des demandes de changement ; les agents de gestion immobilière peuvent organiser des documents ; les agents B2B peuvent analyser des tickets. L’envoi d’avis aux résidents ou la modification des permissions client exigent un contrôle de la conséquence.

L’exemple Ads MCP provient de la documentation de conception d’un outil interne. Il ne décrit ni un service de comptes publicitaires client ni un audit indépendant de l’environnement de production actuel.

Identité et isolement nécessitent plus qu’un jeton valide

L’autorisation MCP requiert des jetons destinés à la ressource du serveur lui‑même. Une signature valide sur le jeton d’un autre service est insuffisante. Vérifiez l’audience, l’émetteur et la validité. Rejetez les jetons inappropriés avant l’exécution.

Vérifiez également l’accès à la ressource. Comparez un tenant_id fourni avec l’identité établie par le serveur plutôt que de faire confiance à l’identifiant de l’agent. Chaque lecture et écriture nécessite une autorisation de ressource, y compris les pièces jointes, les exportations et les travaux en arrière‑plan.

MCP 2026-07-28 ne comporte pas de sessions au niveau protocolaire. Les applications peuvent toujours maintenir un état, tel qu’un handle de prévisualisation de changement. La possession ne doit pas remplacer l’authentification. Liez les handles aux opérateurs autorisés, vérifiez chaque utilisation et définissez une expiration. Un handle volé ne doit pas exposer le flux de travail d’une autre personne.

Valider le contenu et les destinations de communication

Les résultats de recherche, PDF, e‑mails et réponses d’API sont du matériel d’analyse. Les instructions intégrées visant à récupérer des secrets ou à envoyer des documents ailleurs ne constituent pas une approbation d’opérateur. Pour la protection contre les injections d’invite, le serveur doit rejeter les ressources, destinataires et opérations non autorisés même lorsque les arguments de l’outil sont techniquement valides.

Pour un outil acceptant des URL, définissez les destinations permises et la gestion des redirections. Les directives MCP évoquent le SSRF dans la découverte de métadonnées OAuth. Appliquez le même examen aux outils de récupération personnalisés. La permission de récupérer une page publique ne doit pas exposer un service d’administration local ou un point de terminaison de métadonnées cloud. Les protections dépendent de l’architecture réseau ; une simple liste d’hôtes peut ne pas contrôler la destination finale de la connexion.

Pour les outils de fichiers, limitez les répertoires et la taille des charges utiles. Rejetez les chemins en dehors de la zone permise, les champs inconnus et les exportations excessives. Une erreur explicite est préférable à une expansion silencieuse de l’affectation.

Petit scénario de déploiement : brouillons de tickets de service

Supposons qu’une entreprise veuille réduire le temps de préparation des tickets d’incident d’équipement. L’agent lit un manuel approuvé et l’historique des incidents, puis prépare un brouillon. L’envoi au fournisseur reste une opération distincte. Il s’agit d’un scénario de conception, pas d’une affirmation selon laquelle Brillnet propose actuellement cette fonctionnalité.

Le propriétaire du service sélectionne un groupe d’équipement et définit la sortie attendue : un brouillon identifiant l’équipement, le symptôme, l’heure de l’événement et les informations manquantes. Le développeur expose deux outils étroits : récupération de documents approuvés et création de brouillon dans un projet spécifié. La version initiale ne fournit ni messagerie ni configuration d’équipement. L’examinateur de sécurité vérifie la portée des données et la révocation d’accès centralisée.

Testez une lecture autorisée, une tentative de lecture inter‑projet, un document contenant des instructions malveillantes, et une nouvelle tentative d’écriture après un délai d’attente. Un petit catalogue d’outils suffit pour démarrer. Il doit appliquer les restrictions promises par la conception.

Si l’envoi est ajouté plus tard, l’approbation doit couvrir le destinataire et le contenu. Modifier le destinataire invalide l’approbation précédente. Lorsqu’un fournisseur ne supporte pas l’idempotence, résolvez un délai d’attente ambigu en vérifiant si le message existe déjà. Ne renvoyez pas simplement parce que l’agent n’a pas reçu de réponse.

Que faire demain, avec un propriétaire

Le propriétaire du processus sélectionne une action et la conséquence autorisée. Le développeur cartographie l’outil, l’opération et la ressource, y compris le chemin d’accès le plus large disponible. L’examinateur de sécurité vérifie où l’identité de l’opérateur se termine, où l’identité de service commence et si le modèle peut accéder aux identifiants. Le livrable du premier jour doit être une carte courte et une exécution dont l’état résultant peut être vérifié dans le système cible.

Mesurez la qualité des brouillons acceptés, les violations de portée rejetées et le temps de révision humaine. Plus d’appels d’outil ne sont pas automatiquement utiles. Si la correction prend plus de temps que la préparation ne le fait gagner, restreignez la tâche avant d’ajouter des capacités.

Guide technique et obligations légales

OWASP et NIST offrent des guides techniques. La spécification MCP définit les exigences du protocole. Ces sources ne déterminent pas de façon indépendante les obligations légales ou les périodes de conservation des données d’une entreprise donnée. Identifiez les exigences sectorielles, contractuelles et légales applicables au processus. Ce guide explique la conception des contrôles et ne confère aucune certification de conformité.

Frontière

Ce sont des modèles que nous utilisons dans notre propre travail. Cette page ne prétend pas que l’ensemble de l’outil soit certifié ou universellement conforme à OWASP, NIST ou à la spécification complète du MCP. Chaque intégration nécessite toujours son propre modèle de menace et ses tests de sécurité.

Si vous souhaitez évaluer comment Brillnet gère l’accès, les données et l’IA, consultez Sécurité et Conformité et supervision IA.

Sources

Les sources techniques soutiennent les principes énoncés. Les scénarios de déploiement et le plan d’action sont les recommandations de conception de l’auteur.

• Model Context Protocol — Spécification version 2026-07-28 — consulté : 2026-10-02.
• Model Context Protocol — Autorisation 2026-07-28 — consulté : 2026-10-02.
• Model Context Protocol — Meilleures pratiques de sécurité 2026-07-28 — consulté : 2026-10-02.
• OWASP AI Agent Security Cheat Sheet — consulté : 2026-10-02.
• OWASP MCP07:2025 — Insufficient Authentication & Authorization — consulté : 2026-10-02.
• OWASP MCP08:2025 — Lack of Audit and Telemetry — consulté : 2026-10-02.
• OWASP Authorization Cheat Sheet — consulté : 2026-10-02.