Votre contrôle d’accès est-il adapté aux agents IA ?

Un agent d’IA autorisé à ouvrir GitHub peut aussi disposer d’autorisations suffisantes pour effectuer un force-push vers une branche de production à 2 heures du matin. Cet écart change la question de sécurité pour les entreprises qui déploient des agents. Savoir à quels systèmes un agent peut accéder définit une première limite, mais une exécution sûre exige de décider si cet agent peut effectuer une action précise sur une ressource précise à un moment précis. Sécuriser les agents exige donc une identité vérifiable comme base d’exécution de ces décisions.

Les agents d’IA révèlent la limite du contrôle d’accès au niveau applicatif

Cette exigence d’exécution prend de l’ampleur à mesure que les entreprises ajoutent des agents d’IA, des applications, des workloads et d’autres identités machine plus vite qu’elles n’ajoutent d’employés. Beaucoup d’entreprises se préparent à des populations non humaines plusieurs fois plus importantes que leurs populations humaines. À mesure que ces populations augmentent, l’architecture d’identité limite un déploiement sûr, car chaque agent de production a besoin d’une identité vérifiable, d’un identifiant résistant aux fuites, et d’autorisations à périmètre strictement limité.

Ces exigences mettent en évidence un décalage avec la gestion des identités et des accès (IAM) en entreprise, les systèmes utilisés pour établir les identités et gouverner leurs autorisations. Les plateformes IAM actuelles ont été conçues principalement autour des identités humaines et n’ont pas été pensées pour délivrer cette combinaison d’identité, d’identifiants et d’autorisations à des entités logicielles. Les responsables sécurité qui travaillent sur leurs premiers déploiements sérieux d’IA agentique soumettent systématiquement le problème aux équipes IAM plutôt qu’aux responsables des endpoints ou des applications. Leur travail immédiat consiste à découvrir quels agents existent, à établir pour eux des identités vérifiables et à restreindre ce qu’ils peuvent faire sur les systèmes centraux.

Ces restrictions deviennent importantes dès qu’un agent commence à travailler. L’IAM conventionnelle peut déterminer si l’agent est autorisé à entrer dans une application ou à atteindre une ressource. L’identité d’exécution doit permettre une décision plus fine : savoir si cette identité peut effectuer cette action sur cette ressource pendant cette fenêtre temporelle. L’accès à l’application reste une partie de cette décision, mais les actions au sein de l’application ont besoin de leur propre frontière d’autorisation.

L’IAM conventionnelle et le zero trust sont trop grossiers pour les agents

Le besoin d’une frontière plus fine commence avec les hypothèses intégrées à l’IAM traditionnelle. Un humain prouve son identité par des mécanismes tels qu’un mot de passe, une empreinte digitale ou une reconnaissance faciale, puis reçoit des autorisations selon un rôle suffisamment large pour représenter une fonction. Admin, utilisateur et lecture seule en sont des exemples familiers. Les équipes identité qui introduisent des agents doivent donc établir des identités, des identifiants et des autorisations propres aux machines avant que ces agents puissent fonctionner sous une gouvernance comparable.

Le principe traditionnel du moindre privilège réduit déjà l’accès en faisant correspondre les ressources aux responsabilités de travail. Un employé de l’ingénierie peut recevoir un accès à GitHub et à une console cloud, tandis qu’un employé de la finance reçoit un accès au système comptable. Ces limites restent utiles, mais un agent qui opère via le jeu d’autorisations existant d’un humain peut hériter d’un champ d’actions possibles bien plus large que ce que sa tâche immédiate exige. Pour un agent, la décision d’autorisation déterminante peut se situer à l’intérieur de l’application.

