El agente de IA hereda tus credenciales: el riesgo oculto en la pyme

La adopción de agentes de IA en entornos empresariales avanza rápidamente, pero a menudo pasamos por alto un aspecto crítico: la identidad y los permisos con los que operan. Un reciente artículo de The New Stack pone el foco en una práctica común pero peligrosa: dar a un agente de IA las credenciales personales de un empleado. El autor, tras entregar sus credenciales de Azure a un agente de codificación, midió qué podía hacer realmente y descubrió resultados preocupantes.

El experimento reveló que el agente podía acceder a dos permisos en un almacén de producción y a 107 en otro. Además, el entorno donde podía borrar datos de una base segura era el único sin auditoría activada. Estos hallazgos no son meras anécdotas: reflejan un modelo de identidad que rara vez se diseña conscientemente.

Autenticación por suplantación: el token lo dice todo

Cuando un agente se autentica usando las credenciales de un humano, el token de acceso resultante incluye el ámbito user_impersonation. Según el RFC 8693, esto significa que el agente recibe todos los derechos del usuario y es indistinguible de él. En la práctica, el agente se convierte en una extensión del empleado, con sus mismos privilegios y sin una identidad propia que lo diferencie.

El token también incluye la afirmación mfa, lo que indica que cada acción del agente lleva adjunta la attestación de que un humano completó un segundo factor. Esto puede dar una falsa sensación de seguridad, ya que el MFA se realizó horas antes para otra tarea. Además, aunque el token tiene una vida de 84 minutos, el CLI lo renueva automáticamente, por lo que un proceso desatendido puede seguir operando indefinidamente hasta que el refresh token expire o se desactive la cuenta de usuario.

Para una pyme, esto significa que si un empleado con altos privilegios conecta un agente a sus credenciales, ese agente podrá hacer todo lo que el empleado puede hacer, sin control adicional. Y lo que es peor, las acciones del agente quedarán registradas a nombre del empleado, dificultando la atribución.

Autorización basada en grupos: el agujero en la auditoría

El artículo describe cómo, al revisar las asignaciones de roles directas, solo aparecía un rol de lector en una suscripción no productiva. Sin embargo, la pertenencia a grupos revelaba 34 membresías activas y acceso a 7 suscripciones, incluidas las de producción. Los grupos otorgan acceso a datos y viven en el plano de datos, donde las consultas de plano de control no los ven. Un revisor de seguridad que solo mire las asignaciones de roles directas obtendrá una visión sesgada y un falso sentido de un radio de impacto pequeño.

Este patrón es común en organizaciones que gestionan permisos mediante grupos de Active Directory o Azure AD. Para las pymes, es habitual que los equipos de IT otorguen permisos a grupos para simplificar la administración, pero luego no revisen qué hereda un agente cuando se conecta con una cuenta de usuario.

La conclusión es clara: los controles de autorización basados en grupos pueden pasar desapercibidos en las auditorías tradicionales, y los agentes de IA heredan todos esos permisos sin que nadie lo note.

El problema de la auditoría: sin rastro del agente

Otro hallazgo preocupante es que las sesiones de base de datos registran el nombre de inicio de sesión del humano, el nombre del programa (sqlcmd) y el host, pero no hay un campo que indique si la consulta fue ejecutada por una persona o por un agente. Esto hace que las acciones del agente y del humano sean idénticas en los registros. Como consecuencia, no se pueden aplicar políticas diferenciadas: ni límites de velocidad, ni pasos de aprobación, ni retención distinta para acciones automatizadas.

Además, si en el futuro se cuestiona una consulta, el humano no puede probar que no fue él quien la ejecutó. La falta de trazabilidad es un riesgo tanto operativo como legal.

En el entorno descrito, el único sistema sin auditoría era precisamente donde el agente podía borrar datos de una base segura. Esto subraya la necesidad de revisar la configuración de auditoría en todos los sistemas, especialmente aquellos con permisos elevados.

¿Qué implica esto para una pyme?

Las pymes suelen tener equipos de IT reducidos y priorizan la agilidad sobre la seguridad. Dar credenciales humanas a un agente es rápido y no requiere infraestructura adicional, pero conlleva riesgos significativos:

• Falta de atribución: no se puede distinguir si una acción la realizó un humano o un agente.
• Permisos excesivos: el agente hereda todos los permisos del usuario, que a menudo son más de los necesarios.
• Revocación complicada: si se revoca el acceso al agente, se revoca también al humano, lo que puede afectar a su trabajo.
• Auditoría insuficiente: los registros no reflejan la intervención del agente, dificultando la investigación de incidentes.

Además, la complejidad de los permisos basados en grupos hace que sea fácil pasar por alto accesos no deseados.

Recomendaciones para equipos de IT

Para mitigar estos riesgos, desde ForgeNEX proponemos una serie de medidas prácticas:

1. Identidades dedicadas para agentes: crear cuentas de servicio específicas para cada agente, con permisos mínimos y revisados periódicamente. Esto permite una atribución clara y una revocación sencilla.
2. Revisión de permisos heredados: auditar no solo las asignaciones directas de roles, sino también la pertenencia a grupos que otorgan acceso a datos. Herramientas como las políticas de acceso condicional pueden ayudar.
3. Habilitar auditoría en todos los sistemas: asegurarse de que todos los almacenes de datos, especialmente los de producción, tengan auditoría activada y que los registros incluyan el origen de la acción (humano o agente).
4. Limitar el alcance de los tokens: evitar el uso de user_impersonation y optar por permisos delegados específicos para el agente. Si no es posible, acortar la vida de los tokens y evitar la renovación automática en procesos desatendidos.
5. Monitorización y alertas: implementar alertas cuando un agente realice acciones inusuales, como borrados o accesos a datos sensibles, incluso si el registro no lo distingue inicialmente.

Como hemos visto en otros artículos, como IA en el SOC: ¿cuánta autonomía ceder sin perder el control?, la clave está en equilibrar la autonomía con el control. Los agentes de IA pueden aportar mucho valor, pero deben operar bajo un modelo de identidad bien definido.

Conclusión

La práctica de dar credenciales humanas a agentes de IA es un atajo que puede salir caro. Las pymes deben tomar conciencia de que los agentes heredan no solo permisos, sino también la identidad y los privilegios de quien les presta sus credenciales. Diseñar una estrategia de identidad para agentes, con cuentas dedicadas y auditoría adecuada, es fundamental para evitar sorpresas desagradables. En ForgeNEX podemos ayudar a implementar estas medidas y a revisar la configuración de tus sistemas para que la IA sea una aliada segura.

Fuente: The New Stack. Análisis y adaptación: ForgeNEX.