Jacob Ideskog, director de tecnología de Curity – Serie de entrevistas

Jacob Ideskog Es especialista en identidad y director de tecnología de Curity. Dedica la mayor parte de su tiempo a trabajar con soluciones de seguridad en el ámbito de las API y la web. Ha trabajado tanto en el diseño como en la implementación de soluciones OAuth y OpenID Connect para grandes empresas, así como para pequeñas startups.

Curidad Es una plataforma moderna de gestión de identidades y accesos (IAM) basada en Curity Identity Server, una solución basada en estándares diseñada para proteger la autenticación y la autorización de aplicaciones, API y servicios digitales a gran escala. Es compatible con protocolos como OAuth 2.0 y OpenID Connect para centralizar los flujos de inicio de sesión, aplicar políticas de acceso detalladas y emitir tokens seguros tanto para usuarios humanos como para clientes informáticos, incluyendo API y servicios. La plataforma está diseñada para ofrecer flexibilidad y escalabilidad, lo que permite a las organizaciones implementar en entornos en la nube, híbridos o locales, integrarse con sistemas existentes y ofrecer experiencias de usuario seguras y fluidas sin depender de una infraestructura de seguridad personalizada.

Ha dedicado gran parte de su carrera al desarrollo de sistemas de seguridad de identidad y API, desde la cofundación de Curity hasta su liderazgo como director de tecnología durante el auge de la nube y, ahora, de la IA. ¿Cómo ha influido esta trayectoria en su visión de que los agentes de IA deben ser tratados como identidades digitales de primera clase y no como un simple software más?

En todos los campos tecnológicos en los que he trabajado, un problema persiste. Ya sea computación en la nube o, ahora, inteligencia artificial, si el software actúa en nombre de una persona u otro sistema, se produce un problema de identidad.

Con la adopción masiva de la IA con agentes, este problema se agrava. Su comportamiento ya no está estrictamente programado y operan con un nivel de autonomía sin precedentes para las empresas. Los agentes de IA toman decisiones, acceden a las API y encadenan acciones entre sistemas, a menudo sin supervisión humana directa. Este comportamiento genera desafíos de identidad y acceso que son fundamentalmente diferentes a los del software tradicional.

Tratar a los agentes de IA como identidades digitales de primera clase es la única manera de abordar esto adecuadamente. Si las organizaciones los tratan como un proceso o cuenta de servicio más, pierden visibilidad y control muy rápidamente, y eso es la clave para una crisis de seguridad.

Muchas empresas están entusiasmadas con la IA con agentes, pero siguen estancadas en la experimentación. A juzgar por lo que se observa en implementaciones reales, ¿cuáles son las brechas de identidad y gobernanza más comunes que impiden a las organizaciones escalar agentes de forma segura?

La mayor parte de la experimentación se realiza en entornos aislados que ignoran lo que sucede a escala. Durante las primeras pruebas piloto, los equipos suelen otorgar a los agentes claves de API amplias, credenciales compartidas o permisos generales en la nube solo para poner en marcha el proyecto.

Este enfoque fracasa en el momento en que se implementan agentes más allá de los pilotos. Esto se debe a que los equipos de seguridad no pueden ver a qué datos ha accedido un agente, sus acciones ni si puede o ha excedido su alcance previsto, ya sea accidental o maliciosamente. Estos puntos ciegos impiden la gestión segura de los agentes, razón por la cual muchas organizaciones tienen dificultades para avanzar más allá de los pilotos.

Ha argumentado que unas medidas de seguridad estrictas son esenciales para la IA agencial. ¿Cómo se ve en la práctica un buen diseño de identidad para los agentes de IA y en qué aspectos suelen fallar las empresas?

Un buen diseño de identidad parte del principio del mínimo privilegio y de permisos vinculados a una intención explícita. Cada agente de IA debe tener su propia identidad, permisos con un alcance limitado y relaciones de confianza claramente definidas (reglas explícitas sobre con qué sistemas puede interactuar). Fundamentalmente, el acceso debe estar limitado a un propósito, tener una duración limitada y ser fácil de revocar.

Las empresas se equivocan al reutilizar las cuentas de servicio existentes o al asumir que los agentes internos son seguros por defecto. Esta suposición no se sostiene ante amenazas reales. Los actores maliciosos buscan activamente precisamente estos puntos débiles, y los agentes de IA aumentan drásticamente el radio de acción potencial cuando el diseño de la identidad es descuidado.

Curity lleva mucho tiempo trabajando con estándares como OAuth y OpenID Connect. ¿Qué tan cruciales son los estándares de identidad abiertos para que la IA de la agencia sea interoperable y segura en entornos empresariales complejos?

Los estándares abiertos son absolutamente cruciales. Las empresas ya utilizan estructuras de identidad complejas que abarcan plataformas en la nube, servicios SaaS y API internas. La IA agente solo añade más complejidad.

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

