Los agentes de IA heredan todos los permisos del usuario, rompiendo las pistas de auditoría y los límites de seguridad

Una reciente investigación de seguridad sobre cómo los agentes de IA se autentican en entornos empresariales ha expuesto brechas críticas en la gestión de identidades y el registro de auditorías. Cuando los desarrolladores permiten que los agentes de codificación utilicen sus propias credenciales almacenadas en caché, estos heredan el alcance completo de los permisos humanos, a menudo eludiendo los límites de seguridad previstos. El estudio, publicado el 8 de octubre de 2026, demuestra que esta práctica colapsa la atribución, haciendo imposible distinguir entre la intención humana y las acciones automatizadas en los registros de bases de datos.

Qué ocurrió

El autor, un ingeniero full-stack, midió los permisos reales que poseía un agente de IA cuando se autenticaba utilizando sus credenciales personales de Azure. Esta configuración es común en flujos de trabajo de desarrollo donde los agentes se conectan a bases de datos mediante herramientas de línea de comandos que aprovechan la sesión existente del desarrollador. La investigación reveló que el agente no tenía una identidad limitada o con alcance restringido; en su lugar, operaba con exactamente los mismos privilegios que el usuario humano, incluidas pertenencias a grupos que eran invisibles para las verificaciones estándar de permisos.

Los resultados variaron drásticamente entre diferentes almacenes de producción accedidos en el plazo de una hora. En un entorno, el agente solo tenía dos permisos, correctamente restringidos al acceso de solo lectura. En otro, el mismo token otorgaba 107 permisos, incluidos derechos de escritura, definición de esquema y administración de bases de datos. Lo más preocupante fue el hallazgo de que el entorno donde el agente podía eliminar datos de una base de datos segura era el único con la auditoría completamente deshabilitada a nivel de servidor. La base de datos informaba que la auditoría estaba habilitada debido a objetos de configuración residuales, pero en realidad no se escribían registros.

Detalles clave

• Herencia de credenciales: Los agentes que usan tokens CLI almacenados en caché se autentican como el usuario humano, con el alcance del token establecido explícitamente en user_impersonation.
• Permisos invisibles: La autorización depende en gran medida de la pertenencia a grupos, que las consultas estándar de asignación de roles suelen pasar por alto, lo que genera una falsa sensación de acceso limitado.
• Brechas de auditoría: El entorno con mayor riesgo (acceso de eliminación) no tenía una pista de auditoría activa, mientras que los entornos más seguros estaban completamente registrados.
• Colapso de la atribución: Los registros de la base de datos anotan el nombre de inicio de sesión y la estación de trabajo del humano, lo que hace imposible probar si una consulta fue escrita por una persona o ejecutada por un agente.
• Longevidad del token: Aunque los tokens de acceso tienen vidas cortas, los mecanismos de actualización automática permiten que los agentes sin supervisión mantengan el acceso indefinidamente hasta que se desactive la cuenta de usuario.
• Limitaciones de las cuentas de servicio: Incluso las identidades de máquina configuradas correctamente no proporcionaban una atribución distinta en la capa de base de datos, ya que a menudo recurrían a inicios de sesión SQL estándar que no distinguen entre llamantes.

Contexto

Para comprender estos riesgos, es útil distinguir entre autenticación y autorización. La autenticación verifica quién está conectándose, mientras que la autorización determina qué puede hacer. En entornos cloud modernos, esto suele gestionarse mediante tokens y pertenencias a grupos. Cuando un agente de IA utiliza las credenciales de un desarrollador, realiza una "suplantación", lo que significa que se vuelve indistinguible del usuario.

Los registros de auditoría suelen capturar metadatos como nombres de inicio de sesión, máquinas host e interfaces cliente. Sin embargo, estos registros no incluyen actualmente un campo para la "intención del agente". Como consecuencia, los equipos de seguridad confían en la suposición de que hay un humano detrás de cada acción. Cuando un agente autónomo realiza miles de operaciones, esta suposición se rompe. Además, los grupos de acceso "just-in-time" pueden permanecer activos en un token almacenado en caché incluso después de haber sido desactivados en el directorio, creando una ventana de vulnerabilidad que las verificaciones estándar no pueden detectar.

Por qué importa

Para los equipos que ejecutan su propio software, este problema afecta al corazón de la seguridad operativa y el cumplimiento normativo. Los entornos autoalojados a menudo dependen de controles de acceso estrictos para proteger datos sensibles. Si un agente de IA hereda permisos amplios, un único prompt mal configurado o un script con errores podría llevar a la eliminación o exposición de datos que se rastrea hasta un ingeniero senior. Esto no solo complica la respuesta ante incidentes, sino que también crea problemas de responsabilidad legal, ya que el ingeniero no puede demostrar fácilmente que no ejecutó personalmente el comando dañino.

Además, la inconsistencia en la cobertura de auditoría plantea un punto ciego significativo. Los equipos pueden creer que están protegidos por registros exhaustivos, solo para descubrir que los entornos de alto riesgo fallan silenciosamente al registrar la actividad. Esto es particularmente peligroso en entornos de no producción, que a menudo se dejan sin monitorear para ahorrar costos. A medida que los agentes se vuelven más autónomos, el volumen de acciones automatizadas aumentará, haciendo esencial contar con registros precisos y atribuibles para la depuración y las revisiones de seguridad.

Qué puedes hacer

• Evita compartir credenciales: No permitas que los agentes de IA usen credenciales personales almacenadas en caché; en su lugar, aprovisiona cuentas de servicio distintas o identidades administradas para cada agente.
• Implementa tokens de delegación: Utiliza estándares de autenticación que admitan la delegación, donde el token lleva tanto el sujeto (humano) como el actor (agente), permitiendo que los registros anoten ambas identidades.
• Aplica el principio de mínimo privilegio: Asegúrate de que los permisos del agente sean la intersección de las tareas requeridas, nunca excediendo las acciones específicas necesarias para el flujo de trabajo.
• Verifica activamente las pistas de auditoría: Prueba regularmente las configuraciones de auditoría realizando acciones de muestra y confirmando que aparecen en el destino de monitoreo, en lugar de confiar en banderas de estado.
• Desacopla la revocación: Diseña sistemas donde el acceso del agente pueda revocarse independientemente sin desactivar la cuenta principal del usuario humano.
• Define el alcance por acción: Aleja a los agentes del acceso basado en roles amplio e implementa permisos vinculados a operaciones específicas o puntos finales de API.