Exposer ses API à des agents

Les agents consomment les API autrement que les applications. Ils lisent un catalogue d’outils au lieu d’une documentation. Ils enchaînent des dizaines d’appels pour une seule tâche. Et ils agissent pour le compte de quelqu’un sans être ce quelqu’un. Ces différences déplacent la gouvernance, pas seulement la technique.

Ce que MCP change

Le protocole MCP décrit des outils : un nom, une description en langage naturel, un schéma d’entrée. L’agent lit ce catalogue et décide seul quoi appeler. Le contrat n’est plus lu par un développeur au moment de l’intégration, il est lu par une machine à chaque tâche.

Conséquence directe et souvent manquée : la description devient une interface. Une description approximative produit des appels approximatifs. Les mêmes exigences que pour un contrat OpenAPI de qualité, exemples réels, sémantique des erreurs, limites d’usage, deviennent ici des conditions de fonctionnement plutôt que des politesses éditoriales.

Il n’y a pas de nouveau contrat à produire : le travail porte sur les descriptions, pas sur les interfaces. Azure API Management génère les outils MCP depuis les API déjà gérées par l’instance, et AgentCore chez AWS depuis une spécification OpenAPI fournie, à condition que chaque opération porte un identifiant. L’agent passe alors par la même gouvernance que n’importe quel autre consommateur.

Et depuis la révision du 28 juillet 2026, le protocole n’a plus de session. Plus de poignée de main, plus d’identifiant de session : chaque requête se décrit elle-même. Un intermédiaire arbitre donc sur ce qu’il voit passer, au lieu de faire confiance à un état qu’il ne détient pas.

Un serveur peut même demander que certains paramètres d’outil soient recopiés en en-têtes HTTP (Mcp-Param-*). Une gateway route alors, et applique ses règles, sans ouvrir le corps de la requête. À condition de n’y mettre aucun paramètre sensible : ces en-têtes sont visibles de tous les intermédiaires. Le protocole a été réécrit en partie pour rendre ce travail de plateforme possible.

Deux identités, pas une

Un agent agit pour le compte d’un utilisateur. Il faut donc savoir deux choses à chaque appel : quel agent, et pour qui.

Confondre les deux produit les deux échecs symétriques. Avec une seule identité d’agent, l’audit perd l’utilisateur et les décisions d’autorisation ne peuvent plus dépendre de lui. En faisant simplement suivre le jeton de l’utilisateur, l’agent obtient toutes ses portées, et un agent compromis devient l’utilisateur.

Ce n’est pas une bonne pratique de cabinet, c’est une obligation de la norme. La spécification d’autorisation MCP interdit au serveur d’accepter ou de faire transiter un jeton qui ne lui était pas destiné. Elle impose la validation de l’audience. Et elle exige que le client indique la ressource visée, selon la RFC 8707, même quand le serveur d’autorisation ne sait pas la lire.

La révision du 28 juillet 2026 a durci le reste. Elle impose la validation de l’émetteur de la réponse d’autorisation (RFC 9207), contre les attaques par confusion de serveur. Et elle déprécie l’enregistrement dynamique du client, au profit d’un client_id qui est une URL vers un document de métadonnées.

La mécanique est celle du chaînage d’appels classique, décrite dans accès : le token exchange de la RFC 8693. L’agent obtient un jeton destiné à l’API cible, aux portées réduites, qui conserve l’identité d’origine.

Découvrir n’est pas invoquer

Ces deux identités ne suffisent pas si elles ne sont établies qu’une fois. Un agent peut voir un outil dans le catalogue et se faire refuser son usage : la décision se réévalue à chaque appel, jamais une fois pour toutes à la découverte.

La raison est propre aux agents : le catalogue est lu au début de la tâche, l’invocation survient plusieurs étapes plus tard, dans un contexte qui a changé. Traiter la découverte comme une autorisation revient à figer des droits pour toute la session, ce que l’autorisation évaluée par appel est précisément censée corriger.

En pratique, cela fait deux décisions distinctes, au même endroit, sur des données différentes. MCP les sépare d’ailleurs en deux méthodes. Sur tools/list, la gateway filtre le catalogue selon l’identité qui le demande : un outil qu’un agent ne pourra jamais invoquer n’a pas à y figurer, parce qu’un outil visible est un outil qu’il essaiera.

