Refael Angel, Co-Fundador y CTO de Akeyless – Serie de Entrevistas

Refael Angel, Co-Fundador y CTO de Akeyless, es un líder en ciberseguridad y ingeniería de software con una profunda experiencia en seguridad en la nube, cifrado, autenticación de máquinas y infraestructura empresarial. Desde que co-fundó Akeyless en 2018, ha ayudado a construir la empresa alrededor de la gestión moderna de secretos y la seguridad de identidad para entornos nativos de la nube. Antes de Akeyless, trabajó como Ingeniero de Software Senior en Seguridad en Intuit (INTU ), donde construyó sistemas para la gestión de claves de cifrado en la nube pública y la autenticación de máquinas, ganando experiencia práctica en AWS, Go, Python, Java, PHP, Bash, Linux, Git y Jenkins. Al comienzo de su carrera, Angel ocupó puestos de ingeniería de software en 3D Systems (DDD ) y Cimatron, desarrollando aplicaciones CAD/CAM y basadas en Windows utilizando C/C++, C#, WPF, MFC y patrones de diseño orientados a objetos.

Akeyless es una empresa de seguridad de identidad centrada en la seguridad de máquinas, agentes de inteligencia artificial y humanos a través de una plataforma nativa de la nube construida alrededor de la criptografía de conocimiento cero. Su plataforma reúne la gestión de secretos, la gestión de claves de cifrado, la gestión del ciclo de vida de certificados, el acceso privilegiado y la seguridad de identidad de máquinas, lo que da a las organizaciones una forma unificada de gestionar credenciales, claves, certificados y acceso en entornos híbridos, multi-nube, DevOps y de inteligencia artificial. La posición de la empresa refleja un cambio más amplio en la ciberseguridad: a medida que las cargas de trabajo, los servicios y los agentes de inteligencia artificial realizan cada vez más el acceso al sistema sin la participación directa de los humanos, las empresas necesitan controles más fuertes alrededor de identidades no humanas, credenciales de vida corta, rotación automatizada y gobernanza en tiempo de ejecución.

Co-fundaste Akeyless en 2018 después de construir sistemas de gestión de claves de cifrado y autenticación de máquinas en Intuit. ¿Qué brecha en la seguridad en la nube y la gestión de identidad te convenció de que era hora de empezar Akeyless, y cómo ha evolucionado esa visión original a medida que los agentes de inteligencia artificial han surgido como una nueva clase de identidades digitales?

En Intuit, formé parte del equipo que construyó sistemas de gestión de claves de cifrado y autenticación de máquinas en un momento en que Intuit era una de las primeras grandes empresas en migrar a la nube. Lo que se me hizo claro fue que cada organización que adoptara la nube eventualmente enfrentaría el mismo problema que estábamos resolviendo internamente: cómo gestionar secretos y claves en infraestructuras distribuidas y dinámicas. Construir esto en casa consume enormes recursos de ingeniería, y no tiene sentido que cada empresa lo reinvente. La respuesta lógica era un modelo de SaaS.

El problema era la confianza. Este es el material más sensible que posee una empresa, y ninguna organización seria le dará a un tercero la capacidad de acceder a él. Entonces, el requisito era casi contradictorio: entregarlo como SaaS para escala y simplicidad, pero hacer que sea arquitectónicamente imposible para el proveedor ver los datos del cliente. Esa tensión es exactamente lo que dio origen a la Criptografía de Fragmentos Distribuidos (DFC). La DFC nos permite ejecutar un controlador de SaaS completamente gestionado mientras el cliente mantiene un fragmento que nunca poseemos, por lo que somos matemáticamente incapaces de acceder a sus claves. Eso se convirtió en la base del modelo SaaS más Zero-Conocimiento que Akeyless está construido.

La visión original era sobre la seguridad del acceso humano y de máquinas en la nube. Los agentes de inteligencia artificial son la extensión natural y más extrema de ese mismo problema. Operan a una escala y velocidad que ningún directorio estaba diseñado para, y la misma base de conocimiento cero y centrada en la identidad ahora se extiende directamente a ellos.

Se te acredita como el arquitecto detrás de la tecnología de cifrado de confianza cero patentada por Akeyless. ¿Cuáles fueron los mayores desafíos técnicos al construir un modelo de seguridad que pudiera eliminar las suposiciones de confianza y seguir siendo práctico para grandes empresas?

