Harold Byun, PDG de BlueRock – Série d’entretiens

Harold Byun, PDG de BlueRock, est un vétéran de l’exécutif de la technologie d’entreprise avec une expertise approfondie en cybersécurité, en plateformes SaaS, en sécurité cloud et en leadership de produits d’entreprise. Avant de devenir PDG en avril 2026, il a occupé le poste de directeur des produits de l’entreprise, où il a aidé à définir la direction de BlueRock autour de la sécurité et de l’observabilité de l’IA agente. Avant de rejoindre BlueRock, Byun a occupé des postes de direction chez AppOmni, ServiceNow, Skyhigh Networks, Symantec et Citrix après son acquisition de Zenprise. À travers ces rôles, il a construit une réputation pour aider les entreprises à sécuriser des environnements cloud et de données de plus en plus complexes, une expérience qui s’aligne maintenant directement sur les défis de sécurité émergents entourant les agents autonomes et les écosystèmes du Protocole de contexte de modèle (MCP).

BlueRock se concentre sur la sécurisation de la couche d’exécution des systèmes d’IA agente, un domaine devenant de plus en plus critique à mesure que les entreprises déployent des agents d’IA autonomes capables d’interagir avec des outils, des API, des bases de code et des données d’entreprise sensibles. L’entreprise développe des technologies de sécurité et d’observabilité conçues pour surveiller, mettre en sandbox et faire respecter les limites de comportement des agents d’IA, en particulier dans les environnements basés sur MCP. La plateforme de BlueRock met l’accent sur la visibilité et la protection de la couche d’exécution au lieu de s’appuyer uniquement sur les mesures de sécurité au niveau de la invite, reflétant un déplacement plus large de l’industrie vers la sécurisation de la façon dont les agents d’IA agissent, et non seulement de ce qu’ils disent. À mesure que les organisations passent de l’expérimentation de l’IA à des flux de travail autonomes en production, des entreprises comme BlueRock se positionnent au centre de ce qui pourrait devenir une nouvelle catégorie majeure dans la cybersécurité d’entreprise.

Vous avez passé des années dans le cloud, le SaaS, la prévention des pertes de données (DLP) et la sécurité d’entreprise dans des entreprises comme AppOmni, Symantec, ServiceNow et Skyhigh Networks. Qu’est-ce qui vous a convaincu que la sécurité d’exécution pour les agents d’IA allait devenir la prochaine grande catégorie de sécurité ?

Ce qui est devenu évident pour moi, c’est que l’IA change où se produisent réellement les risques opérationnels et la complexité. Dans les logiciels traditionnels, la plupart du comportement est défini avant le déploiement. Dans les systèmes agents, le comportement émerge de plus en plus pendant l’exécution à travers les invites, le contexte, les outils, les API, les serveurs MCP et les interactions en aval.

Cela crée un modèle opérationnel très différent. Une fois que les agents peuvent prendre des décisions dynamiques et effectuer des actions à travers les systèmes, les organisations perdent la visibilité claire et la compréhension opérationnelle sur lesquelles elles comptaient depuis des années.

J’ai vu des changements de plateforme similaires auparavant dans la sécurité cloud et SaaS, où l’infrastructure évoluait plus vite que les systèmes utilisés pour la gérer. L’IA crée un autre de ces moments. Le défi à long terme n’est pas seulement la sécurité du modèle. C’est permettre aux organisations de faire fonctionner des systèmes agents à l’échelle de manière sécurisée.

La catégorie qui compte finalement est celle qui aide les organisations à comprendre ce que les agents font réellement en production et qui leur donne la confiance de faire évoluer les opérations natives d’IA de manière responsable.

BlueRock parle du « fossé d’exécution agente », où les organisations perdent la visibilité une fois que les agents commencent à agir de manière autonome au moment de l’exécution. Pourquoi les outils de sécurité et d’observabilité traditionnels échouent-ils dans ces environnements ?

Les outils de sécurité et d’observabilité traditionnels ont été conçus pour des systèmes déterministes avec des chemins d’exécution relativement prévisibles. Ils supposent que les développeurs connaissent en grande partie le comportement des applications avant qu’elles ne s’exécutent.

Les systèmes agents brisent cette hypothèse.