La spécification l’autorise explicitement : la liste peut varier selon l’autorisation présentée sur la requête. Elle ne doit pas varier selon la connexion. La raison tient en une phrase : les credentials sont une entrée par appel, pas un état de session.

Sur tools/call, elle décide sur ce que la liste ne portait pas : les portées du jeton échangé, l’identité de l’utilisateur d’origine, les paramètres réels de l’appel. D’où la seule règle qui compte : l’autorisation porte sur la donnée demandée, pas sur l’outil. Un agent autorisé à consulter un dossier client ne l’est pas pour tous les dossiers. Cette décision ne peut pas se prendre à la découverte, puisque l’identifiant du dossier n’existe pas encore.

La rafale change les quotas

Reste la différence la plus banale, et la plus chère : le volume. Une tâche d’agent produit couramment plusieurs dizaines d’appels là où un écran en produisait un.

Compter en coût, pas en appels, dès que l’aval est un modèle : le coût dépend des jetons consommés, et deux appels peuvent différer d’un facteur mille. Les gateways récentes savent compter en jetons et attribuer la dépense par équipe consommatrice.

Limiter la tâche, pas seulement l’appel. Un quota par appel ne protège de rien face à une boucle d’agent. La limite utile porte sur la tâche ou sur la session.

Garder un journal exploitable. Quel agent, pour quel utilisateur, quel outil, quel coût. Sans cela, la première facture surprend et personne ne peut dire quelle tâche l’a produite.

La réponse d’une API devient une entrée de commande

C’est le risque le plus spécifique aux agents, et celui qu’aucune grille de sécurité d’API ne couvre. Un agent lit les réponses qu’il reçoit et les traite comme du contexte. Or une réponse contient souvent du texte rédigé par un tiers : un nom de client, un commentaire, le champ libre d’un formulaire. Ce texte peut porter des instructions, et l’agent n’a aucun moyen de distinguer une donnée d’un ordre.

Le scénario n’a rien de théorique : un attaquant sans aucun accès à votre plateforme place la charge dans un champ que votre API restitue, et attend qu’un agent la lise. La frontière de confiance se déplace donc de l’appelant vers le contenu retourné, ce qui est nouveau.

Trois mesures se posent au niveau de la gateway, et elles valent mieux que la confiance dans le client. Marquer explicitement les champs qui contiennent du texte non maîtrisé, pour que l’agent puisse les traiter comme des données. Plafonner la taille et le nombre d’éléments retournés par appel, parce qu’une exfiltration passe par des réponses volumineuses. Et surtout, ne jamais faire dépendre une opération sensible du seul enchaînement décidé par l’agent : c’est l’objet de la confirmation ci-dessous.

Ce qu’il ne faut pas exposer

Le réflexe naturel est d’exposer tout le catalogue, puisque la génération est automatique. C’est une erreur de deux ordres.

Un catalogue trop large dégrade le comportement de l’agent : plus d’outils, plus de mauvais choix, et une description ambiguë entre deux outils voisins produit des appels faux. Un sous-ensemble choisi fonctionne mieux qu’un catalogue exhaustif.

Et toute opération irréversible doit passer par une confirmation humaine. MCP prévoit des annotations pour signaler qu’un outil est en lecture seule ou destructeur. Mais ce sont des indications à destination du client, pas une frontière de sécurité. La spécification le dit elle-même : un client doit tenir une annotation pour non fiable tant qu’elle ne vient pas d’un serveur de confiance.

Le protocole sait désormais interrompre un appel pour réclamer une saisie, mais c’est encore le client qui l’affiche et qui décide de la poser. La confirmation s’impose donc en amont, dans la gateway, où elle n’est pas facultative. Un agent qui peut supprimer, débiter ou notifier des tiers ne doit pas pouvoir le faire seul.

Par où commencer

Trois API en lecture, bien décrites, exposées à un seul agent, avec un journal des invocations et un quota par tâche. Ce périmètre tient en quelques jours et révèle ce qu’aucune documentation ne dit : la qualité réelle de vos descriptions de contrat. C’est d’ailleurs le meilleur argument pour investir dans les contrats, bien plus convaincant que la découverte pour les humains, parce que l’échec est immédiat et visible.