Sean Blanchfield, Co-Fondateur et PDG de Jentic – Série d’entretiens

Sean Blanchfield, Co-Fondateur et PDG de Jentic, est un entrepreneur technologique sériel avec des décennies d’expérience dans la construction de sociétés de logiciels et d’infrastructures à grande échelle. Basé à Dublin, il dirige actuellement Jentic tout en siégeant au Conseil consultatif sur l’IA d’Irlande, conseillant le gouvernement sur la politique d’intelligence artificielle. Plus tôt dans sa carrière, il a co-fondé DemonWare, une plate-forme de services en ligne à grande échelle pour les principaux éditeurs de jeux vidéo qui a été acquise par Activision Blizzard (ATVI ) , et PageFair, une startup financée par des capitaux de risque axée sur l’analyse des bloqueurs de publicités qui a été acquise par Blockthrough. Il a également fondé ou dirigé plusieurs startups et continue de soutenir l’écosystème des startups irlandaises à travers des initiatives telles que Techpreneurs.

Jentic développe une couche d’intégration universelle conçue pour aider les agents d’IA à interagir de manière sécurisée avec les systèmes et les API d’entreprise. La plate-forme permet aux organisations de connecter les modèles d’IA avec les outils internes, les services externes et les flux de travail opérationnels tout en maintenant la gouvernance, l’authentification et la surveillance. En transformant les API fragmentées en interfaces structurées que les agents d’IA peuvent utiliser de manière fiable, Jentic vise à aider les entreprises à déployer l’automatisation basée sur l’IA à grande échelle dans des environnements logiciels complexes.

Vous avez fondé et dirigé plusieurs sociétés de technologie, de DemonWare (acquise par Activision Blizzard) à PageFair et maintenant Jentic, et vous siégez également au Conseil consultatif sur l’IA d’Irlande. Qu’est-ce qui vous a amené à reconstruire à nouveau à la couche d’infrastructure avec Jentic, et quel fossé avez-vous vu dans l’écosystème émergent des agents d’IA que les autres manquaient ?

La troisième fois que vous remarquez un modèle, vous devez le prendre au sérieux. Chez DemonWare, tout le monde parlait du multijoueur en ligne – mais le problème difficile était l’infrastructure réseau sous-jacente. La même chose se passe avec les agents d’IA. Les modèles sont remarquables. Le goulet d’étranglement est la couche d’intégration – toujours a été. Les agents d’IA fonctionnent sur des API, et ces API ont été construites pour les humains : documentées pour les humains, sécurisées pour les humains et structurées pour les humains. Pointez un agent autonome sur cette infrastructure, et il se décompose rapidement. Les pilotes d’IA d’entreprise ne échouent pas parce que le modèle n’a pas compris la tâche ; ils échouent parce que l’agent n’a pas pu se connecter de manière fiable aux systèmes dont il avait besoin. L’IA générative offre une nouvelle façon de résoudre ce problème – en traitant l’intégration comme un problème de connaissance, et non comme un problème de codage. Cette idée m’a attiré.

Quand vous avez lancé Jentic en 2024, la sécurité des agents était-elle la thèse principale dès le premier jour, ou l’accent s’est-il affiné à mesure que vous observiez la façon dont les organisations déployaient réellement des agents autonomes en production ?

Le premier fil que j’ai tiré était les informations d’identification. J’ai imaginé des agents se multipliant, chacun ayant besoin d’informations d’identification pour des dizaines de systèmes, toutes ces clés se déversant dans les fenêtres de contexte LLM, étant exfiltrées – un véritable chaos. La réponse est la même qu’il y a vingt ans : centraliser l’authentification et l’autorisation. Mais tirer ce fil m’a conduit directement au problème suivant : si vous centralisez à l’aide d’outils d’intégration traditionnels, vous êtes de retour dans le pays des connecteurs statiques, et les agents ne sont pas statiques. Ce qui a cimenté la vision, c’est la réalisation que la découverte de capacités devrait être étroitement couplée au contrôle d’accès – qu’un agent ne devrait être proposé qu’une capacité s’il est réellement autorisé à l’utiliser, et que le système fournissant la découverte peut également être le point unique d’application et d’observation.

La récente exposition d’un grand nombre d’instances d’agents accessibles sur Internet a mis en évidence la façon dont l’orchestration et les informations d’identification partagent souvent la même limite de confiance. Quel est, à votre avis, le défaut architectural fondamental de ce modèle ?

