Sean Blanchfield, Co-Fundador y CEO de Jentic – Serie de Entrevistas

Sean Blanchfield, Co-Fundador y CEO de Jentic, es un emprendedor tecnológico serial con décadas de experiencia en la creación de empresas de software y infraestructura a gran escala. Con sede en Dublín, actualmente lidera Jentic mientras también forma parte del Consejo Asesor de Inteligencia Artificial de Irlanda, asesorando al gobierno sobre políticas de inteligencia artificial. Al comienzo de su carrera, cofundó DemonWare, una plataforma de servicios en línea de alta escala para importantes editores de videojuegos que posteriormente fue adquirida por Activision Blizzard (ATVI ), y PageFair, una startup respaldada por capital de riesgo centrada en análisis de bloqueo de anuncios que fue adquirida por Blockthrough. También ha fundado o dirigido múltiples startups y continúa apoyando el ecosistema de startups de Irlanda a través de iniciativas como Techpreneurs.

Jentic está desarrollando una capa de integración universal diseñada para ayudar a los agentes de inteligencia artificial a interactuar de manera segura con los sistemas y API empresariales. La plataforma permite a las organizaciones conectar los modelos de inteligencia artificial con herramientas internas, servicios externos y flujos de trabajo operativos mientras mantienen la gobernanza, la autenticación y la supervisión. Al transformar las API fragmentadas en interfaces estructuradas que los agentes de inteligencia artificial pueden utilizar de manera fiable, Jentic pretende ayudar a las empresas a implementar la automatización impulsada por la inteligencia artificial a gran escala en entornos de software complejos.

Ha fundado y dirigido múltiples empresas tecnológicas, desde DemonWare (adquirida por Activision Blizzard) hasta PageFair y ahora Jentic, y también forma parte del Consejo Asesor de Inteligencia Artificial de Irlanda. ¿Qué lo llevó a regresar a la construcción de la capa de infraestructura con Jentic, y qué brecha vio en el ecosistema emergente de agentes de inteligencia artificial que otros estaban pasando por alto?

Por tercera vez que notas un patrón, debes tomártelo en serio. En DemonWare, todos hablaban de multiplayer en línea, pero el problema difícil era la infraestructura de red subyacente. Lo mismo está sucediendo con los agentes de inteligencia artificial. Los modelos son notables. El cuello de botella es la capa de integración, siempre ha sido así. Los agentes de inteligencia artificial funcionan con API, y esas API fueron diseñadas para humanos: documentadas para humanos, seguras para humanos y estructuradas para humanos. Apunta un agente autónomo a esa infraestructura y se desmorona rápidamente. Los proyectos piloto de inteligencia artificial empresarial no fallan porque el modelo no entendió la tarea; fallan porque el agente no pudo conectarse de manera fiable a los sistemas que necesitaba. La inteligencia artificial generativa ofrece una nueva forma de resolver este problema: tratando la integración como un problema de conocimiento, no como un problema de codificación. Esa idea me atrajo.

Cuando comenzó Jentic en 2024, ¿la seguridad del agente fue la tesis principal desde el primer día, o se enfocó más a medida que observaba cómo las organizaciones estaban desplegando agentes autónomos en producción?

El primer hilo que saqué fue el de las credenciales. Imaginé agentes proliferando, cada uno necesitando credenciales para decenas de sistemas, todos esos secretos fluyendo hacia ventanas de contexto de LLM, siendo exfiltrados: un desastre. La respuesta es la misma que habría sido hace veinte años: centralizar la autenticación y la autorización. Pero al tirar de ese hilo, me llevó directamente al siguiente problema: si centralizas utilizando herramientas de integración tradicionales, regresas a la tierra de conectores estáticos, y los agentes no son estáticos. Lo que cementó la visión fue darme cuenta de que la descubierta de capacidades debería estar estrechamente acoplada al control de acceso: que un agente solo debería ser ofrecido una capacidad si está autorizado a utilizarla, y que el sistema que proporciona la descubierta también puede ser el único punto de aplicación y observabilidad.

La reciente exposición de un gran número de instancias de agentes que se enfrentan a Internet ha resaltado cómo la orquestación y las credenciales a menudo comparten el mismo límite de confianza. Desde su perspectiva, ¿cuál es el error arquitectónico central en ese modelo?

