Pourquoi l’identité seule ne sécurise pas les agents IA

Un agent de rapprochement financier peut présenter un jeton utilisateur valide, effectuer un appel API que l’utilisateur est autorisé à faire, et malgré tout exécuter une action pour laquelle aucune délégation ne lui a jamais été accordée. Une passerelle d’exécution peut approuver la requête parce qu’elle voit des identifiants valides et un accès en écriture autorisé. Pourtant, la décision d’autorisation change lorsque la passerelle sait aussi qu’un agent a initié la requête, que son périmètre de rapprochement est plus étroit que les permissions de l’utilisateur, et qu’un artefact non fiable a déclenché la chaîne d’outils.

Pourquoi une sécurité des agents centrée d’abord sur la passerelle peut créer un faux sentiment de confiance

Le cas de la finance met en évidence un problème fondamental lorsqu’on fait commencer la sécurité des agents au niveau de la passerelle. L’authentification établit qu’un identifiant est acceptable, mais elle n’établit pas qu’une action de l’agent relève bien de la mission qui lui a été assignée. Si l’agent hérite d’un accès en écriture de l’employé qu’il assiste, modifier un enregistrement de production peut être techniquement autorisé tout en sortant du cadre de la tâche déléguée.

Cette distinction change la question de sécurité pour les équipes qui mettent des agents en production. La question est de savoir si l’identité, la délégation, le moindre privilège et l’attribution fournissent un contexte suffisant pour que les contrôles d’exécution puissent prendre des décisions pertinentes. Une passerelle consomme ces éléments en aval ; la traiter comme fondation peut donc laisser des agents authentifiés exécuter des actions inappropriées sur le plan opérationnel.

Comme ces éléments proviennent de contrôles en amont, l’ordre de construction compte autant que les contrôles qu’une organisation acquiert. L’agent doit être identifiable, l’autorité qui lui est déléguée doit être connue et contrainte, et son activité doit pouvoir lui être attribuée avant qu’une passerelle puisse décider de manière fiable ce qu’un identifiant valide peut faire dans le cadre d’une tâche donnée. Une application stricte avec un contexte amont faible peut créer un niveau de confiance que le point d’application ne peut pas justifier.

Les passerelles ont de la valeur, mais elles sont la porte 5

La dépendance au contexte amont ne rend pas inutile un déploiement précoce de la passerelle. L’application des règles à l’exécution peut bloquer immédiatement des violations de politique évidentes, de sorte que l’ingénierie de la passerelle peut avancer pendant que les systèmes amont sont encore en cours de construction. Mais sa limite opérationnelle est claire : une passerelle ne peut pas distinguer de manière fiable une action justifiée d’une action techniquement autorisée mais inappropriée tant qu’elle ne reçoit pas l’identité de l’agent, le principal délégant, le contexte de la tâche, l’autorité limitée au périmètre et une télémétrie attribuable.

Cette limite compte parce que la couche d’exécution crée sa propre surface d’attaque. En juin, la CISA a ajouté une faille LiteLLM à son catalogue des vulnérabilités connues comme exploitées après l’observation d’exploitations dans la nature. Une vulnérabilité LiteLLM permettait d’exécuter des commandes sur l’hôte via la passerelle ; combinée à une seconde faille, l’attaque ne nécessitait aucun identifiant. Sept CVE ont été divulguées dans LiteLLM en l’espace d’un mois.

Ces vulnérabilités ne montrent pas que les passerelles sont intrinsèquement peu sûres. Elles montrent pourquoi un composant d’exécution ne doit pas porter à lui seul l’architecture située en dessous, en particulier lorsque ce composant peut lui-même devenir une surface d’attaque. L’application des règles par la passerelle a une valeur substantielle une fois que les contrôles amont fournissent le contexte requis par ses décisions.

Un modèle de « déploiement conditionné par les dépendances » organise ces exigences amont et aval en six portes. Chaque porte produit le contexte nécessaire aux contrôles qui viennent plus tard dans la séquence, et chacune comporte un test de sortie qui établit quand elle est opérationnellement complète. Les tests de sortie amont doivent être validés avant que les contrôles aval reçoivent ce statut, même lorsque l’ingénierie et les achats pour plusieurs portes avancent en parallèle.

