Jacob Ideskog, CTO de Curity – Série d’entretiens

Jacob Ideskog est un spécialiste de l’identité et CTO chez Curity. La majeure partie de son temps est consacrée à travailler sur des solutions de sécurité dans l’espace API et Web. Il a travaillé sur la conception et la mise en œuvre de solutions OAuth et OpenID Connect pour de grandes entreprises et de petites startups.

Curity est une plateforme moderne d’identité et de gestion des accès (IAM) construite autour du serveur d’identité Curity, une solution basée sur les normes conçue pour sécuriser l’authentification et l’autorisation pour les applications, les API et les 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 détaillées et délivrer 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 être flexible et évolutiva, permettant aux organisations de déployer sur le cloud, les environnements hybrides ou sur site, d’intégrer avec les systèmes existants et de fournir des expériences utilisateur sécurisées et sans interruption sans avoir recours à des infrastructures de sécurité personnalisées.

Vous avez passé une grande partie de votre carrière à construire des systèmes d’identité et de sécurité API, de la cofondation de Curity à sa direction en tant que CTO, à travers l’essor du cloud et maintenant de l’IA. Comment ce parcours a-t-il façonné votre point de vue selon lequel les agents IA devraient être traités comme des identités numériques de premier plan et non comme un simple logiciel ?

À travers chaque domaine de la technologie dans lequel j’ai travaillé, un problème revient constamment. Que ce soit le cloud computing ou maintenant l’IA, si un logiciel agit au nom d’une personne ou d’un autre système, vous avez un problème d’identité.

Avec l’adoption massive de l’IA agente, ce problème est aggravé. Le comportement de ces agents n’est plus strictement scripté et ils opèrent avec un niveau d’autonomie que les entreprises n’ont jamais connu auparavant. Les agents IA prennent des décisions, appellent des API et enchaînent des actions à travers plusieurs systèmes – souvent sans surveillance humaine directe. Ce comportement crée des défis d’identité et d’accès qui sont fondamentalement différents de ceux des logiciels traditionnels.

Le traitement des agents IA comme des identités numériques de premier plan est la seule façon de résoudre ce problème correctement. Si les organisations les traitent comme un simple processus ou un compte de service, elles perdent rapidement la visibilité et le contrôle – et c’est une recette pour une crise de sécurité.

De nombreuses entreprises sont enthousiastes à l’idée de l’IA agente mais restent bloquées à l’étape de l’expérimentation. D’après ce que vous observez dans les déploiements réels, quels sont les écarts les plus courants en matière d’identité et de gouvernance qui empêchent les organisations de mettre à l’échelle les agents en toute sécurité ?

La plupart des expérimentations ont lieu dans des environnements de test isolés qui ignorent ce qui se passe à grande échelle. Lors des premiers essais, les équipes accordent souvent des clés API étendues, des informations d’identification partagées ou des autorisations cloud générales pour simplement lancer les choses.

Cette approche s’effondre dès que les agents sont déployés au-delà des essais. En effet, les équipes de sécurité ne peuvent pas voir quelles données un agent a accédées, ses actions ou s’il a dépassé son périmètre prévu ; que ce soit accidentellement ou de manière malveillante. Ces angles morts rendent impossible la gouvernance sécurisée des agents, ce qui explique pourquoi de nombreuses organisations peinent à aller au-delà des essais.

Vous avez soutenu que des garde-fous stricts sont essentiels pour l’IA agente. Quelle est la bonne conception d’identité pour les agents IA dans la pratique, et où les entreprises se trompent-elles généralement ?

Une bonne conception d’identité commence par le principe du moindre privilège et des autorisations liées à une intention explicite. Chaque agent IA devrait avoir sa propre identité, des autorisations étroitement définies et des relations de confiance clairement définies (règles explicites pour les systèmes avec lesquels il est autorisé à interagir). Fondamentalement, l’accès devrait être lié à un objectif, limité dans le temps et facile à révoquer.

Les entreprises se trompent en réutilisant des comptes de service existants ou en supposant que les agents internes sont sûrs par défaut. Cette hypothèse ne tient pas face aux menaces réelles. Les acteurs malveillants cherchent activement ces points faibles, et les agents IA augmentent considérablement la surface d’attaque potentielle lorsque la conception d’identité est laxiste.

Curity a longtemps travaillé avec des normes comme OAuth et OpenID Connect. Quelle est l’importance des normes d’identité ouvertes pour rendre l’IA agente interopérable et sécurisée à travers des environnements d’entreprise complexes ?

Les normes ouvertes sont absolument critiques. Les entreprises exécutent déjà des tissus d’identité complexes qui s’étendent sur les plateformes cloud, les services SaaS et les API internes. L’IA agente ne fait qu’ajouter de la 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é comme n’importe quelle autre charge de travail. C’est la seule approche qui peut faciliter une mise à l’échelle sécurisée à travers de véritables environnements d’entreprise.

Les identités non humaines deviennent plus courantes, des comptes de service aux identités de machine. Qu’est-ce qui rend les agents IA fondamentalement différents des identités non humaines précédentes du point de vue de la sécurité ?

