Netwrix 1Secure ofrece visibilidad unificada de datos e identidad - gratis durante 14 días con acceso completo.Comience una prueba gratuita

Centro de recursosBlog

Los agentes de IA pueden heredar derechos de administrador local

Los agentes de IA pueden heredar derechos de administrador local

Sep 9, 2026

Un agente de IA se ejecuta como un proceso bajo la cuenta que lo inició y hereda el token de acceso de esa cuenta. Si la cuenta tiene derechos de administrador local, el agente también los tiene, junto con todos los procesos auxiliares y scripts que genera; un ejemplo sería Claude Desktop ejecutándose bajo una cuenta de administrador, generando ayudantes de PowerShell. Lo que diferencia a los agentes de una aplicación privilegiada típica es que su siguiente acción suele provenir de contenido analizado en tiempo de ejecución, incluyendo entradas no confiables.

Mismo token, mismos derechos

Windows no tiene un nivel de permisos separado para el "AI process." Un agente, ya sea una extensión de navegador, una aplicación de escritorio o un servicio en segundo plano, comienza como un proceso hijo de quien lo lanzó y hereda el token de acceso de ese padre. Inicie sesión como usuario estándar, lance el agente y se ejecutará como usuario estándar. Inicie sesión con una cuenta con local admin rights, y el agente también se ejecuta con esos derechos, junto con todo lo que genere para realizar su trabajo: una llamada de PowerShell, un binario auxiliar, un runtime local que instala para poder operar fuera del sandbox del navegador.

Los tokens de proceso han funcionado así durante décadas. Lo nuevo es lo que hacen los agentes con el token que heredan. Las aplicaciones privilegiadas tradicionales ejecutan rutas de código fijas aprobadas por los proveedores; los agentes son diferentes. Leen y escriben archivos locales, ejecutan comandos en la línea de comandos, llaman a las API del sistema operativo para interactuar con otras aplicaciones y, en un número creciente de casos, instalan un componente local en la primera ejecución. Cada una de esas acciones se ejecuta con el nivel de privilegio que ya tenía la cuenta.

En una cuenta con derechos de administrador local, esa huella alcanza HKEY_LOCAL_MACHINE, el Service Control Manager, tareas programadas que se ejecutan bajo SYSTEM, la memoria del proceso LSASS donde se encuentran las credenciales, la instalación de controladores y las ACL que protegen Program Files y System32. Llegar allí no requiere que el agente haga nada inusual. La cuenta ya tiene la puerta abierta. El agente simplemente pasa como cualquier otro proceso.

Este no es el mismo perfil de riesgo que una aplicación privilegiada normal

Los equipos de TI saben cómo gestionar el riesgo del software privilegiado que ejecuta un conjunto fijo de rutas de código escritas por el proveedor. Los agentes rompen ese modelo porque la ruta de código no es fija. El siguiente movimiento de un agente a menudo se decide en tiempo de ejecución, basado en un aviso, un documento que está resumiendo, una página web que está navegando, un hilo de correo electrónico al que está redactando una respuesta. Si ese contenido contiene un lenguaje que el modelo subyacente interpreta como una instrucción, y el agente tiene acceso para usar herramientas en el sistema operativo, el modelo puede actuar en consecuencia.

Eso es una inyección de prompt: texto incrustado en contenido que parece normal, tratado como un comando en lugar de como datos. Ejecuta el agente con un token de usuario estándar y el radio de acción de la instrucción inyectada se limita a lo que un usuario estándar ya podría hacer. Ejecútalo con permisos de administrador local y la instrucción hereda alcance de administrador; escribe en claves protegidas del registro, instala tareas programadas, accede a la red con credenciales en caché, desactiva el agente antivirus. Cada paso ahora está elevado.

También hay un ángulo de visibilidad, separado del problema de permisos. Marketing adopta un asistente de escritura. Ingeniería utiliza un asistente de código. Ventas instala un resumen de reuniones. Cada uno aparece en un endpoint diferente, bajo una cuenta distinta, con su propio ritmo de actualizaciones y su propia postura de seguridad del proveedor, generalmente sin ninguna revisión formal de TI. Leer el código fuente del agente no diría mucho de todos modos, ya que lo que una instrucción inyectada puede hacer depende completamente de la cuenta bajo la que se ejecuta, no del propio código del agente.

Eliminar los derechos de administrador local, también para AI

Revisar cada nueva herramienta de IA para la postura de seguridad es una carrera que TI no puede ganar frente a la rapidez con que se adoptan estas herramientas. Cortar la herencia en la fuente funciona mejor: quitar los derechos de administrador local permanentes de la cuenta, y no queda nada elevado para que un agente, o cualquier otra cosa que se ejecute bajo esa cuenta, pueda heredar.

El problema es la fricción en el flujo de trabajo. Algunas de estas herramientas realmente necesitan escribir en una ubicación protegida una vez, durante la instalación. Quitar los derechos de administrador sin un camino para una elevación limitada en ese paso, hace que el volumen de tickets de soporte aumente en lugar de que el riesgo disminuya.

PolicyPak Least Privilege Manager gestiona esa división: el privilegio predeterminado de la cuenta permanece como usuario estándar, y las tareas específicas reciben reglas de elevación. Define qué instalador, applet o acción puede ejecutarse con privilegios elevados, para qué usuarios y por cuánto tiempo. Si un agente necesita admin para una instalación auxiliar única, limita la regla a ese instalador. Todo lo demás que haga esa cuenta después, incluido el agente, se ejecuta como usuario estándar. Una instrucción inyectada que intenta escribir en HKLM o instalar un servicio se topa con la misma barrera que un usuario estándar.

Least Privilege Manager cubre Windows y macOS. Es importante destacar esto dado el gran uso de herramientas de IA en flotas Mac, que una política solo para Windows no detectaría.

Comience una prueba gratuita para ver cómo se aplica la elevación con alcance a las herramientas de IA que ya funcionan en sus endpoints.

Descargar PolicyPak

Preguntas frecuentes

Compartir en

Aprende más

Acerca del autor

Imagen de dirk schrader

Dirk Schrader

Vicepresidente de Investigación de Seguridad

Dirk Schrader es un Resident CISO (EMEA) y VP de Security Research en Netwrix. Con 25 años de experiencia en seguridad informática y certificaciones como CISSP (ISC²) y CISM (ISACA), trabaja para promover la ciberresiliencia como un enfoque moderno para enfrentar las amenazas cibernéticas. Dirk ha trabajado en proyectos de ciberseguridad en todo el mundo, comenzando en roles técnicos y de soporte al inicio de su carrera y luego pasando a posiciones de ventas, marketing y gestión de productos tanto en grandes corporaciones multinacionales como en pequeñas startups. Ha publicado numerosos artículos sobre la necesidad de abordar la gestión de cambios y vulnerabilidades para lograr la ciberresiliencia.