Dans les deux dernières parties de cette série, j'ai abordé comment le protocole de contexte de modèle est mappé sur une API de fret, puis a fait tomber les serveurs MCP de fret qui ont été expédiés en 2026. Les deux se terminaient sur la même question ouverte, donc cette partie y répond directement : une fois qu'un agent peut réserver du fret réel, comment l'empêcher de réserver la mauvaise chose pour la mauvaise personne ? La sécurité est l'endroit où un serveur MCP de fret cesse de ressembler à un jouet de développeur pour ressembler à un système qui déplace de l'argent et des camions.
Je dirige cela depuis le siège d'un marché qui expose une API, donc mon point de vue est pratique plutôt qu'académique. Les menaces ci-dessous sont celles que nous modélisons réellement lorsque nous décidons quel outil un agent peut appeler sans supervision humaine.
Pourquoi un serveur de fret augmente les enjeux
Un serveur MCP générique qui lit votre calendrier divulgue des informations en cas d'échec. Un serveur de fret qui réserve un chargement fait quelque chose de plus coûteux. Un mauvais appel peut envoyer un camion au mauvais dépôt, modifier un destinataire sur un envoi en cours, annuler une réservation sur laquelle un client compte, ou retirer un connaissement qui n'aurait jamais dû quitter le compte. Ce ne sont pas des bugs d'exposition de données. Ce sont de l'argent et des biens physiques qui se déplacent sur une instruction que personne n'a tapée.
Cette différence recadre tout le problème. Avec un assistant de conversation, le pire scénario est une réponse embarrassante. Avec le fret, le pire scénario implique une facture de fret et une expédition à un endroit où elle ne devrait pas être. La question n'est donc jamais "ce serveur est-il sécurisé" dans l'abstrait. Il s'agit de "quelles actions spécifiques un agent peut-il entreprendre, et quel est le coût de chacune si les choses tournent mal".
Les deux modes de défaillance qui valent la peine d'être étudiés en détail
La plupart des risques liés aux MCP en 2026 se résument à deux formes, et le fret empire les deux.
L'**injection de prompt** est un vieux problème du web qui change de déguisement. Un agent lit un texte provenant d'une source qu'il ne contrôle pas entièrement, un bordereau d'expédition, un PDF, le corps d'un e-mail, et ce texte contient une instruction à laquelle le modèle obéit. Dans le domaine du fret, le texte empoisonné arrive par des canaux légitimes toute la journée : un commentaire de réservation, une description douanière, une mise à jour de statut d'un transporteur. Si votre outil de réservation fait confiance à tout ce que le modèle lui transmet, une phrase enfouie dans un avis de livraison peut devenir une véritable annulation.
Le **empoisonnement d'outils** est plus subtil et spécifique à MCP. Le protocole permet à un serveur de décrire ses propres outils, et l'agent lit ces descriptions pour décider de ce qu'il faut appeler. Un serveur malveillant ou compromis peut écrire une description qui demande discrètement au modèle d'exfiltrer une clé d'API ou de rediriger une expédition, et l'utilisateur ne voit jamais ce texte. Anthropic et des chercheurs indépendants ont passé le début de l'année 2026 à documenter des variantes de cela, et la leçon pour le fret est directe : la couche de description est exécutable, alors traitez une description d'outil tierce avec la même suspicion que vous traiteriez du code tiers.
Lecture versus écriture : la ligne qui devrait décider de votre authentification
La décision de sécurité la plus utile que j'aie prise a été d'arrêter de penser au "serveur MCP" comme une seule frontière de confiance et de le diviser en fonction de ce que chaque outil fait dans le monde.
Qu'est-ce qui peut rester ouvert
Citer une voie, lister la capacité, calculer un temps de transit estimé, rechercher un code de port. Rien de tout cela ne change quoi que ce soit. Permettre à un agent de les atteindre avec peu ou pas de friction est le but, et c'est là que réside la valeur quotidienne. Un lecteur qui souhaite comparer trois itinéraires ne devrait pas avoir à créer un jeton pour le faire. Sur les serveurs lors du démontage, les plus sérieux ont maintenu les outils de citation et de référence à faible friction exactement pour cette raison.
Qu'est-ce qui doit être contrôlé
Réservation, annulation, modification d'un destinataire, modification d'une adresse, récupération d'un document, tout ce qui touche à une facture. Chacune de ces actions interagit avec le monde réel et chacune nécessite un appel authentifié, autorisé et auditable. La règle que nous suivons est simple à énoncer et plus difficile à appliquer : un outil de lecture peut être ouvert, un outil d'écriture jamais.
OAuth 2.1 et PKCE, pas une clé à longue durée de vie dans un fichier de configuration
La spécification d'autorisation MCP a opté pour OAuth 2.1 pour les serveurs distants, et ce choix a un poids réel pour le fret. Une clé API statique collée dans un fichier de configuration convient à un développeur solo exécutant un serveur via stdio sur sa propre machine. C'est le mauvais modèle à partir du moment où le serveur est accessible via HTTP et qu'un agent agit au nom d'un utilisateur nommé au sein d'un compte partagé.
Trois propriétés fournissent l'essentiel. Les jetons **scoped** signifient qu'un jeton créé pour la réservation ne peut pas être utilisé pour une autre action. Les jetons **short-lived** signifient qu'une credential compromise expire d'elle-même au lieu de rester indéfiniment dans un journal. Les jetons **révocables** signifient que lorsque quelque chose semble suspect, vous coupez l'accès en quelques secondes au lieu de faire une rotation d'une clé partagée dont tout le monde dépend. OAuth 2.1 exige également PKCE sur le flux "authorization-code", ce qui comble le manque de sécurité contre l'interception que les anciennes implémentations OAuth laissaient ouverte. Rien de tout cela n'est exotique. C'est le même renforcement que toute API de paiement a subi, appliqué au moment où un agent dit "réserver".
Voici la forme de la limite que nous imposons, écrite telle que je souhaite que tous les serveurs de fret la publient.
| Action de l'agent | Lit ou écrit | Authentification requise | En cas de problème |
| Obtenir un devis | Lire | Clé ouverte ou basique | Appel perdu, sans dommage |
| Vérifier la capacité, le transit, le suivi | Lire | Clé ouverte ou basique | Réponse obsolète au pire |
| Réserver une expédition | Écrire | Jeton OAuth délimité, étape de confirmation | Coût réel, camion réel |
| Annuler ou réserver à nouveau | Écrire | Jeton délimité, clé d'idempotence | Perte d'emplacement, pénalité |
| Changer le destinataire ou l’adresse | Écrire | Jeton à portée, confirmation humaine | Détournement, fraude |
| Tirez un connaissement ou une facture | Lire sensible | Jeton à portée, vérification par document | Fuite de données et de documents |
Le schéma de ce tableau est la décision de produit réelle. Les lectures sont à gauche et restent bon marché. Les écritures sont à droite et méritent leur friction.
Le problème de l'instance exposée
Une quantité surprenante de risques liés à MCP ne sont pas du tout astucieux. Il s'agit d'un serveur destiné à s'exécuter localement, exposé à Internet sans authentification, car il était plus facile de l'expédier ainsi. Le protocole prend en charge deux transports. Un serveur stdio s'exécute en tant que processus local lancé par le client, ce qui le maintient sur votre machine et hors du réseau. Un serveur HTTP hébergé est accessible par tout ce qui peut trouver son URL.
Pour un serveur utilitaire en lecture seule, l'exposition HTTP est en grande partie inoffensive. Pour un serveur doté d'outils de réservation, c'est le jeu entier. Si vos outils d'écriture sont accessibles via HTTP public, l'authentification n'est pas une fonctionnalité que vous ajoutez plus tard, c'est ce qui se trouve entre un étranger et votre file d'attente de dépêche. Notre règle est que les outils de réservation et de documents ne sont jamais servis via un point de terminaison HTTP non authentifié, point final. En cas de doute, un serveur capable d'écrire doit par défaut utiliser stdio et le lancement local, et ne passer à HTTP hébergé qu'une fois le flux OAuth ci-dessus en place.
Défendre la couche de description contre l'empoisonnement des outils
Parce que les descriptions d'outils orientent le modèle, elles méritent les mêmes contrôles que le code que vous déployez. Trois habitudes couvrent la plupart des expositions.
- **Fichez et révisez les serveurs auxquels vous vous connectez.** Un agent connecté à un ensemble présélectionné de serveurs connus est une cible plus petite que celui qui installe tout ce qu'un registre propose. Traitez un nouveau serveur comme une nouvelle dépendance, car c'est ce qu'il est.
- Gardez un humain à chaque opération. Une étape de confirmation avant de réserver, annuler ou modifier un destinataire transforme une instruction silencieusement injectée en une demande visible que l'utilisateur peut refuser. C'est le contrôle le moins cher avec le rendement le plus élevé.
- Validez au niveau de l'API, pas dans l'invite. Le serveur doit revérifier chaque paramètre qu'il reçoit par rapport aux autorisations réelles du compte et à l'état réel de la réservation, plutôt que de faire confiance au modèle pour assembler un appel judicieux. Le modèle propose, l'API décide.
Ce qu'un serveur de place de marché doit imposer pour qu'un seul transporteur puisse ignorer
Un serveur à porteuse unique n'agit que sur son propre réseau, le rayon d'impact est donc d'un seul opérateur. Un serveur de place de marché cite et réserve auprès de nombreux transporteurs pour le compte de nombreux utilisateurs, ce qui modifie le travail de sécurité de deux manières.
Premièrement, la portée doit être par utilisateur et par transporteur, pas par serveur. Un jeton qui permet à un agent d'effectuer une réservation auprès d'un transporteur ne doit pas en atteindre silencieusement un autre, et l'agent d'un client ne doit jamais voir les documents d'un autre client. Deuxièmement, la piste d'audit est plus importante, car lorsqu'un agent effectue une réservation sur un marché, il faut pouvoir répondre « quel utilisateur, quel jeton, quel transporteur, à quel moment » pour chaque écriture. Nous traitons ce journal comme faisant partie du produit, et non comme une réflexion après coup, car c'est ce qui nous permet de révoquer de manière ciblée plutôt que de tout arrêter pour tout le monde.
Une liste de contrôle pratique avant de publier une réservation
- Divisez les outils par lecture et écriture, et notez la distinction là où l'agent et votre équipe pourront la voir.
- Faites en sorte que les outils de citation et de référence soient faciles à utiliser pour que la valeur quotidienne subsiste.
- Mettez chaque écriture derrière un jeton OAuth 2.1 scopé, éphémère et révocable avec PKCE.
- Exiger une étape de confirmation pour les réservations, annulations et modifications de destinataire et d'adresse.
- Re-valider chaque paramètre de l'API en regard des autorisations réelles et de l'état réel du chargement.
- Ne servez jamais d'outils d'écriture via HTTP non authentifié, et les serveurs d'écriture par défaut vers stdio local.
- Épinglez les serveurs auxquels votre agent se connecte, et examinez les nouveaux comme vous le feriez pour du nouveau code.
- Enregistrez chaque écriture avec l'utilisateur, le jeton, le support et l'heure, et répétez la révocation avant d'en avoir besoin.
Aucune de ces choses n'est propre à l'intelligence artificielle. Ce sont les commandes que le fret et les paiements utilisent déjà, appliquées au nouvel endroit où une instruction peut être lancée. L'agent est un nouvel appelant, pas un nouvel ensemble de règles.
Foire aux questions
Est-il sûr de laisser un agent IA réserver du fret ?
Oui, lors de la réservation, cela se situe derrière un appel authentifié et autorisé avec une étape de confirmation, et lorsque le serveur revérifie chaque paramètre plutôt que de faire confiance au modèle. La version non sécurisée est un outil d'écriture ouvert sans intervention humaine. Traitez la réservation comme toute autre action de transfert d'argent et l'agent devient un nouvel appelant authentifié.
Pourquoi utiliser OAuth 2.1 plutôt qu'une simple clé d'API ?
Une clé statique a tendance à avoir une longue durée de vie, une portée large et est difficile à révoquer sans perturber tous ceux qui la partagent. OAuth 2.1 vous offre des jetons à portée limitée, de courte durée et révocables, et exige PKCE pour le flux d'autorisation. Pour un serveur stdio local, une clé est acceptable, mais tout ce qui est accessible via HTTP et qui peut écrire devrait utiliser le modèle OAuth.
Qu'est-ce que l'empoisonnement d'outils dans MCP ?
Le "poisoning" d'outil se produit lorsqu'une description d'outil sur un serveur, que l'agent lit pour décider de ce qu'il doit appeler, contient des instructions cachées qui orientent le modèle vers des actions nuisibles, comme la fuite d'une clé ou le détournement d'une expédition. Comme la description influence le comportement, vous la protégez de la même manière que vous protégez le code : épinglez des serveurs de confiance, maintenez un humain pour les écritures et validez au niveau de l'API.
Un serveur MCP de fret devrait-il fonctionner en stdio ou en HTTP hébergé ?
Un serveur utilitaire en lecture seule convient parfaitement sur HTTP hébergé. Un serveur avec des outils de réservation ou de documents devrait utiliser par défaut le stdio local et passer uniquement au HTTP hébergé une fois que l'OAuth ciblé est en place, car un point d'écriture exposé sans authentification est accessible par quiconque trouve l'URL.
Cela boucle la boucle que cette série a ouverte. Si vous n'avez pas lu les parties précédentes, le catalogue de protocoles explique comment une API de fret devient un ensemble d'outils, et le démontage montre où les serveurs expédiés ont tracé ces lignes en pratique.