Identidades no humanas y agentes de IA: guía profunda de gobernanza

Edición ampliada · 27 de octubre de 2026. Las cifras se atribuyen a sus informes; la arquitectura, el modelo de madurez y las metas de 90 días son propuestas de implementación, no resultados experimentales ni una certificación de cumplimiento.

Resumen ejecutivo

Un agente de IA puede operar mediante una identidad con credenciales y permisos, y decidir qué herramientas invocar. Si esa identidad es privilegiada, sus decisiones amplían el riesgo. Gobernarlo como una cuenta de servicio más es el error estructural de 2026.

La escala reportada por proveedores es relevante, aunque no representa un censo de todas las organizaciones. En una encuesta a 2.930 responsables de ciberseguridad, el informe 2026 de Palo Alto Networks reporta 109 identidades de máquina por cada humano, de las cuales 79 son identidades de agentes de IA. OWASP publicó en 2025 su Top 10 de riesgos NHI y en diciembre de 2025 el Top 10 para aplicaciones agénticas, donde el abuso de identidad y privilegios (ASI03) ocupa el tercer lugar.

Esta guía profundiza el artículo original en cinco frentes:

• Modelo de amenazas: cómo una inyección de prompt se convierte en abuso de credenciales, y por qué el agente es un intermediario confundido con privilegios.
• Arquitectura: identidad de workload, tokens efímeros, intercambio de tokens con delegación y autorización por acción.
• Operación: ciclo de vida completo, recertificación y detección de comportamiento.
• Cumplimiento: cómo esto aterriza en ISO/IEC 42001, ISO/IEC 27001, NIST, la Ley de IA europea y las leyes chilenas 21.663 y 21.719.
• Ejecución: modelo de madurez, hoja de ruta de 90 días y métricas para el directorio.

La pregunta de cierre del artículo original sigue siendo la prueba de fuego: ¿cuántos agentes tienen credenciales activas ahora mismo, quién responde por cada uno y cuándo se revisó lo que pueden hacer?

1. El empleado que nunca duerme, ahora con cifras

Cuando una empresa contrata a una persona existe un proceso: onboarding, accesos según el rol, revisión periódica y un offboarding que revoca todo. Cuando despliega un agente con acceso al CRM, al repositorio o a la base de clientes, ese proceso casi nunca existe. El agente queda con una API key que nadie recuerda haber creado y una vida útil que supera al caso de uso que lo justificó.

Lo nuevo en 2026 no es el patrón, es la escala y la velocidad:

Las proporciones de distintos informes no son directamente comparables: cambian las poblaciones, las definiciones de identidad y los métodos de medición. Los datos anteriores corresponden a las muestras y periodos de cada proveedor.

Tres datos del informe de Palo Alto resumen la brecha de gobernanza. Primero, menos de la mitad de las organizaciones aplica monitoreo de comportamiento o revocación de credenciales a sus agentes. Segundo, el 54 % de los ejecutivos cree que aplica menor privilegio de forma efectiva, mientras el 61 % de los practicantes lo niega. Tercero, solo el 15 % considera privilegiada a una identidad de máquina con acceso a datos sensibles: el privilegio se sigue pensando con lente humana.

2. Taxonomía: qué es una NHI y qué cambia cuando detrás hay un agente

Una identidad no humana es la representación de una entidad de software o máquina que se autentica y recibe autorización. Una credencial prueba o representa esa identidad; no es la identidad en sí. Los agentes no reemplazan las NHI clásicas: se montan encima de ellas y las usan como palancas.

Por qué un agente no es una cuenta de servicio más

La idea central del artículo original se mantiene: el riesgo vive en la distancia entre lo que el agente puede hacer y lo que debería hacer. En una cuenta de servicio esa distancia la fija el código. En un agente la fija, en cada paso, un modelo que lee texto que no controlas.

3. Modelo de amenazas: de la inyección de prompt al abuso de credenciales

En un agente, la identidad es el multiplicador del daño: el modelo puede ser engañado, pero solo puede hacer lo que su credencial permite. Por eso los dos marcos de OWASP deben leerse juntos.

OWASP Non-Human Identities Top 10 (2025)

El proyecto OWASP NHI Top 10 prioriza riesgos con la metodología de calificación de OWASP, usando brechas reales, encuestas y CVE.

