Jacob Ideskog, CTO de Curity – Serie de entrevistas

Jacob Ideskog es un especialista en identidad y CTO en Curity. La mayor parte de su tiempo lo dedica a trabajar con soluciones de seguridad en el espacio de API y Web. Ha trabajado en el diseño y la implementación de soluciones de OAuth y OpenID Connect para grandes empresas y startups.

Curity es una plataforma de gestión de identidad y acceso (IAM) moderna construida alrededor del servidor de identidad de Curity, una solución basada en estándares diseñada para garantizar la autenticación y autorización seguras para aplicaciones, API y servicios digitales a gran escala. Soporta protocolos como OAuth 2.0 y OpenID Connect para centralizar flujos de inicio de sesión, aplicar políticas de acceso detalladas y emitir tokens seguros para usuarios humanos y clientes de máquina, incluidas API y servicios. La plataforma está diseñada para ser flexible y escalable, lo que permite a las organizaciones implementarla en la nube, en entornos híbridos o locales, integrarla con sistemas existentes y ofrecer experiencias de usuario seguras y sin interrupciones sin depender de infraestructura de seguridad personalizada.

Has pasado gran parte de tu carrera construyendo sistemas de identidad y seguridad de API, desde cofundar Curity hasta liderarla como CTO a través del auge de la nube y ahora el AI. ¿Cómo ha moldeado tu visión de que los agentes de AI deberían ser tratados como identidades digitales de primera clase en lugar de solo otro software?

A lo largo de todos los campos de la tecnología en los que he trabajado, un problema sigue resurgiendo. Ya sea la computación en la nube o ahora el AI, si el software actúa en nombre de una persona o de otro sistema, tienes un problema de identidad.

Con la adopción masiva de AI agente, este problema se complica. Su comportamiento ya no está estrictamente limitado por un guion y operan con un nivel de autonomía que las empresas nunca han visto antes. Los agentes de AI toman decisiones, llaman a API y encadenan acciones en varios sistemas, a menudo sin supervisión humana directa. Este comportamiento crea desafíos de identidad y acceso que son fundamentalmente diferentes a los de software tradicional.

Tratar a los agentes de AI como identidades digitales de primera clase es la única forma de abordar esto adecuadamente. Si las organizaciones los tratan como solo otro proceso o cuenta de servicio, pierden visibilidad y control muy rápidamente, y eso es una receta para una crisis de seguridad.

Muchas empresas están emocionadas con el AI agente pero siguen atascadas en la experimentación. Desde lo que estás viendo en despliegues reales, ¿cuáles son las brechas de identidad y gobernanza más comunes que impiden que las organizaciones escalen agentes de manera segura?

La mayoría de la experimentación ocurre en entornos de prueba aislados que ignoran lo que sucede a gran escala. Durante los primeros pilotos, los equipos a menudo otorgan a los agentes claves de API amplias, credenciales compartidas o permisos de nube generales, solo para poner las cosas en marcha.

Este enfoque se desmorona en el momento en que los agentes se despliegan más allá de los pilotos. Esto se debe a que los equipos de seguridad no pueden ver qué datos ha accedido un agente, sus acciones o si puede o ha excedido su alcance previsto, ya sea accidental o maliciosamente. Estos puntos ciegos hacen imposible gobernar a los agentes de manera segura, lo que explica por qué muchas organizaciones luchan por avanzar más allá de los pilotos.

Has argumentado que las barreras estrictas son esenciales para el AI agente. ¿Cómo se ve un buen diseño de identidad para los agentes de AI en la práctica, y dónde suelen equivocarse las empresas?

Un buen diseño de identidad comienza con el principio de privilegios mínimos y permisos vinculados a una intención explícita. Cada agente de AI debe tener su propia identidad, permisos con un alcance limitado y relaciones de confianza claramente definidas (reglas explícitas para qué sistemas está permitido interactuar). Fundamentalmente, el acceso debe estar vinculado a un propósito, restringido en el tiempo y fácil de revocar.

Donde las empresas se equivocan es reutilizando cuentas de servicio existentes o asumiendo que los agentes internos son seguros por defecto. Esa suposición no se mantiene contra amenazas del mundo real. Los actores maliciosos buscan activamente estos puntos débiles, y los agentes de AI aumentan dramáticamente el radio de acción potencial cuando el diseño de identidad es descuidado.

Curity ha trabajado durante mucho tiempo con estándares como OAuth y OpenID Connect. ¿Qué tan críticos son los estándares de identidad abiertos para hacer que el AI agente sea interoperable y seguro en entornos empresariales complejos?

Los estándares abiertos son absolutamente críticos. Las empresas ya ejecutan telas de identidad complejas que abarcan plataformas en la nube, servicios SaaS y API internas. El AI agente solo agrega más complejidad.

Sin estándares, cada agente se convierte en su propia integración y en una excepción de seguridad permanente. Con estándares como OAuth y OpenID Connect, los agentes pueden ser autenticados, autorizados y auditados como cualquier otra carga de trabajo. Este es el único enfoque que puede facilitar un escalado seguro en entornos empresariales reales.

