Bienvenue dans le deuxième épisode de « A Walk in the Park », une nouvelle série de courtes vidéos qui explore les forces qui redéfinissent l’avenir de la confiance numérique. Au cours des cinq prochaines semaines, nous sortirons les discussions des salles de réunion pour les mener en plein air, tandis que nos experts analyseront certains des plus grands défis auxquels sont confrontés aujourd’hui les responsables de la sécurité.
Nous avons passé des années à perfectionner nos compétences en matière d’identité pour les utilisateurs : badges, identifiants, authentification multifactorielle… tout le tralala. Mais aujourd’hui, une nouvelle catégorie d’identités fait son apparition dans toute l’entreprise : les agents IA. Et ils arrivent à un rythme effréné.
Voici le point sur lequel les gens se trompent. Ce n’est pas que nous ne disposions pas de la technologie nécessaire pour les sécuriser. C’est simplement que la responsabilité n’est pas clairement définie. Les entreprises se précipitent pour adopter des agents, tandis que les services chargés de l’identité et de la sécurité ont du mal à suivre le rythme. Ainsi, lorsqu’un agent est mis en service, qui est réellement responsable de la manière dont il prouve son identité ? Le service IAM ? Le service de sécurité ? Une toute nouvelle équipe dédiée à l’IA ? Dans la plupart des entreprises aujourd’hui, la réponse honnête se résume à un haussement d’épaules.
C'est là tout le problème de l'identité de l'IA. Je vais être franc à ce sujet.
▶️ Regardez l'épisode : Ryan et moi abordons le problème de l’identité dont personne n’est propriétaire dans cet épisode de « A Walk in the Park ». La vidéo fait beaucoup parler d’elle. Poursuivez votre lecture ci-dessous pour en savoir plus sur ce que, selon moi, tout responsable de la sécurité et de l’IA doit savoir.
Ce que signifie l'identité pour un agent
On parle presque toujours d’identité en se référant aux êtres humains (et même aux machines), mais un nouvel acteur est entré en scène, et il ne respecte pas les règles.
Nous avons rapidement dépassé le stade de l'IA générative pour entrer dans l'ère de l'IA agentique. Software nous confions les rênes. Les entreprises commencent à lui donner accès à plusieurs systèmes, puis la laissent réfléchir et prendre des décisions de manière autonome.
Réfléchissez-y un instant. Nous donnons software capacité d'agir dans notre environnement, en notre nom. La seule façon responsable de permettre cela est de lui attribuer une identité fiable.
Là où la plupart des équipes commettent des erreurs
Voici ce que je constate presque partout.
Les équipes reprennent les modèles d'identité que nous avons utilisés pour les humains et les machines, et tentent de les appliquer aux agents d'IA. Elles se rabattent donc sur ce qui a déjà fait ses preuves : les identifiants délégués, les clés API, les jetons.
C'est là que ça casse.
Un identifiant statique repose sur la possession. Celui qui détient le secret y a accès. Point final. Cela ne pose aucun problème jusqu’à ce qu’un agent, ou un attaquant ayant subtilisé cette clé dans un fichier de configuration, l’utilise pour accéder à des données auxquelles il n’était pas censé avoir accès.
Imaginez maintenant cela à la vitesse d'une machine, sur des dizaines de systèmes. « Celui qui détient le secret » est une approche risquée pour déterminer la confiance.
Il s'agit là d'un nouveau type de crise d'identité. Les secrets statiques ne garantissent ni la responsabilité ni la sécurité. Ils sont copiés, partagés et volés, et par la suite, il est souvent impossible de prouver qui a fait quoi sans mener une enquête approfondie.
Ce dont nous avons besoin, c'est d'une identité dynamique, vérifiable et générée par cryptographie. Une identité que l'on peut délivrer, renouveler et révoquer dès qu'un élément semble suspect.
Ce que je trouve gratifiant
Lorsque les auteurs des recommandations relatives aux agents d'IA s'appuient sur une technologie éprouvée et fiable, c'est un bon signe pour les équipes de sécurité.
Le récent cadre « Zero Trust » d’Anthropic pour les agents IA est très clair à ce sujet. Attribuez à chaque agent une identité unique, cryptographiquement ancrée. Pas une simple étiquette. Une véritable identité. Considérez les clés API statiques comme déjà compromises, car elles font partie des premières cibles recherchées par un attaquant aidé par l’IA. Émettez des jetons à durée de vie limitée. À grande échelle, authentifiez les agents à l’aide de certificats X.509 et TLS mutuel. Signez vos composants afin que personne ne puisse les altérer entre le code source et l’exécution.
Relisez cette liste. C'est ça, l'infrastructure à PKI. C'est ça, l'identité basée sur des certificats.
Il s’agit du même modèle de confiance cryptographique que nous utilisons à l’échelle des machines depuis des années. Il s’adresse simplement désormais à un nouveau public très avide de technologies. Les frameworks ont rattrapé leur retard par rapport à ce que le monde de la cryptographie savait déjà. On ne sécurise pas software autonome software un mot de passe dans un fichier texte. On le sécurise grâce à une identité vérifiable. La même identité solide et vérifiable que nous attribuons déjà aux personnes et aux appareils.
Alors, à qui appartient-il ?
Et voilà le passage qui met mal à l'aise. C'est aussi la raison pour laquelle cet épisode porte ce titre.
Les obstacles à la mise en production d'un agent ont pratiquement disparu. Un développeur peut en créer un, l'intégrer aux systèmes avec ses propres identifiants et le faire fonctionner avant même l'heure du déjeuner. Idéal pour aller vite. Mais problématique en termes de gouvernance.
Et ces agents ne rentrent pas dans nos anciens schémas. Ce ne sont pas des identités humaines rattachées à un responsable. Ce ne sont pas des infrastructures rattachées à un propriétaire de système. Ils se situent dans une zone grise pour laquelle la plupart des programmes de gestion des identités ne disposent pas encore de processus.
La responsabilité se retrouve donc fragmentée. Des études récentes menées dans le secteur le confirment. Dans une enquête réalisée en 2026 auprès de responsables de la sécurité, la responsabilité de l’identité des agents était répartie entre les équipes de sécurité, le service informatique et de toutes nouvelles fonctions dédiées à l’IA, sans qu’aucune responsabilité claire ne soit définie ; seul un quart environ des organisations disposait d’une stratégie formelle en la matière. L’adoption de ces technologies avance à grands pas. La gouvernance, quant à elle, progresse au mieux à petits pas.
On ne résout pas ce problème avec un outil. On le résout en déterminant qui en est responsable. Réunissez les développeurs d’IA et les équipes chargées de l’identité et de la sécurité autour d’une même table. Définissez les responsabilités et mettez en place une structure claire. Puis, posez des bases solides de confiance. C’est ce qui vous permettra de tirer pleinement parti des agents IA, au lieu d’accumuler silencieusement des risques à chaque fois qu’un agent est déployé.
Par où commencer ?
Avant que votre prochain agent ne soit mis en service, posez-vous une question : comment cet agent prouve-t-il son identité, et qui peut le révoquer ?
Si la réponse est « une clé API » ou « je ne sais pas », vous avez trouvé ce qu'il vous faut.
Attribuez à vos agents des identités réelles et vérifiables par cryptographie. Ensuite, désignez un responsable pour ce problème.
L'IA agentique va prendre une ampleur considérable. Mais elle ne fonctionnera que s'il existe une infrastructure de confiance suffisamment solide pour en supporter le poids.
Prochain épisode de notre série « A Walk in the Park » : rejoignez Ted Shorter, directeur technique chez Keyfactor, pour comprendre l'évolution de TLS et pourquoi la disponibilité de vos services en dépend. Rendez-vous lors de la prochaine balade.
