Gouvernance des agents IA : les cinq piliers à bâtir (et non à rédiger)

Ce que régit réellement la gouvernance des agents

Jane, ingénieure support, saisit une phrase dans un copilot support : prépare un résumé de remboursement pour le ticket #4521. Le copilot la transmet à un agent planificateur, qui appelle un agent de recherche (ticket Zendesk, bug Jira lié) et un agent de facturation (enregistrement de paiement Stripe). Une seule demande humaine, six appels de machine à machine, la plupart exécutés par un logiciel qui a décidé de son propre chef d'appeler d'autres logiciels.

Cette chaîne — utilisateur → application → agent → sous-agent → outil MCP — constitue le chemin d'appel agentique (agentic call path), et c'est ce que la gouvernance des agents doit contrôler. Tout modèle d'accès en entreprise repose sur trois hypothèses : un utilisateur est à l'origine de la requête, l'entité qui passe l'appel est cet utilisateur, et la portée correspond au consentement de l'utilisateur. Dès le troisième saut, ces trois hypothèses deviennent fausses, de sorte que trois questions se retrouvent sans réponse :

• Pour qui cet appel est-il effectué ? L'utilisateur s'est authentifié trois sauts plus tôt. Son identité figure-t-elle toujours sur la requête, ou a-t-elle été remplacée par un compte de service ?
• Qui passe l'appel ? Un jeton au porteur (bearer token) prouve la possession d'un identifiant, mais ne permet pas de savoir lequel de vos deux cents agents le détient.
• Que peut-il faire ? Un jeton émis pour le premier appelé est sur-privilégié pour tous les appelés suivants.

Répondre à ces trois questions à chaque saut, preuves à l'appui, est la définition même de la gouvernance de l'IA agentique — à travers cinq systèmes, et non un paragraphe sur l'usage responsable.

L'agent est un troisième type de principal

La plupart des équipes optent pour l'un des deux raccourcis suivants : laisser l'agent transmettre le jeton de l'utilisateur, ou lui attribuer un compte de service partagé. Ces deux approches sont incorrectes, car un agent n'est ni l'un ni l'autre.

Accorder à chaque agent sa propre identité vérifiable est la décision dont découle tout le reste. Elle garantit l'attribution (le destinataire sait quel agent a appelé), une politique par agent (le copilot de Jane lisant Jira et son agent d'ingénierie écrivant dedans sont des principaux différents, bien que tous deux agissent pour Jane) et l'absence d'agents anonymes (un outil accessible uniquement par une identité enregistrée fait de l'enregistrement le point d'application).

L'urgence est bien réelle : dans la plupart des entreprises, les identités machines sont déjà plus de 40 fois supérieures en nombre aux utilisateurs humains, et les agents se multiplient plus vite que les comptes de service ne l'ont jamais fait — toute personne disposant d'un framework et d'une clé d'API peut en créer un.

Les cinq piliers

Une gouvernance complète repose sur cinq capacités fonctionnant en boucle. Les deux premières s'exécutent avant qu'un agent ne passe le moindre appel, les deux suivantes à chaque appel, et la dernière en continu — avec un retour d'information vers la deuxième étape.

Le pilier 4 est le point de jonction entre la gouvernance et le réseau. À chaque saut, la passerelle identifie l'appelant, vérifie si cet agent est autorisé à appeler cette cible et à agir pour cet utilisateur, génère un nouveau jeton restreint exactement au prochain appelé, applique les garde-fous (guardrails), puis transmet et enregistre. Trois propriétés en découlent naturellement : une attribution par saut, des jetons à privilèges minimaux (un jeton compromis n'est valable que pour un seul appelé et une seule portée) et une révocation centralisée.

Pourquoi la passerelle, et non le fournisseur d'identité (IdP)

Chaque pilier pourrait résider dans un outil différent. Ce qui maintient la cohérence du modèle est l'application des règles au niveau d'une passerelle située sur le chemin d'appel — le seul composant qui voit chaque saut quel que soit le framework ou le cloud, transmet l'identité, restreint l'autorité à chaque étape et reste neutre vis-à-vis des plateformes. Entra régit les agents Entra, Okta régit les applications Okta, Bedrock régit les agents Bedrock ; la passerelle régit le chemin à travers l'ensemble d'entre eux, là où réside le risque — un point que nous développons dans l'article sur la gouvernance des agents IA sur plusieurs plateformes. Un fournisseur d'identité sans passerelle émet des identifiants parfaits qui sont ensuite transmis sans contrôle ; un registre sans passerelle n'est que de la documentation.

