Série d'entretiens avec Jacob Ideskog, directeur technique de Curity.

Jacob Ideskog Il est spécialiste de l'identité et directeur technique chez Curity. Il consacre la majeure partie de son temps aux solutions de sécurité pour les API et le Web. Il a conçu et mis en œuvre des solutions OAuth et OpenID Connect pour de grandes entreprises et de jeunes startups.

Curiosité est une plateforme moderne de gestion des identités et des accès (IAM) basée sur Curity Identity Server, une solution conforme aux normes conçue pour sécuriser l'authentification et l'autorisation des applications, des API et des services numériques à grande échelle. Elle prend en charge des protocoles tels que OAuth 2.0 et OpenID Connect pour centraliser les flux de connexion, appliquer des politiques d'accès précises et émettre des jetons sécurisés pour les utilisateurs humains et les clients machines, y compris les API et les services. La plateforme est conçue pour offrir flexibilité et évolutivité, permettant aux organisations de la déployer dans des environnements cloud, hybrides ou sur site, de l'intégrer aux systèmes existants et de proposer des expériences utilisateur sécurisées et fluides sans nécessiter d'infrastructure de sécurité personnalisée.

Vous avez consacré une grande partie de votre carrière à la conception de systèmes de sécurité des identités et des API, depuis la cofondation de Curity jusqu'à son poste de directeur technique, en passant par l'essor du cloud et maintenant de l'IA. Comment ce parcours a-t-il influencé votre conviction que les agents d'IA doivent être considérés comme des identités numériques à part entière et non comme de simples logiciels ?

Dans tous les domaines technologiques que j'ai explorés, un problème revient sans cesse. Qu'il s'agisse du cloud computing ou, aujourd'hui, de l'IA, si un logiciel agit pour le compte d'une personne ou d'un autre système, un problème d'identité se pose.

Avec l'adoption massive de l'IA agentielle, ce problème s'aggrave. Leur comportement n'est plus strictement programmé et elles opèrent avec un niveau d'autonomie inédit pour les entreprises. Les agents d'IA prennent des décisions, appellent des API et enchaînent des actions entre les systèmes, souvent sans supervision humaine directe. Ce comportement engendre des défis en matière d'identité et d'accès fondamentalement différents de ceux des logiciels traditionnels.

Considérer les agents d'IA comme des identités numériques à part entière est la seule façon de traiter correctement ce problème. Si les organisations les considèrent comme un simple processus ou compte de service, elles perdent très vite en visibilité et en contrôle, ce qui constitue un facteur de risque majeur pour la sécurité.

De nombreuses entreprises s'enthousiasment pour l'IA agentielle, mais restent bloquées au stade de l'expérimentation. D'après vos observations lors de déploiements concrets, quelles sont les principales lacunes en matière d'identité et de gouvernance qui empêchent les organisations de déployer des agents à grande échelle en toute sécurité ?

La plupart des expérimentations se déroulent dans des environnements isolés, ignorant tout de ce qui se passe à grande échelle. Lors des premiers projets pilotes, les équipes attribuent souvent aux agents des clés API larges, des identifiants partagés ou des autorisations cloud globales, simplement pour démarrer le projet.

Cette approche se heurte à des difficultés dès que les agents sont déployés au-delà des phases pilotes. En effet, les équipes de sécurité ne peuvent pas voir les données auxquelles un agent a accédé, ses actions, ni s'il a dépassé son périmètre d'action prévu, que ce soit accidentellement ou intentionnellement. Ces angles morts rendent impossible la gouvernance sécurisée des agents, ce qui explique pourquoi de nombreuses organisations peinent à aller au-delà des phases pilotes.

Vous avez soutenu que des garde-fous stricts sont essentiels pour l'IA agentive. Concrètement, à quoi ressemble une « bonne » conception d'identité pour les agents IA, et où les entreprises se trompent-elles généralement ?

Une bonne conception d'identité repose sur le principe du moindre privilège et des permissions liées à une intention explicite. Chaque agent d'IA doit posséder sa propre identité, des permissions limitées et des relations de confiance clairement définies (règles explicites précisant les systèmes avec lesquels il est autorisé à interagir). Fondamentalement, l'accès doit être limité dans le temps, circonscrit à un objectif précis et facilement révocable.

L'erreur fréquente des entreprises est de réutiliser des comptes de service existants ou de supposer que leurs agents internes sont protégés par défaut. Cette hypothèse ne résiste pas aux menaces réelles. Les acteurs malveillants recherchent activement ces failles, et les agents d'IA augmentent considérablement le risque d'attaque lorsque la conception des identités est négligée.

Curity travaille depuis longtemps avec des standards comme OAuth et OpenID Connect. Dans quelle mesure les standards d'identité ouverts sont-ils essentiels pour garantir l'interopérabilité et la sécurité des IA agentielles au sein d'environnements d'entreprise complexes ?

Les standards ouverts sont absolument essentiels. Les entreprises utilisent déjà des infrastructures d'identité complexes qui s'étendent sur des plateformes cloud, des services SaaS et des API internes. L'IA agentielle ne fait qu'accroître cette complexité.

Sans normes, chaque agent devient une intégration à part entière et une exception de sécurité permanente. Avec des normes comme OAuth et OpenID Connect, les agents peuvent être authentifiés, autorisés et audités comme n'importe quelle autre charge de travail. C'est la seule approche qui permette une mise à l'échelle sécurisée dans les environnements d'entreprise réels.

Les identités non humaines se généralisent, des comptes de service aux identités de machines. Du point de vue de la sécurité, qu'est-ce qui distingue fondamentalement les agents d'IA des identités non humaines précédentes ?

