AIBlog del CAIO
← Todos los artículos

IA / Análisis

Identidades no humanas: el control de acceso que nadie está gestionando en tus agentes de IA

Cada agente de IA que despliegas es una identidad con credenciales, permisos y capacidad de acción. La mayoría de las organizaciones no las inventaría, rota ni audita. Así se gestiona el riesgo de las NHI.

El empleado que nunca duerme, nunca pide vacaciones y nunca cambia su contraseña

Cuando una empresa contrata a una persona, existe un proceso conocido: onboarding, asignación de accesos según el rol, revisión periódica, y un offboarding que revoca todo el día que se va.

Cuando esa misma empresa despliega un agente de IA con acceso a un CRM, un repositorio de código o una base de datos de clientes, ese proceso casi nunca existe.

El agente queda con una API key que nadie recuerda haber creado, permisos que nunca se revisan y una vida útil que se extiende indefinidamente — mucho después de que el caso de uso original quedó obsoleto.

Eso es una identidad no humana (NHI) sin gobernanza. Y en 2026, hay más agentes con credenciales activas en la mayoría de las organizaciones que empleados humanos.


Por qué las NHI son distintas a una cuenta de servicio tradicional

Las identidades no humanas no son nuevas — llevan décadas existiendo como cuentas de servicio, certificados de máquina o claves de API entre sistemas. Lo que cambió con los agentes de IA es la naturaleza de lo que hay detrás de la credencial.

DimensiónCuenta de servicio tradicionalAgente de IA
ComportamientoDeterminista, código fijoNo determinista, decide en tiempo real
Alcance de accionesDefinido en el códigoDefinido por el prompt y el contexto disponible
Capacidad de encadenar accionesNingunaPuede invocar otras herramientas y agentes
Auditoría de “por qué actuó así”Trivial (revisar el código)Compleja (revisar razonamiento, contexto, prompt)
Velocidad de creaciónRequiere ticket, revisiónUn desarrollador la crea en minutos

Una cuenta de servicio hace exactamente lo que el código le indica. Un agente de IA con las mismas credenciales puede interpretar una instrucción ambigua, encadenar herramientas que nadie anticipó combinar, y ejecutar acciones que técnicamente están dentro de su permiso pero fuera de su intención original.

Esa brecha entre lo que el agente puede hacer y lo que el agente debería hacer es exactamente el espacio donde vive el riesgo de las NHI.


Los tres puntos ciegos más comunes

1. Sobre-aprovisionamiento por conveniencia

Es más rápido darle a un agente un token con permisos de administrador que diseñar un rol granular. La presión de entregar un prototipo funcionando hace que el “ya ajustaremos los permisos después” se convierta en la configuración permanente de producción.

El resultado: agentes con acceso de lectura y escritura a sistemas completos cuando su caso de uso real solo necesitaba leer tres tablas.

2. Credenciales que nunca expiran ni rotan

Las claves de API para agentes suelen generarse una vez y vivir para siempre en una variable de entorno o un secreto de despliegue. A diferencia de las contraseñas humanas, no hay política que fuerce su renovación.

Cuando un agente se retira de producción, la credencial casi nunca se revoca — simplemente queda huérfana, activa y sin nadie monitoreándola.

3. Ausencia de trazabilidad de “agente que actúa en nombre de quién”

En un flujo agéntico, un usuario dispara una acción, el agente la interpreta, invoca una herramienta, y esa herramienta invoca a otro agente. Si la cadena de identidad no se propaga extremo a extremo, los logs terminan mostrando que “el sistema” hizo algo — sin poder reconstruir la intención humana original ni el camino de decisiones que llevó hasta ahí.

Esto no solo es un problema de seguridad. Es un problema de responsabilidad: si un agente ejecuta una acción dañina, necesitas poder responder quién lo autorizó y por qué.


Principios para gobernar identidades de agentes

Ciclo de vida completo, igual que un empleado

  • Alta: cada agente se registra con un propietario humano responsable, un propósito documentado y una fecha de revisión
  • Uso: permisos mínimos necesarios para la tarea, nunca “por si acaso”
  • Revisión: recertificación periódica de accesos, igual que se hace con cuentas humanas privilegiadas
  • Baja: revocación automática de credenciales cuando el agente se retira o el proyecto termina

Identidad de corta duración por defecto

Los tokens de larga duración son el equivalente a una contraseña que nunca caduca. La alternativa es credenciales efímeras, emitidas por sesión o por tarea, con rotación automática y sin secretos estáticos almacenados en el código o la configuración.

Permisos scoped a la acción, no a la plataforma

Un agente que resume tickets de soporte no necesita acceso de escritura al sistema de tickets. La granularidad importa más en agentes que en aplicaciones tradicionales, porque el agente decide qué hacer con el permiso que tiene — no solo ejecuta un flujo predefinido.

Propagación de identidad en cadenas multiagente

Cuando un agente invoca a otro, la identidad del solicitante original debe viajar con la solicitud. No basta con que el sistema sepa “un agente hizo esto” — necesita saber en nombre de quién, con qué autorización, y bajo qué contexto.

Monitoreo de comportamiento, no solo de acceso

Un log de “se usó la credencial X” no dice si el uso fue legítimo. El monitoreo efectivo de NHI observa patrones: ¿este agente normalmente hace 50 llamadas por hora y de pronto hizo 5.000? ¿Está accediendo a datos fuera de su patrón habitual? Ese tipo de anomalía es la señal temprana de una credencial comprometida o un agente que se salió de su alcance previsto.


No es un problema técnico nuevo — es una deuda de gobernanza que se aceleró

La gestión de identidades no humanas no requiere inventar disciplinas nuevas. IAM, principio de menor privilegio, segregación de funciones y gestión de secretos son prácticas conocidas desde hace años.

Lo que cambió es la velocidad y el volumen. Antes, crear una cuenta de servicio pasaba por un proceso con fricción suficiente para forzar cierta disciplina. Hoy, cualquier desarrollador puede generar un agente con credenciales productivas en el tiempo que toma escribir un prompt.

La pregunta que toda organización debería poder responder hoy es simple: ¿cuántos agentes de IA tienen credenciales activas ahora mismo, quién es responsable de cada uno, y cuándo fue la última vez que alguien revisó lo que pueden hacer?

Si la respuesta no es inmediata, ese es exactamente el punto ciego que un atacante — o un agente mal configurado — va a encontrar primero.

Publicado originalmente en el blog CISO de TTPSEC. La fecha y autoría originales se conservan.