OWASP Top 10 for Agentic Applications (diciembre 2025)

El OWASP GenAI Security Project publicó este marco tratando a los agentes como principales con objetivos, herramientas, memoria e identidad, no como simples aplicaciones. La tabla siguiente resume su relación con la identidad; las medidas de identidad no sustituyen los controles de herramientas, contexto y cadena de suministro.

Tres patrones que conviene nombrar

El intermediario confundido (confused deputy). Un agente con privilegios legítimos ejecuta una orden que vino de alguien sin esos privilegios. El autor de un ticket de soporte no tiene acceso a la base de datos, pero el agente que lee el ticket sí.

La trifecta letal. Simon Willison describe la combinación de acceso a datos privados, exposición a contenido no confiable y un canal para sacar información. Si un agente reúne las tres, una inyección de prompt puede abrir una ruta de exfiltración; su éxito depende de las herramientas y controles disponibles. La gobernanza de identidad es la forma más confiable de quitarle al menos una pata.

La herencia de privilegios en cadena. Cuando un agente pasa su credencial a un sub-agente o herramienta, el privilegio viaja completo aunque el receptor no lo necesite. Tres saltos después, nadie sabe quién tiene qué.

La conclusión operativa es incómoda: no conviene confiar en que el modelo resistirá toda manipulación; hay que limitar externamente lo que puede ejecutar y probar esos límites. Ese límite depende de controles de identidad y autorización correctamente implementados.

4. Incidentes reales y lo que enseñan

Estos casos combinan incidentes reportados y demostraciones de investigación. No son equivalentes ni todos involucran agentes autónomos: ilustran cómo las credenciales y los permisos amplifican el impacto.

Los casos permiten revisar tres controles: duración de las credenciales, alcance concedido y detección de acciones anómalas. No todos implicaron credenciales robadas ni la misma causa raíz.

5. Los tres puntos ciegos, en profundidad

Los tres puntos ciegos del artículo original siguen siendo los correctos; lo que falta es entender por qué aparecen, cómo detectarlos y qué control los cierra.

5.1 Sobre-aprovisionamiento por conveniencia

Causa raíz. En un agente, el conjunto de acciones necesarias no se conoce de antemano: depende de lo que el modelo decida. Ante esa incertidumbre, el equipo otorga «todo lo que podría necesitar». El prototipo pasa a producción con ese alcance.

Cómo se ve en la práctica. Un token service_role para leer tickets. Un scope Mail.ReadWrite cuando el agente solo resume correos. Un PAT de GitHub con acceso a toda la organización para revisar un solo repositorio.

Cómo detectarlo. Comparar permisos otorgados contra permisos efectivamente usados en 30 a 90 días. Todo permiso nunca ejercido es candidato a retiro. Revisar si el agente tiene acceso de escritura a algo que solo lee.

Control que lo cierra. Diseñar el permiso desde la herramienta, no desde la plataforma: cada herramienta del agente declara qué recurso toca y con qué verbo. Lectura por defecto; escritura solo bajo demanda y con confirmación para operaciones destructivas.

5.2 Credenciales que nunca expiran ni rotan

Causa raíz. La forma más rápida de conectar un agente es pegar una API key en un archivo de configuración. Muchas guías oficiales de servidores MCP lo enseñan así. GitGuardian encontró más de 24.000 secretos en configuraciones MCP públicas en 2025.

Cómo se ve en la práctica. Claves en .env, en mcp.json, en el prompt de sistema o en una nota de Notion compartida con el equipo. Cuando el piloto termina, nadie revoca nada: la credencial queda huérfana y activa.

Cómo detectarlo. Escaneo de secretos en repositorios, herramientas de colaboración y estaciones de desarrollo. Inventario de credenciales con fecha de creación, última rotación y último uso. Una credencial sin uso en 30 días y sin dueño es una puerta abierta.

Control que lo cierra. Credenciales efímeras emitidas por tarea, con federación de identidad de workload en lugar de secretos estáticos. Cuando un secreto estático es inevitable, se guarda en un gestor de secretos, el agente nunca lo ve y se rota de forma automática.

5.3 Trazabilidad de «quién actuó en nombre de quién»