Les agents peuvent découvrir dynamiquement des outils, invoquer des serveurs MCP, chaîner des flux de travail, interagir avec des API et prendre des décisions en temps réel. Le chemin d’exécution émerge souvent pendant l’exécution.

La plupart des outils existants capturent des fragments comme des journaux, des traces, des données de télémétrie ou des sorties de modèle. Mais les organisations ont de plus en plus besoin d’une compréhension causale de l’ensemble du chemin d’exécution : pourquoi un agent a sélectionné un outil, quel contexte a influencé la décision, quels systèmes en aval ont été touchés et quelles actions se sont produites en conséquence.

C’est le fossé d’exécution agente. L’exécution est devenue dynamique, mais les modèles de visibilité et de contrôle n’ont pas évolué en parallèle.

Un nombre croissant d’entreprises expérimente des architectures basées sur le Protocole de contexte de modèle (MCP) et des flux de travail d’IA autonomes. Quels sont les plus grands malentendus sur la sécurité que les organisations ont encore sur les serveurs MCP et les systèmes agents ?

MCP devient rapidement une infrastructure fondamentale pour la façon dont les agents d’IA découvrent, se connectent et interagissent avec des outils, des systèmes et des données d’entreprise.

Ce qui rend MCP important, c’est qu’il réduit considérablement les frictions entre les systèmes d’IA et les environnements opérationnels. Il augmente la vitesse de développement des développeurs et débloque des flux de travail puissants, mais il élargit également massivement le nombre de chemins d’exécution que les agents peuvent prendre à travers les systèmes d’entreprise.

Dans de nombreux cas, les organisations peuvent déjà avoir des outils d’IA qui interagissent avec des services connectés à MCP sans comprendre pleinement l’exposition opérationnelle en aval qui est créée.

Un autre malentendu est que contrôler les invites ou les modèles est suffisant. Dans la pratique, les risques plus importants émergent après que le modèle ait pris une décision. Une fois que les agents peuvent invoquer des outils, exécuter des flux de travail, récupérer des données sensibles ou interagir avec l’infrastructure, le défi se déplace vers le comportement d’exécution et le contrôle d’exécution.

La surface opérationnelle est en train de croître beaucoup plus vite que la plupart des modèles de gouvernance et d’observabilité n’ont été conçus pour gérer.

La recherche de BlueRock a révélé de graves vulnérabilités sur les serveurs MCP publics, notamment des vulnérabilités de forgery de requête côté serveur (SSRF) et d’injection de commande. Les entreprises sous-estiment-elles à quel point rapidement les écosystèmes MCP pourraient devenir une nouvelle surface d’attaque de la chaîne d’approvisionnement logiciel ?

Oui. Je pense que l’industrie est encore en train de comprendre à quel point l’écosystème MCP pourrait devenir important d’un point de vue de chaîne d’approvisionnement et de confiance opérationnelle. Par exemple, plus de 36 % des 11 000 serveurs MCP que nous avons analysés ont des vulnérabilités SSRF non bornées. La plupart des gens dans l’industrie ne comprennent pas que cela ouvre effectivement leur réseau entier du point de vue de l’accès aux données. Cela ne serait jamais autorisé sciemment dans presque tous les environnements d’entreprise du monde d’aujourd’hui.

Historiquement, les organisations se sont inquiétées des bibliothèques, des conteneurs et des dépendances open source parce que ces composants faisaient partie de la pile logicielle avant le déploiement. MCP change ce modèle. Les agents peuvent maintenant découvrir et interagir dynamiquement avec des outils et des services externes pendant l’exécution elle-même. Et, dans de nombreux cas, les développeurs et l’entreprise ont simplement avancé et déployé MCP sans comprendre ou évaluer les risques.

Cela crée un problème de confiance très différent.

Les organisations ne gèrent plus seulement des dépendances statiques. Elles gèrent de plus en plus des dépendances d’exécution dynamiques qui émergent pendant que les systèmes sont en cours d’exécution. Les agents peuvent invoquer des outils, chaîner des flux de travail ou accéder à des systèmes en aval de manière que les opérateurs ne prévoient pas ou n’observent pas pleinement.

Notre recherche sur les vulnérabilités SSRF, l’injection de commande et d’autres vulnérabilités reflète à quel point certaines parties de l’écosystème sont encore immatures. Mais le problème plus large est plus vaste que les vulnérabilités individuelles. À mesure que l’adoption de MCP s’accélère, les organisations auront besoin d’une visibilité beaucoup plus approfondie sur la façon dont les systèmes autonomes interagissent avec les services externes pendant l’exécution.

