Sean Blanchfield, cofundador y director ejecutivo de Jentic – Serie de entrevistas

Sean BlanchfieldCofundador y CEO de Jentic, es un emprendedor tecnológico en serie con décadas de experiencia en la creación de empresas de software e infraestructura a gran escala. Con sede en Dublín, actualmente dirige Jentic y también forma parte del Consejo Asesor de IA de Irlanda, donde asesora al gobierno sobre políticas de inteligencia artificial. Anteriormente, cofundó DemonWare, una plataforma de servicios en línea de gran escala para importantes editoras de videojuegos que posteriormente fue adquirida por Activision Blizzard, y PageFair, una startup respaldada por capital de riesgo centrada en el análisis de bloqueo de anuncios que fue adquirida por Blockthrough. También ha fundado o dirigido varias startups y continúa apoyando el ecosistema emprendedor de Irlanda a través de iniciativas como Techpreneurs.

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

Has fundado y dirigido varias empresas tecnológicas, desde DemonWare (adquirida por Activision Blizzard) hasta PageFair y ahora Jentic, y también formas parte del Consejo Asesor de IA de Irlanda. ¿Qué te impulsó a volver a desarrollar infraestructura con Jentic y qué carencias detectaste en el ecosistema emergente de agentes de IA que otros no habían cubierto?

A la tercera vez que detectas un patrón, debes tomártelo en serio. En DemonWare, todos hablaban del multijugador en línea, pero el verdadero problema era la infraestructura de red subyacente. Lo mismo ocurre con los agentes de IA. Los modelos son extraordinarios. El cuello de botella es la capa de integración, y siempre lo ha sido. Los agentes de IA se ejecutan en API, y esas API fueron diseñadas para humanos: documentadas, seguras y estructuradas para humanos. Si un agente autónomo se enfrenta a esa infraestructura, se desmorona rápidamente. Los proyectos piloto de IA empresarial no fracasan porque el modelo no haya entendido la tarea; fracasan porque el agente no puede conectarse de forma fiable a los sistemas que necesita. La IA generativa ofrece una nueva forma de resolver esto: tratar la integración como un problema de conocimiento, no de programación. Esa idea me cautivó.

Cuando fundaste Jentic en 2024, ¿la seguridad de los agentes fue la tesis principal desde el primer día, o el enfoque se fue precisando a medida que observabas cómo las organizaciones implementaban agentes autónomos en producción?

El primer aspecto que se me ocurrió fue el de las credenciales. Imaginé agentes proliferando, cada uno necesitando credenciales para docenas de sistemas, con todos esos secretos fluyendo hacia las ventanas de contexto de LLM y siendo exfiltrados: un caos total. La solución es la misma que hace veinte años: centralizar la autenticación y la autorización. Pero este punto me llevó directamente al siguiente problema: si se centraliza mediante herramientas de integración tradicionales, se vuelve a la época de los conectores estáticos, y los agentes no son estáticos. Lo que consolidó la visión fue comprender que el descubrimiento de capacidades debe estar estrechamente vinculado al control de acceso: que a un agente solo se le debe ofrecer una capacidad si está autorizado a usarla, y que el sistema que proporciona el descubrimiento también puede ser el único punto de control y observabilidad.

La reciente exposición de un gran número de instancias de agentes con acceso a internet ha puesto de manifiesto cómo la orquestación y las credenciales suelen compartir el mismo límite de confianza. Desde su perspectiva, ¿cuál es el principal fallo arquitectónico de este modelo?

El fallo es sencillo: el agente —un sistema que ejecuta las solicitudes de un LLM— es también el que almacena las credenciales y realiza las llamadas a la API. Si se compromete el agente, se obtiene acceso total a sus funcionalidades. Es el mismo error que cometimos en los inicios de la web: servidores de aplicaciones con acceso de superusuario a la base de datos por comodidad. Jentic actúa como una capa intermedia entre el agente y las API a las que llama. El agente nunca almacena credenciales. Realiza las solicitudes a través de nuestra capa de ejecución gestionada, que inyecta las credenciales en el servidor, aplica las políticas y registra cada llamada. Y cuando algo falla, existe un único mecanismo de desactivación: una sola acción detiene el acceso del agente a todos los sistemas conectados simultáneamente.

Has hablado de separar la orquestación de la ejecución para limitar el alcance del ataque. ¿Puedes explicar en términos prácticos cómo cambia esa separación el perfil de riesgo cuando una instancia se ve comprometida?

En el modelo plano, la capa de lógica de negocio (LLM) razona sobre qué hacer y llama directamente a las API utilizando las credenciales que posee. Si se compromete la capa de razonamiento, se controla la capa de ejecución. Con la separación, la LLM emite una intención —«llama a la API de facturación de Stripe con estos parámetros»—, una capa de ejecución gestionada valida esa solicitud según la política, inyecta la credencial en el servidor y realiza la llamada. La LLM nunca manipula la credencial. En la práctica: el movimiento lateral se vuelve mucho más difícil, el radio de impacto está limitado por lo que la capa de ejecución permite para esa identidad de agente específica, y se obtiene un interruptor de apagado. Con un solo interruptor, el acceso del agente se detiene en todos los sistemas conectados. El agente aún puede ser manipulado, pero la manipulación ya no implica automáticamente una vulneración total de las credenciales.

En implementaciones empresariales reales, ¿cómo se ve en la práctica la gestión centralizada de credenciales y la revocación instantánea, y en qué se diferencia de cómo la mayoría de los equipos gestionan actualmente las claves API y los tokens para los agentes?