Causa raíz. El agente usa una sola identidad para todos los usuarios que lo invocan, o usa directamente el token del usuario. En el primer caso los logs dicen «el agente hizo X»; en el segundo dicen «el usuario hizo X». Ninguno dice la verdad completa.

Cómo se ve en la práctica. Un registro de borrado sin saber qué humano lo pidió, qué prompt lo originó, qué documento leyó el agente antes y qué sub-agente ejecutó la llamada.

Cómo detectarlo. Tomar una acción sensible al azar de la última semana e intentar reconstruir la cadena completa. Si no se puede en menos de una hora, no hay trazabilidad.

Control que lo cierra. Tokens que llevan dos identidades a la vez: la del sujeto (el humano que delega) y la del actor (el agente que ejecuta), con la cadena de actores anidada en cada salto. Es lo que permite el intercambio de tokens de OAuth (RFC 8693) con su claim act, y lo que desarrolla la sección siguiente.

Aquí hay una cuestión de responsabilidad, no solo de seguridad. Si un agente ejecuta una acción dañina, la organización debe poder responder ante un regulador, un cliente o un tribunal quién lo autorizó, con qué alcance y por qué.

6. Arquitectura de referencia: identidad para agentes

La arquitectura aquí propuesta combina estándares existentes con trabajos todavía en desarrollo: tratar al agente como un workload con identidad criptográfica propia y llevar la delegación humana con OAuth. El concept paper del NCCoE de NIST (borrador conceptual de febrero de 2026, no norma obligatoria) apunta en esa dirección y nombra OAuth 2.0/2.1, OpenID Connect, SPIFFE/SPIRE, SCIM, NGAC y MCP como piezas de partida.

Cinco capas

1. Identidad del agente (quién soy). Cada agente recibe una identidad verificable y cada instancia un identificador de ejecución correlacionable, ambos gestionados por la plataforma, no un secreto pegado en configuración. SPIFFE/SPIRE o la federación de identidad de workload del proveedor cloud emiten credenciales de minutos u horas, ligadas a dónde corre el agente.
2. Delegación (en nombre de quién actúo). El usuario autoriza al agente con OAuth. El agente intercambia ese token (RFC 8693) por uno nuevo, reducido al recurso que va a tocar, que lleva al usuario como sub y al agente como act.
3. Alcance por llamada (qué puedo hacer ahora). Dentro del sistema, un transaction token reduce el permiso a una sola transacción y viaja por toda la cadena de servicios. Su alcance y duración deben verificarse en el servidor. La resistencia a repetición requiere controles adicionales; el token no se vuelve de un solo uso automáticamente.
4. Decisión de autorización (puedo hacer esto en este contexto). Un punto de decisión de políticas evalúa cada acción con atributos del agente, del usuario, del recurso y del riesgo. Se detalla en la sección 8.
5. Evidencia (qué hice y por qué). Cada llamada registra agente, usuario delegante, cadena de actores, herramienta, argumentos, decisión de política y resultado, correlacionados con una traza de ejecución observable.

El agente nunca usa una credencial propia y amplia contra el CRM: pide un token reducido que nombra al usuario y a la cadena de agentes, y el gateway consulta al motor de políticas antes de dejar pasar cada llamada.

Estándares y su estado a octubre de 2026

El campo se mueve rápido. Según un borrador de julio de 2026, el grupo OAuth de IETF fue re-charterado en junio de 2026 con los agentes que actúan en nombre de usuarios dentro de su alcance, y varias decenas de borradores individuales abordan alguna parte del problema. La apuesta segura es componer las piezas estables de la tabla, no adoptar un borrador concreto.

Cómo se ve un token con delegación

Ejemplo ilustrativo de claims, no una credencial utilizable. En RFC 8693, el act exterior identifica al actor actual; los actores anidados documentan la historia y no conceden permisos adicionales:

{
  "iss": "https://idp.empresa.cl",
  "sub": "usuario-ejemplo-123",
  "aud": "https://api.crm.empresa.cl",
  "scope": "tickets:read",
  "exp": 1793145600,
  "act": {
    "sub": "spiffe://empresa.cl/agentes/resumen-tickets",
    "act": { "sub": "spiffe://empresa.cl/agentes/orquestador" }
  },
  "cnf": { "jkt": "<huella de la clave del agente>" }
}