Las identidades no humanas son cada vez más comunes, desde cuentas de servicio hasta identidades de máquina. ¿Qué diferencia fundamentalmente a los agentes de IA de las identidades no humanas anteriores desde una perspectiva de seguridad?

La diferencia clave entre los agentes de IA modernos y las identidades no humanas (NHI) más antiguas reside en la autonomía. Una cuenta de servicio tradicional hace exactamente lo que su código le indica, estrictamente vinculada a su tarea. Un agente de IA interpreta instrucciones, adapta su comportamiento y realiza acciones que nunca fueron programadas explícitamente, lo que aumenta el riesgo potencial si no existen las medidas de seguridad adecuadas.

Un pequeño error de identidad o acceso puede convertirse rápidamente en una catástrofe, ya que un agente puede actuar con rapidez y en múltiples sistemas. Desde una perspectiva de seguridad, esto representa un riesgo importante.

¿Qué importancia tienen los registros de auditoría y los registros basados ​​en identidad para la gobernanza de la IA agente, especialmente en industrias reguladas?

Los registros de auditoría no deberían ser una mera cuestión de gustos. Deben estar integrados desde el principio. En entornos regulados, se espera que las organizaciones respondan a preguntas sencillas pero cruciales: ¿A qué accedió este agente, cuándo lo hizo y quién lo autorizó?

El registro basado en identidad es la única forma fiable de lograr ese nivel de responsabilidad. Además, desempeña un papel fundamental en la respuesta a incidentes. Sin un contexto de identidad claro, es casi imposible determinar si un problema se originó en un agente con mal comportamiento, una identidad comprometida o simplemente un mensaje incorrecto.

¿Qué riesgos reales cree que surgen cuando las organizaciones implementan agentes de IA con privilegios excesivos o mal monitoreados en producción?

Un riesgo común es la agregación silenciosa de datos. Un agente con privilegios excesivos puede extraer información confidencial de múltiples sistemas (registros de clientes, documentos internos, registros) y luego exponerla mediante avisos, resúmenes o integraciones externas.

Otro riesgo es que los agentes con acceso administrativo realicen cambios importantes a la velocidad de una máquina, causando mucho más daño del que un humano podría causar en poco tiempo. Esto puede incluir modificar recursos en la nube, deshabilitar controles de seguridad o activar flujos de trabajo automatizados sin supervisión.

Estos incidentes pueden ser maliciosos, pero no tienen por qué serlo. Un agente con demasiados privilegios o mal supervisado podría simplemente estar operando con suposiciones obsoletas o incorrectas, amplificando los errores en múltiples sistemas sin que nadie se dé cuenta.

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

Para las empresas que pasan de pilotos a implementaciones de agentes reales, ¿qué decisiones sobre identidad y acceso se deben tomar con anticipación para evitar rediseños costosos más adelante?

Las organizaciones deben decidir con anticipación cómo se emiten identidades a los agentes, cómo se aprueban los permisos y cómo se revisa el acceso a lo largo del tiempo, definiendo los límites de identidad de antemano.

Implementar controles de identidad de forma retroactiva casi siempre es problemático. Los agentes suelen estar profundamente integrados en los flujos de trabajo mediante credenciales compartidas o roles amplios, por lo que restringir el acceso a posteriori rompe las premisas en las que se basa el sistema. Esto, en última instancia, provoca fallos en los flujos de trabajo y socava la confianza en la tecnología. Es mucho más económico, y mucho más seguro, diseñar identidades, alcances y límites de acceso adecuados desde el principio.

¿Dónde la integración de identidad se convierte con mayor frecuencia en un cuello de botella al implementar una IA agente y qué prácticas recomendadas ayudan a reducir la fricción?

La gestión de identidades puede convertirse en un cuello de botella, pero solo cuando se trata como algo secundario. Los equipos se centran primero en desarrollar capacidades de agente impresionantes, solo para darse cuenta después de que necesitan integrarse con sistemas IAM, puertas de enlace 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 las plataformas de identidad y, posteriormente, diseñar agentes que se adapten a ellas. Las organizaciones deberían reutilizar los estándares y la infraestructura existentes en lugar de ignorarlos; omitir este paso inevitablemente causará problemas en el futuro. Cuando la identidad se integra desde el principio, se acelera la implementación en lugar de ralentizarla.

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

Disminuya la velocidad lo suficiente para sentar las bases. Los agentes de IA deben tratarse como identidades, por lo que debe aplicar la misma gobernanza que espera para los humanos e insistir en la visibilidad desde el principio. Si una organización logra esto, escalar la IA agética se convierte en un ejercicio de seguridad, no en un acto de fe ciega y arriesgado.

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