Un cadre de gestion des risques destiné aux professionnels dans le contexte de l'entreprise
24 mars 2026
Directeur technique
Points clés à retenir
- Les comptes de service traditionnels et les clés API ne suffisent pas pour les agents IA ; utilisez des identités de charge de travail vérifiables par cryptographie, telles que SPIFFE/SPIRE.
- Les flux OAuth 2.1 « On-Behalf-Of » (OBO) constituent le modèle de délégation approprié, car ils ne permettent en aucun cas aux agents de se faire passer directement pour les utilisateurs.
- Sécurisez les déploiements MCP en dissociant le point de décision des politiques du point d'application des politiques et en désactivant l'enregistrement dynamique ouvert des clients.
- Aligner la gouvernance sur la norme ISO/IEC 42001 et mettre en place des mesures de protection en temps réel, notamment le masquage des données à caractère personnel et l'intervention humaine (HITL), via CIBA.
- Les chaînes de délégation récursives nécessitent une restriction de portée via l'échange de jetons OAuth 2.0 ou des jetons de capacité de type « macaroon ».
Ce guide s'adresse aux architectes en sécurité d'entreprise, aux ingénieurs IAM et aux RSSI qui déploient ou évaluent des systèmes d'IA basés sur des agents et qui ont besoin d'un cadre de gestion des risques structuré et conforme aux normes — et non d'un argumentaire commercial.
L'essor rapide de l'IA agentique impose une réorientation structurelle de la manière dont les entreprises gèrent les accès, l'identité et les autorisations. Contrairement aux logiciels traditionnels qui exécutent une logique déterministe sur des données structurées, les agents IA adoptent un comportement flexible et orienté vers un objectif : ils appellent de manière autonome des API, interrogent des bases de données, créent des sous-agents et conservent leur état d'une session à l'autre.
Selon Le cycle de hype de l'intelligence artificielle, 2024, d'ici 2028, plus de 15 % des décisions opérationnelles quotidiennes seront prises de manière autonome par des agents d'IA. Les architectures existantes de gestion des identités et des accès (IAM) n'ont pas été conçues pour ce modèle opérationnel, et cette faille peut être exploitée.
Le cadre présenté ci-dessous repose sur quatre piliers : l'identité des machines, l'architecture de connectivité, la gouvernance opérationnelle et la délégation récursive
Pourquoi les systèmes IAM traditionnels ne font pas le poids face à l'IA agentique
Le modèle IAM classique part du principe qu'un être humain intervient à chaque étape de la chaîne d'accès. Les comptes de service et les clés API ont été conçus comme des identifiants statiques et de longue durée, destinés à des charges de travail prévisibles et bien délimitées. Les agents IA remettent en cause chacune de ces hypothèses.
Un agent agit pour le compte d’un mandant humain, mais s’exécute à la vitesse d’une machine — pouvant déclencher des centaines d’appels API en une seule session. Un compte de service compromis lié à un utilisateur humain engendre un champ d’action proportionnel aux autorisations de cet utilisateur, multiplié par la vitesse d’exécution de l’agent. Le rapport 2024 d'IBM sur le coût des violations de données a révélé que les identifiants constituaient le vecteur d'attaque initial le plus courant, à l'origine de 16 % des violations, pour un coût moyen de 4,81 millions de dollars par incident. Dans un contexte d'agent, un seul identifiant volé peut déclencher une cascade d'actions en aval avant même qu'un humain ne détecte l'anomalie.
Le problème est d'ordre structurel, et non opérationnel. Il ne suffit pas de corriger ponctuellement la gestion des comptes de service ; c'est le modèle d'identité lui-même qui doit évoluer.
Identité des machines : au-delà des comptes de service
Identités de charge de travail vérifiables avec SPIFFE/SPIRE
Les agents ont besoin d'identités qui décrivent ce qu'ils sont, et pas seulement qui a émis leurs informations d'identification. La norme «https://spiffe.io/», un projet de la CNCF ayant atteint le statut «graduated», fournit des identités de charges de travail vérifiables cryptographiquement via des SVID (SPIFFE Verifiable Identity Documents) X.509 à durée de vie limitée. Il est essentiel de noter qu'une identité SPIFFE peut être enrichie de métadonnées : le nom du modèle sous-jacent, la version, l'étendue des capacités et l'entité humaine au nom de laquelle l'agent opère. Ces métadonnées permettent aux moteurs de politiques de prendre des décisions d'autorisation plus précises que ne le permettent les clés API statiques. D'autres normes et technologies peuvent offrir des fonctionnalités similaires ; tant les fournisseurs de cloud que les fournisseurs de solutions IAM proposent des identités de charge de travail susceptibles de répondre à vos besoins. SPIFFE est mentionné ici car il peut être déployé partout et fournit une implémentation de référence claire.
De l'usurpation d'identité à la délégation via OAuth 2.1
Le contre-modèle le plus dangereux dans les déploiements d'agents est l'usurpation d'identité de l'utilisateur : il s'agit de fournir à un agent un jeton utilisateur cloné et de lui permettre d'agir en tant que cet utilisateur. Cela compromet la traçabilité ; les enregistrements de journal indiqueront alors que l'utilisateur humain a effectué des actions qu'il n'a jamais réalisées.
Le modèle approprié est la délégation « On-Behalf-Of » (OBO), normalisée dans https://oauth.net/2.1/ (qui regroupe les RFC 6749, RFC 6750 et le BCP de sécurité). Un flux OBO émet un jeton d'accès dérivé qui contient deux identifiants : l'entité humaine d'origine et l'instance spécifique de l'agent. Chaque système en aval voit ces deux acteurs dans chaque requête, ce qui permet de conserver une piste d'audit complète et non répudiable.
Gestion automatisée du cycle de vie via SCIM
Dans les entreprises qui déploient des centaines d'agents, la rotation manuelle des identifiants n'est pas viable sur le plan opérationnel. Les organisations devraient étendre l'https://www.rfc-editor.org/rfc/rfc7644e afin de gérer la création et la suppression des identités des agents parallèlement à celles des utilisateurs.
Cela offre deux fonctionnalités essentielles :
- Provisionnement automatisé : les nouveaux déploiements d'agents reçoivent des identifiants spécifiques sans intervention humaine.
- Commutateur d'arrêt d'urgence : une simple opération SCIM DELETE désactive immédiatement un agent compromis et supprime ses droits d'accès délégués sur l'ensemble des systèmes intégrés ; cela revient à désactiver un compte utilisateur en quelques secondes plutôt qu'en plusieurs heures.
Une fois encore, les fournisseurs de solutions de sécurité des identités proposent des solutions de gestion du cycle de vie des agents pour obtenir les mêmes résultats ; l'utilisation de protocoles ouverts tels que SCIM rend la mise en œuvre plus rapide et plus flexible.
Architecture : sécurisation du protocole de contexte de modèle
Le Protocole MCP, lancé par Anthropic fin 2024, est en passe de devenir la norme en matière d'interface permettant de connecter des modèles d'IA à des outils et des sources de données externes. À l'instar de l'USB-C pour le matériel, le MCP offre une couche de protocole uniforme, ce qui implique également une surface d'attaque uniforme en cas de mauvaise configuration.
Dissocier le PDP du PEP
L'erreur architecturale la plus courante consiste à intégrer la logique d'autorisation directement au sein du serveur MCP. Cela donne lieu à une logique de règles fragile et redondante, difficile à contrôler et impossible à appliquer de manière cohérente sur plusieurs serveurs.
Une architecture adéquate dissocie le point de décision de politique (PDP), qui évalue les règles d'accès, du point d'application de la politique (PEP), qui intercepte les requêtes. Une passerelle API, une couche de middleware de sécurité ou le serveur MCP lui-même fait office de PEP, interceptant chaque requête des agents. Le PEP interroge un PDP centralisé pour obtenir une décision d'autorisation. Ce modèle est conforme à Principes de l'architecture Zero Trust.
Supprimer le transfert de jeton
Une vulnérabilité critique et souvent sous-estimée est le « token passthrough » : un serveur MCP reçoit le jeton d'accès d'un utilisateur et le transmet tel quel à une API en aval. Cela crée une vulnérabilité de type « Confused Deputy » : l'API en aval ne peut pas déterminer si la requête provient directement de l'utilisateur ou d'un agent agissant en son nom.
Les serveurs MCP ne doivent en aucun cas transmettre un jeton émis par un client ; ils doivent soit utiliser un jeton explicitement lié à l'identité de service du serveur lui-même, soit lancer un échange OBO distinct afin d'obtenir un jeton dérivé à portée restreinte
Désactiver l'enregistrement dynamique des clients
Enregistrement dynamique des clients OAuth permet aux clients de s'enregistrer automatiquement. Si cela s'avère utile dans un contexte grand public, cette fonctionnalité présente des risques dans un environnement d'entreprise. Open DCR génère des « clients anonymes » non approuvés : des agents ou des intégrations qui contournent le processus de vérification et d'approbation de l'organisation, créant ainsi une « informatique fantôme » non contrôlée dotée d'identifiants OAuth complets.
Dans le cadre des déploiements d'entreprise, il est nécessaire de désactiver le DCR ouvert et d'adopter l'autorisation gérée en entreprise : les administrateurs doivent préconfigurer et approuver toutes les connexions des agents de confiance au sein du fournisseur d'identité avant qu'un agent ne puisse demander des jetons.
Par ailleurs, afin de réduire au minimum la charge opérationnelle, les clients peuvent recourir à des « déclarations logicielles » associées à une solution d'identité des charges de travail telle que SPIFFE pour établir une relation de confiance entre le fournisseur d'identité (IDP) et la solution d'identité des charges de travail.
Connexion MCP locale sécurisées
Les serveurs MCP locaux s'exécutent en tant que processus du système d'exploitation dans le contexte de sécurité de l'utilisateur hôte, ce qui signifie qu'ils héritent de tous les droits d'accès au système de fichiers et au réseau de l'utilisateur connecté.
Les développeurs doivent privilégier les sockets STDIO ou les sockets de domaine Unix pour la communication interprocessus locale (IPC) plutôt que les sockets réseau TCP/IP ; ces dernières exposent en effet le serveur à tous les processus du segment de réseau local, y compris les autres conteneurs et machines virtuelles. Pour les déploiements en production, les serveurs MCP locaux doivent s'exécuter au sein d'environnements d'exécution isolés (par exemple, des conteneurs dotés de profils seccomp restreints).
Gouvernance et garde-fous en matière d'IA
Conformité à la norme ISO/IEC 42001
ISO/IEC 42001, publiée en novembre 2023, est la première norme internationale relative aux systèmes de gestion spécifiquement dédiée à l'IA. Elle impose aux organisations de mettre en place des processus documentés visant à évaluer l'impact des systèmes d'IA sur les individus, les groupes et la société dans son ensemble, et ce tout au long de leur cycle de vie, de la conception à la mise hors service.
Les professionnels doivent aligner leurs évaluations des risques liés à l'IA agentique directement sur les exigences des clauses 6 (Planification) et 8 (Exploitation) de la norme ISO/IEC 42001, en veillant à ce que l'équité, la transparence, la sûreté et la sécurité soient formellement évaluées et consignées avant le déploiement de tout agent en production.
Barrières de sécurité en temps réel au PEP
La gouvernance ne peut se limiter à des aspects purement procéduraux ; elle doit être mise en œuvre de manière programmatique lors de l'exécution.
Le point d'application des politiques décrit à la section 3 est l'emplacement approprié pour les mesures de protection en temps réel :
-
Masquage des données à caractère personnelIntercepter et masquer les informations à caractère personnel avant qu'elles ne soient transmises à un modèle LLM, afin d'éviter tout apprentissage involontaire du modèle sur des données sensibles.
-
Taux et limites budgétairesAppliquez des limites de débit API et des budgets de jetons par agent afin de maîtriser les coûts et de détecter les schémas d'utilisation anormaux.
-
Filtrage de sortieVérifier les réponses des agents afin de détecter toute fuite de données sensibles avant que les résultats ne soient renvoyés à l'utilisateur demandeur ou au système en aval.
Une autre solution consiste à mettre en place ces mesures de protection lors de l'appel des grands modèles de langage (LLM), car il peut être acceptable que les données à caractère personnel parviennent au serveur MCP, mais pas aux modèles d'IA.
Intervention humaine via CIBA
Pour les opérations à haut risque ou irréversibles (virements bancaires, suppressions massives de données, communications externes), l'exécution des agents autonomes doit être interrompue afin d'obtenir une validation humaine.
CIBA fournit un mécanisme standardisé : l'agent envoie une demande d'authentification par canal secondaire au serveur d'autorisation, qui transmet alors une invite d'approbation hors bande à l'appareil de confiance enregistré de l'utilisateur (notification push sur mobile, SMS, application d'authentification).
L'action de l'agent est bloquée jusqu'à ce qu'un signal d'approbation explicite soit reçu. Le mécanisme de sollicitation du « mode URL » du MCP offre un modèle complémentaire en bande pour les approbations interactives au sein même de la session de l'agent.
Délégation récursive à grande échelle
Le problème de l'orchestration des sous-agents
Les systèmes d'agents de production sont rarement constitués d'un seul agent. Un agent de planification décompose une tâche complexe et délègue des sous-tâches à des agents spécialisés — un agent de recherche, un agent de rédaction, un agent de récupération de données — dont chacun peut à son tour générer d'autres sous-agents. Il en résulte une chaîne de délégation récursive où l'autorité se transmet en aval à travers plusieurs niveaux.
Le risque de sécurité réside dans l'escalade des privilèges par délégation : si chaque sous-agent hérite de l'ensemble des autorisations de son parent, une vulnérabilité n'importe où dans la chaîne peut permettre d'obtenir les autorisations maximales de l'orchestrateur.
Atténuation de la portée par échange de jetons
La solution est atténuation du champ: chaque étape de délégation doit réduire, et non élargir, le champ d'application des autorisations. Le modèle «https://www.rfc-editor.org/rfc/rfc8693» fournit le mécanisme nécessaire : un agent parent demande un jeton dérivé dont le champ d'application correspond exactement aux autorisations dont le sous-agent a besoin pour sa sous-tâche spécifique, et rien de plus.
Le serveur d'autorisation veille à ce que les jetons dérivés ne dépassent pas la portée du jeton de présentation. Aucun sous-agent ne peut étendre ses propres prérogatives.
Dans les cas de fonctionnement hors ligne ou asynchrone où le serveur d'autorisation n'est pas accessible au moment de la délégation, à la manière des macarons Les jetons de capacité offrent une alternative : des jetons au porteur intégrant des clauses d'atténuation infalsifiables, qui peuvent être ajoutées localement sans aller-retour sur le réseau, tout en restant cryptographiquement vérifiables par toute partie de confiance.
Liste de contrôle pour la mise en œuvre
Identité des machines
-
Déployer SPIFFE/SPIRE ou un système équivalent pour l'identification des charges de travail ; enrichir les SVID avec des métadonnées de modèle
-
Remplacer les modèles d'usurpation d'identité par les flux OBO OAuth 2.1
-
Étendre SCIM pour couvrir le cycle de vie de l'identité des agents (provisionnement, rotation, déprovisionnement)
-
Procédure de désactivation d'urgence : SCIM DELETE → révocation d'accès SLA < 60 secondes
MCP Architecture
-
Placez une passerelle API/un PEP devant tous les points de terminaison du serveur MCP ou faites en sorte que le serveur MCP fasse office de PEP
-
Centraliser les politiques dans OPA ou un PDP équivalent ; supprimer l'autorisation en ligne des serveurs MCP
-
Vérifier tous les serveurs MCP pour le transfert de jetons — supprimer tout transfert direct de jetons vers les clients
-
Désactivez le protocole DCR ouvert sur tous les serveurs d'autorisation OAuth ; passez à l'utilisation de clients préenregistrés
-
Limiter les serveurs MCP locaux aux sockets STDIO/Unix ; les conteneuriser avec un minimum de privilèges
Gouvernance
-
Réaliser une analyse d'impact complète conformément à la clause 6/8 de la norme ISO/IEC 42001 pour chaque déploiement d'agent
-
Mettre en œuvre le masquage des données à caractère personnel au niveau du PEP avant toute invocation du LLM
-
Définir les limites de débit par agent, les budgets de jetons et les seuils d'alerte
-
Configurer la détection CIBA ou MCP pour toutes les actions irréversibles des agents
-
Planifier des audits trimestriels de l'identité et des autorisations des agents
Délégation
-
Adopter l'échange de jetons défini dans la RFC 8693 pour toutes les chaînes de délégation des sous-agents
-
Appliquer l'atténuation de portée : la portée du jeton dérivé ⊆ la portée du jeton parent (appliquée au niveau de l'AS)
-
Évaluer les jetons de capacité basés sur Macaroon pour des scénarios de délégation hors ligne ou en périphérie
Foire aux questions
Le cadre présenté ci-dessus traite des changements structurels et architecturaux nécessaires à la sécurité de l'IA agentique. Afin d'apporter rapidement des éclaircissements sur les préoccupations courantes et les fondements des bonnes pratiques, la section suivante répond aux questions fréquemment posées par les professionnels du secteur.
Quelle est la différence entre la sécurité basée sur l'IA agentique et la gestion traditionnelle des identités et des accès (IAM) ?
Réponse : L'IAM traditionnel régit les utilisateurs humains et les comptes de service statiques, dont les modèles d'accès sont prévisibles et délimités. La sécurité basée sur l'IA agentique étend l'IAM à des agents machines non déterministes et orientés vers des objectifs, capables d'effectuer des milliers d'appels API par session, de créer des sous-agents et d'agir simultanément au-delà de plusieurs frontières de confiance ; cela nécessite des identités de charge de travail vérifiables, des chaînes de délégation et des garde-fous comportementaux en temps réel que les outils IAM classiques ne fournissent pas.
Pourquoi les agents IA ne peuvent-ils pas simplement utiliser les comptes de service existants ?
Réponse : Les comptes de service utilisent des identifiants statiques à longue durée de vie qui ne permettent pas de codifier la version du modèle de l'agent, l'étendue de ses capacités ou l'utilisateur humain qu'il représente. Cela empêche toute traçabilité : il est impossible de déterminer, à partir d'un journal d'accès, quel utilisateur humain a autorisé l'action de l'agent, quelle version du modèle l'a exécutée, ou si l'étendue des privilèges était adaptée à la tâche. De plus, les identifiants statiques ne peuvent pas être atténués tout au long des chaînes de délégation, ce qui engendre des risques d'escalade des privilèges.
Qu'est-ce que le « token passthrough » et pourquoi est-ce dangereux ?
Réponse : Le « token passthrough » se produit lorsqu’un serveur MCP reçoit le jeton d’accès d’un utilisateur et le transmet tel quel à une API en aval. L’API en aval a alors accès à l’identité complète et à l’ensemble des autorisations de l’utilisateur, ce qui crée une vulnérabilité de type « Confused Deputy » : l’agent peut ainsi agir avec l’autorité maximale de l’utilisateur plutôt qu’avec une autorité déléguée dont la portée est strictement limitée. Les systèmes en aval perdent également la possibilité de savoir quel intermédiaire a participé à la requête.
Comment CIBA permet-il l'intervention humaine dans le processus des agents IA ?
Réponse : Le protocole CIBA (Client Initiated Backchannel Authentication) permet à un agent de déclencher une authentification hors bande ou une demande d'autorisation sur l'appareil de confiance de l'utilisateur — une notification push sur mobile, par exemple — sans interrompre la session en cours de l'utilisateur dans son navigateur ou son application. L'action de l'agent est bloquée jusqu'à ce que l'utilisateur l'approuve ou la refuse explicitement via son appareil de confiance, ce qui garantit que les actions irréversibles font l'objet d'une confirmation humaine avant leur exécution.
La norme OAuth 2.1 est-elle prête à être déployée en production dans les entreprises ?
Réponse : OAuth 2.1 regroupe les meilleures pratiques actuelles en matière de sécurité issues des RFC 6749, RFC 6750, RFC 7636 (PKCE) et du BCP de sécurité OAuth (RFC 9700). Il ne s'agit pas d'un nouveau protocole, mais d'une harmonisation des normes existantes. Les principaux fournisseurs d'identité (IdP), notamment Microsoft Entra ID, Okta, PingOne et Auth0, ont mis en œuvre ses principales exigences. Les entreprises peuvent adopter progressivement les modèles OAuth 2.1 parallèlement à leurs déploiements OAuth 2.0 existants.
Conclusion : étendre, ne pas remplacer
Le passage à l'IA agentique ne nécessite pas de renoncer à une décennie d'investissements dans la gestion des identités et des accès (IAM) en entreprise. Les mêmes fournisseurs d'identité, serveurs d'autorisation OAuth, annuaires SCIM et moteurs de politiques qui régissent aujourd'hui l'accès humain constituent la base adéquate — complétée par des normes d'identité des charges de travail (SPIFFE/SPIRE ou similaires), des protocoles de délégation (OAuth 2.1 OBO, RFC 8693 Token Exchange), l'application de politiques tenant compte du MCP et les processus de gouvernance ISO/IEC 42001.
Les organisations qui considèrent la sécurité de l'IA agentique comme un tout nouveau défi mettront en place des contrôles fragmentés et impossibles à maintenir. Celles qui étendront leur infrastructure IAM existante en s'appuyant sur les quatre piliers susmentionnés parviendront plus rapidement à des déploiements d'IA agentique conformes et prêts à être mis en production, tout en disposant d'une piste d'audit solide.