Les six portes décrivent des dépendances d’information ; elles ne doivent donc pas être confondues avec un calendrier d’achats. Une entreprise peut déjà posséder une passerelle, un système comportemental et une stack IAM mature, ou elle peut construire l’ensemble simultanément. La séquence concerne les informations sur lesquelles chaque contrôle peut s’appuyer lorsqu’il commence à prendre des décisions de production.

Portes 1 et 2 : savoir quel agent existe, qui en est responsable et quelle autorité il porte

Parce que chaque contrôle ultérieur agit sur un agent, la porte 1 établit quels agents de production existent et ce que chacun est censé faire. La découverte doit couvrir les agents exécutés via des frameworks open-source, des offres cloud, des services SaaS et des outils de développement. Pour chaque agent identifié, l’inventaire doit consigner son propriétaire, sa responsabilité, son étape de cycle de vie, les outils autorisés, les domaines de données et les sources d’identifiants. La porte 1 est prête sur le plan opérationnel lorsque chaque agent de production a un propriétaire nommé, une finalité, des outils approuvés et un état de cycle de vie.

Cet inventaire peut sembler administratif par rapport à une politique d’exécution, mais un incident rend son rôle de sécurité concret. Sans registre faisant autorité, les équipes de réponse peuvent passer la première heure à déterminer quels agents existent et ce que chacun est censé faire. Avec l’inventaire en place, l’investigation et l’application des règles disposent d’un actif défini, avec une finalité connue et un responsable identifié.

Une fois que la porte 1 établit l’actif, la porte 2 lui donne une identité distincte. Un agent enfoui dans un jeton de développeur, un compte de service partagé ou une session humaine peut s’authentifier avec succès, mais les contrôles ultérieurs ne peuvent pas séparer de manière fiable ses actions de celles d’autres logiciels ou personnes utilisant la même identité. Donner à l’agent sa propre identité crée un acteur révocable et auditable qui peut persister au fil des appels individuels.

Cette identité distincte laisse une deuxième question : quelle autorité l’agent exerce-t-il, et à quelle fin ? Le contexte de délégation doit préserver qui a assigné le travail, la tâche précise confiée à l’agent et les ressources nécessaires pour l’accomplir. L’identité indique au système quel acteur a effectué un appel ; la délégation explique l’autorité et la raison qui le sous-tendent.

La distinction devient importante lorsque vingt agents opèrent sous les permissions d’une seule personne. Les permissions de l’humain peuvent plafonner ce que les vingt peuvent atteindre, mais les agents peuvent effectuer des travaux très différents et ont donc besoin d’identités séparées, de journaux d’audit distincts, de profils comportementaux distincts et de chemins de révocation distincts. Un plafond de permissions humaines limite l’autorité agrégée, mais la responsabilité exige toujours que le système distingue les agents individuels qui l’utilisent.

L’agent de rapprochement montre ce qui se passe lorsque ce test échoue. Lorsque l’agent emprunte le jeton d’un employé sans lien d’identité agent-humain, les journaux en aval attribuent son activité à l’employé et perdent l’identité de l’acteur qui a exécuté la tâche. La porte 2 n’est franchie que lorsque le système peut identifier l’agent, son propriétaire et le principal pour lequel il agit, en préservant les deux côtés de cette relation pour les décisions ultérieures.

Porte 3 : réduire l’autorité avant d’essayer d’inférer un mauvais comportement

Une fois que le système connaît l’acteur et la délégation, la porte 3 réduit l’ampleur des dommages que cet acteur peut causer. La séquence est concrète : identifier l’agent, borner l’accès à la tâche qui lui est assignée, le restreindre aux outils et ressources requis, et faire expirer cet accès avec la tâche. Le test de sortie est tout aussi pratique : la compromission de l’agent ne doit pas accorder l’accès à des ressources en dehors de l’affectation.

Les mécanismes IAM existants peuvent mettre en œuvre une grande partie de cette limite. L’identité de workload peut établir l’acteur logiciel, l’échange de jetons peut émettre des identifiants adaptés au travail délégué, l’accès conditionnel peut appliquer des contraintes, et les droits limités dans le temps peuvent supprimer l’autorité permanente. Ensemble, ces contrôles transforment un large ensemble de permissions héritées en identifiants façonnés autour d’une tâche spécifique.