La parte más difícil fue hacer que “no confíes en nadie” fuera práctico en lugar de académico. La mayoría de los esquemas de claves divididas o compartidas de secretos todavía ensamblan la clave completa en algún momento, generalmente dentro de un solo proceso, un módulo de seguridad de hardware (HSM) o un enclave en el instante de una operación criptográfica. Esa ventana breve es precisamente lo que los atacantes, los insiders maliciosos y los escenarios de compulsión legal apuntan.

Con la DFC, la clave nunca se ensambla, ni en su creación, ni en reposo, ni durante su uso. Los fragmentos se generan de forma independiente en dominios de confianza separados, y las operaciones criptográficas se ejecutan como un cálculo distribuido donde cada titular de fragmentos calcula su parte localmente y solo se intercambian resultados parciales. El desafío de ingeniería fue lograr esto con la latencia, el rendimiento y la confiabilidad que las grandes empresas exigen en producción.

Un segundo desafío, y uno de los más significativos, fue permitir la actualización continua de los fragmentos. Teníamos que poder reemplazar cada fragmento con un nuevo valor matemático, en cada ubicación, mientras la clave maestra que los fragmentos representan permanece sin cambios y el proceso criptográfico nunca se interrumpe. Esto agregó una capa de seguridad sustancial a la solución. Debido a la actualización, un atacante ya no puede recopilar fragmentos pacientemente con el tiempo. Un fragmento capturado la semana pasada es matemáticamente no relacionado con los fragmentos que existen hoy, por lo que es ruido en lugar de una ventaja. Para aprender algo sobre una clave, un adversario tendría que comprometer cada ubicación de fragmentos simultáneamente, dentro de una sola ventana de actualización, y ese requisito se vuelve exponencialmente más difícil a medida que aumentan las ubicaciones, los dominios de confianza y la frecuencia de actualización. Combinado con el umbral de todo o nada, donde se necesitan el 100% de los fragmentos para revelar algo y cualquier subconjunto estricto no filtra información, la actualización convierte el modelo de seguridad de una garantía estática en una garantía basada en el tiempo.

Muchas organizaciones están compitiendo para desplegar agentes de inteligencia artificial, pero la seguridad de la identidad a menudo sigue siendo un tema secundario. ¿Cuáles son los errores más comunes que las empresas cometen al dar a los agentes de inteligencia artificial acceso a sistemas y datos empresariales sensibles?

El error más grande es tratar a un agente como una cuenta de servicio y darle una clave de API estática y de larga duración. Esa credencial se convierte en un activo permanente y recopilable que se sienta dentro de un actor no determinístico e inyectable de comandos.

Los otros errores comunes que veo son: otorgar privilegios permanentes en lugar de acceso justo a tiempo, confiar en permisos basados en roles gruesos que describen qué puede alcanzar un agente pero nunca qué pretende hacer, dar a los agentes rutas de red directas a bases de datos y API para que un compromiso se convierta en movimiento lateral, y no tener una cadena de auditoría que vincule la acción de un agente con el prompt humano y el que lo desencadenó. Cada uno de estos es un intento de retroadaptar controles de la era humana a algo que no se comporta como un humano.

Akeyless ha argumentado que los agentes de inteligencia artificial requieren un modelo de identidad fundamentalmente diferente al de los humanos o las cargas de trabajo de máquinas tradicionales. ¿Qué hace que los agentes de inteligencia artificial sean particularmente difíciles de asegurar en comparación con los marcos de IAM y PAM existentes?

El error central es tratar a los agentes de inteligencia artificial como un nuevo tipo de usuario, o incluso como un nuevo tipo de cuenta de servicio, y asumir que pueden ser incorporados y gobernados como identidades humanas. Eso es un error de categoría, por varias razones conectadas.

Las identidades de los agentes no son enumerables. La instancia específica que deseas gobernar generalmente no existe aún, y para cuando existe, ya ha desaparecido. Un agente puede aparecer en una Lambda, ejecutarse durante 800 milisegundos y desvanecerse antes de que algún escáner lo note, o generar cadenas de subagentes a través de VM, contenedores y servidores sin estado que se completan en segundos. Registrarlos en un directorio es tratar a fantasmas como residentes: para cuando la entrada se confirma, la entidad que describía ya ha desaparecido.