Hoy en día, la mayoría de los equipos tienen un desarrollador que proporciona claves 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 tienen qué credenciales. Cuando alguien se va, las claves que proporcionó no se rotan. Cuando un agente se comporta de forma extraña, no hay un registro de auditoría para reconstruir lo que sucedió. Con Jentic, el desarrollador nunca maneja credenciales sin procesar. Declara 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 obtiene revocación instantánea por agente, la capacidad de pausar el acceso mientras investiga y un registro de auditoría con marca de tiempo de cada llamada a la API. La diferencia entre eso y "clave API en un .El archivo "env" es sustancial.

Muchos equipos 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 observan las organizaciones al pasar de la experimentación a la producción?

Se repiten los mismos patrones: agentes con privilegios excesivos que siguen ejecutándose con las credenciales de administrador con las que fueron prototipados; credenciales pasadas en mensajes o ventanas de contexto que terminan en registros, telemetría y, potencialmente, datos de entrenamiento; credenciales compartidas entre múltiples instancias de agentes, lo que impide aislar a un único atacante; ausencia de un mecanismo de desactivación para detener un agente sin afectar al sistema en general; ausencia total de un registro de auditoría útil; y la inyección de mensajes no se toma en serio, a pesar de que cualquier agente que lea correos electrónicos, procese documentos o navegue por la web se encontrará con contenido malicioso. El denominador común es que estos equipos diseñaron pensando en el escenario ideal y ahora están descubriendo que la producción se caracteriza principalmente por los escenarios problemáticos.

Jentic se posiciona como una capa de ejecución gestionada que se sitúa entre los marcos de agentes y los sistemas externos. ¿Cómo garantiza esta capa intermedia la gobernanza sin ralentizar a los desarrolladores ni reducir la flexibilidad de los agentes?

En lugar de conectar un agente a cincuenta API diferentes —cada una con su propio esquema de autenticación, límites de velocidad y particularidades—, el desarrollador se conecta a un único punto final. Este punto final expone herramientas para buscar en todo nuestro catálogo de funcionalidades de API, cargar detalles y ejecutar cualquier llamada. Esto maximiza la flexibilidad mediante una única interfaz unificada para un número ilimitado de API, al tiempo que permite la gobernanza —qué agentes acceden a qué API, bajo qué condiciones y con qué límites—, todo gestionado en la plataforma, no en el código del cliente. La capa de ejecución es de paso; los agentes aún pueden componer flujos de trabajo de varios pasos, encadenar llamadas y gestionar errores dinámicamente. La gobernanza sin fricciones es difícil. El atajo es trasladar la carga a los desarrolladores. La infraestructura debería hacer lo contrario: absorber esa complejidad para que los desarrolladores no tengan que hacerlo.

Ahora que el malware de robo de información se dirige activamente a los archivos de configuración de agentes y a las credenciales almacenadas, ¿cree que los atacantes están centrando su atención en la infraestructura de IA como una nueva área de alto valor?

Absolutamente, y la lógica es obvia. Un archivo de configuración de agente es, en efecto, una superclave multiservicio: credenciales para sistemas de correo electrónico, CRM, plataformas de facturación, API internas y cuentas de GitHub. Un solo ataque exitoso de robo de información proporciona meses de acceso a todos los sistemas externos de una empresa. Esto representa un retorno mucho mayor que atacar un solo servicio de forma aislada. Otra dimensión es que los agentes que se ejecutan continuamente en producción son presencias persistentes y con credenciales, no un usuario que inicia y cierra sesión. Un agente comprometido puede servir como punto de acceso a largo plazo, operando por debajo de los umbrales de detección. La incómoda realidad es que la superficie de ataque evoluciona más rápido que las herramientas de defensa. Jentic puede reducir significativamente la superficie de ataque de credenciales, pero no podemos evitar que un agente haga un mal uso de los permisos que se le han otorgado. Este problema más complejo debe resolverse a nivel de modelo, con medidas de seguridad y detección de inyección inmediata.

Más allá de cualquier marco de referencia específico, ¿qué principios de seguridad más amplios deberían adoptar las organizaciones si desean implementar IA con agentes de forma segura y a gran escala?

La mayoría de las organizaciones gestionadas no pueden implementar sistemas no deterministas en sus procesos de negocio más valiosos. Un banco o una aseguradora no pueden simplemente asignar un agente autónomo a su sistema de facturación y decirle: «Averígualo tú mismo». Entonces, ¿cómo innovar sin que la postura de riesgo se convierta en un obstáculo? La respuesta es el sandboxing. Crea un gemelo digital de tu infraestructura de API con la misma estructura y flujos de trabajo, pero sin credenciales ni consecuencias de producción. Implementa agentes allí, deja que exploren y observa qué sucede. Las rutas exitosas se capturan como automatizaciones de flujo de trabajo estructuradas y deterministas mediante Arazzo, la especificación de flujo de trabajo abierta desarrollada dentro de la OpenAPI Initiative: auditable, repetible y revisable por cualquier equipo de cumplimiento. Esto significa que puedes avanzar a la velocidad de la IA en el sandbox y a la velocidad empresarial en producción, y ambos modos coexisten. Los demás principios siguen siendo válidos: mínimo privilegio, registros de auditoría, interruptores de apagado, separación de la orquestación de la ejecución. Pero el sandbox es la respuesta estructural a la pregunta que realmente se plantean los equipos empresariales: ¿cómo experimentamos con IA no determinista sin poner en riesgo nuestra postura de cumplimiento? No se implementa el no determinismo. Se extrae valor de él bajo condiciones controladas y solo se implementan los resultados deterministas.

Gracias por la gran entrevista, los lectores que deseen obtener más información deben visitar Jentic.