Ces contrôles mettent en œuvre une « délégation monotone », ce qui signifie que chaque transfert de responsabilité préserve ou réduit l’autorité et ne l’augmente jamais. Pour une tâche de rapprochement, un agent qui doit inspecter un grand livre donné devrait recevoir l’autorité sur ce grand livre pour le travail requis. Hériter simplement de tout ce à quoi l’employé peut accéder donne à l’agent une autorité sans rapport avec sa mission.

L’effet du périmètre d’accès apparaît dans une étude Teleport de 2026 menée auprès de 205 responsables de la sécurité. Les organisations avec une IA sur-privilégiée ont déclaré un taux d’incident de 76 %, contre 17 % parmi les organisations opérant selon le principe du moindre privilège. Teleport a interprété les résultats comme montrant que le périmètre d’accès prédisait mieux les incidents liés à l’IA que le secteur, le niveau de maturité ou l’assurance affichée par les répondants. Teleport vend des infrastructures d’identité et d’accès ; l’entreprise a donc un intérêt commercial à ce que les organisations investissent dans des contrôles qui limitent et gouvernent l’accès.

Dans les résultats de Teleport, l’écart important entre les taux d’incident fait du périmètre des privilèges une priorité de sécurité avant tout jugement comportemental sophistiqué. Une application adaptative peut tenter de reconnaître une action dangereuse après qu’une large autorité a déjà été accordée. Des identifiants limités à la tâche réduisent d’abord l’éventail des actions possibles, ce qui limite les conséquences d’une dérive, d’une compromission ou d’une entrée empoisonnée avant qu’un système d’exécution n’ait à inférer l’intention.

Cet ensemble d’actions plus restreint donne aussi aux contrôles ultérieurs des éléments plus clairs. Un moteur de politique qui évalue un identifiant étroitement limité peut comparer une action tentée à une frontière explicite de ressources, tandis qu’une investigation peut comparer l’usage réel à cette même frontière. La porte 3 transforme la délégation, de contexte descriptif, en autorité applicable.

Porte 4 : rendre les actions d’un agent reconstituables avant de rendre la politique adaptative

Même une autorité étroite a besoin d’attribution, car la politique d’exécution et la détection ultérieure dépendent de la compréhension de la manière dont les actions individuelles s’inscrivent dans une tâche. La porte 4 relie chaque invocation d’outil pertinente à l’identité de l’agent, au principal initiateur, à l’ID de tâche, à l’action parente et au résultat. Son test de sortie est la capacité à reconstituer une tâche terminée depuis son initiation jusqu’à son effet en aval.

Cette reconstitution teste directement la télémétrie établie par la porte 4. Prenez une tâche terminée et déterminez qui l’a initiée, quel agent l’a exécutée, sous quelle autorité elle s’est déroulée, quels outils ont été utilisés et quel résultat a suivi. Tout lien manquant identifie un point où une politique ultérieure devrait décider avec un contexte incomplet.

Ces liens manquants sont la version télémétrique du problème d’identité de la porte 2. L’infrastructure d’audit peut enregistrer une ressource et l’identifiant qui y a accédé, mais les contrôles adaptatifs des agents ont besoin de la relation entre principal, agent, tâche, actions et effets. Dans les environnements réglementés, une supervision non attribuée est difficile à justifier, car l’organisation ne peut pas relier de manière fiable un résultat à l’acteur et à l’autorité qui l’ont produit.

Porte 5 : l’application à l’exécution dispose maintenant d’un contexte suffisant pour juger l’action

Avec les portes 1 à 4 qui fournissent le contexte, la passerelle peut jouer le rôle que les conceptions centrées sur la passerelle attendent d’elle. Les identités d’agent enregistrées identifient l’acteur, la délégation explicite fournit le principal et la tâche, les identifiants limités au périmètre définissent une autorité bornée, et la télémétrie attribuable relie l’action en cours à une chaîne traçable. La politique d’exécution peut désormais évaluer agent + principal + tâche + action + ressource.

