Résumé
Au rythme actuel de l'accélération de l'IA agentique, il ne semble plus prophétique de dire que, dans peu de temps, il y aura plus d'agents d'IA connectés aux applications de production et aux données que d'utilisateurs humains.
Il y aura de profondes implications pour le lieu de travail — certaines estimations indiquent que la moitié des employés de bureau pourraient ne plus être employés d'ici cinq ans. Il y a également de profondes implications pour la cybersécurité.
L'IA agentique présente de nouveaux risques, tels que les attaques par injection d'invite, dans lesquelles les agents d'IA sont effectivement « victimes d'ingénierie sociale » et amenés à agir pour le compte d'un attaquant après avoir été exposés à des entrées non fiables.
En tant qu'entreprise d'identité, la préoccupation majeure et la plus immédiate d'Okta est de savoir comment l'IA agentique accroît la surface d'attaque de chaque organisation du point de vue de l'authentification et de l'autorisation. Nous pouvons nous attendre de manière fiable à ce que les attaquants découvrent et abusent des innombrables mots de passe de comptes de service et des clés API statiques que les développeurs génèrent afin d'accorder aux agents d'IA l'accès aux ressources de l'entreprise. Nous pouvons également nous attendre de manière fiable à ce que la large autorisation accordée aux agents d'IA exacerbe la perte potentielle de données due à la compromission d'un compte donné.
Ce document est destiné à servir de guide aux fournisseurs de services, aux organisations et aux développeurs qui expérimentent l'IA agentique en vue de créer des applications de production.
Le rôle de l'IA dans la dette d'identité
La dette d'identité s'accumule lorsque des secrets statiques et partagés sont autorisés à s'accumuler au fil du temps dans un système. Un secret est partagé lorsqu'il est connu ou stocké par plus d'un utilisateur ou à plus d'un endroit. Un secret est statique lorsqu'il est de longue durée et qu'il s'écoule de longues périodes sans rotation.
Notre étude a révélé que l'IA agentique contribue à une accélération de cette accumulation de dette d'identité. Les organisations devraient s'appuyer sur des méthodes conçues pour les entreprises pour autoriser un client (application d'IA) à agir au nom d'un utilisateur dans une ressource protégée (applications et données).
Nos recherches ont révélé le contraire. Les méthodes les plus couramment utilisées pour autoriser l'accès d'un agent d'IA aux fonctions et aux données dans les applications SaaS, les référentiels de code, les bases de données et autres ressources entraînent l'exposition de secrets hautement privilégiés.
Le tableau de la page suivante évalue les propriétés de sécurité de diverses approches en matière d'autorisation.
Plugins agentiques : les précurseurs du MCP
Une étude des plug-ins Copilot
Notre étude a révélé que la majorité des communications machine to machine utilisées pour connecter les agents d'IA aux ressources protégées (applications et données d'entreprise) utilisent des formes d'authentification qui ne sont pas adaptées aux environnements de production, avec peu ou pas de contrôle sur l'autorisation.
Pour illustrer cela, nous avons évalué les méthodes d'authentification disponibles pour permettre aux agents Microsoft Copilot AI d'accéder à certaines des données les plus sensibles de l'entreprise : les applications de sécurité.
Copilot est l’un des assistants d’IA à usage général les plus répandus au monde. Microsoft offre la possibilité de créer des « plugins » pour Microsoft Copilot afin d’exposer les fonctionnalités des applications de sécurité tierces aux applications Microsoft (sous la marque « Microsoft Security Copilot »). Chaque plugin Microsoft Security Copilot est configuré dans un fichier YAML ou JSON (un manifeste de plugin) qui décrit les outils du service externe disponibles pour l’agent Copilot.
Utilisation de ces services :
- Microsoft Copilot agit comme l'application hôte
- Les outils et les données des applications de sécurité, telles que Splunk, SentinelOne, Forescout ou Cyberark, sont des ressources protégées.
Un client commun (aux deux services) doit d'abord autoriser Copilot à accéder aux ressources protégées en son nom. Pour cela, le client doit fournir à Copilot des identifiants (mots de passe, clés API ou l'ID client et la clé secrète dans un flux OAuth), qui sont stockées au repos sur les serveurs de Microsoft. Les schémas disponibles sont répertoriés dans le tableau ci-dessous.
Security Copilot prend en charge plusieurs schémas d'authentification des plugins :
Figure 2 : Options d'authentification pour Microsoft Security Copilot. Source : Microsoft
Lorsqu'un utilisateur invite Copilot à utiliser une ressource protégée, l'IA de Copilot analyse la requête et détermine quel plugin annonce la "compétence" pertinente (telle que définie dans le manifeste du plugin) à partir de laquelle s'inspirer. Copilot utilise ensuite les identifiants stockés pour effectuer un appel d'API authentifié à l'application tierce, qui récupère les données ou effectue une action et renvoie un résultat à Copilot. Nous avons cherché à comprendre quelles méthodes d'authentification étaient utilisées pour connecter ces ressources protégées (applications de sécurité) à Microsoft Copilot. 5
D'après notre analyse des manifestes de plug-ins tiers publiés sur GitHub, nous avons constaté que :
- 20 % prennent en charge l'authentification de base
- 75 % prennent en charge la méthode ApiKey
- 5 % prennent en charge un flux OAuth2
Les risques associés à l'utilisation d'un plugin IA Copilot dépendent largement (a) du choix de la méthode d'authentification et (b) du périmètre d'accès fourni à l'agent.
Authentification de base
En utilisant l'authentification de base, les administrateurs doivent créer un compte de service dans l'application tierce et télécharger le nom d'utilisateur et le mot de passe sur les serveurs Microsoft. Copilot envoie ensuite le nom d'utilisateur et le mot de passe dans le header de chaque requête à l'application de sécurité (chaque fois que Copilot sélectionne cet outil en fonction d'une invite utilisateur).
Figures 3 et 4 : captures d’écran de la documentation d’aide du plugin de sécurité Microsoft
Par définition, les comptes d'utilisateur ou de service configurés pour autoriser un agent d'IA à accéder aux ressources via le schéma http:basic (authentification de base) ne peuvent pas prendre en charge l'authentification multifacteur.
Les clients utilisant ce système doivent par conséquent exposer les comptes d'utilisateurs ou de services (qui ont souvent un accès étendu aux données sensibles) aux attaques de credential stuffing et de password spraying.
APIKey
Trois plugins Microsoft Security Copilot sur quatre peuvent être autorisés à l'aide de la méthode APIKey.
Lors de la configuration, les administrateurs créent un token API à longue durée de vie dans la ressource protégée, qui est généralement créé dans le contexte d'un compte utilisateur ou de service, et téléchargent manuellement le token API sur les serveurs Microsoft. Copilot envoie le jeton API dans l'en-tête de chaque requête HTTP qu'il effectue vers la ressource protégée (c'est-à-dire, chaque fois que Copilot sélectionne cet outil de sécurité en fonction d'une invite utilisateur).
Les clés API statiques offrent plusieurs avantages par rapport à l'authentification de base :
- Les clés API sont plus adaptées aux flux machine à machine. Chaque token API unique peut souvent être configuré pour expirer après une période d'inactivité ou une durée déterminée. La révocation de la clé n'a aucun impact sur le compte d'utilisateur ou de service qui l'a créée.
- L'accès au compte de service utilisé pour créer le token API peut désormais être protégé à l'aide de l'authentification multifacteur.
- Les administrateurs sont plus susceptibles de limiter la « portée » de ce qu'un token API peut être utilisé pour lire ou modifier, par rapport aux autorisations d'un compte de service utilisé pour l'authentification de base.
Les risques résiduels sont que ces tokens API sont généralement de longue durée. Les clés API sont régulièrement enregistrées dans les systèmes de contrôle de code source. Les clés API sont régulièrement stockées dans les logs lorsqu'elles sont défini comme paramètres de requête. Il arrive que des clés API soient enregistrées dans des fichiers texte sur le poste de travail du Developer, prêtes à être collectées par le prochain voleur d'informations générique qui infecte le terminal.
Figure 5 : L'accès au token référencé dans ce plugin Copilot permet d'accéder à des données sur tous les terminaux d'une organisation.
Les tokens d'API statiques sont très prisés par les attaquants, et la première chose que beaucoup d'attaquants recherchent après une compromission du système. Une fois interceptés, ces tokens sont généralement valides pendant de longues périodes, ce qui en fait des candidats idéaux pour la revente sur les marchés en ligne.
Les tokens API statiques présentent également des risques de disponibilité, du moins par rapport aux tokens temporaires créés dans les flux OAuth, car les tokens statiques ont tendance à être créés dans le contexte d'un utilisateur plutôt que d'une application.
Dans de nombreux cas, si l'utilisateur ou le compte de service qui a créé le token est supprimé ou déprovisionné, le token est supprimé avec lui, ce qui perturbe toute intégration M2M qu'il assurait.
OAuth 2
Le petit reste des plugins Microsoft Security Copilot semble utiliser des flux OAuth2 conçu pour les entreprises.
Dans ces stratagèmes, un ID client et un secret client (partagés avec Microsoft) sont échangés avec un serveur d'autorisation pour obtenir un token d'accès de courte durée, qui est validé indépendamment par le serveur de ressources.
Si ces flux ont été créés dans Okta, les tokens d'accès résultants peuvent être limités par IP (valides uniquement à partir d'une plage d'adresses IP configurée) et limités par le client (valides uniquement à partir du client qui l'a demandé). Les étendues sont définies au niveau de l'application de service, pas au niveau de l'utilisateur, ce qui signifie que les administrateurs ne désactivent pas accidentellement les intégrations communications machine to machine lorsqu'un compte administratif ou un compte de service est désapprovisionné.
Bien qu'il soit décevant de constater que si peu d'agents Copilot sont conçus pour l'authentification conçu pour les entreprises, ces choix reflètent également les méthodes d'authentification existantes mises à disposition par les applications de sécurité. Dans le contexte de l'intégration avec un seul outil Al propriétaire, ces fournisseurs de sécurité n'étaient manifestement pas prêts à investir dans la mise à jour de leurs méthodes d'authentification disponibles.
Mais que se passerait-il si, au lieu d'écrire des manifestes de plug-in pour chaque application d'IA, les développeurs pouvaient créer un seul serveur conforme à un standard industrielle prise en charge par toutes les versions d'application d'IA ?
Voici le Model Context Protocol.
Modélisation des menaces pour le protocole de contexte de modèle
Si vous êtes un développeur d'applications d'entreprise, l'économie consistant à devoir écrire un nouveau connecteur personnalisé (tel qu'un plugin Microsoft Copilot) pour chaque autre saveur de modèle Al est loin d'être souhaitable.
Les fournisseurs de services préféreraient déclarer dès le départ quelles données et quels outils l'entreprise est disposée à partager avec n'importe quel modèle d'IA, définir les conditions dans lesquelles ces ressources sont exposées, définir comment les clients doivent autoriser l'accès et établir une liste blanche des applications d'IA qui peuvent accéder à ces ressources.
Pour cette raison, la dynamique de l'IA agentique se concentre désormais sur le Model Context Protocol (MCP). MCP est une interface standardisée pour connecter les applications d'IA (hôtes) aux services d'entreprise aussi divers que les plateformes cloud, les applications SaaS, les référentiels de code, les bases de données et même les services de paiement. L'architecture client-serveur de MCP permet le "plug and play" des applications d'IA aux sources de données et aux outils qui leur fournissent un contexte.
Dans l'entreprise, MCP promet une capacité à :
- Déterminer quelles sources de données et outils appartenant à l'entreprise sont disponibles,
- Permettre aux applications d'IA agentiques d'accéder aux sources de données et aux outils de plusieurs applications, sans contamination croisée des données.
- Réduire le coût de l'expérimentation avec différentes applications d'IA qui accèdent à ces sources de données et à ces outils.
Figure 6 : Description visuelle du Model Context Protocol. Source : modelcontextprotocol.io
Les serveurs MCP peuvent être déployés localement ou à distance. Ce choix de modèle de déploiement pour un cas d'usage donné a une incidence significative sur le modèle de menace qui en résulte.
La portée de notre recherche s'est limitée à comprendre comment les applications d'IA (hôtes), les clients MCP et les serveurs MCP gèrent les identifiants. Les composants principaux que nous avons évalués étaient les suivants :
- Hôtes MCP : applications Al, y compris les environnements de développement intégrés (IDE) tels que Cursor, VS Code ou Claude, qui nécessitent un accès aux outils annoncés par les serveurs MCP.
- Clients MCP : les multiples clients qu'un hôte MCP utilise pour communiquer avec un serveur MCP apparié.
- Serveurs MCP : les serveurs MCP annoncent les outils et les ressources disponibles dans un service externe et effectuent des appels d’API à ces services.
Serveurs MCP locaux
Le modèle MCP est particulièrement intéressant pour les cas d'usage du développement de logiciels.
Les ingénieurs logiciels utilisant des IDE compatibles avec l'IA, comme Cursor et VS Code, peuvent créer du code localement tout en bénéficiant de l'aide de modèles d'IA distants pour faire des suggestions au fur et à mesure que le Developer écrit du code.
Anthropic met son agent Claude Al à disposition pour un déploiement local sous le nom de « Claude Desktop ». Claude Desktop est un client MacOS et Windows déployé localement et une alternative à l’accès aux modèles Al d’Anthropic via le navigateur. L'un des avantages des serveurs MCP locaux est que les clients peuvent interagir à la fois avec un modèle Al distant et des fichiers locaux (documents, images, etc.).
Ces applications de bureau doivent souvent s'authentifier à la fois auprès du LLM (ce qui nécessite généralement une clé API) et auprès de sources de données distantes (telles que des référentiels de code, qui nécessitent un token d'accès personnel).
Lorsqu'un utilisateur lance l'application hôte, telle que Claude ou Cursor, le client MCP génère un serveur MCP et transmet au serveur tous les identifiants (clés API, identifiants de la base de données, mots de passe, secrets de client OAuth, etc.) nécessaires au fonctionnement à partir d'un fichier de configuration local, y compris les identifiants dont le serveur MCP a besoin pour accéder aux services distants.
Si le serveur MCP est conçu pour accéder aux ressources Github, par exemple, l'hôte nécessite qu'un Personal Access Token (PAT) Github soit disponible dans le fichier de configuration local. Le serveur affichera une erreur si le PAT Github n'est pas fourni.
Figure 7 : Un serveur MCP utilisé pour accéder aux ressources GitHub génère une erreur si un PAT n’est pas fourni dans le fichier de configuration.
L'emplacement des fichiers de configuration pour trois des applications de développement les plus populaires qui utilisent Al est indiqué ci-dessous :
| Application | Fichier de configuration local | Emplacements par défaut |
|---|---|---|
| Claude Desktop | claude_desktop_config.json | Emplacement par défaut sur MacOS : ~/Library/Application Support/Claude/ Emplacement par défaut sur Windows : ~/AppData/Roaming/Claude |
| Cursor | mcp.json | Emplacement par défaut en cas d'utilisation globale (tous les systèmes d'exploitation) : ~/.cursor/mcp.json Si un serveur MCP n'est disponible que pour un projet spécifique, le fichier de configuration est placé dans l'annuaire du projet. |
| VS Code | settings.json | Emplacement par défaut sur MacOS : ~/Library/Application Support/Code/utilisateur/ Emplacement par défaut sur Windows : ~/AppData/Roaming/Code/utilisateur |
Une étude de Keith Hoodlet chez Trail of Bits a souligné les risques liés au stockage de clés API statiques en clair dans ces fichiers, et a cité des exemples où ces fichiers étaient lisibles par le monde entier (c'est-à-dire accessible par tout utilisateur du système).
En étendant cette recherche, nous avons évalué les fichiers de configuration par défaut pour Claude Desktop, Cursor et VS Code, et avons observé les mêmes autorisations.
Figure 8 : Autorisations par défaut pour les fichiers de configuration Claude, Cursor et VS Code.
Les mêmes autorisations semblent s'appliquer aux fichiers de configuration inclus dans de nombreuses implémentations de serveur MCP officiel qui sont décrites comme « prêtes pour la production », et pour à peu près toutes les intégrations de la Community développées par des tiers, qui ne sont pas approuvées par les fournisseurs de services en question.
Figures 9 et 10 : Une « intégration communautaire » non officielle demande aux clients Okta de télécharger un token SSWS vers un fichier de configuration local.
Toute modélisation des menaces doit anticiper que la grande majorité des serveurs MCP partagés à ce jour ne sont pas approuvés, ce qui entraîne des risques accrus pour les développeurs utilisant des serveurs MCP non autorisés.
Une analyse VirusTotal préliminaire des serveurs MCP téléchargés sur GitHub [2] a révélé que 8 % d'entre eux étaient suspects. Un nombre non divulgué d'entre eux contenait du code qui tente d'identifier les secrets (clés, mots de passe, etc.) dans les invites et les publie sur des terminaux externes.
Le stockage non sécurisé des clés API présente une série de risques, chacun étant exploré ci-dessous.
Risques associés au stockage non sécurisé des clés API. Clés téléchargées sur les référentiels de logiciels
Clés téléchargées dans les référentiels de logiciels.
La plupart des documentations pour les implémentations locales de serveur MCP ne mettent pas en garde les développeurs ou autres utilisateurs contre les risques de stockage d'identifiants en clair pour les ressources de production dans les fichiers de configuration. Il est supposé que les développeurs stockeront les identifiants en toute sécurité, de sorte que le fichier de configuration ne référence qu'un identifiant stocké dans un emplacement sécurisé.
Nous avons observé certains scénarios dans lesquels la configuration MCP n'était pas en mesure d'extraire l'identifiant lors de l'exécution, à moins qu'il ne soit stocké en clair dans le fichier de configuration.
- Une étude menée par Gaetan Ferry chez GitGuardian sur des référentiels clonés à partir du registre non officiel de serveurs MCP Smithery.IA a révélé 202 exemples contenant au moins un secret (5,2 % de tous les référentiels analysés). Les jetons d'API statiques (voir « x-api-key ») figuraient en bonne place [3].
Source : « A look into the secrets of MCP », GitGuardian, avril 2025
Les clés sont exposées dans les métadonnées du conteneur
L'exécution de serveurs MCP dans des conteneurs déplace le problème plutôt que de l'atténuer. Le secret doit être transmis au conteneur dans un format que le serveur MCP prend en charge.
L'examen de la configuration du conteneur fournit une référence directe à un secret en clair, que ce soit sous la forme d'un fichier sur l'hôte, ou en étant capable d'identifier les variables d'environnement pertinentes dans un conteneur qui peuvent être exposées en exécutant docker inspect, un outil de ligne de commande qui permet l'inspection des ressources docker.
Figure 11 : Un token d'accès personnel GitHub exposé dans les métadonnées du conteneur.
Clés accessibles par des logiciels malveillants
Les logiciels malveillants voleurs d'informations génériques sont conçus pour localiser des chemins et des types de fichiers spécifiques où les identifiants sont stockés.
Par exemple :
- Les voleurs d'informations Windows, tels que Vidar Stealer, rechercheront les secrets stock s dans ~\AppData\Roaming
- Les voleurs d'informations MacOS, tels que Atomic Stealer, recherchent les secrets stock és dans ~/Library/Application Support
Il est fort probable que le stockage non sécurisé des tokens API statiques à ces emplacements entraînera des Événements importants. Alors qu'un token de session stocké à cet emplacement offre une courte fenêtre de temps pendant laquelle un attaquant peut obtenir un accès de niveau utilisateur à une ressource, un token API statique fournit un accès persistant aux ressources à l'échelle de l'organisation.
Clés sauvegardées sur des systèmes externes
Les clés sont exposées dans les volumes de sauvegarde si les administrateurs n'excluent pas les dossiers sensibles (tels que ~\AppData\Roaming sous Windows ou ~/Library/Application Support sous MacOS).
Postes de travail partagés entre plusieurs utilisateurs
Étant donné que les fichiers de configuration ont été jugés lisibles par tous, les clés stockées par un utilisateur sur un terminal partagé sont également accessibles aux autres utilisateurs qui se connectent au même terminal.
Solutions alternatives sécurisées pour le stockage local des identifiants
La section des recommandations de ce document présente des solutions tactiques qui minimisent ces risques de stockage d'identifiants.
Alternativement, les organisations qui expérimentent avec MCP peuvent adopter une approche « secure by conception » et utiliser des solutions développées en tenant compte de ces menaces.
Prenez le serveur Auth0 MCP, par exemple [4]. Le serveur Autho MCP offre aux administrateurs la possibilité d'autoriser l'accès aux ressources Autho à partir des applications locales Claude Desktop, Cursor ou Windsurf à l'aide du flux d'autorisation de code de terminal OAuth 2.0.
Figure 12 : Flux d’authentification utilisant le serveur Autho MCP
Par défaut, les identifiants sont stockés dans le trousseau MacOS après l'authentification et sont supprimées du trousseau chaque fois que l'administrateur se déconnecte du serveur MCP.
De plus, aucune portée n'est sélectionnée par défaut : un utilisateur est invité à les sélectionner.
Serveurs MCP distants
Un serveur MCP distant fonctionne comme un service web. Si la spécification MCP est implémentée fidèlement, un client MCP établit une connexion HTTP de longue durée avec le serveur, avec la gestion de session gérée par une authentification basée sur des jetons.
La publication du 26 mars 2025 de la spécification Model Context Protocol a stipulé que, lorsque l'autorisation est requise, OAuth 2.1 est la méthode appropriée :
Les implémentations d'authentification MCP DOIVENT implémenter OAuth 2.1 avec des mesures de sécurité appropriées pour les clients confidentiels et publics.
Atlassian a été parmi les premiers fournisseurs de logiciels d'entreprise à proposer unserveur MCP distant pour ses clients. Cela offre une alternative simple, compatible OAuth, à un serveur communautaire qui l'a précédé de plusieurs mois.
Une comparaison entre le serveur MCP distant officiel et le serveur local "communautaire" développé localement est instructive.
Lorsque le serveur Community découvre les méthodes d'authentification disponibles dans un fichier .env local. (de configuration), tous les mots de passe configurés pour l'authentification de base ont la priorité sur tous les jetons d'accès personnels configurés, qui à leur tour ont la priorité sur les identifiants OAuth.
Figure 13 : Instructions pour Atlassian Community Server
Les auteurs de ce plugin déclarent clairement qu'ils ont privilégié la commodité des développeurs au détriment de la sécurité.
Figure 14 : Instructions du serveur Atlassian Community
Le serveur MCP distant officiel d'Atlassian, en revanche, inclut le support de localhost afin de fournir une connexion et un consentement basés sur OAuth pour tous les utilisateurs, y compris ceux qui se connectent à partir d'IDE locaux comme Cursor.
Cela élimine efficacement le besoin pour les Developers de copier-coller des secrets dans des fichiers de configuration locaux. Le fichier de configuration fait simplement référence au service distant, et il est demandé à l'utilisateur de remplir un consentement OAuth après une authentification réussie.
Et contrairement à Microsoft Copilot, qui est optimisé pour le choix des méthodes d'authentification plutôt que pour un résultat de sécurité spécifique, OAuth est la seule méthode d'authentification disponible dans le serveur MCP distant d'Atlassian. Atlassian autorise également les hôtes (applications Al) qui peuvent se connecter à ce serveur MCP distant.
Figure 15 : Source : Atlassian
S curisation de l'IA agentique
La seule question est de savoir quel flux OAuth utiliser !
Bien que les serveurs MCP distants basés sur OAuth offrent une approche plus sûre et normalisée que les plugins propriétaires, la voie à suivre est loin d'être définie. 20 Voici quelques-uns des défis de sécurité restants :
- Comment pouvons-nous autoriser les agents d'IA à accéder aux ressources protégées, tout en gardant toujours l'utilisateur interactif (humain) dans la boucle ?
- Comment pouvons-nous réduire la charge de gestion liée à la rédaction de règles d'autorisation pour chaque ressource individuelle au niveau du fournisseur de services ?
- Comment pouvons-nous fournir des politiques centralisées et un audit des autorisations d'autorisation ?
Dans les serveurs MCP distants que nous avons évalués, les agents Al étaient autorisés avec le même niveau d'accès aux services que l'utilisateur qui les avait autorisés. Ils agissent « au nom de » un utilisateur dans toute la mesure de ce que l'utilisateur est autorisé à faire.
Cela peut ne pas satisfaire les RSSI préoccupés par les risques liés à la connexion d'agents d'IA aux données qu'ils sont tenus de protéger. Les administrateurs d'entreprise ne se contenteront pas de laisser les fournisseurs de services être les autorités finales sur les outils que le serveur MCP fournit.
Un administrateur centralis é ne peut pas, dans l'exemple d'Atlassian, écrire de politiques qui autorisent les utilisateurs à autoriser les agents Al à lire et à écrire des pages wiki Confluence, mais refuser la possibilit é de modifier les tickets Jira. Les administrateurs ne peuvent pas choisir des projets sp cifiques auxquels ils ne veulent pas que les agents Al acc èdent. Si l'utilisateur peut y accéder, l'agent peut également y accéder.
Le projet IETF OAuth identité assertion Grant, rédigé par d'anciens et actuels architectes d'Okta, vise à résoudre ce problème. Cette autorisation combine deux standards existants : OAuth 2.0 Token Exchange et JWT Profile for OAuth 2.0 Authorization Grants en une autorisation qui offre contrôle et visibilité aux entreprises.
En utilisant cette approche, les administrateurs sont en mesure de configurer des politiques centralisées qui garantissent qu'un utilisateur protégé par l'authentification unique (SSO) peut autoriser un agent d'IA à accéder aux données de plusieurs applications où une relation de confiance a déjà été établie.
Le RSSI serait de nouveau en mesure de limiter la portée de ce à quoi les clients (dans ce cas, les agents d'IA) peuvent accéder dans une ressource protégée. Okta collabore avec des éditeurs de logiciels indépendants (ISV) pour offrir ces fonctionnalités aux clients dans le cadre du nouveau Cross application Access.
Remarques de conclusion
En tant qu'industrie, nous devons maintenant prendre des décisions importantes afin de profiter en toute sécurité des avantages de la connexion des ressources protégées à l'IA agentique.
Nous devons résister à la tentation de réutiliser des méthodes d'authentification qui étaient déjà inadaptées à la connexion de systèmes sur l'Internet public, et encore moins de systèmes capables d'agir de manière autonome. Alors que les agents d'IA recherchent et obtiennent des ensembles d'autorisations plus larges, le "rayon d'explosion" de toute compromission unique sera considérablement amplifié. Une seule brèche pourrait exposer beaucoup plus de données et de systèmes critiques qu'auparavant.
Nous devons plutôt adopter des flux conçus pour l'ère de l'IA : des flux d'accès à portée limitée, délégués par l'utilisateur, utilisant des jetons éphémères et auditables, offrant ainsi au RSSI un contrôle et une visibilité attendus depuis longtemps.
Annexe : Contrôles de protection
Recommandations aux fournisseurs de services
- Adoptez OAuth 2.1 comme mod le d'autorisation minimum viable pour les serveurs Model Context Protocol (MCP).
- Abonnez-vous aux mises à jour sur MCP pour vous tenir au courant des nouveaux développements.
Recommandations pour les développeurs
- Limitez l'utilisation de tokens d'API statiques aux environnements de développement et de test uniquement (pas de données de production) et appliquez les portées minimales requises.
- Lors du développement en local, utilisez les coffres-forts de secrets au niveau du système d'exploitation (MacOS keychain, Windows Credential Manager) pour récupérer dynamiquement les secrets au moment de l'exécution.
- Modifier les autorisations de .env. et d'autres fichiers de configuration ainsi que les fichiers log locaux des applications Al, de sorte que seul votre compte utilisateur puisse les lire ou les modifier.
- Répertoriez tous les fichiers de configuration et de logs dans .gitignore pour vous prémunir contre leur commit accidentel dans les systèmes de contrôle de version.
Recommandations pour les équipes sécurité
- Limitez les activités de développement aux postes de travail renforcés fournies par l'entreprise.
- Exiger une authentification résistante au phishing pour l’accès aux ressources d'entreprise.
- Utilisez des solutions de gestion des secrets dédiées pour les identifiants de production.
- G rez et r gissez l'adh sion aux groupes ayant acc s aux ressources de conteneur, et assurez-vous que le d mon (processus) Docker est configur pour viter l'exposition.
- Exigez des flux OAuth 2.1 pour autoriser l’accès des clients aux ressources de l’entreprise.
- Pour les cas d'usage où les risques liés à l'utilisation de tokens API statiques sont acceptés :
- Sensibiliser les développeurs aux risques liés à l’utilisation de jetons à longue durée de vie.
- Autoriser les requêtes utilisant le token à la plage d'adresses IP connue du serveur MCP correspondant.
- Refuser l'accès interactif aux applications à l'aide du compte de service lié au token API, ou à tout le moins exiger des demandes d'authentification multifactorielle (MFA) de niveau d'assurance élevé pour y accéder.
- Recherchez de manière proactive les tokens stockés en clair sur les serveurs, dans les fichiers, dans les référentiels de code, dans les logs et dans les applications de messagerie et de collaboration.
- Surveiller l'utilisation abusive des tokens.
