Des agents sous la même décision que vos applications.

Une opération devient un outil d'agent quand le contrat la marque x-flexway-tool : l'exposition est opt-in, et une écriture n'est jamais offerte à un agent sans que quelqu'un l'ait décidé. tools/list est dérivé de l'OpenAPI - nom (operationId ou nom déclaré), description, schéma d'entrée construit depuis les paramètres et le corps déclarés - et filtré par les portées de l'appelant. Un outil qui n'est pas une opération déclarée n'existe pas.

tools/call construit la requête de l'opération et la fait passer, en mémoire, par la même décision qu'un appel REST : portées, quota de l'appelant, validation, politiques, budgets, métriques. Une opération est donc appelable en REST et via MCP avec le même verdict et le même seau de quota. Un argument non déclaré est refusé ; le résultat est rendu en texte, en structuredContent pour un objet JSON, avec isError pour un statut supérieur ou égal à 400, et borné à 1 Mio.

Le transport est Streamable HTTP sans session : une session vivrait sur une réplique et mourrait au rechargement. Le transport stdio ne traverse pas de réseau, il reste hors du périmètre d'une passerelle. Une opération à réponse en flux ne peut pas être un outil.

La surface MCP est un serveur de ressources OAuth 2.1 à part entière. Elle publie ses métadonnées de ressource protégée (RFC 9728) sous /.well-known/oauth-protected-resource/<chemin> et répond 401 avec resource_metadata, pour que le client découvre où obtenir un jeton au lieu de le deviner. Le jeton doit être émis pour cette surface (RFC 8707) : son audience est l'URL publique déclarée dans agents.mcp.resources, jamais déduite de la requête.

Le jeton de l'agent n'est jamais relayé à l'amont, ce qui ferme la voie du « confused deputy ». Un jeton MCP est refusé sur une route REST, et la surface n'accepte que des jetons OAuth : une clé d'API n'est pas l'identité d'un agent qui agit pour quelqu'un. L'émetteur est vérifié, et ses clés ne valident que ses propres jetons.

Le client est lu dans le jeton (client_id, sinon azp) ; agents.mcp.clients ferme la surface aux clients déclarés, par URL de document de métadonnées ou par préfixe. Un agent non surveillé - un client qui agit pour lui-même - est reconnu, et x-flexway-tool: { unattended: false } lui cache et lui refuse un outil.

Un amont qui déclare token_exchange reçoit un jeton émis pour lui, au nom de l'appelant, par le fournisseur qui a signé le jeton d'origine (RFC 8693) ; la passerelle consomme des identités, elle n'en émet pas. L'échange a lieu après toute la décision - identité, portées, quota, validation, politiques - et avant le relais : un appel refusé ne coûte aucun échange. Un appel anonyme n'a rien à échanger, et l'amont ne reçoit pas d'Authorization.

L'échange ne fait que rétrécir : il demande au plus les portées de l'appelant, et une portée accordée en plus donne 403 sans appeler l'amont. Le sujet (sub) reste l'humain, les acteurs (act imbriqués) sont les agents, lus et tracés. Un refus du fournisseur donne 403 ; un fournisseur injoignable ou un secret introuvable donne 503 avec Retry-After. Il n'y a jamais de repli sur le jeton d'origine.

Le secret client est une référence relue à chaque échange, ce qui permet une rotation sans rechargement. Un jeton échangé est réutilisé jusqu'à son expiration moins 30 s, avec un seul échange en vol par jeton d'origine et audience.

Une chaîne réelle ressemble à « humain -> agent A -> agent B -> service ». agents.delegation borne sa profondeur (max_depth) et son âge (max_age, compté depuis auth_time, sinon iat) ; une opération peut resserrer ces bornes par x-flexway-delegation, jamais les élargir, et c'est le minimum des deux qui s'applique. Au-delà, la réponse est 403 ; un jeton délégué dont l'âge ne peut pas être établi est refusé.

La révocation passe par l'introspection RFC 7662 auprès de l'émetteur, avec un cache court : un jeton révoqué donne 401, un jeton invérifiable 503 avec Retry-After. Révoquer l'humain coupe ainsi toute la chaîne. Ces règles valent en REST, à la connexion à la surface MCP, et pour les outils projetés comme fédérés.

La trace porte delegation.depth et delegation.actors, la métrique flexway.delegation.refused compte les refus par raison, et la ligne d'audit des décisions porte la chaîne entière d'acteurs. Savoir quel humain, quels agents et quelles portées sont derrière une écriture vous aide à répondre aux exigences de traçabilité des actions d'agents.

Des serveurs MCP existants se placent derrière Flexway sans réécriture : un amont protocol: mcp et une entrée agents.mcp.servers suffisent. L'exposition se fait par une liste déclarée d'outils, fermée par défaut - un outil ajouté côté serveur n'apparaît pas sans décision - ou par "*", choisi explicitement. Les outils gardent leurs noms d'origine, renommables ; une collision sur un même hôte refuse le chargement avec une liste déclarée, et avec "*" l'outil en collision n'est pas servi, et c'est dit.

La découverte se fait en arrière-plan (initialize puis tools/list), retentée avec un délai croissant et rafraîchie à intervalle régulier ; ni le démarrage ni /readyz n'attendent un serveur. Chaque appel exige une identité, des portées (tool_scopes, sinon scopes) et consomme le seau de l'appelant ; la classe de débit est déclarée, sinon read pour un outil annoncé en lecture seule, write autrement. Le serveur reçoit un jeton échangé pour lui s'il déclare token_exchange, jamais le jeton de l'agent.

Chaque appel profite du cloisonnement, du coupe-circuit et du budget de l'amont, avec un résultat borné à 1 Mio. Une même surface sert les outils du contrat et les outils fédérés, en une seule liste triée par nom.

La gouvernance du trafic entre agents (A2A v1.0) n'est pas livrée dans son ensemble ; son état à cette version est indiqué ci-dessous. Le cadre retenu : relayer A2A sous la même décision que le reste - router, authentifier, autoriser, compter, observer - sans terminer le protocole, c'est-à-dire sans tenir d'état de tâche ni délivrer de notification push. Un agent se déclare par sa carte d'agent, traitée comme un contrat versionné, et l'agent amont reçoit toujours un jeton échangé, jamais celui de l'appelant.

Ce cadre prévoit un tenant tenu égal à celui de l'identité, une classe de débit par méthode, un plafond de flux et une durée de tâche bornée, des cibles de notification push restreintes à une liste d'hôtes déclarés, et un audit sans contenu. La vérification des cartes amont signées, la re-signature de la carte publiée et la délégation d'agent à agent restent à faire.