Cette décision plus riche change le cas initial du rapprochement financier. Les identifiants d’un employé peuvent autoriser des écritures, mais la passerelle peut voir que l’agent de rapprochement agit dans le cadre d’une délégation plus étroite et rejeter une modification de production qui sort de cette finalité. La passerelle peut distinguer une requête valide du point de vue des identifiants d’une requête valide du point de vue de la délégation, parce qu’elle dispose désormais des éléments nécessaires pour faire cette distinction.

Avec ces éléments disponibles, l’application la plus stricte doit se situer au niveau des actions dont les conséquences sont difficiles à annuler ou particulièrement sensibles. Ces frontières incluent les paiements, les changements de politique d’accès, les suppressions, les modifications d’environnements de production et les exportations de données. À chaque frontière, la porte 5 est franchie lorsque la décision intègre le contexte de l’agent, du principal, de la tâche et de l’action en plus de la validité du jeton.

Un déploiement plus précoce de la passerelle conserve de la valeur, car des violations manifestes peuvent être bloquées avant que ce contexte soit complet. Après les quatre premières portes, toutefois, la qualité du jugement disponible à l’exécution change. L’application des règles passe de la vérification d’une requête observable au regard d’une politique large à la décision de savoir si cet acteur précis, agissant pour ce principal sur cette tâche, doit exécuter cette action sur cette ressource.

Porte 6 : le comportement et le confinement viennent après que l’activité devient distinguable

Une fois l’activité de l’agent attribuable, des référentiels comportementaux peuvent décrire la manière dont un agent particulier opère normalement dans le cadre du travail qui lui est assigné. Les équipes de sécurité peuvent alors détecter des schémas anormaux d’utilisation des outils, des accès inattendus entre domaines de données et des écarts par rapport aux tâches assignées à cet agent. Construire ces référentiels plus tôt mélangerait une activité que le système ne peut pas encore distinguer ni attribuer de manière fiable.

La détection a ensuite besoin d’un chemin de confinement qui va au-delà d’un seul point de politique. La porte 6 est franchie lorsque l’autorité effective de l’organisation sur l’agent peut être stoppée partout où l’agent agit. Atteindre cet état exige de désactiver l’identité de l’agent, d’invalider les identifiants actifs et dérivés, de bloquer l’activation des outils, de mettre fin aux tâches en cours et d’isoler le workload qui contient l’agent.

Ce chemin d’arrêt inter-systèmes est important parce que l’autorité de l’agent peut persister sous plusieurs formes après la désactivation d’un objet d’annuaire ou d’une route de passerelle. Une tâche active peut encore être en cours d’exécution, un identifiant dérivé peut rester utilisable, ou le workload peut conserver l’accès à un outil. Le confinement est complet lorsque ces chemins peuvent être coupés ensemble, chaque point d’application pertinent stoppant l’autorité qu’il contrôle.

Un IAM brownfield peut prendre en charge cette séquence sans remplacement complet

Le modèle de dépendance est particulièrement utile pour un IAM brownfield, où l’infrastructure d’identité est déjà en production et où l’organisation doit ajouter des agents sans reconstruire son programme d’identité. Les modèles de maturité conventionnels peuvent désavantager cet environnement lorsqu’ils décrivent un futur ensemble de contrôles sans expliquer comment les superposer à l’IAM existant. Les organisations dans cette situation se tournent souvent d’abord vers les passerelles, alors même que la passerelle dépend d’un contexte que le modèle d’identité actuel ne représente peut-être pas encore.

Ce contexte peut être ajouté même lorsqu’un fournisseur d’identité ne dispose pas d’un objet agent natif. L’entreprise peut établir un registre d’agents faisant autorité et relier ses enregistrements aux identités de workload existantes. Les identifiants d’agent et de tâche peuvent alors devenir des contextes d’exécution de confiance, tandis que des identifiants à durée de vie courte réduisent les privilèges hérités et que ces identifiants sont inscrits dans les journaux d’appels d’outils pour une ingestion ultérieure par la passerelle.

Parce que les portes ultérieures dépendent de l’information plutôt que d’une implémentation particulière, le modèle peut rester stable à mesure que le support des fournisseurs mûrit. Une capacité d’identité native peut à terme remplacer ou intégrer des éléments de l’implémentation intermédiaire sans modifier les informations dont les portes ultérieures ont besoin. Pour une organisation brownfield, un registre faisant autorité associé à une identité de workload constitue une architecture de départ praticable sans remplacement complet de l’IAM.