Con este token, el CRM identifica al usuario delegante que pidió la tarea, que el orquestador la derivó al agente de resumen, y el alcance solicitado. Solo tendrá ese efecto si el CRM valida emisor, firma, audiencia, expiración y permisos. La vinculación de clave requiere implementar y verificar DPoP; incluir cnf por sí solo no basta.

Reglas específicas para MCP

La especificación de autorización de MCP ya incorpora varias de estas ideas. Un servidor MCP protegido actúa como servidor de recursos OAuth 2.1, los clientes deben indicar el recurso destino al pedir el token y el servidor debe validar que el token fue emitido para él. El token passthrough — que el servidor reenvíe el token recibido a otra API — está explícitamente prohibido, porque recrea el intermediario confundido (confused deputy). A eso se suman tres prácticas: fijar la versión y el hash de cada servidor MCP, mantener una lista blanca de servidores aprobados y no usar nunca servidores comunitarios con credenciales productivas sin revisión.

7. Ciclo de vida del agente: igual que un empleado, pero más rápido

El principio del artículo original — alta, uso, revisión y baja — se vuelve operable cuando cada etapa tiene un disparador, un dueño y una evidencia.

Ficha mínima de registro de un agente

Ningún agente recibe credenciales productivas sin esta ficha completa en el inventario:

Etapas, disparadores y responsables

Dos reglas evitan la mayoría de los huérfanos. Primera: un agente sin dueño vigente se suspende automáticamente; cuando el dueño deja la organización, su salida dispara la reasignación o la baja de sus agentes. Segunda: toda identidad de agente nace con fecha de expiración; renovar es una decisión activa, no la ausencia de una decisión.

La baja tiene un componente propio de la IA: la memoria persistente del agente y los índices vectoriales que construyó pueden contener datos personales y credenciales. Revocar el token sin limpiar esa memoria deja la información disponible para el próximo agente que la herede.

8. Autorización por acción, no por plataforma

En un agente, el permiso que importa no es «acceso al CRM» sino «puede leer este ticket ahora, para esta tarea, en nombre de esta persona». Eso exige separar la decisión de autorización del código del agente.

Patrón PEP / PDP

Cada llamada del agente a una herramienta pasa por un punto de aplicación (PEP): un gateway de herramientas o de MCP. El PEP pregunta a un punto de decisión (PDP) — por ejemplo OPA, Cedar u otro motor de políticas — si la acción procede. El PDP decide con cuatro grupos de atributos:

• Agente: identidad, clasificación de riesgo, herramientas declaradas, modo de autonomía.
• Delegante: quién pidió la tarea, su rol y sus propios permisos.
• Recurso y acción: qué se toca, con qué verbo, sensibilidad del dato, volumen.
• Contexto: hora, origen, si la sesión leyó contenido no confiable, presupuesto de llamadas consumido.

La regla base es la intersección de permisos: el agente puede hacer, como máximo, lo que su ficha permite y lo que el usuario delegante podría hacer. Nunca la unión.

Escalera de autonomía

OWASP llama a esto «mínima agencia»: la autonomía se gana, no se asume. Una forma práctica de aplicarla:

Contaminación del contexto

Una regla específica de agentes: cuando la sesión ha leído contenido no confiable (un correo externo, una página web, un ticket de cliente), se propone que el PDP reduzca la autonomía según la procedencia registrada por la plataforma. Las acciones de comunicación externa o escritura pasan a requerir aprobación. Esto reduce el riesgo si la plataforma impide rutas alternativas; no es una garantía de detección o contención universal.

Aprobación humana que sí protege

La aprobación humana falla cuando el humano aprueba lo que el agente le resume (riesgo ASI09). Para que funcione:

• Mostrar la acción literal con sus argumentos, no la descripción que redactó el agente.
• Enviar la solicitud por un canal distinto al de la sesión del agente.
• Limitar la cantidad de aprobaciones por hora para evitar la fatiga.
• Registrar quién aprobó, qué vio y cuándo, como parte de la cadena de evidencia.

9. Detección: vigilar el comportamiento, no solo el acceso

Un log que dice «se usó la credencial X» no distingue un uso legítimo de uno robado. En el caso Drift, el tráfico malicioso era técnicamente idéntico al de la integración. Lo que lo delataba era el patrón: volumen, objetos consultados y origen.

