Las contraseñas se convirtieron en un problema de seguridad porque podían separarse de las personas a las que debían autenticar. Una vez compartida o robada, la misma clave secreta podía reutilizarse hasta que alguien detectara el uso indebido y revocara la credencial. Las empresas han pasado años alejándose de ese modelo para adoptar sistemas de acceso vinculados más estrechamente a la identidad y el contexto de la persona que realiza la solicitud.
Los agentes de IA están introduciendo esa misma vulnerabilidad en los flujos de trabajo automatizados, pero a una velocidad propia de las máquinas y a través de múltiples sistemas. Una credencial otorgada para una tarea legítima puede permanecer activa después de que finalice el trabajo, cambie el propósito del agente o la persona que la autorizó pase a desempeñar otro rol.
A diferencia de una aplicación convencional que sigue instrucciones predefinidas, un agente puede decidir qué herramientas utilizar y qué pasos seguir. Por lo tanto, un acceso que persiste más allá de lo necesario puede utilizarse de formas que la persona que lo autorizó nunca previó.
Pensemos en un agente autorizado para elaborar una propuesta de renovación para un cliente. Es posible que necesite acceso temporal a una plataforma CRM, a archivos de precios, al correo electrónico y a un sistema de gestión de contratos. Si dichas conexiones dependen de tokens reutilizables o de una cuenta de servicio permanente, el agente podría conservar el acceso una vez completada la propuesta.
Una instrucción maliciosa insertada en un documento, una herramienta comprometida o un flujo de trabajo posterior podrían llevar al agente a recuperar o transmitir información ajena a la tarea original.
Las claves secretas estáticas no tienen cabida en los flujos de trabajo autónomos.
Las credenciales reutilizables son peligrosas porque convierten el acceso en una cuestión de posesión. Quienquiera —o lo que sea— que posea la clave secreta puede utilizarla hasta que la credencial caduque, se renueve o sea revocada. Ese modelo conlleva riesgos para los usuarios humanos, pero las consecuencias son mayores cuando se aplica a agentes capaces de utilizar herramientas, interactuar con aplicaciones y activar flujos de trabajo.
A menudo, los equipos conectan los agentes a credenciales existentes para que estos puedan realizar tareas empresariales. Ese atajo convierte al agente en un titular independiente del acceso, en lugar de un ejecutor temporal de las instrucciones de una persona. Además, combina dos riesgos que las empresas han gestionado tradicionalmente por separado: el robo de la credencial o la posibilidad de que el agente utilice una credencial válida para realizar una acción no autorizada o no prevista.
Una vez que esto sucede, la empresa puede perder el vínculo entre la credencial, la persona que autorizó su uso y la tarea para la que se concedió. Un registro de acceso convencional podría mostrar qué token invocó una interfaz de programación de aplicaciones (API) y en qué momento. Es posible que no se muestre quién dio las instrucciones al agente, qué objetivo perseguía, qué decisiones intermedias tomó o si la acción resultante se mantuvo dentro de los límites del encargo original.
Lo que la autenticación humana puede enseñarnos.
La autenticación moderna sin contraseñas ofrece una lección útil para la seguridad de los agentes. En lugar de pedir a los usuarios que presenten un secreto reutilizable, se basa en una prueba criptográfica vinculada a un autenticador y evalúa la identidad, el dispositivo y el contexto de la solicitud. Esto hace que las credenciales sean más difíciles de robar, compartir o reutilizar en ataques de repetición.
El acceso de los agentes debería seguir el mismo principio, sin tratarlos exactamente igual que a los usuarios humanos. En lugar de almacenar un secreto de larga duración, un agente debería solicitar acceso para un fin concreto; cada solicitud se evaluaría teniendo en cuenta la autoridad de la persona, la tarea asignada al agente y el riesgo de la acción propuesta.
Cualquier acceso concedido debería limitarse a los sistemas, datos y acciones necesarios, y finalizar cuando se complete la tarea o cambie la autoridad subyacente. Es posible que los agentes deban actuar con rapidez, pero la velocidad no exige la posesión permanente de credenciales confidenciales.
Control de la autoridad delegada.
El aspecto más complejo del acceso de los agentes no es su autenticación, sino controlar qué sucede una vez que una persona les delega autoridad.
Cuando una persona ordena a un agente que actúe, este ejerce una autoridad delegada. Sus permisos pueden derivar del rol de dicha persona, de las políticas que rigen el proceso empresarial o de las restricciones impuestas por el servicio de destino. Cada acción debe poder rastrearse hasta la persona que inició la tarea y hasta las políticas que la autorizaron.
Dicha cadena resulta más difícil de preservar cuando un agente invoca varias herramientas, llama a otro agente o continúa trabajando una vez que la persona que inició la tarea ya no está presente. Los equipos de seguridad deben ser capaces de determinar no solo quién inició el proceso, sino también qué aprobó esa persona y si todas las acciones posteriores se mantuvieron dentro de esos límites.
Un token, por sí solo, no preserva esa cadena de autoridad. Puede identificar un alcance y una fecha de caducidad, pero no establece necesariamente quién delegó la tarea, cómo se autenticó a esa persona, qué resultado se aprobó o si dicha persona seguía teniendo la facultad de autorizarlo.
Aquí es donde la verificación de identidad y la autenticación se vuelven fundamentales para la gobernanza de agentes. Cuanto mayor sea el riesgo de la acción, mayor será la confianza que la empresa necesite tener en la identidad y la autoridad de la persona que la delega. Las actividades rutinarias pueden basarse en la autenticación y las políticas existentes, mientras que los flujos de trabajo confidenciales pueden requerir una verificación adicional o pruebas de identidad más rigurosas antes de permitir que un agente actúe.
El acceso intermediado tiene límites.
La abstracción de credenciales ofrece a los equipos de seguridad una forma práctica de mantener los secretos reutilizables fuera de los flujos de trabajo de los agentes. En lugar de incluir una clave de API en la configuración de un agente o asignarle una cuenta de servicio permanente, la organización almacena la credencial detrás de un intermediario o una capa de aplicación de políticas.
El agente debe solicitar acceso a través de esa capa para cada acción específica. El intermediario evalúa la política, el riesgo y el contexto de identidad antes de emitir una credencial de corta duración limitada a esa acción. Que sea de corta duración no significa automáticamente que sea de bajo riesgo; una credencial válida solo por unos minutos puede permitir, aun así, un pago perjudicial, una transferencia de datos o un cambio de configuración. Su alcance debe restringir lo que el agente puede hacer, no simplemente cuánto tiempo puede permanecer conectado.
Las solicitudes de mayor riesgo pueden activar procesos de aprobación adicionales o una verificación de identidad más estricta. En entornos heredados, el intermediario puede conservar una credencial de larga duración e impedir que el agente acceda a ella directamente.
Limitar el acceso según el sistema, los datos, la acción y la duración reduce el posible radio de impacto y crea un registro de auditoría más claro. De este modo, cada acción puede vincularse a la persona que inició la tarea, a la autoridad delegada al agente y a la política bajo la cual se aprobó.
Sin embargo, estas medidas de protección fallan si un agente puede acceder directamente al sistema de destino o transferir el trabajo a otro agente fuera de la ruta de control. Los controles de red y de terminales (*endpoints*) deben bloquear dichas rutas, mientras que los registros de auditoría preservan la conexión entre la solicitud original, la autoridad que la respalda y la acción resultante.
Qué deben hacer ahora los equipos de seguridad.
Las organizaciones deben comenzar por identificar qué agentes pueden acceder a los sistemas empresariales, qué credenciales utilizan y quién autorizó dichas conexiones. Las credenciales integradas en las configuraciones de los agentes o asociadas a cuentas de servicio permanentes requieren un escrutinio especial.
Los equipos de seguridad deben restringir el acceso según el sistema, los datos, la acción y la duración. Las actividades sensibles pueden requerir una autenticación más robusta o una aprobación explícita, mientras que los controles de red y de terminales deben impedir que los agentes eludan la ruta de acceso intermediada.
El acceso de los agentes también debe revisarse cuando los empleados cambian de rol, se modifican los flujos de trabajo, se añaden herramientas o los agentes comienzan a delegar tareas a otros agentes. Dichos cambios pueden ampliar el alcance práctico de una credencial existente, incluso cuando sus permisos documentados permanecen inalterados.
Evitar una nueva generación de contraseñas.
Los agentes de IA pueden acelerar la proliferación de credenciales y magnificar su impacto en el negocio. Si los equipos conectan agentes copiando claves en las configuraciones o asociándolas a cuentas de servicio permanentes, pierden el control sobre dónde residen los privilegios, cómo se utilizan y cuándo deben revocarse.
Un enfoque más adecuado consiste en mantener las credenciales privilegiadas fuera del alcance de los agentes y conceder permisos únicamente para la tarea específica que se está realizando. Mediante políticas, se vincula dicha autoridad a una fuente verificada y se revoca el acceso del agente una vez finalizado el trabajo o cuando cambian las condiciones que justificaron su concesión.
De este modo, las organizaciones pueden utilizar agentes sin permitir que un acceso específico para una tarea se convierta en un derecho permanente, evitando así reproducir el problema de las contraseñas que tanto tiempo y esfuerzo costó resolver.