El ancla correcta es, por lo tanto, no el agente, sino la identidad de la carga de trabajo que el tiempo de ejecución ya emite, el rol de ejecución de AWS, el token de cuenta de servicio de Kubernetes, el token de federación OIDC y los estándares como SPIFFE/SPIRE que ya están probados en producción y son transubstrato. Esa identidad ya existe, es avalada por la plataforma en la que se ejecuta el agente y desaparece cuando el agente desaparece. Debido a que las identidades son efímeras, las únicas entidades estables para escribir políticas entre son los métodos de autenticación y los sistemas objetivo, no identidades nombradas y alcances.

Y esto es donde los IAM y PAM existentes se rompen más decisivamente: el RBAC y ABAC estáticos no pueden contener a un actor no determinístico. Un agente con un token perfectamente delimitado y un TTL perfectamente aplicado todavía puede ser inyectado con comandos, puede alucinar una consulta destructiva o puede cambiar de una tarea de lectura a una tarea de escritura en la misma sesión, sin que se produzca una violación de política visible en la capa de autorización. El RBAC y ABAC evalúan en la autenticación, no después, porque lo que sucede después es decidido por un modelo de lenguaje grande que mira una ventana de contexto que el autor de la política no puede ver.

Entonces, los agentes son particularmente difíciles porque son efímeros, no determinísticos, multi-sustrato y susceptibles a la inyección de comandos, todo al mismo tiempo. La capa que falta no es un directorio mejor. Es una capa de aplicación de políticas consciente de la intención en cada acción, mediada por una puerta de enlace que verifica qué está haciendo el agente en realidad contra lo que dijo que haría, antes de que se acuñe ninguna credencial.

Hay un creciente debate en torno a las arquitecturas “sin secretos” para sistemas de inteligencia artificial. ¿Cómo defines la autenticación sin secretos, y por qué crees que las credenciales estáticas y las claves de API están volviéndose insostenibles en la era de los agentes autónomos?

La autenticación sin secretos significa que el agente nunca posee una credencial en absoluto. En lugar de darle al agente una clave que deba almacenar y presentar, el agente se autentica a través de su identidad de carga de trabajo nativa, y una credencial de vida corta y justo a tiempo se inyecta en una sesión intermediada en el momento de la ejecución, y luego se destruye cuando la sesión termina. El agente nunca la ve.

Las credenciales estáticas y las claves de API se están volviendo insostenibles por una razón simple: un secreto que un agente posee es un secreto que un atacante puede robar. En un mundo donde el actor que posee la credencial puede ser inyectado con comandos o alucinar, una clave de larga duración se convierte en una fuga de clave potencial cada vez que un agente se ve comprometido. Eliminar la credencial del agente y un agente comprometido no tiene nada que filtrar. Ese es el punto entero de lo que llamamos SecretlessAI.

A medida que los agentes de inteligencia artificial ganan la capacidad de planificar, ejecutar acciones y interactuar con múltiples sistemas de forma independiente, ¿qué nuevos vectores de ataque te preocupan más en los próximos tres a cinco años?

Los vectores que me preocupan más todos se derivan de los agentes que pueden planificar y actuar en sistemas de forma independiente. La inyección de comandos que secuestra la intención de un agente en medio de una tarea es el más claro, porque la identidad permanece válida incluso mientras el comportamiento se vuelve malicioso. Más allá de eso, me preocupa la transferencia de agentes a agentes donde se pasa la autoridad a lo largo de una cadena sin rendición de cuentas clara, el movimiento lateral a través de agentes que tienen acceso directo a la red, y la extracción de datos donde un agente sobrepoderado extrae mucho más de lo que su tarea requiere.

El hilo común es que la credencial y el rol pueden ser perfectamente legítimos mientras la acción no lo es. Las defensas que solo verifican permisos, no propósito, no atraparán ninguno de estos. Es por eso que la aplicación de políticas consciente de la intención en una puerta de enlace, en cada acción, es el control que creo que importará más.

Estamos viendo un cambio de la seguridad de las identidades humanas a la seguridad de las identidades de máquinas y agentes. ¿Cómo ves que cambian las prioridades de seguridad a medida que las organizaciones comienzan a gestionar millones de identidades no humanas en su infraestructura?

Estamos entrando en un mundo donde la abrumadora mayoría del acceso al sistema lo realizan identidades no humanas, máquinas, cargas de trabajo y ahora agentes, pero la mayoría de las herramientas todavía asumen un humano detrás del teclado. El resultado es secretos por todas partes, privilegios permanentes y identidades que nadie puede rastrear completamente.