Qué registrar en cada acción del agente

• Identidad del agente e instancia, usuario delegante y cadena completa de actores.
• Herramienta invocada, argumentos necesarios para auditoría y recurso afectado, con secretos y datos sensibles redactados o protegidos.
• Decisión del motor de políticas y la regla que la produjo.
• Fuentes de contenido leídas en la sesión y si alguna era no confiable.
• Identificador de traza que une decisiones observables, llamadas y resultado. No se requiere capturar razonamiento interno del modelo.
• Resultado: éxito, error, volumen de datos devuelto.

Señales de alerta concretas

El interruptor de apagado

Cada agente debe poder detenerse en minutos, en tres niveles: revocar sus credenciales en el proveedor de identidad, bloquear sus llamadas en el gateway de herramientas y detener su ejecución en la plataforma. Si alguno de los tres no existe o nadie sabe ejecutarlo, el agente no está listo para producción.

El playbook de respuesta también cambia. Ante un agente comprometido no basta con rotar la clave: hay que revisar su memoria persistente por instrucciones envenenadas, revocar todos los tokens que delegó hacia abajo en la cadena y revisar qué datos leyó para evaluar si hay obligación de notificar.

10. Marco normativo y estándares

Los marcos siguientes aportan requisitos o prácticas aplicables según el alcance de cada organización. Este mapeo técnico ayuda a organizar evidencias; no demuestra cumplimiento por sí solo. En ISO/IEC 27001 los controles se seleccionan y justifican en la declaración de aplicabilidad.

Chile: dos fechas que conviene tener claras

Ley 21.663. La Ley Marco de Ciberseguridad distingue servicios esenciales y obligaciones adicionales de los operadores de importancia vital. La clasificación y las instrucciones de ANCI aplicables deben comprobarse para cada organización; incorporar los agentes al alcance cuando operen sobre esos sistemas.

Ley 21.719. La ficha oficial de la Biblioteca del Congreso Nacional consultada para esta edición indica entrada en vigencia el 1 de diciembre de 2026. Una propuesta de postergación no cambia por sí misma la fecha legal: comprobar el texto vigente y el Diario Oficial antes de decidir plazos de cumplimiento.

Con postergación o sin ella, la conclusión operativa no cambia. Un agente que lee datos personales es un tratamiento de datos, y la organización debe poder explicar con qué base, con qué medidas de seguridad y quién supervisa sus decisiones. Sin inventario de agentes y sin trazabilidad de delegación, esa explicación no existe.

Nota: esta sección es un mapeo técnico de controles, no asesoría legal. Las obligaciones específicas de cada organización deben validarse con su equipo jurídico.

11. Modelo de madurez y hoja de ruta de 90 días

Este modelo de madurez y sus metas son una propuesta del autor, no una medición de mercado ni una exigencia normativa. El objetivo sugerido es alcanzar el nivel 3 en los agentes de mayor riesgo, ajustándolo a la línea base de cada organización.

Modelo de madurez de gobernanza de identidades de agentes

Hoja de ruta de 90 días

1. Días 1 a 30: ver. Objetivo: saber qué existe.
   1. Descubrir agentes y sus credenciales en proveedores de IA, cloud, SaaS conectados, repositorios, CI/CD y estaciones de desarrollo.
   2. Escanear secretos en código, configuraciones MCP y herramientas de colaboración; revocar lo filtrado.
   3. Asignar un dueño humano a cada agente encontrado; suspender lo que quede sin dueño.
   4. Clasificar los agentes por riesgo según datos que tocan y acciones que pueden ejecutar.
   5. Puerta de salida: inventario con dueño para el 100 % de los agentes de riesgo alto.
2. Días 31 a 60: contener. Objetivo: reducir el radio de explosión.
   1. Retirar permisos no usados en los agentes de riesgo alto y medio.
   2. Separar identidades: un agente, una identidad; prohibir cuentas compartidas y uso humano.
   3. Mover secretos a un gestor con rotación automática; migrar a federación de workload donde el proveedor lo permita.
   4. Poner un gateway frente a las herramientas y servidores MCP; aprobación humana para acciones destructivas y comunicación externa.
   5. Publicar la política de registro obligatorio para nuevos agentes.
   6. Puerta de salida: cero credenciales de administrador en agentes de riesgo alto.