Les erreurs fréquemment commises

Traiter le registre comme une feuille de calcul. Un registre que les agents peuvent ignorer n'inventorie que les agents que vous connaissiez déjà. Il n'est efficace que lorsqu'il sert de point de passage obligé : pas d'identité enregistrée, pas d'appel.

Transmettre un jeton puissant partout. C'est le moyen le plus rapide de faire fonctionner les appels, mais aussi le plus court vers une faille de sécurité. Les agents peuvent subir des injections de prompts les incitant à détourner les identifiants qu'ils détiennent ; ces derniers ne doivent donc jamais dépasser le strict besoin du prochain appel.

Revoir les comptes plutôt que les chaînes. Trois agents dans un flux d'achats — l'un crée les fiches fournisseurs, l'autre lit les données bancaires, le dernier initie les paiements — semblent acceptables pris isolément. Enchaînés, ils forment un parcours de paiement qu'aucun réviseur n'aurait approuvé : une séparation des tâches recréée (et contournée) par le logiciel.

Supposer que la portée d'un agent est statique. Un agent financier auquel on accorde l'accès à un nouveau module ERP peut commencer à traiter des données non prévues dans sa portée initiale, non pas en raison d'un défaut, mais parce que l'adaptation est le propre des agents. Le comportement doit être comparé en continu à l'autorité définie, et non sur une base trimestrielle.

Vous souhaitez mettre en place un système opérationnel plutôt qu'un schéma ?

Enregistrez un agent, attribuez-lui une identité et accordez-lui l'accès à un serveur MCP.

Commencer gratuitement

La partie complexe : deux réponses à la question « qui a fait cela ? »

Lorsque l'agent de recherche lit les tickets Jira de Jane, la réponse exacte à la question qui a fait cela désigne à la fois Jane et l'agent de recherche. Omettez l'un des deux et vous perdez une information essentielle. Il existe deux façons d'intégrer cela dans un jeton, et ce choix détermine la valeur même de votre piste d'audit.

Pour les agents, la délégation est presque toujours préférable. Le jeton délégué conserve l'utilisateur dans la revendication sub et nomme l'intervenant dans act ; les appels en chaîne imbriquent les revendications, la plus externe représentant l'intervenant le plus récent :

Deux revendications complémentaires se partagent le travail. may_act est le filtre préalable — cet intervenant est-il autorisé à agir pour ce sujet — vérifié avant l'émission du jeton. act enregistre qui a réellement agi. L'autorisation s'effectue sur l'intervenant actuel, le sujet et la politique ; la chaîne imbriquée est conservée pour l'analyse décisionnelle ou légale (forensics).

Le mécanisme sous-jacent est l'échange de jetons (token exchange). La spécification RFC 8693 le définit ainsi : présenter un jeton sujet et optionnellement un jeton acteur pour recevoir un nouveau jeton ciblé sur un destinataire précis. Les fournisseurs nomment cela On-Behalf-Of (OBO). Une propriété essentielle mérite d'être retenue : un échange n'amplifie jamais l'autorité. Le jeton émis accorde l'intersection de ce que l'utilisateur peut faire, de ce que l'agent peut faire et de ce que la cible accepte, de sorte que chaque saut est plus restreint que le précédent. Entre différents domaines de confiance, le type d'octroi ID-JAG de l'IETF (Cross App Access d'Okta) prend le relais en générant auprès de votre IdP un octroi temporaire que le propre serveur d'autorisation de la cible échange.

Comment cela fonctionne dans TrueFoundry

TrueFoundry associe les cinq piliers aux fonctionnalités de sa plateforme. Il est essentiel d'être transparent sur les fonctionnalités existantes plutôt que de présenter un tableau artificiellement complet ; les disponibilités sont donc indiquées sans ambiguïté.

Le registre

Chaque agent dispose d'une entrée, quelle que soit son infrastructure d'exécution — Bedrock, Vertex, LangGraph, un service HTTP personnalisé, un agent A2A ou un copilot dans le SaaS d'un tiers. Rien n'a besoin d'être déplacé ou réécrit.

L'enregistrement s'effectue via un assistant en quatre étapes : Métadonnées, Identité de l'agent, Configuration, Contrôle d'accès.

Identité

