En abril de 2026, Microsoft anunció Entra Agent ID, un sistema de identidad diseñado específicamente para agentes de IA — no para personas, no para aplicaciones comunes. La justificación oficial es directa: a medida que las empresas ponen en producción agentes asistentes y autónomos, "necesitan estructuras de identidad propias para autenticar, autorizar, gobernar y proteger" esas identidades que no son humanas.
El motivo de un sistema de identidad separado queda más claro con una cifra: según el informe 2026 Identity Security Landscape, de Idira (la marca de Palo Alto Networks que heredó la base de CyberArk), las identidades de máquina hoy superan a las humanas en una proporción de 109 a 1 dentro de las organizaciones — y 99 de cada 100 empresas ya adoptaron algún agente de IA. Cada agente nuevo es, en la práctica, una identidad más que necesita dueño, permiso y fecha de vencimiento.
El problema es que la mayoría de las empresas todavía trata a un agente de IA como si fuera un script cualquiera: alguien configura una cuenta de servicio, presta su propia contraseña, o usa una clave que nunca vence y que nadie más sabe que existe. Funciona el primer mes. Después de eso, se convierte exactamente en el tipo de identidad sin control que describen las cifras anteriores.
Una automatización con contraseña prestada es un problema esperando a ocurrir
Piense en el camino más común hoy: alguien del equipo de operaciones configura un agente para actualizar el registro de un proveedor, generar un informe financiero o responder en un sistema de tickets. Para que el agente funcione, necesita acceso — y el camino más rápido es darle la propia contraseña, o una cuenta de servicio genérica que varias personas conocen.
Ese atajo crea tres problemas al mismo tiempo. Primero, el agente hereda todo el acceso de esa persona, no solo lo que la tarea exige — si la persona tiene acceso a nómina, el agente también lo tiene, aunque solo necesitara tocar el registro de un proveedor. Segundo, cuando la persona cambia de función o deja la empresa, nadie recuerda revisar qué puede seguir haciendo el agente con esa credencial prestada. Tercero, y más grave en una investigación: una acción tomada por el agente aparece en los registros como si la hubiera hecho la persona, porque fue su identidad la que se usó.
El informe de Gartner sobre el ciclo de madurez de identidad digital para 2026, resumido por Silverfort, llega a la misma conclusión desde el otro lado: las identidades de máquina crecen más rápido que la capacidad de las empresas para descubrirlas y gobernarlas, y la recomendación de la consultora es explícita — los agentes de IA necesitan identidad propia, con credenciales limitadas a lo necesario y un responsable humano definido, en lugar de reutilizar el login de una persona.
Por qué "le presto mi contraseña" no escala
La salida más común — prestar una credencial personal — funciona para un agente. No funciona para diez, y definitivamente no funciona para cien. A medida que la proporción de 109 identidades de máquina por cada identidad humana se vuelve realidad dentro de la empresa, el modelo de "cada agente usa la contraseña de alguien" simplemente no se puede auditar: no existe una lista central de quién prestó qué, a qué agente, por cuánto tiempo.
Además, revocar el acceso de un agente se vuelve una tarea manual y fácil de olvidar. Cuando un proyecto termina y el agente que usaba debería dejar de funcionar, la credencial prestada sigue siendo válida hasta que alguien, de memoria, recuerda cambiar la contraseña de la persona original — algo que rara vez pasa el mismo día.
El patrón que la propia Microsoft describe para Entra Agent ID resuelve este punto de una manera específica: cada agente recibe una identidad con un origen claro (qué equipo lo creó, para qué finalidad), las mismas políticas de acceso adaptativas que cualquier otra identidad corporativa, y todo el historial de autenticación y actividad del agente registrado para auditoría — nada de esto depende de que alguien recuerde revisarlo manualmente.
Lo que tiene que existir en la práctica
Darle identidad propia a un agente de IA significa replicar, para él, los mismos mecanismos que ya existen para las personas — no inventar un régimen aparte.
Identidad proveniente del mismo directorio corporativo. El agente ingresa al sistema con una identidad creada y controlada por la empresa, del mismo lugar de donde viene el login de cualquier colaborador — no una cuenta improvisada por quien configuró la automatización.
Acceso según el rol, también para agentes. Un agente de atención al cliente no necesita el mismo alcance que un agente de análisis financiero. El acceso se define por la función que el agente cumple, no se presta de quien lo creó.
Credencial personal por herramienta conectada. Cuando un agente se conecta a un sistema externo, la credencial usada es suya, no de una persona — y puede revocarse de forma aislada, sin afectar el acceso de nadie más.
Aprobación humana antes de una acción sensible. Antes de que el agente ejecute algo con impacto real — enviar un pago, modificar un registro crítico, publicar un documento — la acción se detiene y pide confirmación de una persona, dentro de la propia conversación.
Así es como Skyller trata la identidad de agente: proveniente del directorio de la empresa, con alcance propio por rol y aprobación humana antes de acciones sensibles, de la misma forma en que ya funciona para cualquier persona del equipo.
Lo que gana la empresa cuando el agente tiene identidad propia
La primera ganancia aparece en el trabajo diario de TI: saber cuántos agentes existen, quién los creó y qué puede hacer cada uno deja de exigir una investigación manual y se convierte en una lista consultable, de la misma forma en que ya existe para las personas.
La segunda ganancia aparece cuando algo necesita cambiar rápido. Un proyecto termina, un agente se da de baja, una herramienta se reemplaza — apagar el acceso de ese agente específico no exige cambiar la contraseña de nadie ni revisar todo lo demás que esa credencial compartida estaba habilitando.
La tercera ganancia es la más estratégica: escalar el número de agentes deja de ser un riesgo creciente. Con identidad y alcance propios, agregar el agente 50 no es más arriesgado, en términos de gobernanza, que agregar el agente 5 — porque cada uno lleva solo el acceso que su propia función exige, con dueño e historial definidos desde el inicio.
Esto también cambia la conversación entre TI y las demás áreas. Hoy, pedir un agente nuevo suele chocar con una pregunta incómoda: "¿quién va a garantizar que esto no se convierta en un problema de acceso más adelante?" Con identidad propia por agente, la respuesta deja de ser una promesa y se convierte en una característica del propio sistema — el agente nace con alcance definido, dueño identificado y rastro de uso, de la misma forma en que nace la cuenta de un colaborador nuevo.
Una hoja de ruta para empezar
Antes de poner en producción el próximo agente, vale la pena seguir una secuencia simple junto con el equipo de TI:
- Liste los agentes que ya existen hoy en la empresa. Incluidos los informales — automatizaciones que alguien creó para resolver una tarea puntual y que siguen funcionando meses después.
- Para cada uno, identifique de quién es la credencial que usa. Si la respuesta es "la contraseña de fulano" o "una cuenta genérica que varias personas conocen", ese agente está en la categoría de mayor riesgo.
- Defina el alcance mínimo que cada agente realmente necesita. No lo más conveniente de configurar ahora, sino lo que la función exige.
- Establezca un responsable humano por agente. Alguien que responda por la existencia de ese agente, revise su acceso periódicamente y sepa desactivarlo cuando el motivo original deje de existir.
- Coloque aprobación humana en las acciones de mayor impacto. No todo necesita confirmación manual — pero lo que involucra dinero, datos críticos o comunicación externa, sí.