L’e-mail rend cette distinction concrète. Donner à un agent un accès à la messagerie pour une tâche légitime peut aussi lui laisser la possibilité de déplacer des messages ou d’envoyer des e-mails au conseil d’administration. Matt Caulfield, vice-président produit, identité, chez Cisco, décrit ainsi le modèle d’identifiants et d’autorisations requis : « Nous devons émettre un identifiant, généralement cryptographique, lié au matériel afin que personne ne puisse le voler. Ensuite, nous passons aux autorisations. Dire qu’un agent peut accéder à la messagerie lui laisse la liberté de déplacer des e-mails ou d’écrire au conseil d’administration. Les agents ont besoin d’autorisations juste suffisantes, juste à temps, et juste assez longtemps pour accomplir la mission en cours. » Cisco a un intérêt commercial dans ce modèle, car l’entreprise vend Duo et d’autres offres de sécurité positionnées pour mettre en œuvre les contrôles d’identité décrits par Caulfield.

Le principe d’autorisation de Caulfield resserre l’autorisation selon trois dimensions : la capacité requise pour la tâche, le moment où elle est nécessaire et la durée pendant laquelle elle reste valide. Un droit permanent crée un éventail de comportements possibles plus large que ce qu’une tâche exige. Comme les agents peuvent initier des actions sans qu’une personne formule chaque demande individuellement, le resserrement de ces dimensions transforme l’autorisation, qui passe d’un droit durable à une décision spécifique à une tâche.

L’architecture zero trust rencontre le même problème lorsque sa frontière de politique reste au niveau des utilisateurs, des appareils, des applications et des ensembles de données. Une politique peut établir qu’un agent particulier peut se connecter à GitHub, par exemple, alors que la vraie question reste de savoir si cet agent peut effectuer un force-push vers une branche de production à 2 heures du matin. Une fois la connexion autorisée, l’action elle-même exige une décision distincte.

Caulfield soutient que cette limite impose de changer l’unité gouvernée. « Le zero trust n’a jamais vraiment été du zero trust. C’était de la confiance dans les systèmes d’identité », dit-il. « Nous disons souvent qu’il faut passer du contrôle d’accès au contrôle des actions, et la seule façon d’y parvenir est d’inspecter chaque action, de l’autoriser en temps réel avant que quoi que ce soit ne se produise, et d’enregistrer l’ensemble. » Dans ce modèle, l’identité établit qui ou quoi agit, tandis que la politique évalue l’opération demandée avant son exécution.

Les pratiques existantes de moindre privilège et de zero trust apportent toujours des contraintes utiles, mais les cas de l’e-mail et de GitHub montrent où une politique au niveau de l’action doit les prolonger. Un agent peut rester dans son application approuvée tout en effectuant une action que la tâche n’a jamais exigée. La sécurité des agents a donc besoin d’une autorisation suffisamment fine pour gouverner les opérations à l’intérieur de limites déjà établies pour les applications et les ressources.

L’identité d’exécution change l’unité d’autorisation

Le contrôle des actions transforme un droit persistant au niveau applicatif en une autorisation éphémère pour une opération individuelle. Chaque action pertinente est inspectée, évaluée par rapport à une politique avant exécution, puis enregistrée. L’identité d’exécution fournit l’acteur vérifié derrière cette évaluation, ce qui permet à la politique d’associer une autorisation à l’entité qui demande l’opération et à son contexte actuel.

Une autorisation GitHub illustre à quel point l’autorisation résultante peut être étroite. Caulfield décrit un agent recevant cinq minutes pendant lesquelles il peut fusionner une pull request sans obtenir la capacité de lire l’ensemble d’un dépôt ou de modifier d’autres dépôts. « Ce dépôt, cette action, cette fenêtre », dit-il. La ressource, l’opération et le temps sont donc exprimés ensemble dans une seule autorisation au lieu d’être regroupés dans un large accès au dépôt.

Cette spécificité change aussi la manière dont l’authentification fonctionne pendant l’exécution. L’authentification ponctuelle perdait déjà du terrain pour les utilisateurs humains, et un agent renforce l’argument en faveur de la vérification continue du contexte parce que les actions qu’il demande peuvent changer toutes les quelques minutes. Le processus proposé commence par l’association cryptographique de l’identité de l’agent à un appareil, puis par l’établissement d’un canal sécurisé vers le système à travers lequel l’agent opère. L’identité devient un paramètre des décisions d’autorisation ultérieures tout au long de la session.