3. Días 61 a 90: gobernar. Objetivo: que el control sea sostenible.
   1. Propagar la identidad del usuario delegante en los flujos críticos con intercambio de tokens.
   2. Construir líneas base de comportamiento y las alertas de la sección 9.
   3. Ejecutar la primera recertificación con los dueños.
   4. Probar el interruptor de apagado en un ejercicio de mesa y en un caso real controlado.
   5. Integrar agentes al SGSI, a la evaluación de impacto en protección de datos y al plan de respuesta a incidentes.
   6. Puerta de salida: nivel 3 de madurez en todos los agentes de riesgo alto y reporte al directorio.

12. Métricas y preguntas para el directorio

Lo que no se mide no se recertifica. Estas métricas proponen un tablero mensual. Las metas son orientativas, no umbrales de cumplimiento; deben ajustarse al riesgo y capacidad operativa. Los secretos expuestos válidos requieren contención inmediata, no un plazo de gracia de siete días.

Diez preguntas que el directorio debería poder hacer

1. ¿Cuántos agentes de IA tienen credenciales activas hoy, y cuántos eran hace tres meses?
2. ¿Quién responde por cada uno de ellos?
3. ¿Cuántos pueden borrar datos, mover dinero, enviar comunicaciones externas o cambiar permisos sin aprobación humana?
4. ¿Qué agentes tocan datos personales, y están en nuestras evaluaciones de impacto?
5. ¿Cuántos usan claves que no expiran?
6. Si un agente actúa mal mañana, ¿podemos saber en una hora quién lo pidió y qué leyó antes de actuar?
7. ¿Cuánto tardamos en apagar un agente comprometido, y lo hemos probado?
8. ¿Qué servidores MCP, plugins y conectores de terceros usan nuestros agentes, y quién los aprobó?
9. ¿Qué tan lejos estamos de demostrar estos controles ante la ANCI, la futura Agencia de Protección de Datos o un auditor ISO?
10. ¿Qué nivel de autonomía le estamos dando a los agentes, y con qué evidencia lo justificamos?

13. Conclusión: la deuda de gobernanza ya se está cobrando

La gestión de identidades no humanas no exige inventar disciplinas nuevas. Menor privilegio, segregación de funciones, gestión de secretos y ciclo de vida de identidades son prácticas conocidas. Lo que cambió es que la identidad ahora razona, se crea en minutos y actúa a velocidad de máquina.

Los casos revisados muestran que una credencial válida puede habilitar acciones dañinas sin que cada solicitud parezca un acceso no autorizado. Y los marcos de riesgo, documentos conceptuales, estándares publicados y borradores revisados sugieren una dirección común: identidad propia por agente, credenciales efímeras, delegación explícita, autorización por acción y evidencia completa.

La pregunta del artículo original sigue siendo el mejor punto de partida: ¿cuántos agentes tienen credenciales activas ahora mismo, quién responde por cada uno y cuándo se 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.

Fuentes

• Artículo original — Blog del CAIO
• Palo Alto Networks — 2026 Identity Security Landscape
• GitGuardian — State of Secrets Sprawl 2026
• GitGuardian — hallazgos de State of Secrets Sprawl 2026
• OWASP Non-Human Identities Top 10 — 2025
• OWASP GenAI Security Project
• SecureW2 — OWASP Top 10 for Agentic Applications
• NIST NCCoE — Concept paper on Software and AI Agent Identity and Authorization
• NIST — anuncio del concept paper
• IETF — draft-sweeney-wimse-credential-delegation-00
• IETF — draft-klrc-aiagent-auth-02
• Model Context Protocol — Authorization specification
• Google Threat Intelligence — Salesloft Drift
• BeyondTrust — ataques OAuth a Salesforce (Drift y Gainsight)
• Simon Willison — Supabase MCP y la trifecta letal
• eWeek — incidente Replit
• The Hacker News — compromiso de tj-actions/changed-files
• Comisión Europea — AI Act y calendario de aplicación
• RFC 8693 — Token Exchange
• RFC 9449 — DPoP
• BCN — Ley 21.663
• BCN — Ley 21.719