La différence clé entre les agents IA modernes et les anciennes identités non humaines (INH) est l’autonomie. Un compte de service traditionnel fait exactement ce que son code lui indique, strictement lié à sa tâche. Un agent IA interprète les instructions, adapte son comportement et prend des actions qui n’ont jamais été explicitement scriptées – tout cela augmente le danger potentiel s’il n’y a pas de garde-fous appropriés.

Une petite erreur d’identité ou d’accès peut rapidement se transformer en catastrophe, car un agent peut agir à grande vitesse et à travers plusieurs systèmes. Du point de vue de la sécurité, cela présente un risque majeur.

Combien les traces d’audit et la journalisation basée sur l’identité sont-elles importantes pour la gouvernance de l’IA agente, en particulier dans les industries réglementées ?

Les traces d’audit ne devraient pas être « agréables à avoir ». Elles doivent être intégrées dès le départ. Dans les environnements réglementés, les organisations sont censées répondre à des questions simples mais critiques : qu’a accédé cet agent, quand est-ce arrivé et qui l’a autorisé ?

La journalisation basée sur l’identité est le seul moyen fiable d’obtenir ce niveau de responsabilité. Elle joue également un rôle clé dans la réponse aux incidents. Sans un contexte d’identité clair, il est presque impossible de savoir si un problème provenait d’un agent malveillant, d’une identité compromise ou simplement d’une invite incorrecte.

Quels risques réels voyez-vous émerger lorsque les organisations déployent des agents IA surprivilegiés ou mal surveillés en production ?

Un risque courant est l’agrégation silencieuse de données. Un agent surprivilegié peut extraire des informations sensibles de plusieurs systèmes (enregistrements de clients, documents internes, journaux) et exposer ces données via des invites, des résumés ou des intégrations externes.

Un autre risque est que les agents ayant un accès administratif effectuent des changements importants à grande vitesse, causant beaucoup plus de dégâts qu’un humain ne pourrait le faire en un court laps de temps. Cela peut inclure la modification de ressources cloud, la désactivation de contrôles de sécurité ou le déclenchement de workflows automatisés sans surveillance.

Ces incidents peuvent être malveillants, mais ils n’ont pas à l’être. Un agent surprivilegié ou mal surveillé pourrait simplement fonctionner sur des hypothèses obsolètes ou incorrectes, amplifiant les erreurs à travers plusieurs systèmes avant que quiconque ne s’en aperçoive.

Mais, du point de vue d’un attaquant, une identité d’agent compromise est extrêmement précieuse. Elle permet le mouvement latéral à travers les API et les services, souvent avec un niveau d’accès que aucun utilisateur humain n’aurait jamais. Sans des contrôles d’identité solides et une surveillance, les organisations découvrent souvent ces défaillances après que des dommages réels aient été causés.

Pour les entreprises qui passent des essais à de véritables déploiements d’agents IA, quels sont les décisions d’identité et d’accès qui devraient être prises tôt pour éviter des réconceptions coûteuses plus tard ?

Les organisations devraient décider tôt comment les agents sont dotés d’identités, comment les autorisations sont approuvées et comment l’accès est examiné au fil du temps, en définissant les limites d’identité dès le départ.

Intégrer des contrôles d’identité de manière rétroactive est presque toujours problématique. Les agents sont souvent profondément intégrés dans les flux de travail en utilisant des informations d’identification partagées ou des rôles étendus, donc restreindre l’accès après coup brise les hypothèses sur lesquelles le système repose. Cela fait finalement échouer les flux de travail et mine la confiance dans la technologie. Il est beaucoup moins coûteux, et surtout beaucoup plus sûr, de concevoir des identités, des étendues et des limites d’accès appropriées dès le début.

À quel endroit l’intégration d’identité devient-elle le plus souvent un goulet d’étranglement lors du déploiement de l’IA agente, et quels sont les meilleures pratiques pour réduire les frictions ?

La gestion des identités peut devenir un goulet d’étranglement, mais seulement lorsqu’elle est traitée comme une après-pensée. Les équipes se concentrent d’abord sur la construction de capacités d’agent impressionnantes pour ensuite réaliser qu’elles doivent être intégrées avec les systèmes IAM, les passerelles API et les plateformes de journalisation pour être vraiment sécurisées.

La meilleure approche est de commencer par une compréhension claire et une mise en œuvre appropriée des plateformes d’identité, puis de concevoir les agents pour s’intégrer dans celles-ci. Les organisations devraient réutiliser les normes et les infrastructures existantes plutôt que de les contourner ; couper cet angle va inévitablement causer des problèmes plus tard. Lorsque l’identité est intégrée dès le début, elle accélère le déploiement au lieu de le ralentir.

Pour les dirigeants de la sécurité et de l’ingénierie qui veulent adopter l’IA agente mais sont préoccupés par la gouvernance et les risques, quels conseils leur donneriez-vous alors qu’ils planifient leur feuille de route ?

Ralentissez juste assez pour bien poser les fondations. Les agents IA doivent être traités comme des identités et vous devez appliquer la même gouvernance que vous attendez des humains, et insister sur la visibilité dès le départ. Si une organisation fait cela, alors la mise à l’échelle de l’IA agente devient un exercice de sécurité, et non un saut de foi aveugle et risqué.

Merci pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter Curity.