Le défaut est simple : l’agent – un système exécutant des invites à partir d’un LLM – est également le système détenant les informations d’identification et effectuant les appels d’API. Compromettre l’agent et vous obtenez tout ce qu’il pourrait faire. C’est la même erreur que nous avons commise à l’époque du début du web – des serveurs d’applications avec un accès superutilisateur à la base de données parce que c’était pratique. Jentic s’interpose entre l’agent et les API qu’il appelle. L’agent n’a jamais de clés. Il émet des demandes via notre couche d’exécution gérée, qui injecte les informations d’identification côté serveur, applique les politiques et enregistre chaque appel. Et lorsque quelque chose se passe mal, il y a un seul interrupteur – une seule action arrête l’accès de cet agent à tous les systèmes connectés simultanément.

Vous avez parlé de la séparation de l’orchestration de l’exécution pour contenir la zone d’impact. Pouvez-vous expliquer de manière pratique comment cette séparation modifie le profil de risque lorsque une instance est compromise ?

Dans le modèle plat, le LLM raisonne sur ce qu’il faut faire et appelle directement les API en utilisant les informations d’identification qu’il détient. Compromettre la couche de raisonnement, et vous contrôlez la couche d’exécution. Avec la séparation, le LLM émet une intention – “appeler l’API de facturation Stripe avec ces paramètres” – une couche d’exécution gérée valide cette demande par rapport à la politique, injecte les informations d’identification côté serveur et effectue l’appel. Le LLM ne touche jamais à l’information d’identification. Dans la pratique : le mouvement latéral devient beaucoup plus difficile, la zone d’impact est limitée par ce que la couche d’exécution permet pour cette identité d’agent spécifique, et vous obtenez un interrupteur. Un seul basculement et l’accès de l’agent s’arrête sur tous les systèmes connectés. L’agent peut toujours être manipulé – mais la manipulation ne signifie plus automatiquement une compromission complète des informations d’identification.

Dans les déploiements d’entreprise réels, à quoi ressemble la gestion centralisée des informations d’identification et la révocation instantanée, et comment diffèrent-elles de la façon dont la plupart des équipes gèrent actuellement les clés d’API et les jetons pour les agents ?

Aujourd’hui, la plupart des équipes ont un développeur qui provisionne des clés d’API, les stocke dans un fichier .env et les charge au démarrage de l’agent – souvent directement dans la fenêtre de contexte LLM. Personne n’a une image complète de quels agents détiennent quels informations d’identification. Lorsqu’une personne quitte, les clés qu’elle a provisionnées ne sont pas tournées. Lorsqu’un agent se comporte de manière étrange, il n’y a pas de trace d’audit pour reconstruire ce qui s’est passé. Avec Jentic, le développeur n’a jamais à gérer les informations d’identification brutes. Ils déclarent quel accès un agent nécessite, la plate-forme provisionne un accès étendu, et l’agent appelle via notre couche d’exécution sans jamais voir la clé sous-jacente. Cela signifie que vous obtenez une révocation instantanée par agent, la possibilité de suspendre l’accès pendant que vous enquêtez et une trace d’audit horodatée de chaque appel d’API. La différence entre cela et “une clé d’API dans un fichier .env” est substantielle.

De nombreuses équipes expérimentent avec des cadres d’agents dans les ventes, l’ingénierie et la science des données. Quels sont les faux pas de sécurité les plus courants que vous voyez lorsque les organisations passent de l’expérimentation à la production ?

Les mêmes modèles se répètent : des agents surprivilegiés qui tournent toujours sur les informations d’identification d’administration avec lesquelles ils ont été prototypés ; des informations d’identification transmises dans les invites ou les fenêtres de contexte où elles se retrouvent dans les journaux, la télémétrie et potentiellement les données de formation ; des informations d’identification partagées entre plusieurs instances d’agent de sorte que vous ne pouvez pas isoler un seul mauvais acteur ; pas d’interrupteur pour arrêter un agent sans débrancher l’ensemble du système ; pas de trace d’audit digne de ce nom ; et l’injection d’invite pas prise au sérieux – même si tout agent qui lit des e-mails, traite des documents ou navigue sur le web rencontrera du contenu conçu de manière adversative. Le fil conducteur est que ces équipes ont construit pour le chemin heureux et découvrent maintenant que la production est principalement les chemins malheureux.