Las identidades no humanas se están volviendo más comunes, desde cuentas de servicio hasta identidades de máquina. ¿Qué hace que los agentes de AI sean fundamentalmente diferentes de las identidades no humanas anteriores desde una perspectiva de seguridad?

La diferencia clave entre los agentes de AI modernos y las identidades no humanas (NHIs) anteriores es la autonomía. Una cuenta de servicio tradicional hace exactamente lo que su código le dice que haga, limitado estrictamente a su tarea. Un agente de AI interpreta instrucciones, adapta su comportamiento y toma acciones que nunca fueron explícitamente escritas, aumentando el peligro potencial si no hay guardias adecuados.

Un pequeño error de identidad o acceso puede convertirse rápidamente en una catástrofe, porque un agente puede actuar a velocidad y en varios sistemas. Desde una perspectiva de seguridad, esto presenta un riesgo importante.

¿Qué tan importantes son los registros de auditoría y el registro basado en identidad para gobernar el AI agente, especialmente en industrias reguladas?

Los registros de auditoría no deben ser “agradables de tener”. Deben estar integrados desde el principio. En entornos regulados, las organizaciones se espera que respondan a preguntas simples pero críticas: ¿qué accedió este agente, cuándo sucedió y quién lo autorizó?

El registro basado en identidad es la única forma confiable de obtener ese nivel de responsabilidad. También juega un papel clave en la respuesta a incidentes. Sin un contexto de identidad claro, es casi imposible saber si un problema provino de un agente mal comportado, una identidad comprometida o simplemente una mala instrucción.

¿Qué riesgos del mundo real ves surgir cuando las organizaciones despliegan agentes de AI con demasiados privilegios o mal monitoreados en producción?

Un riesgo común es la agregación silenciosa de datos. Un agente con demasiados privilegios puede extraer información sensible de varios sistemas (registros de clientes, documentos internos, registros) y luego exponer esa información a través de instrucciones, resúmenes o integraciones externas.

Otro riesgo es que los agentes con acceso administrativo realicen cambios importantes a velocidad de máquina, causando mucho más daño que un humano en un corto período de tiempo. Esto puede incluir la modificación de recursos en la nube, la desactivación de controles de seguridad o el disparo de flujos de trabajo automatizados sin supervisión.

Estos incidentes pueden ser maliciosos, pero no tienen que serlo. Un agente con demasiados privilegios o mal monitoreado podría simplemente estar operando con suposiciones obsoletas o incorrectas, amplificando errores en varios sistemas antes de que alguien se dé cuenta.

Pero, desde la perspectiva de un atacante, una identidad de agente comprometida es extremadamente valiosa. Permite el movimiento lateral a través de API y servicios, a menudo con un nivel de acceso que ningún usuario humano recibiría. Sin controles de identidad y monitoreo sólidos, las organizaciones a menudo solo descubren estos fallos después de que se ha hecho daño real.

Para las empresas que pasan de pilotos a despliegues reales de AI agente, ¿qué decisiones de identidad y acceso deben tomarse temprano para evitar rediseños costosos más adelante?

Las organizaciones deben decidir temprano cómo se emiten identidades a los agentes, cómo se aprueban los permisos y cómo se revisa el acceso con el tiempo, definiendo límites de identidad desde el principio.

Introducir controles de identidad de forma retrospectiva es casi siempre problemático. Los agentes a menudo están profundamente integrados en flujos de trabajo que utilizan credenciales compartidas o roles amplios, por lo que restringir el acceso después del hecho rompe las suposiciones en las que se basa el sistema. Esto causa fallas en los flujos de trabajo y socava la confianza en la tecnología. Es mucho más barato, y no mencionar más seguro, diseñar identidades, alcances y límites de acceso adecuados desde el principio.

¿Dónde se convierte la integración de identidad más a menudo en un cuello de botella al implementar el AI agente, y qué mejores prácticas ayudan a reducir la fricción?

La gestión de identidad puede convertirse en un cuello de botella, pero solo cuando se trata como un pensamiento posterior. Los equipos se enfocan en construir capacidades de agente impresionantes primero, solo para darse cuenta más tarde de que necesitan integrarse con sistemas de IAM, pasarelas de API y plataformas de registro para ser verdaderamente seguros.

El mejor enfoque es comenzar con una comprensión clara y una implementación adecuada de plataformas de identidad, y luego diseñar agentes para que se ajusten a ellas. Las organizaciones deben reutilizar estándares y infraestructura existentes en lugar de evitarlos; cortar este corner inevitablemente causará problemas más adelante. Cuando la identidad se construye desde el principio, acelera el despliegue en lugar de frenarlo.

Para los líderes de seguridad y ingeniería que desean adoptar el AI agente pero están preocupados por la gobernanza y el riesgo, ¿qué consejo les darías mientras planean su hoja de ruta?

Desacelera solo lo suficiente para poner los cimientos correctos. Los agentes de AI deben ser tratados como identidades, y así necesitas aplicar la misma gobernanza que esperas para los humanos, e insistir en la visibilidad desde el principio. Si una organización hace eso, entonces escalar el AI agente se convierte en un ejercicio de seguridad, no en un salto ciego y arriesgado de fe.

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