Votre plateforme met l’accent sur l’« observabilité agente » plutôt que simplement sur la surveillance des invites ou des sorties. Qu’est-ce que la visibilité d’exécution significative ressemble-t-elle une fois que les agents prennent des décisions dynamiques à travers les outils, les API et l’infrastructure ?

La visibilité d’exécution significative nécessite de comprendre l’ensemble du chemin d’exécution, et non seulement des événements isolés.

Les organisations doivent voir comment une décision de modèle se transforme en actions à travers les outils, les serveurs MCP, les API, l’infrastructure et les systèmes en aval. Cela signifie comprendre pourquoi un agent a sélectionné un outil, quel contexte a influencé la décision, quels privilèges ont été utilisés, quelles actions ont été déclenchées et quel résultat opérationnel a été créé.

Cela devient particulièrement important à mesure que les agents opèrent dans des environnements distribués et éphémères où la surveillance traditionnelle se fragmente rapidement.

La surveillance des invites seule est insuffisante car les invites n’expliquent pas le comportement opérationnel. Les sorties ne sont pas suffisantes car elles ne révèlent pas quels systèmes ont été impactés en aval.

L’avenir de l’observabilité dans les systèmes agents est conscient de l’exécution. Il s’agit de comprendre le comportement de la décision à l’action au résultat en temps réel.

Le moteur de confiance de BlueRock semble attacher des données d’identité, de confiance et de capacité directement aux flux d’exécution en temps réel. Quelle sera l’importance de la confiance contextuelle à mesure que les agents d’IA interagiront de plus en plus avec des outils et des systèmes externes de manière autonome ?

La confiance contextuelle devient fondamentale dans les systèmes agents car les agents prennent des décisions dynamiquement au moment de l’exécution.

Les systèmes traditionnels reposaient lourdement sur des hypothèses de confiance statiques. Mais les agents opèrent de plus en plus dans des contextes changeants, des outils externes, des API, des serveurs MCP, des identités et des privilèges.

Les organisations doivent évaluer la confiance de manière continue pendant l’exécution elle-même. Pas seulement si un modèle est sécurisé, mais si l’outil invoqué est de confiance, si l’action demandée correspond au comportement attendu et quel risque opérationnel l’action introduit.

C’est pourquoi nous croyons que le contexte de confiance devient une infrastructure critique pour la prochaine génération de systèmes d’IA.

Nous voyons une adoption rapide d’agents de codage d’IA et de flux de travail de développement autonomes. Quels sont les risques les plus préoccupants lorsque les agents acquièrent la capacité de modifier l’infrastructure, de déployer du code ou d’interagir avec des systèmes de production sans examen humain ?

Le plus grand changement est que les organisations tentent de augmenter considérablement la vitesse de développement en permettant à beaucoup plus de personnes de construire avec l’IA, et non seulement les ingénieurs logiciels traditionnels.

Les agents de codage d’IA peuvent déjà générer du code, modifier l’infrastructure, interagir avec les pipelines CI/CD, invoquer des services cloud et accéder à des systèmes sensibles. L’avantage en termes de productivité est énorme car les entreprises peuvent désormais débloquer à la fois les développeurs expérimentés et une nouvelle génération de développeurs natifs d’IA et de citoyens.

Le défi est que la complexité opérationnelle augmente tout aussi rapidement. La préoccupation n’est pas seulement le comportement malveillant. C’est l’impact négatif qu’un agent peut avoir qui provoque des interruptions de service et affecte la disponibilité des données et de l’infrastructure pour une organisation. Ce type de comportement déréglé est similaire au problème de bucket public S3 d’il y a une décennie. Nous attendons que les agents se comportent. Nous attendons que des garde-fous et des contrôles soient mis en place. Mais il y a des chemins vers un comportement non intentionnel, des privilèges excessifs, des dépendances cachées, une utilisation non sécurisée d’outils ou des chemins d’exécution que personne n’a anticipés. Et cela entraînera davantage d’interruptions ou de déploiements sous-optimisés où les gens deviennent des simples boutons et où le ROI n’est pas pleinement réalisé.

