La automatización nunca debería aparecer en un audit log como una credencial sin explicación. Cada bot, workload, pipeline y agente de IA necesita una identidad que explique qué es, quién responde por él, quién delegó la acción y qué runtime la ejecutó.
Una API key identifica la posesión de un secreto. Un cliente OAuth identifica una aplicación. Una service account identifica una aplicación o workload con permisos asignados. SPIFFE entrega identidades cortas y criptográficamente verificables a workloads individuales. Una identidad de agente agrega autonomía, delegación, ciclo de vida y un sponsor responsable. Llamar “bot” a todo borra distinciones necesarias para control de acceso y respuesta a incidentes.
El trabajo de NIST sobre identidad de agentes pregunta cómo las acciones pueden vincularse de vuelta a humanos y volverse no repudiables. El modelo Agent ID de Microsoft incluye identificador único, blueprint, owner y sponsor. La orientación de Google Cloud advierte que un log con solo una service account compartida puede no revelar qué usuario o aplicación causó la acción.
El mecanismo debe corresponder a la pregunta operacional. Para medir tráfico de una API pública, una API key puede bastar. Cuando un SaaS actúa por un usuario, OAuth delegado registra esa relación. Para un workload backend con permisos cloud, service account o workload identity federada es mejor. Para un agente autónomo decidiendo entre tareas y usuarios, se necesita identidad estable propia más delegación por tarea.
| Tipo | Mejor uso | Qué prueba | Principal debilidad | Exigencia de auditoría |
|---|---|---|---|---|
| API key | Identificación y medición de bajo riesgo. | Caller posee un secreto compartido. | Atribución débil; suele copiarse y durar mucho. | Owner, rotación, origen y contexto del request. |
| Cliente OAuth | Acceso de aplicación y flujos delegados. | Identidad del cliente y consentimiento del usuario. | Scopes amplios y acciones downstream ambiguas. | Cliente, usuario, scopes, consentimiento, audience y acción. |
| Service account | Jobs backend, pipelines y workloads cloud. | Workload actúa como principal de máquina asignado. | Claves compartidas ocultan el caller real. | Impersonator, emisión del token, workload, run ID y acción. |
| Workload identity | Infraestructura dinámica y llamadas entre servicios. | Identidad de runtime vinculada criptográficamente. | No explica intención de negocio automáticamente. | Workload ID, attestation, entorno, política y request. |
| Identidad de bot | Chat, repositorio y automatización de workflows. | Actor de automatización nombrado en una plataforma. | Puede ocultar service account o usuario detrás. | Bot, instalación, usuario/evento disparador, permisos y acción. |
| Identidad de agente | Trabajo autónomo, delegado y de múltiples pasos. | Instancia estable, tipo, sponsor y actor delegante. | Ciclo de vida nuevo y brechas de atribución. | Agente, sponsor, principal, tarea, scopes, decisiones, tools y resultados. |
Las claves persistentes aplanan la identidad. Cualquiera con el secreto se vuelve el mismo principal, y el audit log no puede distinguirlos con confianza. Google recomienda impersonation de service accounts porque comienza en un principal autenticado y genera credenciales cortas; la mayoría de logs puede registrar caller y service account. SPIFFE sigue la misma dirección para workloads con SVIDs cortos en lugar de secretos desplegados.
Para agentes, la cadena útil es más larga: sponsor responde por el agente; principal delega una tarea; agente solicita una capacidad; runtime la usa; resource server autoriza; auditoría une los identificadores. Quitar cualquier eslabón debilita la reconstrucción.
Construiría un registro de identidades no humanas que conecta datos de IAM, agent registries, service accounts, clientes OAuth, API keys, SPIFFE IDs, bots de repositorio e identidades de CI/CD. Cada registro exigiría owner responsable, finalidad, entorno, recursos permitidos, tipo de credencial, política de vencimiento y última actividad.
El producto visible sería un explorador de linaje. Desde cualquier cambio en producción, caminaría hacia atrás desde la acción hasta runtime, identidad no humana, principal delegante, aprobación y sponsor responsable. Desde un owner, mostraría cada identidad y privilegio bajo su responsabilidad.
Autenticación responde qué credencial funcionó. Buena identidad no humana responde qué sistema actuó, bajo autoridad de quién, para qué tarea, desde qué runtime y quién debe responder cuando algo sale mal. La pista de auditoría debe preservar esa frase completa.
Artículo que compara API keys, clientes OAuth, service accounts, workload identity, bots e identidades de agentes de IA con ownership, delegación, credenciales cortas y pistas de auditoría reconstruibles.