Les développeurs créent des agents d’IA à un rythme effréné afin de tout automatiser, du support client à la gestion de l’infrastructure. Ces agents d’IA sont particulièrement robustes et peuvent lire des e-mails, interroger des bases de données de production et même déployer des serveurs. Alors que les capacités de ces systèmes d’IA ont évolué, la manière de les protéger n’a pas suivi le même rythme.
La plupart des agents d’IA actuels fonctionnent avec des clés API statiques dotées d’autorisations étendues à longue durée de vie. Cela signifie que si un attaquant modifie l’agent avec une injection de prompt, il pourrait s’emparer des clés administrateur. Ce modèle de sécurité obsolète va à l’encontre des principes fondamentaux du Zero Trust.
Nous examinerons d’abord pourquoi les agents d’IA ont besoin d’identités distinctes, puis nous verrons comment implémenter le Model Context Protocol (MCP) afin d’appliquer aux agents d’IA le principe du moindre privilège et de veiller à ce qu’ils n’agissent que sur autorisation.
La problématique du « superutilisateur »
Ces dix dernières années, nous nous sommes éloignés de l’utilisation de mots de passe partagés pour les personnes, mais nous continuons encore à considérer les agents d’IA comme des superutilisateurs en leur accordant des secrets codés de manière irréversible. Lorsque nous insérons un token API statique directement dans les variables d’environnement d’un agent, nous créons une large surface d’attaque. Ce token n’est pas associé à un contexte : le système sait que le token API a été utilisé, mais il ne connaît ni la raison ni l’identité de la personne ou du processus ayant déclenché l’agent.
Les agents peuvent générer des résultats erronés ou être manipulés ; une fois que cela se produit, ils peuvent effectuer des actions difficiles à retracer, et résilier leur accès sans compromettre l’ensemble de l’application devient très difficile. Pour résoudre ce problème, il est essentiel de traiter les agents d’IA selon la même approche centrée sur l’identité que celle appliquée aux collaborateurs humains.
Le cauchemar de la « rotation »
Soyons honnêtes, la rotation des clés statiques n’est jamais effectuée aussi fréquemment qu’elle le devrait, car c’est un véritable casse-tête logistique.
Si un seul OKTA_API_TOKEN est codé de manière irréversible dans trois microservices différents, un pipeline CI/CD et un fichier .env local dans le cadre d’un test, renouveler cette clé n’est pas une opération de sécurité, c’est une panne à retardement. Pour travailler dans les règles de l’art, il faut générer une nouvelle clé, identifier tous les dépôts utilisant l’ancienne clé, redéployer l’ensemble des services, en espérant n’avoir oublié aucun petit cron job sur un serveur hérité.
Comme ce processus est particulièrement pénible, les équipes le remettent à plus tard. J’ai pu constater que certaines clés de production n’ont pas été renouvelées depuis des années, car le développeur à l’origine de leur création a quitté l’entreprise, et personne ne veut prendre le risque de provoquer une panne en les modifiant. Cela crée une importante période de vulnérabilité : si cette clé est divulguée, l’attaquant dispose d’un accès permanent jusqu’à ce que vous la remplaciez en urgence.
La solution : le flux « on-behalf-of »
Pour protéger cette nouvelle vague d’automatisation, il est nécessaire de passer de clés statiques à un échange dynamique de tokens (défini dans la norme RFC 8693). Dans l’architecture de l’identité, cela correspond au flux on-behalf-of (OBO). Ici, l’agent agit en tant que délégataire plutôt qu’en administrateur doté de tous les pouvoirs. Lorsqu’un utilisateur demande à l’agent d’effectuer une action, l’agent s’authentifie, mais sollicite l’autorisation d’agir au nom de cet utilisateur précis.
Cela nécessite deux composants clés :
- Un protocole standard : nous avons besoin d’un moyen permettant à l’IA d’uniformiser ses requêtes ; c’est là que le Model Context Protocol (MCP) intervient.
- L’assertion d’identité : nous avons besoin d’un moyen d’échanger la session de l’utilisateur contre un token d’accès temporaire et limité pour l’agent.
Implémenter le Model Context Protocol (MCP)
Nous allons maintenant examiner comment mettre en œuvre ce modèle concrètement. Pour cela, nous utiliserons le serveur Okta MCP open source afin de gérer la connexion entre notre LLM (tel que Github Copilot ou Claude) et votre fournisseur d’identité (IdP).
Étape 1 : supprimer les secrets statiques
Tout d’abord, nous allons auditer le code de notre agent. Pour cela, identifiez toutes les variables d’environnement qui stockent des secrets à longue durée de vie, par exemple OKTA_API_TOKEN, et supprimez-les. Utiliser des clés statiques pour des agents dynamiques revient, en matière de sécurité, à partager votre mot de passe bancaire avec un prestataire temporaire. L’objectif est de veiller à ce que l’agent ne dispose d’aucun privilège lorsqu’il est inactif.
Étape 2 : configurer des autorisations à champ d’application limité
Dans votre IdP respectif, enregistrez cet agent en tant qu’application distincte. Cela nous permet de définir précisément ce qu’il peut ou ne peut pas faire. Au lieu d’accorder un accès en lecture/écriture, essayez d’utiliser des champs d’applications granulaires. Par exemple, il ne devrait pas avoir d’autorisations explicites comme users.delete. Dans Okta, cette fonctionnalité est gérée via Cross-App Access (XAA), qui permet d’associer ces autorisations spécifiques à l’identifiant client unique de l’agent.
Étape 3 : l’échange de tokens
Nous allons maintenant nous intéresser au flux technique lorsqu’un utilisateur sollicite l’agent (p. ex. : « Réinitialise mon mot de passe ») :
- Le déclencheur : l’utilisateur envoie un prompt à l’agent depuis son IDE ou son interface de messagerie.
- La validation : l’agent se connecte ensuite au serveur MCP selon le protocole standard.
- L’échange : le serveur intercepte la requête et effectue une assertion d’identité. Il indique à l’IdP « Je suis un agent de réinitialisation de mot de passe. User-X vient de me donner l’autorisation. Veuillez me fournir un token valable cinq minutes. »
- L’action : l’IdP émet ensuite un token à durée de vie limitée, valable uniquement pour cette opération spécifique de réinitialisation du mot de passe.
Le résultat : des agents prêts pour les audits
Lorsque nous mettons en place cette architecture, nous transformons nos journaux vagues en une trace d’appel claire.
Au lieu d’afficher une action système générique, nos journaux indiqueront :
« L’Agent de réinitialisation de mot de passe a accédé à l’API de mot de passe pour le compte de User-X. »
Cette visibilité granulaire permet aux équipes de sécurité d’effectuer des évaluations des accès sur les agents d’IA, comme elles le font pour les collaborateurs classiques. Si un agent IA adopte un comportement suspect, nous pouvons révoquer immédiatement sa politique d’accès spécifique sans devoir renouveler les clés de l’ensemble de l’équipe d’ingénierie.
Des clés statiques à l’autonomie sécurisée
À mesure que les agents d’IA évoluent et gagnent en autonomie, il n’est plus possible de les protéger avec les mêmes clés statiques utilisées pour les tâches cron qu’en 2015.
Une fois que nous adoptons le Model Context Protocol et l’Assertion d’identité (XAA), nous pouvons disposer d’agents d’IA utiles, performants et, surtout, sécurisés.
Envie de commencer à créer ? Découvrez le serveur Okta MCP open source. Cette implémentation de référence fait le lien entre votre agent d’IA et n’importe quel IdP afin de permettre un échange sécurisé de tokens pour le compte d’un tiers.