Les organisations ont besoin d’une visibilité opérationnelle et de contrôles conscients de l’exécution qui suivent la charge de travail pour qu’elles puissent faire évoluer le développement d’IA de manière sécurisée sans ralentir l’innovation.

Beaucoup d’organisations pensent encore à la sécurité de l’IA principalement à travers le prisme de la sécurité du modèle et de l’injection d’invite. Pourquoi pensez-vous que l’industrie doit maintenant passer à la sécurisation des actions et des chemins d’exécution ?

La sécurité du modèle et l’injection d’invite sont absolument importantes, mais elles ne représentent qu’une partie du défi.

L’industrie passe de systèmes qui génèrent des réponses à des systèmes qui prennent des actions. Une fois que les agents peuvent invoquer des outils, modifier des systèmes, récupérer des données sensibles, exécuter des flux de travail ou interagir avec l’infrastructure, le risque opérationnel se déplace vers le comportement d’exécution lui-même.

Un modèle parfaitement aligné peut toujours créer un risque s’il invoque l’outil incorrect, accède au système incorrect ou déclenche des actions non intentionnelles en aval. C’est pourquoi sécuriser les invites seules est insuffisant. Et il y aura toujours des approches nouvelles pour contourner ces types de garde-fous d’invite. Cela sera un jeu constant de chat et de souris.

Les organisations doivent reconnaître que ces garde-fous seront contournés, et que l’impact négatif potentiel est le plus élevé plus tard dans le chemin d’exécution. À mesure que les agents prennent des décisions et effectuent des actions, les organisations ont de plus en plus besoin de visibilité et de contrôle sur l’ensemble du chemin d’exécution et sur l’impact opérationnel du comportement de l’agent en temps réel.

Certains chercheurs ont comparé l’adoption de MCP à donner aux systèmes d’IA un « port USB universel » dans l’infrastructure d’entreprise. Comment les entreprises devraient-elles équilibrer l’énorme avantage en termes de productivité des agents connectés avec les risques opérationnels qu’ils introduisent ?

L’avantage en termes de productivité est réel. MCP simplifie considérablement la façon dont les agents se connectent aux outils, aux systèmes et aux flux de travail, ce qui est une raison pour laquelle l’adoption s’accélère si rapidement.

Mais les organisations devraient éviter de penser à MCP uniquement comme une couche de connectivité. Il devient effectivement partie de la trame opérationnelle de l’entreprise.

L’équilibre vient de permettre aux développeurs et aux constructeurs d’IA de bouger rapidement tout en maintenant une visibilité et un contrôle conscients de l’exécution.

Cela signifie comprendre la sécurité de la mise en œuvre du serveur MCP lui-même, c’est pourquoi nous avons construit le registre mcp-trust.com. Et cela signifie comprendre quels serveurs MCP les agents interagissent, quels types d’outils ces serveurs exposent, quels privilèges sont accordés et comment les actions se propagent pendant l’exécution.

Les organisations qui réussiront seront celles qui construiront la confiance opérationnelle autour de l’exécution autonome.

En regardant vers l’avenir, à quoi ressemblera finalement une pile de sécurité d’IA d’entreprise mature dans un monde où les agents autonomes collaborent, prennent des décisions et exécutent des tâches à travers plusieurs systèmes en production ?

Je pense que la pile de sécurité d’IA d’entreprise mature deviendra beaucoup plus centrée sur l’exécution.

Les organisations auront toujours besoin de sécurité de modèle, d’identité, de protection de données et de sécurité d’infrastructure. Mais le déplacement plus large est que les entreprises auront besoin de systèmes opérationnels conçus pour les logiciels autonomes et non déterministes.

À mesure que les agents collaborent de plus en plus, prennent des décisions et effectuent des actions à travers les outils, l’infrastructure et les flux de travail commerciaux, les organisations auront besoin d’une visibilité continue sur la façon dont les systèmes d’IA se comportent réellement pendant l’exécution.

La pile future combinera l’observabilité, le contexte de confiance, la gouvernance opérationnelle, l’application de politiques d’exécution consciente, l’identité et la sécurité d’exécution en une couche opérationnelle unifiée pour les systèmes agents.

Les organisations qui réussiront seront celles qui pourront continuellement comprendre et exploiter l’exécution autonome sans ralentir l’innovation.

Merci pour cette grande interview. Les lecteurs qui souhaitent en savoir plus peuvent visiter BlueRock.