Jentic se positionne comme une couche d’exécution gérée située entre les cadres d’agents et les systèmes externes. Comment cette couche intermédiaire impose-t-elle la gouvernance sans ralentir les développeurs ou réduire la flexibilité des agents ?

Au lieu de relier un agent à cinquante différentes API – chacune avec son propre schéma d’authentification, ses limites de taux et ses particularités – le développeur se connecte à une seule terminaison. Cette terminaison expose des outils pour rechercher notre catalogue complet de capacités d’API, charger les détails et exécuter n’importe quel appel. Cela maximise la flexibilité via une interface unifiée pour des API illimitées, tout en permettant la gouvernance – quels agents accèdent à quels API, dans quelles conditions, avec quelles limites – tout géré dans la plate-forme, et non dans le code client. La couche d’exécution est un passage ; les agents peuvent toujours composer des flux de travail mult étapes, enchaîner des appels et gérer les erreurs de manière dynamique. La gouvernance sans friction est difficile. La solution de rechange est de reporter la charge sur les développeurs. L’infrastructure devrait faire le contraire – absorber cette complexité afin que les développeurs n’aient pas à.

Avec le logiciel malveillant infostealer visant désormais activement les fichiers de configuration d’agents et les informations d’identification stockées, voyez-vous les attaquants déplacer leur attention vers l’infrastructure d’IA comme une nouvelle surface à haute valeur ?

Absolument – et la logique est évidente. Un fichier de configuration d’agent est effectivement une superclé multiservice : des informations d’identification pour les systèmes de messagerie, les CRM, les plateformes de facturation, les API internes et les comptes GitHub. Un seul vol réussi d’infostealer donne accès pendant des mois à l’ensemble des systèmes externes d’une société. C’est un retour dramatiquement plus élevé que la cible de n’importe quel service isolé. L’autre dimension est que les agents qui s’exécutent en continu dans la production sont des présences persistantes et dotées d’informations d’identification – et non un utilisateur qui se connecte et se déconnecte. Un agent compromis peut servir de point d’appui à long terme, opérant en dessous des seuils de détection. La réalité inconfortable est que la surface d’attaque évolue plus vite que les outils de défense. Jentic peut réduire considérablement la surface d’attaque des informations d’identification, mais nous ne pouvons pas empêcher un agent de mal utiliser les étendues qui lui ont été accordées. Ce problème plus difficile doit être résolu au niveau du modèle, avec des garde-fous et une détection d’injection d’invite.

Au-delà de tout cadre unique, quels principes de sécurité plus larges les organisations devraient-elles adopter si elles veulent déployer l’IA agente de manière sécurisée à grande échelle ?

La plupart des organisations gérées ne peuvent pas déployer des systèmes non déterministes dans leurs processus commerciaux les plus précieux. Une banque ou une compagnie d’assurance ne peut pas pointer un agent autonome vers son système de facturation et dire “allez-y, déterminez-le”. Alors, comment innovez-vous sans que votre posture de risque devienne un frein ? La réponse est la mise en sandbox. Créez un jumeau numérique de votre patrimoine d’API avec la même structure et les mêmes flux de travail, mais sans informations d’identification de production ou conséquences. Déployez des agents là-bas, laissez-les explorer, regardez ce qui se passe. Les chemins réussis sont capturés sous forme d’automatisations de flux de travail déterministes structurées à l’aide d’Arazzo, la spécification de flux de travail ouverte développée dans l’initiative OpenAPI – auditable, reproductible et examinable par n’importe quelle équipe de conformité. Cela signifie que vous pouvez avancer à la vitesse de l’IA dans le sandbox et à la vitesse de l’entreprise en production, et que ces deux modes coexistent. Les autres principes s’appliquent toujours – le privilège minimum, les traces d’audit, les interrupteurs, la séparation de l’orchestration de l’exécution. Mais le sandbox est la réponse structurelle à la question à laquelle les équipes d’entreprise sont réellement bloquées : comment expérimenter avec l’IA non déterministe sans parier leur posture de conformité ? Vous ne déployez pas la non-déterminisme. Vous en extrayez la valeur dans des conditions contrôlées, et vous déployez uniquement les sorties déterministes.

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