Faire fonctionner ce modèle à la vitesse des machines exige quatre capacités liées : découvrir les agents déjà actifs dans l’environnement ; leur fournir des identifiants cryptographiques liés au matériel ; autoriser les actions individuelles ; et enregistrer en continu leur activité. La découverte établit quelles identités logicielles doivent être gouvernées, après quoi un identifiant donne à chaque identité une base vérifiable. L’autorisation des actions limite ensuite ce que cette identité peut faire à un moment donné, tandis que l’enregistrement conserve l’historique nécessaire pour établir ce qui s’est passé.

Le problème d’identité se poursuit lorsque le travail passe d’une entité à une autre. Une demande peut passer d’un humain à un agent, de cet agent à un autre agent, puis du dernier agent à une application ou à un ensemble de données. Chaque transfert crée une relation d’application des règles : humain vers agent, agent vers agent, ou agent vers ressource. La gouvernance à l’exécution doit donc préserver suffisamment d’identité fiable et de contexte à travers chaque relation pour permettre la décision suivante au niveau de l’action.

Préserver ce contexte place l’application des règles directement dans le chemin d’exécution. « Se placer entre les agents et les ressources, entre les agents et d’autres agents, et entre les humains et les agents est la seule façon d’inspecter chaque action au moment où elle se produit », dit Caulfield. « Cette position vous donne une vérification continue de l’identité, une application continue des politiques et une piste d’audit complète de tout ce que l’agent a fait. » Les bénéfices avancés par Cisco dépendent donc de la présence de sa couche de sécurité là où l’interaction a lieu, avant que l’action gouvernée ne soit achevée.

La vérification à l’exécution répond aussi à une différence entre les processus utilisés pour établir la confiance envers les personnes et envers les logiciels. Une entreprise peut passer des semaines ou des mois à établir sa confiance envers une personne avant de lui donner un accès, alors qu’un agent peut être créé en quelques minutes. Comme l’agent ne bénéficie pas de ce processus organisationnel plus lent, l’architecture proposée établit et vérifie de manière répétée son identité pendant qu’il opère.

Caulfield explicite cette différence : « Les personnes construisent la confiance à travers un processus. Nous connaissons la même personne, ou la même entreprise nous a embauchés, et cette entreprise a effectué une vérification des antécédents, mené un entretien, vérifié notre identité lors de l’onboarding. Rien de tout cela n’existe pour les agents. Nous embauchons des personnes sur plusieurs semaines ou plusieurs mois. Nous embauchons des agents en quelques minutes. » Sa comparaison transfère une plus grande part de la charge d’établissement de la confiance pour un agent vers une identité vérifiable et une application des règles à l’exécution.

L’identité devient une infrastructure pour la stack de sécurité

Une fois que la politique suit les agents pendant l’exécution, l’identité devient un paramètre partagé entre les environnements. Un agent peut s’exécuter sur un laptop, dans le cloud, dans un centre de données ou derrière un service tiers, et pourtant les contrôles de sécurité ont toujours besoin d’un moyen fiable de déterminer quelle entité produit une action. « C’est parce que, que les agents s’exécutent sur votre laptop, dans le cloud, dans un centre de données ou derrière des services tiers, ils ont tous besoin d’une identité », dit Caulfield. « C’est le seul principe unificateur entre eux tous. L’identité est la seule couche qui les atteint tous. »

Une couche d’identité commune donne ensuite aux autres contrôles de sécurité un acteur à gouverner. La politique réseau a besoin de cet acteur avant que les règles de segmentation puissent prendre une décision pertinente, tandis que la détection des menaces en a besoin pour relier un comportement à une entité. L’observabilité a besoin de la même association pour expliquer quel agent a produit un événement. L’identité, le réseau, la sécurité des endpoints et la sécurité des données se rejoignent donc là où l’activité des agents est attribuée et gouvernée.