La principale différence entre les agents d'IA modernes et les identités non humaines (INH) plus anciennes réside dans leur autonomie. Un compte de service traditionnel exécute précisément les instructions de son code, strictement limité à sa tâche. Un agent d'IA, quant à lui, interprète les instructions, adapte son comportement et entreprend des actions non planifiées, ce qui accroît les risques potentiels en l'absence de garde-fous adéquats.

Une simple erreur d'identité ou d'accès peut rapidement dégénérer en catastrophe, car un agent peut agir très rapidement et sur plusieurs systèmes. Du point de vue de la sécurité, cela représente un risque majeur.

Quelle est l'importance des pistes d'audit et de la journalisation basée sur l'identité pour la gouvernance de l'IA agentielle, notamment dans les secteurs réglementés ?

Les pistes d'audit ne doivent pas être un simple atout. Elles doivent être intégrées dès la conception. Dans les environnements réglementés, les organisations doivent pouvoir répondre à des questions simples mais essentielles : à quelles données cet agent a-t-il accédé, quand cela s'est-il produit et qui l'a autorisé ?

L'enregistrement des incidents basé sur l'identité est le seul moyen fiable d'atteindre ce niveau de traçabilité. Il joue également un rôle clé dans la gestion des incidents. Sans contexte d'identité clair, il est quasiment impossible de déterminer si un problème provient d'un agent défaillant, d'une identité compromise ou simplement d'une invite erronée.

Quels risques concrets voyez-vous apparaître lorsque les organisations déploient en production des agents d'IA surprivilégiés ou mal surveillés ?

L'un des risques courants est l'agrégation silencieuse de données. Un agent disposant de privilèges excessifs peut extraire des informations sensibles de plusieurs systèmes (dossiers clients, documents internes, journaux) et ensuite exposer ces données via des invites, des résumés ou des intégrations externes.

Un autre risque réside dans le fait que des agents disposant de droits d'administrateur puissent effectuer des modifications majeures à la vitesse de la machine, causant ainsi des dommages bien plus importants qu'un humain ne pourrait jamais le faire en si peu de temps. Cela peut inclure la modification de ressources cloud, la désactivation de contrôles de sécurité ou le déclenchement de flux de travail automatisés sans supervision.

Ces incidents peuvent être malveillants, mais ce n'est pas forcément le cas. Un agent bénéficiant de privilèges excessifs ou mal supervisé pourrait simplement se baser sur des hypothèses obsolètes ou erronées, amplifiant ainsi les erreurs dans plusieurs systèmes avant même que quiconque ne s'en aperçoive.

Du point de vue d'un attaquant, une identité d'agent compromise est extrêmement précieuse. Elle permet de se déplacer latéralement entre les API et les services, souvent avec un niveau d'accès qu'aucun utilisateur humain ne pourrait jamais obtenir. Sans contrôles et surveillance robustes des identités, les organisations ne découvrent souvent ces failles qu'une fois le préjudice subi.

Pour les entreprises qui passent des projets pilotes aux déploiements d'agents réels, quelles décisions en matière d'identité et d'accès doivent être prises au plus tôt pour éviter des refontes coûteuses ultérieurement ?

Les organisations doivent décider dès le départ de la manière dont les identités des agents sont attribuées, dont les autorisations sont approuvées et dont l'accès est examiné au fil du temps, en définissant les limites de l'identité en amont.

L'introduction a posteriori de contrôles d'identité est presque toujours problématique. Les agents sont souvent profondément intégrés aux flux de travail, utilisant des identifiants partagés ou des rôles étendus. Par conséquent, restreindre l'accès après coup remet en cause les hypothèses sur lesquelles repose le système. Cela entraîne en fin de compte des défaillances dans les flux de travail et mine la confiance dans la technologie. Il est bien moins coûteux, et surtout bien plus sûr, de concevoir dès le départ des identités, des étendues et des limites d'accès appropriées.

Où l'intégration des identités devient-elle le plus souvent un goulot d'étranglement lors du déploiement d'une IA agentielle, et quelles sont les meilleures pratiques pour réduire les frictions ?

La gestion des identités peut devenir un goulot d'étranglement, mais seulement lorsqu'elle est négligée. Les équipes se concentrent d'abord sur le développement de fonctionnalités impressionnantes pour leurs agents, pour ensuite réaliser qu'elles doivent être intégrées aux systèmes IAM, aux passerelles API et aux plateformes de journalisation pour garantir une sécurité optimale.

La meilleure approche consiste à commencer par une compréhension claire et une mise en œuvre adéquate des plateformes d'identité, puis à concevoir des agents compatibles avec celles-ci. Les organisations devraient réutiliser les normes et infrastructures existantes plutôt que de les contourner ; faire l'impasse sur ces dernières entraînera inévitablement des problèmes ultérieurement. Intégrer l'identité dès la conception accélère le déploiement au lieu de le ralentir.

Quels conseils donneriez-vous aux responsables de la sécurité et de l'ingénierie qui souhaitent adopter l'IA agentielle mais qui s'inquiètent de la gouvernance et des risques, pour l'élaboration de leur feuille de route ?

Prenez le temps nécessaire pour établir des bases solides. Les agents d'IA doivent être considérés comme des entités à part entière ; il est donc indispensable d'appliquer la même gouvernance que pour les humains et d'exiger une visibilité totale dès le départ. Dans ce cas, le déploiement à grande échelle d'une IA agentielle devient un exercice de sécurité, et non un pari risqué et hasardeux.

Merci pour cette excellente interview, les lecteurs qui souhaitent en savoir plus devraient visiter Curiosité.