Introducción: el próximo usuario de su sistema puede no ser humano
Es posible que la próxima cuenta que acceda a sus sistemas no pertenezca a un empleado. Puede pertenecer (o debería pertenecer) a un agente de IA.
Un gerente de operaciones le pide a un agente que prepare un informe semanal. Abre un panel, descarga un CSV, lee un libro de Excel, compara los resultados de la semana pasada, crea un informe y devuelve el borrador.
El flujo de trabajo se realiza correctamente, pero cada registro registra alex@company.com. La organización no puede decir qué realizó Alex, si el agente excedió su tarea o si el acceso continuó.
Si un agente de IA puede interactuar con sistemas como un usuario, ¿debería seguir tomando prestada la identidad de un usuario?
Aquí es donde Non-Human Identity se vuelve central para la gobernanza de la IA. Las organizaciones deben separar la entidad que realiza el trabajo de la credencial que utiliza y los permisos que recibe.
¿Qué es un Non-Human Identity?
A Non-Human Identity es una identidad digital utilizada por software, servicios, procesos automatizados, dispositivos, cargas de trabajo o agentes de inteligencia artificial para autenticar y acceder a sistemas sin actuar como un usuario humano.
Los ejemplos incluyen cuentas de servicio, entidades principales de servicio, identidades administradas, cargas de trabajo, dispositivos, bots, scripts, canalizaciones de CI/CD, integraciones de API y agentes de IA.
Un Non-Human Identity no es automáticamente una clave API, contraseña, token, certificado, máquina, bot o modelo. Pueden ser credenciales, mecanismos de autenticación, entidades de ejecución o recursos conectados.
El modelo tiene tres preguntas:
- Identity: ¿Quién o qué está actuando?
- Credential: ¿Cómo prueba esa identidad?
- Permission: ¿A qué puede acceder o cambiar?
Identity, Credential, and Permission
| Concepto | Pregunta respondida | Ejemplo |
|---|---|---|
| Identity | ¿Quién o qué está actuando? | Weekly Reporting Agent |
| Credential | ¿Cómo prueba su identidad? | Short-lived access token |
| Permission | ¿A qué puede acceder o cambiar? | Read dashboard data and write report files |
| Patrocinador humano | ¿Quién es responsable de la identidad? | Operations manager |
| Lifecycle | ¿Cuándo debe comenzar y finalizar el acceso? | Active para el flujo de trabajo y revisado trimestralmente |
Una credencial no es la identidad en sí. Es evidencia utilizada por una identidad para autenticarse.
Los principales tipos de Non-Human Identity
Service accounts
Estas cuentas admiten aplicaciones, scripts, programaciones e integraciones. Los riesgos incluyen propiedad compartida, contraseñas estáticas, acceso excesivo y falta de fecha de jubilación.
Application and service principal identities
Representan aplicaciones que acceden a API, servicios en la nube o recursos, incluidos SaaS y automatización interna.
Managed and workload identities
Estos representan cargas de trabajo de software como máquinas virtuales, contenedores, funciones sin servidor, trabajos de CI/CD y aplicaciones en la nube. Las plataformas compatibles pueden usarlos sin almacenar secretos permanentes directamente en el código.
Machine and device identities
Estos verifican servidores, computadoras portátiles, equipos de red, sistemas industriales y dispositivos de IoT a través de certificados, claves o registros de dispositivos.
AI agent identities
Estos representan agentes que interpretan objetivos, eligen herramientas, acceden a recursos y toman acciones. Los agentes de IA encajan en Non-Human Identity, pero su comportamiento adaptativo los hace más difíciles de gobernar que las cuentas de servicios fijos.
Non-Human Identity frente a máquina Identity frente a carga de trabajo Identity
Non-Human Identity es el amplio paraguas. Machine identity, identidad de carga de trabajo, cuentas de servicio e identidad de agente son categorías o patrones de implementación más limitados.
Non-Human Identity comparado con tipos Identity relacionados
| Tipo Identity | lo que representa | Ejemplos típicos |
|---|---|---|
| Identidad humana | una persona real | Employee, contractor, partner, customer |
| Non-Human Identity | Una entidad basada en software o máquina que accede a recursos | Service account, aplicación, bot, carga de trabajo, agente de IA |
| Machine identity | Una máquina, dispositivo, servidor o componente técnico. | Device certificate, server key, IoT identity |
| Workload identity | Running software in cloud or infrastructure | Container, virtual machine, serverless function |
| Service account | Una cuenta utilizada por una aplicación o tarea automatizada | Cuenta de informe programado, integración de base de datos. |
| Agent identity | Una identidad que representa a un agente de IA. | Research agent, reporting agent, desktop agent |
La terminología difiere según las plataformas. La gobernanza debe centrarse en lo que representa la identidad, dónde se ejecuta, a qué puede acceder y quién es su propietario. No todos los Non-Human Identity representan una máquina física.
Por qué los agentes de IA cambian el problema Non-Human Identity
Agents follow goals, not only fixed instructions
La automatización tradicional puede copiar una copia de seguridad a medianoche. Un agente al que se le pide que investigue un desempeño inusual y prepare un informe puede elegir diferentes acciones dependiendo de lo que encuentre.
Agents use multiple tools
Un agente puede moverse entre API, archivos, navegadores, hojas de cálculo, bases de datos, herramientas de comunicación y subagentes. Cada conexión amplía la cadena de permisos.
Permissions vary by task
Los flujos de trabajo de investigación, generación de informes y atención al cliente no deberían recibir el mismo acceso permanente simplemente porque utilizan la misma plataforma.
Agents may delegate
Un agente primario puede llamar a una herramienta especializada u otro agente. El acceso debe ser rastreable y heredado según reglas claras o autorizado por separado.
Agents act on behalf of people
Los sistemas deben distinguir acciones humanas, acciones de agentes solicitadas por humanos, pasos seleccionados por agentes dentro de una tarea aprobada y acciones delegadas. Agent identity debe preservar el vínculo entre el solicitante, el ejecutor, la credencial y el resultado.
Por qué los agentes de IA no deberían esconderse detrás de cuentas humanas
Un agente puede utilizar la sesión del navegador, el token API, la cuenta de correo electrónico o el inicio de sesión de la aplicación de un empleado. El flujo de trabajo puede funcionar, pero la atribución se vuelve débil.
Los registros muestran solo la cuenta del empleado, mientras que el agente hereda todo lo que el empleado puede acceder. Los equipos de seguridad no pueden separar de manera confiable el comportamiento humano de la automatización, y el acceso puede sobrevivir más allá de la tarea prevista.
Un mejor modelo de atribución es:
- Initiated by: Alex
- Executed by: Weekly Reporting Agent
- Environment: Escritorio corporativo homologado
- Approved by: gerente de finanzas
El patrocinador sigue siendo responsable del propósito, mientras que la identidad del agente muestra quién realizó el trabajo. Un agente debe actuar en nombre de un ser humano sin volverse indistinguible de ese ser humano.
Los principales riesgos de las identidades no humanas no gestionadas
Orphaned identities
El acceso permanece activo después de que un empleado se va, finaliza un proyecto, se reemplaza una integración o se abandona un agente.
Excessive permissions
Se concede un acceso amplio porque las políticas estrechas provocan fracasos y la conveniencia temporal se convierte en un privilegio permanente.
Long-lived credentials
Las contraseñas estáticas, las claves API, los certificados y los tokens pueden seguir utilizándose mucho después de que haya pasado la necesidad original.
Shared identities
Varias aplicaciones, agentes o empleados utilizan una cuenta, lo que debilita la atribución y la propiedad.
Identity sprawl
Service accounts, bots, aplicaciones OAuth, tokens, scripts y agentes secundarios se acumulan sin un inventario confiable.
Weak accountability
Después de un incidente, la responsabilidad puede estar en disputa entre el solicitante, el propietario del flujo de trabajo, el propietario de la aplicación, el aprobador y los proveedores de tecnología.
El mayor riesgo muchas veces no es que exista una identidad, sino que nadie sepa por qué existe, qué puede hacer o cuándo debería desaparecer.
Un Non-Human Identity Lifecycle de ocho pasos
Step 1: Descubrir
Inventario de cuentas de servicio, identidades de aplicaciones, aplicaciones OAuth, agentes locales y en la nube, bots, scripts, certificados, programaciones, integraciones de API y herramientas conectadas.
Step 2: Registrarse
Registre un nombre, tipo, propósito, creador, patrocinador, departamento, tiempo de ejecución, herramientas conectadas, datos accesibles, tipo de credencial y vencimiento únicos.
Step 3: Asignar un patrocinador humano
Una persona designada debe aprobar el propósito, revisar el acceso, responder a incidentes, transferir la propiedad y autorizar el retiro.
Step 4: Definir el límite de identidad
Documentar los sistemas permitidos, carpetas, registros, herramientas, acciones y prohibiciones explícitas.
Step 5: Aplicar privilegio mínimo
Otorgue solo lo que requiere el flujo de trabajo actual. Evite el acceso administrativo permanente agregado simplemente para reducir las fallas.
Step 6: Prefiere credenciales de corta duración
Cuando sea compatible, utilice tokens temporales, identidades administradas, federación de cargas de trabajo, credenciales con ámbito de tarea, caducidad y revocación.
Step 7: Supervisar el comportamiento
Capture eventos de autenticación, recursos accedidos, herramientas llamadas, archivos abiertos, cambios, transferencias, fallas, reintentos y delegación.
Step 8: rotar, transferir y retirar
Cuando el flujo de trabajo cambie o finalice, rote las credenciales, transfiera la propiedad, elimine programaciones, revoque permisos, desconecte herramientas, retire identidades secundarias y conserve registros de auditoría.
Non-Human Identity Lifecycle Checklist
| Pregunta Lifecycle | Respuesta requerida |
|---|---|
| ¿Cuál es la identidad? | Unique name and identity type |
| ¿Por qué existe? | Documented business purpose |
| ¿A quién pertenece? | Named human sponsor |
| ¿Dónde corre? | Known application, device, or workload |
| ¿A qué puede acceder? | Defined systems, files, data, and tools |
| ¿Cómo se autentica? | Approved and managed credential |
| ¿Cuándo se revisa el acceso? | Fecha de revisión programada |
| ¿Cuándo caduca? | Defined expiration or retirement condition |
| ¿Cómo se controla la actividad? | Logs, alerts, and audit process |
Cómo dar acceso con mínimos privilegios a los agentes de IA
El privilegio mínimo debe seguir el flujo de trabajo, no la capacidad máxima del agente.
Un agente de informes semanales puede necesitar una carpeta de informes, dos paneles, descargas CSV, un directorio de salida y permiso para preparar un borrador. Es posible que no necesite todo el disco duro, todos los perfiles del navegador, el correo electrónico personal, los controles de facturación, la gestión de permisos, la eliminación del archivo fuente o la autoridad para enviar el informe externamente.
Defina cuatro capas:
- Resource scope: ¿Qué sistemas, carpetas, aplicaciones y registros?
- Action scope: ¿Leer, escribir, modificar, eliminar, publicar o enviar?
- Time scope: ¿Permanente, programado, temporal o basado en tareas?
- Approval scope: ¿Qué acciones necesitan confirmación explícita?
El privilegio mínimo limita lo que un agente puede ver, lo que puede hacer, durante cuánto tiempo puede hacerlo y bajo la aprobación de quién.
Por qué los agentes de IA de escritorio necesitan un Identity Boundaries claro
Los agentes de escritorio pueden interactuar con archivos locales, aplicaciones instaladas, sesiones de navegador, credenciales guardadas, descargas, capturas de pantalla, contenido del portapapeles, controles del sistema operativo y aplicaciones de comunicación. Por lo tanto, su límite de identidad puede abarcar mucho más de una API.
Un flujo de trabajo de escritorio puede implicar:
Solicitante humano -> canal de comunicación -> agente de escritorio -> dispositivo corporativo -> identidad del navegador -> aplicación empresarial -> carpeta de salida
La organización debe saber quién envió la tarea, qué agente la recibió, qué dispositivo y cuenta se utilizaron, qué acciones ocurrieron, qué resultados se crearon y quién la revisó.
La ejecución local puede reducir parte de la transmisión de datos, según la configuración. No elimina el riesgo de identidad ni responde a quién representa el agente y qué permisos utiliza.
EasyClaw ilustra por qué los agentes de escritorio necesitan límites explícitos entre archivos, navegadores, aplicaciones y resultados.
Cómo encaja EasyClaw en una estrategia Identity de agente gobernado
EasyClaw es un agente de flujo de trabajo de IA nativo de escritorio para trabajos que involucran archivos locales, aplicaciones, interfaces de navegador, informes, revisiones y carpetas de proyectos. No es una plataforma de administración de identidades ni un reemplazo de IAM, acceso privilegiado, rotación de credenciales o controles de amenazas.
Su función práctica es ilustrar por qué un agente de escritorio debe operar dentro de un límite de identidad con nombre, limitado, visible y revisable.
Identify the human requester
Defina quién puede emitir tareas EasyClaw, qué canales se aprueban, cómo se autentican los solicitantes y quién puede iniciar flujos de trabajo confidenciales. Cada solicitud debe conducir a una persona específica.
Identify the executing EasyClaw environment
Registre la implementación de EasyClaw, el dispositivo corporativo, la cuenta del sistema operativo, el perfil del navegador, las aplicaciones aprobadas y el propietario del flujo de trabajo. El solicitante y el entorno de ejecución están conectados, pero no son el mismo actor.
Limit file and application scope
Un flujo de trabajo de informes puede necesitar una carpeta, un libro de Excel, paneles seleccionados, una plantilla PDF y un directorio de salida. No debería acceder automáticamente a todos los archivos locales, cuentas de navegador, unidades de nube, configuraciones administrativas o sistemas no relacionados. El alcance claro también reduce la selección de archivos incorrectos y las sobrescrituras accidentales.
Keep consequential actions behind approval
Exija aprobación humana para mensajes externos, publicación pública, eliminación o sobrescritura de archivos, envío de información financiera, cambio de registros de clientes, modificación de permisos, finalización de pagos y modificación de contratos.
EasyClaw puede organizar trabajos intermedios, preparar paquetes de revisión y devolver entregables utilizables. Las decisiones irreversibles, visibles externamente, financieramente Los sistemas de identidad existentes siguen siendo responsables de la autenticación, las credenciales, los permisos y las políticas.
Conclusión: cada agente necesita un Identity, un propietario y una fecha de vencimiento
Non-Human Identity incluye aplicaciones, servicios, máquinas, cargas de trabajo, scripts, bots, procesos automatizados y agentes de IA.
Los agentes de IA aumentan las apuestas porque su comportamiento puede ser adaptable, delegado y distribuido entre herramientas. Las organizaciones necesitan saber qué agente actúa, quién lo patrocina, qué credenciales y permisos utiliza, cómo se registran las acciones, cuándo se requiere aprobación y cuándo vence el acceso.
EasyClaw no es una plataforma de gestión de identidad. Su modelo de ejecución de escritorio muestra por qué los flujos de trabajo de los agentes necesitan propietarios designados, acceso restringido a archivos y aplicaciones, ejecución visible, resultados revisables y aprobación humana para acciones la identidad es la aplicación, servicio, carga de trabajo, script o agente que lo utiliza.