Entretiens
Sean Roche, directeur senior du marketing produit et de l’ingénierie de la valeur chez Obsidian Security — série d’entretiens

Sean Roche, Directeur senior du marketing de produits et de l’ingénierie de la valeur chez Obsidian Security, dirige des initiatives transversales axées sur la sécurité SaaS, la sécurité de l’IA et la stratégie de lancement sur le marché. Il a joué un rôle clé dans l’élaboration du premier cadre unifié de cas d’usage de l’entreprise, en alignant les ventes, le marketing et la réussite des clients sur des résultats commerciaux mesurables, tout en supervisant les lancements de solutions de sécurité pour l’IA générative et les agents IA. Avant d’arriver chez Obsidian Security, Roche a occupé des postes de direction dans des entreprises telles que Forter, Aviatrix et Okta, où il s’est spécialisé dans le conseil en valeur commerciale, la stratégie de tarification, l’ingénierie de la valeur client et l’analyse du retour sur investissement pour les dirigeants. Son expérience combine la cybersécurité, la stratégie de logiciels d’entreprise et la recherche financière, lui donnant une expérience approfondie dans la traduction des capacités techniques en impact commercial mesurable pour les clients d’entreprise.
Obsidian Security est une entreprise de cybersécurité axée sur la sécurisation des applications SaaS, des agents de l’IA, des identités et des intégrations d’entreprise dans les environnements cloud modernes. L’entreprise propose une plateforme unifiée conçue pour aider les organisations à détecter les menaces, à gérer la posture de sécurité SaaS, à gouverner l’accès aux données et à surveiller les activités à risque dans les applications critiques pour l’activité, telles que Microsoft 365, Salesforce (CRM ), Slack et d’autres services cloud. Ces dernières années, Obsidian a étendu ses activités à la sécurité des agents de l’IA, aidant les entreprises à acquérir une visibilité sur la façon dont les systèmes de l’IA autonomes interagissent avec les plates-formes SaaS, les données et les flux de travail en temps réel. Fondée par des dirigeants de la sécurité ayant de l’expérience dans des entreprises telles que CrowdStrike (CRWD ), Okta, Cylance et Carbon Black, Obsidian se positionne comme une plateforme de sécurité SaaS et de l’IA complète conçue pour répondre à la complexité croissante des environnements cloud et des systèmes d’agents IA.
Vous avez construit votre carrière à l’intersection de la valeur commerciale, de la stratégie de risque et de la sécurité SaaS, et vous dirigez maintenant l’ingénierie de la valeur et le marketing de produits chez Obsidian Security. Qu’est-ce qui vous a attiré vers la sécurité des écosystèmes SaaS alimentés par l’IA, et comment l’approche d’Obsidian diffère-t-elle lorsqu’il s’agit de technologies émergentes d’agents comme OpenClaws ?
Tout au long de ma carrière, le plus grand écart a toujours été ce que la sécurité ne peut pas voir, car c’est là que se produisent les failles de sécurité. Nous avons vu cela dans des incidents où des systèmes non connectés ou non gérés ont créé une exposition que les contrôles traditionnels n’ont pas pu détecter. Et j’ai vu la même dynamique de première main avec les passerelles modernes que les gens utilisent pour se connecter aux grandes plateformes, ou des connexions qui se trouvaient en dehors de la visibilité normale de la sécurité, et dans certains cas même après que l’équipe IT ait pensé les avoir désactivées. Ces expériences m’ont montré à quel point le risque réside dans les interstices entre les systèmes, et non seulement à l’intérieur des systèmes que nous pensons avoir sécurisés.
Cette réalité est en train de passer de l’IT fantôme à l’IA fantôme, où de nouveaux outils et des flux de travail alimentés par des agents peuvent apparaître et se propager plus rapidement que les stratégies de gouvernance ne peuvent suivre. De nombreuses approches de sécurité répondent en essayant de centraliser et de contrôler tout dans un seul plan de contrôle. Mais ce modèle se brise dans les environnements distribués, en particulier lorsque des données et des activités critiques se produisent à l’intérieur d’applications tierces que vous ne possédez pas et ne pouvez pas contrôler entièrement.
C’est ce qui m’a attiré vers la sécurité des écosystèmes SaaS alimentés par l’IA, et c’est aussi pourquoi l’approche d’Obsidian est si convaincante. Le nombre de failles de sécurité SaaS a augmenté de 300 %, et pourtant, la plupart des organisations manquent encore de visibilité sur la façon dont ces applications sont utilisées. C’est l’écart que nous nous efforçons de combler, afin que vous puissiez comprendre ce qui se passe réellement au sein de l’entreprise et où se trouve l’exposition. À mesure que les technologies agentiques comme OpenClaws mûrissent, cette approche devient encore plus importante, car le risque n’est pas seulement de savoir si un agent a accès à certaines données, mais à quoi il peut accéder et à quelle vitesse il peut agir.
Les systèmes d’IA agentique tels que OpenClaws attirent une attention significative après la conférence NVIDIA (NVDA ) GTC. De votre point de vue, qu’est-ce qui les différencie fondamentalement des outils de l’IA précédents en termes de risque de sécurité ?
Comprendre ce que sont les identités non humaines et comment les sécuriser est devenu critique pour les équipes de sécurité, car 68 % des incidents de sécurité IT impliquent des identités de machine et la moitié des entreprises interrogées ont subi une faille de sécurité due à des identités non humaines non gérées. L’industrie de la sécurité s’est principalement concentrée sur la gestion de la posture de sécurité SaaS et la gouvernance des identités humaines, tandis que les identités non humaines ont proliféré en arrière-plan. Maintenant, à mesure que les organisations déploient des agents de l’IA avec des privilèges d’administration à grande échelle, le déficit de gouvernance est devenu critique.
Les systèmes d’agents comme OpenClaws montrent à la fois la promesse et le risque d’une véritable IA agentique. C’est l’une des premières fois que nous voyons de l’IA libérée dans la nature avec une véritable autonomie, opérant au-delà d’un flux de travail étroit et supervisé.
Le risque de sécurité change rapidement lorsque ces capacités deviennent plus accessibles, en abaissant la barrière pour que les non-experts interagissent et exploitent potentiellement ces systèmes critiques. Les gens connectent déjà des agents de l’IA à leurs environnements SaaS et élargissent le paysage des menaces de diverses manières, notamment via des clés API, des intégrations natives et des applications tierces. Cependant, chaque nouveau flux de travail alimenté par un agent multiplie le nombre de chemins d’accès.
La faille de sécurité récente de Vercel illustre cette menace croissante qui fait face aux équipes de sécurité. Lorsque vous autorisez une application tierce, vous faites implicitement confiance à tous ceux qui touchent l’infrastructure de cette application, leur fournisseur de services cloud, leurs développeurs, leurs propres services connectés. La plupart des organisations ne savent pas ce à quoi elles ont réellement consenti, et ce problème est amplifié par l’utilisation généralisée de l’IA agentique.
De nombreux agents de l’IA opèrent sans véritable cadre technique pour maîtriser leurs actions. Lorsque vous ne disposez pas de traces permettant d’identifier l’activité des agents ou que vous avez des garde-fous faibles, il est difficile de savoir ce que l’agent a fait, ce qu’il a touché et ce qui a changé avant une analyse a posteriori. Cette combinaison est ce qui rend le profil de risque fondamentalement différent des outils de l’IA précédents.
Vous avez décrit OpenClaws comme pouvant ouvrir de nouvelles surfaces d’attaque en raison de leurs permissions étendues et de leur autonomie. Pouvez-vous nous présenter un scénario réel dans lequel ce risque devient tangible pour une entreprise ?
Les risques tels que ceux posés par OpenClaws deviennent tangibles dès l’instant où ces agents passent des tâches isolées et sont installés dans des environnements de production réels, ce qui est déjà en train de se produire.
La plupart des organisations se concentrent sur le fait de s’assurer que la bonne personne peut accéder à un agent et que l’agent se comporte comme prévu. Cependant, peu d’organisations réfléchissent à ce qui se passe lorsque l’agent commence à interagir avec un autre agent.
C’est là que la surface d’attaque s’étend de manière spectaculaire. Les sorties d’un système, comme des messages Slack ou des tickets Jira, déclenchent des actions dans un autre système. Les dirigeants perdent le contrôle des interactions et ne peuvent pas maintenir une visibilité et des traces d’audit cohérentes. Ces agents sont également en train de se connecter en parallèle aux API SaaS, dont beaucoup manquent encore de passerelles ou de protections de sécurité appropriées.
L’entreprise moyenne exécute déjà des centaines d’agents, un nombre qui a augmenté de près de 100x au cours de la dernière année. Lorsque les équipes regardent réellement, 38 % présentent des facteurs de risque moyen, élevé ou critique, la plupart n’ayant pas de propriétaire documenté, plusieurs ayant été créés par des comptes qui n’existent plus, avec des connecteurs actifs vers des systèmes de production et aucun historique d’exécution.
La fermeture de cet écart nécessite une visibilité approfondie à l’intérieur des applications elles-mêmes pour mieux comprendre ce que ces informations d’identification peuvent réellement faire, dans chaque système, par rapport à chaque ensemble de données, pour toute personne ou tout système susceptible de les utiliser pour déclencher une action. Sans ce contexte approprié, vous opérez avec seulement la moitié de l’image. Les dirigeants doivent également modifier leurs stratégies pour passer de la détection à l’application des contrôles pendant l’exécution pour bloquer les actions au moment de l’exécution, avant que l’action ne soit terminée, plutôt qu’après que le dommage soit déjà fait.
De nombreuses organisations pensent qu’elles ont déjà une sécurité SaaS adéquate en place. Où ces hypothèses se brisent-elles lorsque l’IA agentique entre en scène ?
De nombreuses organisations pensent qu’elles ont déjà « résolu » la sécurité SaaS, mais cette hypothèse est remise en question à mesure que l’adoption de l’IA agentique s’accélère. La sécurité SaaS est souvent traitée comme une case à cocher : le budget est approuvé, un outil est déployé et le problème est considéré comme réglé. En pratique, cependant, les API SaaS qui sous-tendent ces environnements n’ont jamais été pleinement maîtrisées, en grande partie parce qu’il y a vraiment une visibilité limitée de l’entreprise sur ce qui se passe au niveau de l’API et quels actifs SaaS parlent les uns aux autres.
Cela crée un angle mort structurel, où les entreprises peuvent sécuriser les identités et les points de terminaison, mais elles manquent souvent d’une vue claire sur la façon dont les données SaaS sont consultées et font l’objet d’actions une fois que les API sont en jeu. Par conséquent, de nombreuses organisations opèrent encore sur Internet ouvert directement dans des systèmes critiques sans pleinement comprendre l’étendue ou le comportement des interactions basées sur les API qui se produisent en dessous.
L’IA agentique expose désormais cet écart, créant des défis plus rapides que les équipes ne peuvent les résoudre, et en le faisant, devenant un catalyseur pour la conversation sur les API.
Comment les entreprises devraient-elles repenser la gouvernance lorsqu’elles traitent avec des agents de l’IA autonomes qui peuvent accéder, déplacer et agir sur des données à travers plusieurs systèmes ?
Aucun dirigeant ne veut ralentir l’adoption de l’IA en ce moment, en particulier à mesure que les pressions augmentent pour aller plus vite ou montrer un rendement mesurable où même la consommation de jetons est utilisée dans les évaluations. Dans de nombreux cas, les mandats de l’IA proviennent directement du sommet, avec des PDG qui rendent compte des progrès aux conseils d’administration ou même aux parties prenantes publiques, ce qui intensifie encore la pression pour adopter à grande vitesse. Dans cet environnement, où « l’IA à tout prix » devient la posture par défaut, les erreurs de configuration et les droits d’accès excessifs ne peuvent pas être réellement corrigés suffisamment rapidement par les cycles de gouvernance traditionnels.
Le problème est que les systèmes d’agents n’attendent pas la remédiation. Ils peuvent découvrir des systèmes, enchaîner des actions et exécuter des flux de travail à travers plusieurs applications SaaS en quelques secondes, souvent en terminant dix étapes ou plus avant qu’une personne puisse même s’en apercevoir, et encore moins intervenir.
C’est pourquoi la gouvernance n’est plus seulement une question de détecter les problèmes plus tôt dans le cycle de développement, mais de plus en plus de contrôle au moment où l’agent agit réellement. Les dirigeants de la sécurité ne peuvent pas gouverner efficacement les agents si le contrôle n’a lieu qu’après une utilisation abusive.
Dans un monde où les agents prennent des décisions autonomes à travers les systèmes SaaS, la seule approche viable pour protéger contre ces menaces de l’IA agentique est la gouvernance en temps réel. Cette approche nécessite de passer au-delà de la détection post-exécution pour détecter et bloquer l’escalade des privilèges, l’accès excessif aux données et les violations des politiques avant qu’elles ne puissent avoir un impact sur l’organisation. Ces contrôles doivent être alignés sur les normes OWASP et les meilleures pratiques de l’industrie, en garantissant que les agents opèrent dans des limites explicites et exécutoires – afin que les équipes puissent suivre le rythme de l’adoption de l’IA agentique sans compromettre l’innovation.
Sur le plan technique, quels sont les points de vulnérabilité les plus négligés introduits par l’IA agentique dans les environnements SaaS ?
Lorsqu’une organisation adopte un nouvel outil SaaS, elle découvre de plus en plus souvent que la fonctionnalité de l’IA est ajoutée ou activée par défaut. Le problème est que ces capacités ne viennent souvent pas avec le même niveau de contrôles de configuration ou de traçabilité sur lesquels les équipes de sécurité comptent pour les fonctionnalités SaaS traditionnelles. Par conséquent, lorsqu’une action est prise, il est difficile de distinguer si elle a été initiée par un utilisateur humain ou par un agent autonome. Dans de nombreux cas, les entreprises n’ont pas la possibilité de désactiver la fonctionnalité de l’IA, car ces capacités sont intégrées dans l’application SaaS elle-même.
Cette ambiguïté crée un grand angle mort pour la sécurité et la gouvernance. Si une fonctionnalité de l’IA intégrée prend des décisions au nom d’un utilisateur, les organisations n’ont souvent aucun moyen de tracer l’intention, de comprendre la logique de décision ou même de confirmer ce qui a déclenché une action spécifique.
Le risque devient encore plus prononcé lorsque l’on considère la chaîne d’approvisionnement de l’IA à l’intérieur du SaaS. Ces capacités de l’IA intégrées dépendent souvent de modèles en amont, de services et d’intégrations tierces. Si une partie de cette chaîne est compromise, dégradée ou manipulée, l’IA à l’intérieur de l’application SaaS peut transformer des applications d’affaires de confiance en participants actifs à un chemin d’attaque.
La couche de l’IA à l’intérieur du SaaS est devenue sa propre chaîne d’approvisionnement, et elle introduit une nouvelle classe de risque qui doit être surveillée et gérée de façon distincte. Sans visibilité sur la façon dont ces systèmes de l’IA intégrés se comportent et sur les données dont ils dépendent, les organisations sont aveugles à une partie croissante de leur surface d’attaque SaaS.
Vous avez travaillé de manière approfondie sur la quantification de la valeur commerciale et du risque. Comment les organisations devraient-elles mesurer l’exposition financière et réputationnelle liée aux agents de l’IA non sécurisés ?
Si un agent de l’IA est mal utilisé ou provoque une faille de sécurité, l’impact immédiat n’est pas seulement l’incident lui-même, mais la réponse organisationnelle qui suit. Cet événement ralentira le rythme auquel l’entreprise est prête à adopter et à mettre à l’échelle l’IA, car les dirigeants deviennent plus prudents. Une fois que la confiance est brisée, il devient beaucoup plus difficile de redémarrer le moteur d’innovation qui a généré de la valeur à l’origine.
Cette dynamique s’étend au-delà des équipes internes aux parties prenantes externes. Les conseils d’administration, les clients et les actionnaires s’attendent tous à un déploiement responsable, et toute faille liée aux agents autonomes devient rapidement une question de responsabilité fiduciaire et de réputation. Lorsque la sécurité n’est pas intégrée dès la conception, les organisations sont contraintes à des conversations réactives sur le contrôle et la sécurité, ce qui ralentit inévitablement la prise de décision dans l’ensemble de l’entreprise.
Il y a également une exposition financière plus structurelle qui est souvent négligée. À mesure que le rayon d’impact perçu des agents de l’IA augmente, les entreprises ont tendance à devenir plus conservatrices dans la façon dont elles allouent le capital. Dans certains cas, cela signifie retenir des fonds ou retarder les investissements pour se protéger contre les incidents potentiels.
Dans ce sens, la sécurisation des agents de l’IA devient moins un exercice de réduction du risque pur et plus une discussion sur les revenus et la croissance. Les organisations qui peuvent déployer l’IA avec confiance, en sachant que les agents sont gérés et contenus, seront en mesure d’aller plus vite, tandis que celles qui n’ont pas cette confiance ralentiront naturellement. En 2026, cette capacité à associer vitesse et confiance est en train de devenir un superpouvoir.
Il y a clairement une tension entre l’adoption rapide de l’IA et le déploiement responsable. Quelle stratégie équilibrée les entreprises devraient-elles adopter pour innover sans augmenter leur profil de risque ?
Actuellement, l’un des plus grands écarts entre l’adoption de l’IA et le déploiement responsable est la communication. De nombreuses entreprises utilisent activement l’IA dans les environnements SaaS, mais elles n’ont pas constamment de conversation claire et externe sur la façon dont elle est utilisée et quels sont les garde-fous en place. Ce manque de transparence peut en fait augmenter le risque, car il laisse les clients et les partenaires supposer le pire des cas plutôt que de comprendre les contrôles réels en place.
Une approche plus équilibrée traite l’utilisation responsable de l’IA comme faisant partie de la proposition de valeur, et non comme un simple exercice de conformité interne. Il y a une opportunité pour les entreprises d’être plus explicites sur la façon dont l’IA est gérée à l’intérieur de leurs environnements, y compris ce qu’elle peut et ne peut pas faire, et quels sont les garde-fous en place lorsqu’elle interagit avec des systèmes sensibles. Ce type de clarté favorise la confiance pour mettre à l’échelle l’IA en toute sécurité.
Les entreprises qui peuvent clairement articuler comment l’IA est utilisée à travers leurs environnements SaaS et démontrer qu’elle est contrôlée de manière structurée et observable seront en mesure d’innover plus rapidement sans augmenter le risque perçu.
Alors que de plus en plus d’entreprises expérimentent l’IA agentique, quelles sont les mesures immédiates que les équipes de sécurité devraient prendre aujourd’hui pour éviter de subir la prochaine intrusion qui fera les gros titres ?
L’IA agentique ne présente pas seulement une nouvelle classe de risque, mais elle accélère également ceux que les organisations ne peuvent pas encore voir. En fait, l’IA fantôme ajoute un montant supplémentaire de $670 000 au coût moyen d’une faille de sécurité. Cependant, le problème de base est la visibilité. Lorsque les organisations ne savent pas où l’IA est utilisée ou comment elle interagit avec les systèmes, cela prend plus de temps pour détecter et contenir les incidents, augmentant directement l’impact financier et réglementaire.
La première étape immédiate consiste à établir la visibilité à l’échelle de l’entreprise. Les équipes de sécurité ont besoin d’une image claire de l’utilisation de l’IA, tant approuvée que non approuvée, et pas seulement au niveau de l’application, mais également à travers les flux de travail où l’IA est activement en train de prendre ou d’influencer des décisions.
Une fois que la visibilité existe, l’accent est mis sur la traduction de celle-ci en politique exécutoire et l’intégration dans les systèmes où le travail se déroule réellement. Cela signifie s’aligner avec l’entreprise sur la façon dont l’IA devrait être utilisée, puis passer de la documentation aux contrôles techniques qui opèrent sur les points de terminaison, les plates-formes SaaS et les systèmes d’agents. Plus tôt ces contrôles sont introduits dans le chemin d’exécution, plus faible est la probabilité d’incidents coûteux et difficiles à contenir qui émergent de l’IA fantôme et des agents autonomes.
En regardant vers l’avenir, comment voyez-vous l’évolution du paysage de la sécurité à mesure que les systèmes d’IA agentique s’enracinent davantage dans les infrastructures d’entreprise ?
Les organisations auront besoin d’une sécurité native de l’IA pour répondre aux menaces de l’IA. Ces systèmes doivent fonctionner à la vitesse des machines, en redéfinissant fondamentalement les opérations de sécurité. Les humains resteront dans la boucle, mais passeront à une surveillance stratégique, en appliquant la compréhension du contexte et le jugement qui manquent encore à l’IA.
Ce changement modifie également la façon dont les équipes de sécurité sont structurées. Les équipes ne diminueront peut-être pas, mais leur portée s’étendra considérablement, un seul professionnel de la sécurité étant responsable d’une surface d’attaque beaucoup plus grande grâce à l’automatisation et à l’outillage de l’IA.
De plus, dans les environnements avec des agents, la surveillance et la détection ne suffisent pas. Les organisations devront mettre en œuvre de véritables mécanismes d’application des contrôles. Cela signifie construire des systèmes qui agissent comme des commutateurs : la capacité de mettre des capacités en marche ou à l’arrêt, de restreindre le comportement en temps réel et d’isoler les systèmes qui se comportent mal ou pourraient compromettre l’entreprise dans son ensemble. Le risque de la chaîne d’approvisionnement de l’IA est simplement trop grand pour ne pas avoir des mécanismes d’arrêt d’urgence intégrés dans l’architecture.
En regardant vers l’avenir, l’IA continuera d’accélérer potentiellement au-delà de la vitesse et des capacités humaines. Mais la conversation ne peut pas se concentrer uniquement sur le risque ; elle doit également inclure les opportunités. C’est comme élever des enfants : l’IA grandira et commettra des erreurs, mais elle a également la capacité de nous dépasser. Les gagnants seront ceux qui adopteront l’IA à grande échelle tout en construisant les systèmes de contrôle nécessaires pour la déployer en toute sécurité et avec confiance.
Je vous remercie pour cet excellent entretien, les lecteurs qui souhaitent en savoir plus devraient visiter Obsidian Security.












