Cuando un agente de inteligencia artificial utiliza la credencial de un usuario humano para acceder a bases de datos, el sistema no obtiene una «identidad de agente» oculta detrás de la cuenta; ve al propio usuario. Esta es la conclusión central de una medición realizada por Naseeb Ahmed Mian en un entorno de producción que utiliza Azure, Azure CLI y sqlcmd.
En la configuración examinada, las habilidades del agente de software se conectaban a las bases de datos mediante el comando sqlcmd, utilizando la autenticación a través de Azure CLI. El comando extrae el token de acceso almacenado en caché después del inicio de sesión del usuario y luego lo presenta a la base de datos. Como resultado, las conexiones aparecían con el nombre del usuario, el nombre de su dispositivo y la herramienta sqlcmd, tanto si él mismo había escrito la consulta como si la había ejecutado el agente.
El registro de auditoría ve la credencial, pero no ve la intención
El registro de la sesión mostró el nombre de inicio de sesión del usuario, el nombre de la estación de trabajo y la interfaz del cliente, pero no incluía un campo que distinguiera las acciones ejecutadas por el agente. De este modo, las consultas humanas y automatizadas se vuelven idénticas en el registro, y los controles posteriores no pueden aplicar una tasa de solicitudes, un paso de aprobación o una política de retención diferentes en función del origen de la ejecución.
El problema no se limita a las investigaciones de seguridad. Si posteriormente se cuestiona una consulta ejecutada meses atrás, el registro no demostrará si la escribió el usuario o si la ejecutó una herramienta automatizada. Es preciso al atribuir la acción a la credencial, pero guarda silencio sobre la intención y el autor real.
¿Qué revela el token de acceso?
El token entregado por Azure CLI contenía el alcance user_impersonation, además de una declaración que indicaba que la autenticación había incluido un factor de autenticación multifactor. En la práctica, cada acción ejecutada por el agente llega acompañada de una prueba de que el usuario superó la autenticación multifactor, aunque eso haya ocurrido horas antes y en el contexto de una tarea diferente.
Además, la duración del token, de 84 minutos, no representa necesariamente el final de la ejecución del agente. La CLI renueva automáticamente el token mediante un token de actualización, por lo que la ejecución desatendida puede continuar hasta que expire el token de actualización o se deshabilite la cuenta del usuario.
La pertenencia a grupos amplía el panorama
El examen de las asignaciones de roles mostró una sola fila: el rol Reader en una suscripción no productiva. Sin embargo, el token de acceso incluía 37 grupos, mientras que una consulta de pertenencia directa mostraba 34 grupos, con la existencia de grupos anidados. Entre los grupos relacionados con el acceso había roles como visor de bases de datos SQL, usuario con privilegios elevados, colaborador de recursos y administrador de bases de datos.
El peligro reside en que estas pertenencias pueden contener los permisos efectivos en la capa de datos y no aparecer necesariamente en las comprobaciones de roles de la capa de control. Por ello, el alcance de acceso del agente puede parecer limitado al revisar el método tradicional, mientras que su pertenencia a grupos le concede una capacidad mayor.
¿Qué cambia en la práctica?
Al probar la misma identidad en dos almacenes de producción con una diferencia de una hora, aparecieron dos resultados muy divergentes. En uno de ellos, la identidad tenía únicamente los permisos CONNECT y SELECT y no podía conectarse a la capa segura. En cambio, otro punto de análisis de producción mostró 430 tablas y 107 permisos que incluían lectura, escritura, definición del esquema y administración de la base de datos.
La comparación demuestra que el alcance de los permisos no lo determina únicamente la identidad; la ruta de acceso, el motor y los controles asociados al punto final también son factores decisivos. Un punto final puede ser de solo lectura según su documentación, mientras que sus reglas de seguridad no necesariamente se aplican cuando los datos se solicitan a través de otro motor.
Lectura editorial de certi.news: el problema no es que el agente esté «sin identidad», sino que la identidad humana se utilizó como sustituto rápido de una identidad automatizada independiente. Esto falla en tres puntos: atribución, amplitud de los permisos y revocación. La medición también mostró que el entorno en el que la credencial tenía capacidad de eliminar datos de una base de datos segura era el único entorno en el que no se había activado un registro de auditoría. Siguen abiertas preguntas importantes sobre la coherencia de la pertenencia a grupos, la persistencia de los permisos temporales dentro de los tokens emitidos y la capacidad de las organizaciones para registrar la intención de ejecución, no solo al titular de la credencial.