Muchos equipos que implementan agentes de IA han hecho una concesión en materia de seguridad que no eligieron conscientemente. Le proporcionaron al agente una cuenta de servicio, tal vez una clave API compartida; algo con acceso suficiente para realizar su trabajo, almacenado en un archivo de configuración o una variable de entorno. Realmente funciona. El agente llama a las APIs correctas, las demostraciones se ejecutan sin problemas y el proyecto se entrega.
Lo que realmente han hecho es recrear el problema de la cuenta de servicio, solo que ahora el principal opera de forma autónoma, a gran velocidad, y su "juicio" puede verse influenciado por cualquier texto que lea en una solicitud.
Quiero plantear un argumento concreto: regular el acceso de los agentes de IA no es un problema nuevo que requiera nuevas herramientas. Las herramientas de gestión de acceso privilegiado (PAM) que ya tiene —acceso justo a tiempo (JIT), grabación de sesiones, aplicación del principio de mínimo privilegio y registros de auditoría— se vuelven más importantes, no menos. En cambio, lo que necesita evolucionar es el modelo de identidad, y esa evolución tiene implicaciones sobre qué arquitecturas PAM son realmente adecuadas para la tarea.
El problema de tratar a un agente como una cuenta de servicio
Una cuenta de servicio es una identidad estática. Tiene credenciales y permisos, y cuando algo sale mal, el registro de auditoría indica qué cuenta hizo qué. La solución es clara: rotar la credencial, restringir los permisos y seguir adelante.
Un agente de IA es un tipo diferente de principal. Existen varias razones por las que no se ajusta perfectamente al modelo de cuenta de servicio:
Funciona en nombre de un ser humano.
Cuando un analista del centro de operaciones de seguridad (SOC) le pide a un agente que investigue un servidor de producción, el agente no actúa por criterio propio; está ejecutando una directiva de una persona específica. La identidad de esa persona debe constar en el registro de acceso. Una cuenta de servicio no incluye ese contexto. «El agente accedió al servidor» es una afirmación más débil que «El agente de Jason accedió al servidor, después de una sesión que Jason inició a las 6:51 p. m. tras completar la autenticación multifactor».
Sus instrucciones pueden ser manipuladas
Una cuenta de servicio hace lo que su código le indica que haga. Un agente de IA procesa el lenguaje natural, lo que significa que una sugerencia bien elaborada puede hacer que casi cualquier cosa suene como un siguiente paso razonable. El límite de seguridad que protege una cuenta de servicio —el código en sí— no se aplica de la misma manera. La solución consiste en añadir capas de control alrededor del agente que no evalúen la intención y que no se vean anuladas por una entrada manipulada.
Las credenciales estáticas representan un único punto de fallo a gran escala.
A medida que proliferan los agentes, el alcance de una credencial compartida aumenta con cada agente que la utiliza. Un archivo de configuración comprometido no solo expone un servicio; expone todos los sistemas con los que interactúa la credencial, a través de todos los agentes que la utilizan.
La solución no reside en un marco de agente sofisticado ni en un nuevo tipo de clave API. Es la misma respuesta que dio PAM para el acceso privilegiado humano: No emita credenciales permanentes en absoluto. Otorgue acceso justo a tiempo, limítelo a la sesión, registre lo sucedido y no deje nada que pueda ser robado cuando finalice la sesión.
Gobernanza de agentes de IA en la práctica: un caso de uso del flujo de trabajo SOC
A principios de este año, desarrollé una demostración funcional de un flujo de trabajo SOC asistido por IA que permitía a un analista de seguridad, mediante una interfaz de chat, dirigir a un agente para investigar un servidor de producción que se ejecutaba en nuestra infraestructura de laboratorio. El agente no contaba con las credenciales necesarias para el entorno de producción.
Grabamos la sesión de principio a fin. Cuando el analista inició la sesión, esta fue la secuencia de eventos que se desarrolló:
- El analista se autenticó a través de Okta con MFA (autenticación multifactor), una verificación de identidad real, no un token de servicio.
- El agente realizó un intercambio de tokens OAuth 2.0 (RFC 8693), que es el paso de delegación que produce un token que contiene tanto la identidad del humano (sub = firstname.lastname@com.com) como la identidad del agente (cid = ag_ir_forensic_7f3a2). Ambos presentes, ninguno omitido. Para que existiera este token, la persona tenía que estar presente.
- Okta Privileged Access (OPA) validó el token con respecto al conector de carga de trabajo y la política configurados para confirmar que el agente estaba autorizado a acceder a esta clase de servidor bajo estas condiciones.
- OPA emitió un certificado SSH de corta duración a través del cliente PAM, que recibió una carga útil cifrada, gestionó la conexión a través de la puerta de enlace de OPA y se encargó del descifrado allí. El agente nunca tuvo una credencial legible.
- El agente se conectó a través de la puerta de enlace privilegiada de Okta, que es la única vía de acceso a la red en el entorno de producción. Los servidores de producción no eran directamente accesibles desde el sistema informático del agente; la puerta de enlace era el único puente de acceso, y solo para sesiones que cumplían con las políticas establecidas.
Tiempo total transcurrido desde el navegador del analista hasta una sesión segura en un servidor de producción: 37 segundos.
El agente encontró una shell inversa en el primer comando, ejecutó nc como root y se conectó a una IP externa. Ese es el caso de uso: rápido, controlado y totalmente auditado.
Cómo el acceso JIT elimina los privilegios permanentes para los agentes de IA
Hay algunos detalles de ese proceso que merece la pena analizar. En primer lugar, el acceso JIT aquí funciona en dos niveles:
- OPA emitió un certificado SSH efímero limitado a esta sesión.
- OPA también creó una cuenta de sistema operativo local en el host de producción para esta sesión, la cual se eliminó al finalizar la misma. No había ninguna cuenta persistente en el servidor esperando a ser comprometida.
Aplicar el privilegio mínimo con políticas sudo en tiempo de ejecución.
La aplicación del permiso sudo en tiempo de ejecución merece una mención aparte, ya que es el control que aborda lo que realmente preocupa a la mayoría de la gente con respecto a los agentes en producción: las historias que circulan sobre agentes que se descontrolan, eliminan bases de datos y sobrescriben archivos. Esos escenarios requieren acceso de escritura. Nuestro agente forense necesitaba acceso a producción, pero operaba en modo de solo lectura, y la política sudo gestionada centralmente por OPA lo imponía a nivel del sistema operativo, no a través de una solicitud del sistema, ni a través de la lógica de la aplicación, ni mediante el propio criterio del agente sobre lo que era apropiado.
Pero la política no solo frenó las conductas destructivas. Esto reforzó los límites específicos de lo que este agente debería haber estado haciendo, lo cual es importante incluso para las operaciones de lectura. En las pruebas, el propio razonamiento del LLM detectó de forma fiable las solicitudes para que el agente leyera /etc/shadow; era bastante obvio que el límite flexible se mantenía.
Sin embargo, pedirle al agente que analizara un mapa de memoria de proceso era diferente. Dado que esa solicitud era plausible desde el punto de vista forense y no destructiva, después de algunos intentos, la capa de razonamiento del agente accedió a intentarlo. De todas formas, la política sudo de OPA lo bloqueó. La cuestión no es que el LLM haya fracasado; es que la política no depende de que el LLM acierte. La persona que creó el paquete sudo pensó detenidamente en a qué debería y a qué no debería tener acceso un analista de SOC. Ese criterio se aplica en tiempo de ejecución, independientemente de lo que el agente considere razonable.
Trazando la identidad humana a través del registro de auditoría de PAM
El registro de auditoría también es importante aquí. El registro del sistema de Okta contiene siete eventos para esa sesión, desde el inicio de sesión único (SSO) del analista hasta el inicio de sesión SSH en el servidor de producción. Todos los eventos están vinculados. La identificación del usuario humano está presente en toda la cadena.
El WorkloadPrincipal en los eventos PAM no es solo "un agente", sino opa://pam-fbach/IR-Forensic-Agent/firstname.lastname@com.com (el equipo propietario de este agente, el contexto de política bajo el cual se ejecutó y la persona que lo autorizó). Los tres en un mismo campo de registro PAM. El correo electrónico del usuario humano figura en el registro PAM porque estaba incluido en el token y provenía del mismo sistema de identidad que autenticó al analista en primer lugar.
Esa es la historia de la rendición de cuentas. No «un agente accedió al servidor», sino más bien: «el agente de Firstnames accedió al servidor, aquí está el certificado que utilizó, aquí está la grabación de la sesión, aquí están todos los tokens de la cadena que lo autorizaron».
Por qué la fundación IdP no es opcional
Aquí es donde quiero presentar un argumento más contundente a favor de que los arquitectos de seguridad evalúen a los proveedores de PAM.
Muchos proveedores de PAM empresariales admiten la autenticación mediante JSON Web Token (JWT). Muchos admiten la autenticación JWT/OIDC y permiten vincular reclamaciones con políticas. Esto funciona, pero "aceptar el JWT" y "comprender la identidad de forma nativa" no son lo mismo.
Cuando el proveedor de identidad (IdP) y el PAM son la misma plataforma, existen algunas diferencias estructurales:
- El registro del agente reside en el IdP: el conector de carga de trabajo de OPA se vincula al
ciddel agente, que no es una cadena en un archivo de configuración de políticas, sino una referencia en tiempo real a una entidad principal registrada. Revocar la provisión del agente en Okta revoca el acceso. - El registro de auditoría es un flujo único: el evento SSO del analista, la concesión de tokens, la emisión de credenciales PAM, el inicio de sesión SSH; todo ello se encuentra en el registro del sistema de Okta y se puede consultar conjuntamente. Con un proveedor de PAM independiente, se combinan dos sistemas de auditoría para reconstruir lo sucedido.
- La identidad humana en el registro PAM no es una reclamación mapeada que sobrevivió a una transferencia: es la misma identidad que se autenticó al inicio de la cadena, sin salir nunca del límite de confianza de la plataforma.
Para el acceso con privilegios humanos, la integración IdP-PAM resultaba conveniente, ya que permitía el inicio de sesión único (SSO) en la consola PAM y, posiblemente, el aprovisionamiento SCIM. Sin embargo, en lo que respecta al acceso de los agentes de IA, se trata de una cuestión arquitectónica. La rendición de cuentas depende de que la identidad humana se transmita intacta desde la autenticación, pasando por la delegación, hasta el acceso, y cada límite de confianza que cruza representa una oportunidad para que se pierda, se registre incorrectamente o, simplemente, no quede registrada.
Esa preocupación arquitectónica no se aplica únicamente al acceso privilegiado a la infraestructura.
El flujo de trabajo SOC descrito anteriormente no es una integración puntual, sino una expresión de una arquitectura más amplia. Okta para agentes de IA responde a tres preguntas a las que se enfrenta todo equipo de seguridad que implementa agentes: ¿Dónde están mis agentes? ¿A qué pueden conectarse? ¿Qué pueden hacer?
Okta Privileged Access es la forma en que respondemos a la tercera pregunta para los objetivos de mayor riesgo: infraestructura de producción, sistemas sensibles y cualquier lugar donde un agente comprometido o manipulado pueda causar daños reales. Los mismos principios que rigen la pareja (human, agent) en el flujo OPA —que están vinculados al contexto del usuario en cada acción, ámbitos de privilegios mínimos, credenciales efímeras y un registro de auditoría inmutable— se extienden a través de los servidores MCP, las API SaaS, las llamadas de agente a agente y las conexiones de servicio con credenciales. El acceso de agentes a un servidor de producción es precisamente el caso en el que cometer errores resulta más costoso, por lo que es importante establecer una base sólida de IdP-PAM antes de que el número de agentes se dispare.
La conclusión
Los agentes de IA son los nuevos actores privilegiados en la infraestructura empresarial. El modelo de amenaza es conocido: credenciales permanentes, cuentas con privilegios excesivos, ausencia de registro de auditoría. La diferencia con los agentes es que estos problemas ocurren más rápidamente y son más difíciles de detectar.
Los elementos básicos sobre los que se basa PAM, como el acceso JIT, la grabación de sesiones, el almacenamiento seguro de credenciales, la aplicación de políticas y los controles de elevación de privilegios, no pierden relevancia cuando el principal es una IA. Se convierten en el elemento que hace que el acceso agente sea seguro de implementar desde un principio.
Lo que tiene que evolucionar es el modelo de identidad. El principal ahora es un par (humano, agente). Ambas identidades deben constar en el registro. Reconstruir la responsabilidad a posteriori, como «¿de quién fue este agente y quién lo autorizó?» requiere que la plataforma comprenda ese par desde el principio, y no que lo reconstruya a partir de registros de dos sistemas.
Si su arquitectura PAM actual trata el acceso de los agentes como un problema de cuenta de servicio, vale la pena preguntarse si fue diseñada para un mundo donde el principal tiene dos identidades, opera de forma autónoma y necesita un sistema de gobierno que no se fíe de su palabra respecto a lo que se le ha pedido que haga.
Estos materiales se ofrecen únicamente con fines informativos generales y no constituyen asesoramiento legal, de privacidad, de seguridad, de cumplimiento ni empresarial. © Okta, Inc. o sus filiales.