La nécessité d’intégrer les contrôles des agents dans les opérations de sécurité normales apparaît aussi dans l’enquête 2026 d’Okta. Seuls 34 % des dirigeants ont déclaré que leur organisation applique toujours à sa main-d’œuvre agentique la même rigueur de sécurité qu’à sa main-d’œuvre humaine. Ce chiffre n’établit pas la séquence en six portes, mais il montre bien un large déficit de gouvernance autour des systèmes agentiques.

Un test sur 30 jours : commencer avec 10 agents de production

Ce déficit de gouvernance peut être testé sur une infrastructure réelle avec un exercice sur les 30 prochains jours couvrant 10 agents de production. Pour chacun, identifiez le propriétaire, la finalité, les outils approuvés et les identifiants, afin de faire de l’exercice le début d’un registre d’agents tout en mettant au jour les lacunes immédiates de gouvernance. Testez ensuite si l’IAM et la journalisation peuvent distinguer chaque agent de l’humain ou du service qui a délégué son travail ; si ce n’est pas le cas, la passerelle n’a pas la visibilité nécessaire sur l’acteur réel.

Une fois ces identités testées, choisissez une tâche d’agent terminée et reconstituez toute sa chaîne d’actions, y compris les effets en aval. Suivez l’initiateur à travers l’exécution par l’agent, l’autorité, les appels d’outils et les changements qui en résultent, et consignez chaque point où la chaîne ne peut plus être suivie. Chaque rupture identifie une dépendance que les contrôles de production supposent actuellement, mais qu’ils ne peuvent pas établir.

Utilisez chaque rupture consignée pour identifier la prochaine dépendance de contrôle à corriger. Si la chaîne perd l’identité de l’agent, corrigez la propagation de l’identité ; si elle perd l’autorité déléguée, préservez ce contexte ; si un appel d’outil ne peut pas être relié à son effet en aval, corrigez la télémétrie à travers cette frontière. Réexécutez la même reconstitution de tâche terminée après chaque changement jusqu’à ce que le système puisse suivre la tâche depuis son initiateur jusqu’aux changements qui en résultent.

En conclusion

Pour les dirigeants, la décision principale n’est pas de savoir s’il faut investir dans la sécurité des agents, mais si ces investissements sont réalisés dans un ordre qui permet à chaque contrôle de fonctionner comme prévu. Une passerelle peut appliquer une politique, des systèmes comportementaux peuvent détecter des anomalies, et l’IAM existant peut contraindre l’accès, mais aucun d’eux ne peut compenser un agent dont l’identité, l’autorité déléguée et les actions restent floues.

Le modèle en six portes fournit un moyen de transformer cette dépendance en plan opérationnel. Établissez quels agents existent et qui en est responsable, préservez l’identité et la délégation, réduisez leur autorité, rendez leurs actions reconstituables, puis utilisez ce contexte pour l’application à l’exécution, la détection comportementale et le confinement. Les équipes peuvent construire plusieurs capacités en parallèle, mais la confiance en production doit dépendre de la preuve du contexte amont requis par chaque contrôle.

Pour les responsables métier, cela crée aussi une norme pratique pour mesurer les progrès. Au lieu de demander si l’organisation a acheté une plateforme de sécurité des agents ou déployé une passerelle, demandez si un agent de production peut être identifié, limité à sa tâche assignée, tracé de l’instruction au résultat, et stoppé sur tous les systèmes auxquels il peut accéder. Ce sont des propriétés testables qui relient l’investissement de sécurité au risque opérationnel.

À mesure que les agents obtiennent l’accès aux paiements, aux systèmes de production, aux données sensibles et à d’autres ressources à fort enjeu, une authentification valide restera nécessaire mais insuffisante. Les organisations les mieux placées pour étendre l’usage des agents en toute sécurité seront celles qui traitent l’identité, l’autorité, l’attribution, l’application des règles et le confinement comme un système de contrôle connecté plutôt que comme des produits de sécurité séparés.