La deuxième étape détermine la méthode de preuve d'identité de l'agent. Géré par TrueFoundry signifie que TrueFoundry émet et signe le jeton, le choix par défaut idéal pour les agents que vous hébergez. Adossé à un fournisseur d'identité signifie que l'agent présente un jeton provenant d'Okta, Entra, de n'importe quel fournisseur OIDC ou d'un point de terminaison SPIFFE/SPIRE, les valeurs des revendications étant associées à l'agent.

L'étape de configuration détermine si l'Agent Gateway est positionnée en amont. Proxy via Gateway signifie que les appelants utilisent une URL TrueFoundry, la passerelle se chargeant d'authentifier, d'appliquer les règles et de transmettre. Embedded correspond à un mode réservé à la gouvernance : une identité et des autorisations, sans proxy entrant. C'est ainsi que vous régissez un copilot au sein d'un produit tiers — vous ne pouvez pas contrôler son point d'accès entrant, mais ses appels sortants traversent toujours vos passerelles.

Contrôle d'accès de l'agent

L'accès fonctionne sur le principe d'une liste d'autorisations (allow-list) ; il n'y a pas de paramètre de refus (deny), l'absence d'autorisation valant refus. Les collaborateurs peuvent être un utilisateur, une équipe ou un autre agent, avec le rôle Agent Manager (afficher et modifier) ou Agent Access (invoquer et agir en son nom). Le champ Owner est un champ optionnel distinct qui doit désigner une équipe — le point d'ancrage de la responsabilité.

Remarquez la portée de cette liste unique : elle définit à la fois qui peut appeler l'agent et pour le compte de qui l'agent peut agir. Accorder cet accès à l'équipe intégrée everyone attribue à l'agent une capacité de délégation à l'échelle de toute l'organisation — ce qui dépasse les besoins de la plupart des agents.

Le sens inverse fonctionne de manière identique : ajoutez l'agent comme collaborateur sur chaque serveur MCP ou modèle, sous la forme agent:<nom>, via le même sélecteur que pour les utilisateurs et les équipes.

Pour limiter un agent à un sous-ensemble d'outils d'un serveur, configurez ce sous-ensemble sous la forme d'un Virtual MCP Server et accordez l'accès à ce dernier ; la restriction des outils par agent au niveau de l'autorisation sera disponible prochainement.

Garde-fous à chaque saut

Le contrôle d'accès détermine si un appel a lieu. Les garde-fous (guardrails) déterminent ce qu'il peut contenir, indépendamment de l'appelant. Les agents augmentent les risques pour une raison simple : un chatbot qui fournit une mauvaise réponse peut nuire à votre image, mais un agent qui fournit une mauvaise réponse exécute des actions sur cette base. Chaque résultat d'outil réintègre le contexte du modèle et peut véhiculer une injection ; les entrées doivent donc être vérifiées, même lorsque l'utilisateur est de confiance.

Une base de référence fonctionnelle : la suppression des PII et la détection d'injection de prompt sur l'entrée du LLM, la détection de secrets en sortie, un nettoyeur SQL et un linter de sécurité du code avant l'outil, et la suppression d'informations après l'outil. Commencez par exécuter chaque règle en mode Audit avant de l'activer pleinement — un seul saut bloqué peut interrompre toute une chaîne.

Audit

L'application des règles et l'observation s'effectuant au même endroit, la piste d'audit est complète par conception. Chaque trace enregistre quel agent a passé l'appel et pour quel utilisateur il a agi — répondant ainsi aux deux volets de la question.

Chaque garde-fou exécuté apparaît sous la forme d'une étape (span) dédiée : ce qu'il a vérifié, s'il a validé l'étape, et ce qu'il a détecté ou masqué. Les requêtes bloquées sont également consignées — un saut refusé constitue une preuve, non une lacune d'information.

Au-delà des traces, un tableau de bord unique couvre chaque agent enregistré quel que soit son lieu d'exécution : nombre de requêtes, centiles de latence, taux d'erreur, utilisation au fil du temps. La détection de dérive et les alertes d'anomalies s'appuient sur ces données et seront disponibles prochainement.

Exemple d'application

Mise en place de la gouvernance pour le copilot de résumé de remboursement mentionné au début de cet article.

Enregistrer les agents. Les agents planificateur, de recherche et de facturation disposent chacun d'une entrée avec une description et une équipe Owner. Le copilot tiers est enregistré en mode Embedded — sans URL, uniquement pour la gouvernance, mais ses appels sortants sont désormais encadrés.

