Résumé : Sécuriser les agents d’IA au niveau de la couche d’identités
- La faille de sécurité principale : Les entreprises enregistrent des agents d'IA comme des applications de service traditionnelles afin d’accélérer leur déploiement, créant ainsi, sans le vouloir, des vecteurs critiques d’élévation des privilèges au sein de leurs piles agentiques.
- Le risque démontré : Lors d’un test mené sur un serveur MCP du secteur financier, un agent configuré comme une application de service fonctionnant via un échange de token OBO a contourné les restrictions propres à chaque utilisateur, permettant à un employé standard d’accéder à l’ensemble du registre des salaires de l’entreprise.
- La solution : Passer des applications de service à un modèle d'identité de premier plan reposant sur Cross-App Access (XAA) permet au serveur d'autorisation d'évaluer à la fois les privilèges de l'utilisateur et de l'agent, en appliquant le niveau d'accès le plus restrictif.
- Impact stratégique : Un alignement optimal de l’identité permet aux déploiements d’agents d’hériter nativement de la gouvernance des annuaires d’entreprise existants, des outils d’audit de conformité et des solutions de réduction continue des menaces.
Quel est le risque d’escalade des privilèges dans l’architecture des agents d’IA ?
Alors que les entreprises s’empressent de mettre des agents d’IA en production, le même raccourci revient sans cesse : pour lancer rapidement et limiter les coûts, les équipes conçoivent l’agent comme une application de service plutôt que de lui attribuer une identité propre. L’instinct est compréhensible, mais la décision reste une erreur.
Preuve technique : résultats des tests du serveur MCP Finance
Modéliser un agent d’IA comme une application de service revient à intégrer une élévation des privilèges dans votre pile agentique. L’agent peut se voir attribuer plus d’accès que la personne pour laquelle il agit. Lors de notre test avec un serveur Model Context Protocol (MCP) dédié à la finance, un agent assistant à la rémunération des collaborateurs s’est vu accorder l’accès à la lecture de tous les salaires de l’entreprise, y compris celui du CEO, ainsi que la possibilité de modifier la rémunération de n’importe quelle personne, alors qu’aucun collaborateur ne devrait pouvoir effectuer de telles actions.
Donnez à ce même agent une identité de premier ordre, et la demande identique est refusée. Même utilisateur, même politique. La seule chose qui a changé, c’est le modèle d’identité, et les tokens présentés dans cet article en sont la preuve.
Une application de service est l’outil adapté pour un trafic stable entre services, et elle conserve cet avantage dans ce contexte. Il s’agit de la mauvaise identité pour un agent d’IA. Un agent raisonne et s’adapte à tout ce qui se présente dans son contexte à l’exécution, si bien qu’un identifiant d’application de service partagé confère à cet agent une portée supérieure à celle de tout autre utilisateur autorisé.
Les agents constituent une catégorie distincte d’identités. Les modéliser comme une seule entité, ou vous perdez la capacité de contrôler leurs actions. Le tableau ci-dessous présente les deux options côte à côte.
Comparer les modèles d’identité des agents d’IA : application de service ou identité de premier ordre
| Dimension | Agent modélisé comme une application de service | Agent modélisé comme une identité de premier ordre |
|---|---|---|
| Risque d’élévation des privilèges Scénario : l’agent demande plus d’accès que ceux détenus par l’utilisateur délégant | Contourne les contrôles des accès spécifiques à l’utilisateur. L’agent hérite de vastes périmètres d’application et obtient des privilèges dépassant le niveau maximal de l’utilisateur à l’origine de l’action, ce qui crée immédiatement un vecteur d’exposition non autorisée des données. | Okta for AI Agents évalue dynamiquement les autorisations des utilisateurs et des agents. Si un agent demande un périmètre qui dépasse les droits de l’utilisateur, le système rejette la requête. |
| Gouvernance et conformité Alignement sur les Frameworks pour la certification et l’audit | Ne repose pas sur un objet d’identité central, ce qui oblige les équipes à développer des outils de gouvernance personnalisés. Augmente la charge opérationnelle et crée des lacunes de conformité susceptibles d’entraîner des échecs lors des audits d’entreprise. | Inherits existing Enterprise Identity and Access Management (IAM) governance cadres natively. Élimine le développement personnalisé lié à la conformité en faisant passer les actions de l’agent par les processus de validation standard de l’annuaire. |
| Fonctionnalités de coupure d’urgence Permettre une neutralisation immédiate des menaces en temps réel | Nécessite des développements propriétaires cloisonnés au niveau des gateway, sans standards de framework partagés. Contourne la couche de contrôle principale du fournisseur d’identité (IdP) en déplaçant la gestion des sessions vers l’exécution. | S’intègre nativement à Okta Identity Threat Protection via des standards ouverts, notamment le Framework Shared Signals (SSF) et le Continuous Access Evaluation Protocol (CAEP). Permet l'immediate Universal Logout et la révocation globale des tokens sur l’ensemble des sessions agent. |
| Registre des Agents et onboarding Provisioning d’Agents automatisés multiplateformes | Impose le provisionnement manuel et la maintenance de wrappers personnalisés pour les applications de service afin de monitorer les agents automatisés provenant de sources disparates et multiplateformes. | Simplifie le déploiement multiplateforme en s’appuyant sur des protocoles standard du secteur, tels que SCIM, afin d’intégrer et d’enregistrer les agents de manière fluide dans un annuaire central clé en main. |
Le modèle se répète sur chaque ligne. Une application de service répond à une question : de quelle application s’agit-il ?
Un agent pose une question plus complexe lors de l’exécution : qui a autorisé cette action, et pour le compte de qui ? Seule une identité conçue pour l’agent peut y répondre.
Quelle est la différence entre une application et un agent d’IA ?
La méthode la plus rapide pour permettre à un agent d’IA d’interagir avec vos systèmes consiste à l’enregistrer en tant qu’application de service et à lui permettre d’effectuer un échange de token RFC 8693 afin d’agir au nom de l’utilisateur. sa solution est à toute épreuve. Une application exécute uniquement ce pour quoi elle a été programmée, et rien de plus. Ses autorisations définissent son comportement, qui reste fixe et prévisible.
Un agent dispose d’un cerveau. Il détermine dynamiquement quoi appeler et quoi atteindre, et il s’adapte à tout ce qui se présente dans son contexte. C’est précisément le rôle d’un agent, et c’est pourquoi le raccourci présente un risque. Confier à une application de service un ensemble large et partagé d’autorisations ne réduit en rien le niveau de risque. Confiez les mêmes autorisations à un agent, et ce n’est pas le cas. Vous avez donné à un agent doté de capacités de raisonnement l’accès complet, utilisé de manière que vous n’aviez jamais prévue.
Les enjeux sont plus importants qu’avec toute application que vous avez lancée, car l’application ne peut pas être redirigée, mais l’agent, oui. Et vous ne pourrez pas y répondre par la suite. Une application de service partagé ne peut pas démontrer si l’agent est resté dans le périmètre d’autorité de l’utilisateur pour lequel il agissait. Lorsque quelque chose ne fonctionne pas, la trace reste floue.
Comment les plafonds d’attribution des droits des utilisateurs déterminent le contrôle des accès
Imaginez un serveur MCP financier qui expose la rémunération des collaborateurs. Il définit trois périmètres :
Salary:Read:Self: Consulter votre propre rémunérationSalary:Read:All: Consulter la rémunération de chaque collaborateur, y compris les cadres dirigeants et le CEOSalary:Write: Modifier la rémunération de toute personne
L’accès est accordé par groupe, comme vous le faites déjà avec le contrôle des accès basé sur les rôles (RBAC).
| Groupe | Salaire :Lire :Soi | Salaire :Lire :Tout | Salaire : Écrire |
|---|---|---|---|
| Collaborateurs de l’entreprise (Charlie) | ✓ | – | – |
| Responsables de la planification de la rémunération (Alice) | ✓ | ✓ | – |
| Direction financière (Bob) | ✓ | ✓ | ✓ |
Charlie est ingénieur et dispose du droit Salary:Read:Self. Alice prépare la rémunération, elle consulte donc toutes les informations sans effectuer de modifications. Bob dirige les finances, il lit donc tous les messages, y compris ceux de la direction générale, et il modifie les rémunérations.
Trois personnes, trois plafonds différents. Désormais, chacune de ces personnes demande à un agent assistant de traiter des données de rémunération, et l’agent sollicite des accès dépassant les autorisations accordées à la personne. Gardez cette idée en tête.
Pourquoi les architectures d’applications de service entraînent une élévation des privilèges
L’autorisation effective doit correspondre à l’intersection de ce que l’agent est autorisé à faire, de ce que l’utilisateur est autorisé à faire et de ce que la ressource rend accessible. La réponse la plus prudente est la zone de recoupement. Modéliser l’agent comme une application de service, et l’utilisateur sort de cette intersection, ce qui entraîne une élévation des privilèges.
L’intersection des autorisations efficaces pour les utilisateurs, les agents et les ressources
Figure 1. L’autorisation effective correspond à une intersection. Le centre vert correspond aux actions que Charlie peut effectuer. La zone rouge correspond à des privilèges qu’il n’a jamais eus, c’est l’escalade.
Test de l’échange de token OBO par rapport à Cross-App Access (XAA)
Nous avons modélisé le même agent de deux façons et soumis chaque utilisateur aux trois mêmes requêtes. Dans le premier modèle, l’agent est une application de service exécutant un échange de token en mode « on-behalf-of » (OBO). Dans le second cas, l’agent est une identité de premier plan utilisant Cross-App Access (XAA), le flux ID-JAG co-rédigé par Okta.
Mêmes utilisateurs, mêmes groupes, mêmes politiques de serveur de ressources. La seule chose qui a changé, c’est le modèle d’identité.
Les tokens ci-dessous sont décodés. Les noms d’hôte et les adresses e-mail sont masqués ; les valeurs de scopes, sub_profile, la chaîne act et l’erreur sont renvoyées exactement telles que reçues du serveur d’autorisation.
Un modèle prend en charge l’utilisateur. L’autre non.
Même agent, même serveur MCP finance, deux façons de modéliser l’identité de l’agent :
Un agent d’IA conçu comme une application de service utilisant un échange de token OBO
Figure 2. Agent modélisé comme une application de service. L’utilisateur est attribué à l’application client, puis l’appel s’effectue pour le compte de l’utilisateur via un échange de token OBO. Il n’existe pas d’identité d’agent distincte dans l’échange, ainsi l’acteur figurant sur le token final est l’application de service.
Un agent d’IA conçu comme une identité de premier plan à l’aide de XAA
Figure 3. Agent modélisé comme une identité de premier plan. L’agent est une identité de premier plan. Il reçoit un ID-JAG, une assertion de délégation signée, puis l’échange contre le token MCP. Le token identifie à la fois l’utilisateur et l’agent.
L’escalade, preuve à l’appui : l’application de service accorde tout ce qui lui est demandé
Nous avons soumis chaque utilisateur aux mêmes trois demandes, chacune étant un peu plus exigeante que la précédente. Voici les requêtes, les résultats des modèles, ainsi que la décision prise pour chaque token.
| L’appel de l’outil | Agent modélisé comme une application de service | Agent modélisé comme une identité de premier ordre |
|---|---|---|
Charlie, une personne salariée de l’entreprise disposant du droit Salary:Read:Self | ||
Demandes Read:Selfsa propre étendue | ✓ Accordé."scp": ["Salary:Read:Self"] | ✓ Accordé, et le token désigne l’agent."scp": ["Salary:Read:Self"], "act": ai_agent |
Ajoute Read:Allau-delà de son groupe | ✗ Refusé. Lit chaque salaire, y compris celui du directeur général (élévation des privilèges)."scp": ["Salary:Read:All", "Salary:Read:Self"] | ✓ Refusé. Droits précédemment attribués à Charlie."error": "access_denied" |
Ajoute Lecture : Tous et Écriturelire pour tous, modifier la rémunération | ✗ Refusé. Lit chaque salaire et modifie la rémunération (élévation des privilèges)."scp": ["Salary:Read:All", "Salary:Read:Self", "Salary:Write"] | ✓ Refusé. La frontière tient."error": "access_denied" |
Alice, une personne chargée de la gestion des rémunérations ayant le droit à Salary:Read:Self et Salary:Read:All | ||
Demandes Read:Selfdans le cadre de ses droits | ✓ Accordé."scp": ["Salary:Read:Self"] | ✓ Accordé."scp": ["Salary:Read:Self"] |
Ajoute Read:Alldans le cadre de ses droits | ✓ Accordé."scp": ["Salary:Read:Self", "Salary:Read:All"] | ✓ Accordé. Alice peut consulter chaque salaire."scp": ["Salary:Read:Self", "Salary:Read:All"] |
Ajoute Écritureau-delà de ses droits d’accès | ✗ Refusé. Alice peut désormais modifier la rémunération de toute personne. Escalade."scp": ["Salary:Read:All", "Salary:Read:Self", "Salary:Write"] | ✓ Refusé. Écrire dépasse le droit d’Alice."error": "access_denied" |
Trois appels ont dépassé les limites. Dans chaque cas, l’application de service a accordé un accès que la personne n’avait jamais eu, et le parcours d’identité de premier ordre l’a refusé :
- Charlie, ingénieur, demande
Read:All: L’application de service permet à son agent de consulter tous les salaires de l’entreprise, y compris celui de la direction générale. - Charlie demande
Read:AlletWrite: L’application de service permet à son agent de consulter tous les salaires et de modifier la rémunération de n’importe quelle personne. - Alice, une planificatrice en lecture seule, demande
Écriture: L’application de service permet à son agent de modifier la rémunération à laquelle elle n’aurait jamais eu accès elle-même.
Le parcours d'identité de premier ordre a refusé les trois tentatives. Repérez où se situent les défaillances de sécurité (les cellules rouges dans le tableau ci-dessus). La ligne de Charlie est à Read:All, et celle d’Alice est à Write, car chacune est limitée à ses propres droits. L’application de service ne voit pas cette ligne, elle accorde donc tout ce qui est demandé. Le parcours d'identité de premier ordre est conçu autour des droits d'accès de l'utilisateur.
Bob, le directeur financier, détient le contrôle. Il a droit aux trois périmètres, il n’y a donc rien à remonter, et les deux modèles lui accordent l’ensemble des autorisations. C’est le système qui fonctionne, non qui échoue. Chaque identité possède son propre plafond, et l’escalade n’apparaît que lorsque l’agent dépasse celui de l’utilisateur.
Ce n’est pas une hypothèse. Dans l’ incident PocketOS, un agent de codage basé sur l’IA a découvert un identifiant à longue durée de vie et doté de privilèges excessifs, puis l’a utilisée pour supprimer une base de données de production en quelques secondes. Le justificatif conférait bien plus d’autorité que nécessaire pour la tâche, et rien n’obligeait l’agent à se limiter à un ensemble plus restreint.
Bien que la méthode diffère de la nôtre — un token permanent dans un fichier plutôt qu’un token surémis par une plateforme d’échange —, la défaillance relève de la même catégorie : un agent disposant de privilèges injustifiés dans ce contexte. Lier l’agent aux actions autorisées pour l’utilisateur limite sa portée à ce que détient l’utilisateur.
Un simple rappel suffit. Une injection de prompt dans un document lu par l’agent, ou une prise de contrôle de l’agent, transforme « afficher ma rémunération » en « exporter tous les salaires » ou « modifier la rémunération de cette personne ». L’utilisateur n’a jamais été autorisé à effectuer l’une ou l’autre de ces actions ; l’agent, qui utilise l’identité de l’application de service, l’est.
Les trois escalades, l’ensemble du flux côte à côte
Voici une comparaison côte à côte de chaque escalade présentée comme un flux complet, en utilisant l’application de service et des modèles d’identité de premier plan. L’utilisateur se connecte, l’agent présente sa délégation, et un token parvient à l’outil de gestion des salaires. La connexion est identique pour chaque requête, la divergence concerne donc tout ce qui suit.
Scénario 1 : Charlie, ingénieur, demande Read:All
| Agent modélisé comme une application de service | Agent modélisé comme une identité de premier ordre |
|---|---|
| L’utilisateur connexion (token d’identification utilisateur) | |
{ | { |
| L’agent obtient un token pour l’outil | |
| Aucun ID-JAG ici. L’agent réutilise le client OAuth de l’application de service via un échange de token OBO (RFC 8693). Rien dans cette étape n’intègre le droit de l’utilisateur dans la décision. | { |
| Token dans l’outil de rémunération | |
{ | { |
| Observation | |
Escalade. Charlie a le droit à Salary:Read:Self et rien de plus. Pourtant, ce token comporte Salary:Read:All, ce qui permet à son agent de consulter l’ensemble de la masse salariale de l’entreprise, y compris la rémunération du PDG. Le chemin de l’application de service a accordé sans vérification la demande avec des autorisations excessives. | Refusé. Même demande, même politique. Comme le serveur de ressources identifie Charlie derrière l’agent, il constate que le périmètre demandé dépasse ses droits et rejette la demande. L’agent peut faire exactement ce que Charlie peut faire, rien de plus. |
Scénario 2 : Charlie demande Read:All et Write
| Agent modélisé comme une application de service | Agent modélisé comme identité de premier ordre |
|---|---|
| L’utilisateur connexion (token d’identification utilisateur) | |
| La connexion de Charlie, le même token présenté dans le scénario 1. | La connexion de Charlie, le même token présenté dans le scénario 1. |
| L’agent obtient un token pour l’outil | |
| Aucun ID-JAG ici. L’agent réutilise le client OAuth de l’application de service via un échange de token OBO (RFC 8693). Rien dans cette étape n’intègre le droit de l’utilisateur dans la décision. | { |
| Token dans l’outil de rémunération | |
{ | { |
| Observation | |
Escalade. Le token contient désormais à la fois Read:All et Write. L’agent peut consulter la rémunération de l’ensemble du personnel et modifier la paie de toute personne au sein de l’entreprise. Comme le chemin de l’application de service a contourné entièrement son identité, l’agent a obtenu des autorisations étendues auxquelles Charlie lui-même n’a pas accès. | Refusé. Comme la demande dépasse les droits de Charlie, l’émission du token est refusée. Les autorisations à privilèges élevés telles que Read:All et Write restent strictement inaccessibles à l’agent. |
Scénario 3 : Alice, une planificatrice en lecture seule, demande Write
| Agent modélisé comme une application de service | Agent modélisé comme identité de premier ordre |
|---|---|
| L’utilisateur connexion (token d’identification utilisateur) | |
{ | { |
| L’agent obtient un token pour l’outil | |
| Aucun ID-JAG ici. L’agent réutilise le client OAuth de l’application de service via un échange de token OBO (RFC 8693). Rien dans cette étape n’intègre le droit de l’utilisateur dans la décision. | { |
| Token dans l’outil de rémunération | |
{ | { |
| Observation | |
Escalade. Alice est autorisée à consulter les salaires, mais jamais à les modifier. Pourtant, ce token possède Salary;Write, ce qui permet à l’agent de consulter la rémunération de toute personne. | Refusé. L’écriture ne fait pas partie des droits d’Alice, donc la même limite qui s’appliquait à Charlie s’applique également à elle. L’ancienneté n’élargit pas l’attribution. |
Le modèle se répète :
- Le chemin de l’application de service renvoie un token exploitable car il vérifie uniquement la requête et ses propres autorisations.
- La voie d'identité de premier ordre refuse les trois options, car elle peut identifier l’utilisateur derrière l’agent, et sait que cet utilisateur ne pourrait pas effectuer ces actions.
Lorsqu’une demande reste dans le périmètre d’autorisation de l’utilisateur, ce même chemin émet le token et la chaîne de délégation est conservée, de sorte que l’action demeure attribuable.
Répondre aux objections liées à l’identité et à la disponibilité de la plateforme
Objection : « La plateforme agentique attribue déjà une identité à l’agent. »
Ces plateformes créent une identité pour chaque agent, et une gateway peut la transporter. Cette identité est réelle, mais elle réside dans la plateforme, et non dans votre annuaire Enterprise. Il indique quel agent de la plateforme est intervenu, mais il ne transmet pas les droits de la personne et ne s’intègre pas à la gouvernance que vous appliquez déjà. Vous ne pouvez pas certifier ni révoquer l’accès de l’agent de la même manière que pour le reste de vos identités.
S’appuyer uniquement sur ce mécanisme fait du gateway votre point de contrôle, tandis que votre IdP devient un terminal de token situé derrière celui-ci. L’agent a toujours besoin d’une identité Enterprise liée à l’utilisateur qu’il sert, ce que l’identité de la plateforme ne fournit pas.
Objection : « Le chemin d’accès à l’application de service est déjà disponible aujourd’hui, alors pourquoi ne pas simplement l’utiliser ? »
C’est précisément le parcours que nous avons testé. Elle renvoie tous les scopes demandés par l’appelant, limités uniquement par ses propres droits d’accès et sans tenir compte des droits d’accès de l’identité humaine délégante. La Certification et le provisioning relèvent d’un travail personnalisé. Vous pouvez le mettre en place, mais vous ne pouvez pas lier l’agent aux droits de l’utilisateur ni le gérer comme le reste de vos identités. Cette limite explique pourquoi l’agent doit disposer de sa propre identité de premier ordre.
L’essentiel : Attribuer une identité propre à l’agent
Chaque outil a une utilité. Une application de service est la solution adaptée pour un trafic stable entre services, et elle reste incontournable. Un agent d’IA est un acteur distinct. Attribuer à une application de service partagé des identifiants communs revient à confier à votre intervenant le plus compétent l’identité la moins traçable de l’organisation.
Donner à l’agent une identité propre, liée à l’utilisateur qu’il sert, permet aux tokens de répondre à la question qui finira par se poser : quel agent a effectué cette action, et sous quelle autorité ?
Prêt à résoudre la crise de l’identité liée à l’IA au sein de votre entreprise ?
- Approfondir la question de la responsabilité : Lire The AI Attribution Gap pour découvrir comment remonter les actions des agents automatisés jusqu’aux responsables humains et établir une attribution juridique claire.
- Découvrir nos solutions : Découvrez comment Okta et Auth0 sécurisent les agents d’IA et centralisent l’ensemble du cycle de vie agentique au sein d’un point de contrôle unifié.
- Élaborer votre roadmap : Contacter notre équipe pour commencer à concevoir une stratégie de sécurité de l’IA axée sur l’identité, adaptée à l’architecture de votre Enterprise.