Cette dépendance élargit le travail au-delà d’une refonte de l’IAM. « Nous devons presque repenser les 30 dernières années de sécurité à travers le prisme des agents », dit Caulfield. « Comment nous occupons-nous de la sécurité de l’identité pour les agents ? De la sécurité réseau, de la sécurité des endpoints, de la sécurité des données ? La plupart des programmes de sécurité d’entreprise ont déjà une stratégie pour chacun de ces domaines. Ils ont besoin d’une ligne supplémentaire sous chacun d’eux : comment faisons-nous cela pour les agents ? » Les domaines de sécurité existants ont donc besoin d’un traitement spécifique aux agents, car les acteurs machine changent la manière dont l’identité est établie et la rapidité avec laquelle les actions sont exécutées.

La gouvernance des agents exige aussi de fermer les contournements par identifiants humains

La couche d’identité partagée dépend du fait que les agents entrent dans les systèmes via des identités qui peuvent être gouvernées. Un déploiement fondé sur l’identité d’exécution commence donc par la découverte, car un agent inconnu ne peut pas être placé sous politique. Les applications centrales viennent ensuite, car un utilisateur capable de créer une clé API ou un personal access token peut donner à un agent une autre voie d’entrée dans un système. L’authentification des employés doit faire partie du même examen, car les identifiants humains peuvent eux aussi fournir une voie de contournement des contrôles d’identité machine.

Les mots de passe rendent ce contournement particulièrement direct. « Si les humains de votre organisation s’authentifient avec des mots de passe, les gens donneront ces mots de passe à leurs agents », dit Caulfield. « L’agent agit alors comme la personne, et les deux deviennent indiscernables. Une authentification résistante au phishing ne donne aux employés rien qu’ils puissent partager. » Dès lors que le même identifiant représente les deux parties, le système d’identité perd la distinction nécessaire pour appliquer une politique d’autorisation et d’audit spécifique aux agents.

Cette perte de distinction signifie que le versant humain de l’IAM affecte directement la gouvernance des agents, même lorsqu’une organisation a conçu de solides identités machine. Les mots de passe, les clés API et les personal access tokens peuvent faire s’effondrer ou contourner cette séparation si les personnes peuvent les transférer à des logiciels. La propriété proposée pour l’authentification humaine est une résistance au phishing combinée à des identifiants qui restent liés à l’employé ou à l’appareil, laissant l’agent sans identifiant humain transférable à réutiliser.

Cisco positionne Duo comme une mise en œuvre de cette couche d’identité aux côtés de ses offres de sécurité des endpoints, du réseau et des données. Pour les identités humaines, Duo utilise des identifiants conçus pour rester liés à un utilisateur ou à un appareil et vérifie en continu l’identité et l’activité. Cisco affirme que ces contrôles réduisent la probabilité que des identifiants soient transmis accidentellement à un agent ou délibérément à un attaquant. En tant que fournisseur de Duo, Cisco bénéficie commercialement lorsque les entreprises adoptent cette approche de la sécurité de l’identité.

Pour les identités non humaines, Cisco indique que Duo délègue des autorisations à périmètre strictement limité via OAuth, le mécanisme standard utilisé pour déléguer l’accès sans transmettre l’identifiant utilisateur sous-jacent. Duo prend également en charge les spécifications d’autorisation utilisées aujourd’hui par MCP, ou Model Context Protocol, un protocole permettant de connecter des systèmes d’IA à des outils et des données externes. Il représente aussi les agents comme des identités de premier plan dans son annuaire. Ensemble, Cisco présente ces mécanismes comme des moyens de donner à un agent sa propre identité gouvernable et de déléguer une autorité adaptée à une opération particulière.