Attribuer une identité à chacun. Identité gérée par TrueFoundry pour les trois agents que vous hébergez ; le copilot intégré pointe vers votre IdP, avec les valeurs des revendications associées.

Appliquer le principe du moindre privilège dans les deux sens. Sur l'agent de recherche, ajoutez l'équipe support avec le rôle Agent Access — définissant ainsi qui peut l'invoquer et pour qui il peut agir. Ajoutez ensuite agent:research-agent comme collaborateur sur les serveurs MCP Zendesk et Jira, et nulle part ailleurs. L'agent de facturation reçoit l'accès à Stripe. Aucun n'a accès aux outils de l'autre, l'absence d'autorisation explicite valant refus (403).

Transmettre l'identité à chaque appel. Un appel délégué transporte deux jetons au porteur : l'utilisateur dans Authorization, l'agent dans x-tfy-agent-authorization. Chaque agent insère son propre en-tête d'agent et transmet le jeton de l'utilisateur, permettant à la passerelle de vérifier chaque saut par rapport à l'agent qui l'exécute réellement.

Activer les garde-fous et analyser. Associez la détection d'injection de prompt aux modèles et la suppression d'informations post-outil aux serveurs, puis vérifiez dans Request Traces qu'un appel de research-agent indique bien research-agent comme appelant et Jane comme utilisateur pour le compte duquel il a agi.

Une limitation actuelle à noter : le jeton de l'utilisateur est aujourd'hui transmis aux côtés de l'en-tête de l'agent plutôt d'être échangé contre un nouveau jeton restreint au destinataire à chaque saut. L'échange complet par saut sera disponible prochainement.

Prêt à placer un agent derrière un véritable point d'application des règles ?

Enregistrez-le, limitez sa portée à un serveur MCP et consultez la trace.

Commencer gratuitement sur TrueFoundry

Points d'attention importants

Un agent ne peut pas effectuer un flux d'autorisation OAuth2 avec code d'autorisation. Aucun humain n'est présent pour valider l'écran de consentement, et le jeton appartiendrait de toute façon à cette personne. Un tel serveur renvoie l'erreur MCP server authentication required pour un jeton d'agent, même si cet agent est enregistré comme collaborateur. Utilisez plutôt des identifiants d'accès client (client credentials).

Les garde-fous de sortie sont ignorés sur les réponses en flux continu (streamed). Ils nécessitent la réponse complète pour effectuer l'évaluation ; pour les étapes d'agent dont la sortie alimente un appel d'outil, privilégiez stream: false.

Le jeton de l'agent représente l'agent lui-même. Maintenez-le hors du contrôle de code source et de tout contenu accessible en lecture par le modèle. Un agent qu'on peut amener à révéler son propre jeton via un prompt peut faire l'objet d'une usurpation d'identité.

Lectures complémentaires

• Gouverner les agents IA sur plusieurs plateformes — quand la gouvernance s'arrête à la frontière de la plateforme
• Ingénierie des graphes pour les agents IA — évaluer le nœud vs gouverner les liaisons
• Contrôle d'accès MCP avec une passerelle MCP — autorisations au niveau de l'outil et du serveur
• RBAC vs ABAC pour les agents IA — le modèle d'accès sous-jacent aux autorisations
• Construire un cadre de gouvernance de l'IA — la vision stratégique globale

Conclusion

La plupart des publications sur la gestion des agents IA en entreprise abordent la gouvernance comme un exercice rédactionnel : définir un usage acceptable, désigner un comité, publier une norme. Rien de tout cela ne résiste au troisième saut d'un chemin d'appel, où la question n'est pas de savoir si une action était appropriée, mais si votre infrastructure est en mesure d'identifier qui l'a exécutée.

Les cinq piliers sont efficaces précisément parce que chacun désigne un système et non un principe théorique. La découverte est un scanner. L'enregistrement est une base de données que la passerelle refuse de contourner. L'authentification repose sur deux identifiants au sein d'une requête. L'autorisation est un droit qui renvoie une erreur 403 en son absence. L'audit est une trace identifiant simultanément l'agent et l'utilisateur. En construisant ces éléments, la question complexe — qui a fait cela, et pour le compte de qui — trouve une réponse claire et vérifiable.

Gouvernez votre premier agent sur TrueFoundry

Découvrir gratuitement