El error es simple: el agente, un sistema que ejecuta instrucciones de un LLM, también es el sistema que posee las credenciales y realiza las llamadas a la API. Compromete el agente y obtienes todo lo que podría hacer. Es el mismo error que cometimos en la era temprana de la web: servidores de aplicaciones con acceso de superusuario a la base de datos porque era conveniente. Jentic se sitúa como una capa entre el agente y las API que llama. El agente nunca posee credenciales. Emite solicitudes a través de nuestra capa de ejecución administrada, que inyecta credenciales en el servidor, aplica políticas y registra cada llamada. Y cuando algo sale mal, hay un solo interruptor de desconexión: una acción detiene el acceso del agente a todos los sistemas conectados simultáneamente.

Habla sobre la separación de la orquestación de la ejecución para contener el radio de explosión. ¿Puede explicar en términos prácticos cómo esa separación cambia el perfil de riesgo cuando se compromete una instancia?

En el modelo plano, el LLM razona sobre qué hacer y llama directamente a las API utilizando las credenciales que posee. Compromete la capa de razonamiento, y controlas la capa de ejecución. Con la separación, el LLM emite una intención: “llamar a la API de facturación de Stripe con estos parámetros”. Una capa de ejecución administrada valida esa solicitud contra la política, inyecta la credencial en el servidor y realiza la llamada. El LLM nunca toca la credencial. En la práctica: el movimiento lateral se vuelve mucho más difícil, el radio de explosión está limitado por lo que la capa de ejecución permite para esa identidad de agente específica, y obtienes un interruptor de desconexión. Un solo toggle y el acceso del agente se detiene en todos los sistemas conectados. El agente todavía puede ser manipulado, pero la manipulación ya no significa automáticamente el compromiso total de las credenciales.

En despliegues empresariales del mundo real, ¿cómo se ve realmente la gestión centralizada de credenciales y la revocación instantánea, y cómo difiere de cómo la mayoría de los equipos están manejando actualmente las claves de API y tokens para los agentes?

Hoy en día, la mayoría de los equipos tienen un desarrollador que proporciona claves de API, las almacena en un archivo .env y las carga al iniciar el agente, a menudo directamente en la ventana de contexto del LLM. Nadie tiene una visión completa de qué agentes poseen qué credenciales. Cuando alguien se va, las claves que provisionó no se rotan. Cuando un agente se comporta de manera extraña, no hay un registro de auditoría para reconstruir lo que sucedió. Con Jentic, el desarrollador nunca maneja credenciales sin procesar. Declaran qué acceso necesita un agente, la plataforma proporciona acceso con ámbito y el agente llama a través de nuestra capa de ejecución sin ver nunca la clave subyacente. Eso significa que obtienes revocación instantánea por agente, la capacidad de pausar el acceso mientras investigas y un registro de auditoría con fecha y hora de cada llamada a la API. La diferencia entre eso y “clave de API en un archivo .env” es sustancial.

Muchas organizaciones están experimentando con marcos de agentes en ventas, ingeniería y ciencia de datos. ¿Cuáles son los errores de seguridad más comunes que ve en cuanto a que las organizaciones pasan de la experimentación a la producción?

Los mismos patrones se repiten: agentes con demasiados privilegios todavía ejecutándose con las credenciales de administrador con las que se prototiparon; credenciales pasadas en instrucciones o ventanas de contexto donde terminan en registros, telemetría y potencialmente en datos de entrenamiento; credenciales compartidas entre múltiples instancias de agentes para que no puedas aislar a un solo actor malicioso; no hay interruptor de desconexión para detener a un agente sin tomar todo el sistema; no hay registro de auditoría digno de mención; y la inyección de instrucciones no se toma en serio, incluso cuando cualquier agente que lea correos electrónicos, procese documentos o navegue por la web encontrará contenido creado de manera adversaria. El hilo común es que estos equipos construyeron para el camino feliz y ahora están descubriendo que la producción es principalmente los caminos infelices.