El cambio en las prioridades es de controles periódicos y al ritmo humano hacia la aplicación de políticas en tiempo de ejecución y a escala de máquina. Cuando gestionas millones de identidades no humanas, no puedes confiar en el registro, las campañas de certificación y las revisiones de acceso trimestrales. Necesitas identidades efímeras por construcción, sin privilegios permanentes y políticas evaluadas automáticamente en cada acción. La seguridad de la identidad humana no desaparece, pero se convierte en una fracción menor de la superficie, y la arquitectura debe construirse para la mayoría no humana primero.

Investigaciones recientes sugieren que los agentes de inteligencia artificial pueden estar accediendo a información más allá de sus permisos previstos. ¿Qué controles de gobernanza y en tiempo de ejecución deberían tener las organizaciones antes de permitir que los agentes operen de forma autónoma en entornos de producción?

Antes de que cualquier agente opere de forma autónoma en producción, me gustaría tener algunas cosas en su lugar. Primero, no hay credenciales permanentes en el agente, con acceso justo a tiempo y de vida corta inyectado por sesión. Segundo, no hay ruta de red directa, para que cada acción del agente sea intermediada por un punto de estrangulamiento obligatorio en lugar de llegar directamente a bases de datos y API. Tercero, la aplicación de políticas consciente de la intención que evalúa el propósito de una solicitud contra su prompt de origen antes de que se acuñe cualquier credencial, para que un agente solicitado para analizar ingresos no pueda emitir un comando destructivo. Cuarto, inspección y enmascaramiento de respuesta en sesión para que los datos sensibles como la información personal y la información de salud sean enmascarados antes de que entren en la ventana de contexto del agente. Y quinto, un registro de auditoría único e inmutable que vincula el prompt humano, la intención clasificada, el veredicto de la política, la sesión y la acción final.

La descubierta y la visibilidad también importan, pero como entradas para la política, no como un requisito previo para la protección. Debes poder gobernar un agente la primera vez que se autentica, incluso si nunca has visto esa instancia específica antes.

La industria a menudo se centra en la seguridad del modelo, pero se presta menos atención a la identidad, la autorización y el control de acceso. ¿Por qué crees que estas áreas se convertirán en algunos de los desafíos de seguridad más importantes de la era de la inteligencia artificial?

La seguridad del modelo es lo que recibe los titulares, pero un modelo perfectamente alineado todavía tiene que actuar en el mundo real, y en el momento en que actúa, necesita acceso a sistemas y datos. Ese acceso es donde se produce el daño real. Un modelo que nunca toca una base de datos no puede extraerla.

La autorización también es la parte más difícil de la seguridad de los agentes, porque el actor es no determinístico y efímero. No puedes resolverlo puramente en la capa del modelo, y no puedes resolverlo con roles estáticos. Requiere la aplicación de políticas consciente de la intención en cada acción, en una puerta de enlace. Ese es un trabajo de infraestructura poco glamoroso, que es exactamente por qué está subdiscutido y exactamente por qué resultará ser uno de los problemas de seguridad más importantes de esta era.

Mirando hacia adelante, ¿crees que las empresas eventualmente requerirán una capa de identidad dedicada para los agentes de inteligencia artificial, similar a cómo los proveedores de identidad se volvieron esenciales para los usuarios humanos, y ¿cómo sería esa arquitectura futura?

Sí, pero no se parecerá al modelo de proveedor de identidad para humanos simplemente rebautizado para agentes. Intentar construir un directorio de agentes es construir un directorio para fantasmas, identidades que desaparecen antes de que termines de registrarlas.

La capa de identidad del agente que espero anclará la identidad a la carga de trabajo que el tiempo de ejecución emite, la cuenta de servicio de AWS, el token de cuenta de servicio de Kubernetes, la federación OIDC y los estándares como SPIFFE/SPIRE que ya están probados en producción y son transubstrato. La autorización se expresará como relaciones entre métodos de autenticación y sistemas objetivo, en lugar de entre identidades nombradas y alcances. Y el centro de gravedad será un plano de aplicación de políticas en tiempo de ejecución, una puerta de enlace que intermediará cada acción, clasificará la intención, inyectará credenciales efímeras, enmascarará respuestas sensibles y producirá una cadena de auditoría completa. La identidad todavía importa, pero cae en su lugar detrás de la aplicación de políticas en lugar de delante de ella. Esa capa de autoridad en tiempo de ejecución, sentada en la misma plataforma que ya gobierna el acceso humano y de máquinas, es lo que creo que todas las empresas que ejecutan agentes en producción eventualmente necesitarán.

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