La découverte étend ce modèle aux identités logicielles qu’une entreprise peut déjà avoir. Cisco indique que son acquisition d’Astrix ajoute la capacité de découvrir les identités non humaines et de mettre en lumière les comptes, les autorisations et les secrets que ces identités utilisent. Cette découverte précède la politique au niveau de l’action, car les équipes doivent d’abord identifier les identités et les identifiants par lesquels les agents existants peuvent atteindre les systèmes de l’entreprise.

L’application inline devient une dépendance du chemin d’exécution

Une fois que les équipes ont découvert ces chemins, l’autorisation au niveau de l’action exige que la couche de sécurité y participe. Inspecter et approuver les actions avant exécution signifie que la couche d’identité et de sécurité se place inline sur les connexions pertinentes entre humains, agents, autres agents, applications et données. Cette position permet l’application des règles à l’exécution, car une décision de politique peut intervenir avant que l’opération demandée ne soit achevée.

Cette même position fait aussi de la couche d’application des règles une partie du chemin d’exécution du travail qu’elle gouverne. Une architecture fondée sur le principe « inspecter chaque action » doit donc traiter la vérification d’identité et l’évaluation des politiques comme une infrastructure d’exécution plutôt que comme un processus administratif séparé. Le cas GitHub initial rend cette dépendance concrète : décider si un agent peut effectuer un force-push vers une branche de production à 2 heures du matin n’est utile que si cette décision peut gouverner l’action avant que GitHub ne l’exécute.

Cette exigence définit le test de mise en œuvre pour l’autorisation au niveau de l’action. Le système doit préserver une identité fiable à travers les transferts humain-vers-agent, agent-vers-agent et agent-vers-ressource, puis appliquer la politique pertinente lorsqu’une opération est demandée. Pour une fusion légitime, cela peut signifier cinq minutes d’autorité sur une pull request ; pour un force-push en dehors de l’opération autorisée, le même contexte d’identité et de ressource conduit à une décision d’autorisation différente.

Points clés

• Gouvernez les agents d’IA au niveau de l’action : Les équipes IAM ont besoin de contrôles qui décident si un agent précis peut effectuer une opération précise sur une ressource précise à un moment donné. L’accès au niveau applicatif laisse trop d’autorité à l’intérieur de systèmes comme GitHub et la messagerie.
• Faites de l’identité d’exécution la base de l’autorisation : Les équipes sécurité peuvent associer chaque agent à une identité vérifiable, de préférence adossée au matériel, et utiliser cette identité dans des décisions de politique en temps réel. Des autorisations spécifiques à la tâche et de courtes fenêtres d’autorisation réduisent la portée des accès permanents.
• Préservez l’identité à chaque transfert : Les workflows d’agents peuvent passer des humains aux agents, entre agents, puis vers des applications ou des données. Les architectes sécurité ont besoin d’une identité et d’un contexte fiables pour suivre ces interactions afin que la politique et les enregistrements d’audit restent liés à l’entité qui effectue chaque action.
• Étendez l’identité à toute la stack de sécurité : Les contrôles réseau, endpoint, données et menaces ont tous besoin d’un moyen fiable d’attribuer l’activité des agents. Traiter l’identité des agents comme une infrastructure partagée donne à ces systèmes une base cohérente pour l’application des règles et l’observabilité.
• Fermez les contournements par identifiants humains : Les mots de passe, les clés API et les personal access tokens peuvent permettre aux agents d’opérer comme des employés et de saper les contrôles spécifiques aux agents. Les équipes identité peuvent renforcer la séparation en adoptant une authentification humaine résistante au phishing, en découvrant les identités non humaines et en attribuant aux agents leurs propres identifiants.
• Concevez l’application inline comme une infrastructure d’exécution : L’autorisation au niveau de l’action ne fonctionne que si la politique est évaluée avant que l’opération ne soit achevée. Les équipes d’architecture doivent prendre en compte les exigences de disponibilité, de latence, de scalabilité et d’audit d’une couche d’identité placée directement dans des chemins d’exécution critiques.