Jentic se posiciona como una capa de ejecución administrada que se sitúa entre los marcos de agentes y los sistemas externos. ¿Cómo esa capa intermedia aplica la gobernanza sin frenar a los desarrolladores o reducir la flexibilidad de los agentes?

En lugar de cablear un agente a cincuenta API diferentes, cada una con su propio esquema de autenticación, límites de velocidad y rarezas, el desarrollador se conecta a un solo punto final. Ese punto final expone herramientas para buscar nuestro catálogo completo de capacidades de API, cargar detalles y ejecutar cualquier llamada. Esto maximiza la flexibilidad a través de una interfaz unificada para API ilimitadas, al mismo tiempo que permite la gobernanza, que agentes acceden a qué API, bajo qué condiciones, con qué límites, todo administrado en la plataforma, no en el código del cliente. La capa de ejecución es de paso; los agentes todavía pueden componer flujos de trabajo de múltiples pasos, encadenar llamadas y manejar errores de manera dinámica. La gobernanza sin fricción es difícil. El atajo es empujar la carga hacia los desarrolladores. La infraestructura debería hacer lo contrario: absorber esa complejidad para que los desarrolladores no tengan que hacerlo.

Con malware de robo de información ahora activamente apuntando a archivos de configuración de agentes y credenciales almacenadas, ¿ve a los atacantes cambiando su enfoque hacia la infraestructura de inteligencia artificial como una nueva área de alto valor?

Absolutamente, y la lógica es obvia. Un archivo de configuración de agente es efectivamente una superclave de multiservicio: credenciales para sistemas de correo electrónico, CRM, plataformas de facturación, API internas y cuentas de GitHub. Una sola ejecución exitosa de malware de robo de información produce meses de acceso a todos los sistemas externos de una empresa. Eso es un retorno dramáticamente mayor que apuntar a cualquier servicio de manera aislada. La otra dimensión es que los agentes que se ejecutan continuamente en producción son presencias credenciales y persistentes, no un usuario que inicia y cierra sesión. Un agente comprometido puede servir como un punto de apoyo a largo plazo, operando por debajo de los umbrales de detección. La realidad incómoda es que la superficie de ataque está evolucionando más rápido que las herramientas defensivas. Jentic puede reducir significativamente la superficie de ataque de credenciales, pero no podemos prevenir que un agente malgaste los ámbitos que se le han concedido. Ese problema más difícil necesita ser resuelto a nivel de modelo, con barandillas y detección de inyección de instrucciones.

Más allá de cualquier marco individual, ¿qué principios de seguridad más amplios deberían adoptar las organizaciones si desean implementar inteligencia artificial agente de manera segura a gran escala?

La mayoría de las organizaciones administradas no pueden implementar sistemas no determinísticos en sus procesos comerciales más valiosos. Un banco o asegurador no puede apuntar un agente autónomo a su sistema de facturación y decir “ve a averiguarlo”. Entonces, ¿cómo innovas sin que tu postura de riesgo se convierta en un freno? La respuesta es la sandboxización. Crea un gemelo digital de tu cartera de API con la misma estructura y flujos de trabajo, pero sin credenciales de producción ni consecuencias. Despliega agentes allí, déjalos explorar, observa qué sucede. Los caminos exitosos se capturan como automatizaciones de flujos de trabajo estructurados y determinísticos utilizando Arazzo, la especificación de flujo de trabajo abierta desarrollada dentro de la Iniciativa OpenAPI, auditables, repetibles y revisables por cualquier equipo de cumplimiento. Esto significa que puedes moverte a la velocidad de la inteligencia artificial en la sandbox y a la velocidad empresarial en producción, y esos dos modos coexisten. Los otros principios todavía aplican: privilegios mínimos, registros de auditoría, interruptores de desconexión, separación de la orquestación de la ejecución. Pero la sandbox es la respuesta estructural a la pregunta que los equipos empresariales realmente se quedan atascados: ¿cómo experimentamos con inteligencia artificial no determinística sin apostar nuestra postura de cumplimiento en ella? No despliegues la no determinística. Extrae valor de ella bajo condiciones controladas y despliega solo las salidas determinísticas.

Gracias por la gran entrevista, los lectores que deseen aprender más pueden visitar Jentic.