Automation should never appear in an audit log as an unexplained credential. Every bot, workload, pipeline, and AI agent needs an identity that explains what it is, who owns it, who delegated the action, and which runtime actually executed it.
An API key identifies possession of a secret. An OAuth client identifies an application. A service account identifies an application or workload with assigned permissions. SPIFFE gives individual workloads short-lived, cryptographically verifiable identities. An agent identity adds autonomy, delegation, lifecycle, and an accountable sponsor. Calling all of these “bots” erases the distinctions that access control and incident response need.
NIST's agent identity work asks how actions can be bound back to humans and made non-repudiable. Microsoft's Agent ID model includes a unique identifier, blueprint, owner, and sponsor. Google Cloud's service-account guidance warns that a log containing only a shared service account may not reveal which user or application caused the action.
The identity mechanism should match the operational question. If you only need to meter public API traffic, an API key may be enough. If a SaaS application acts for a user, delegated OAuth records that relationship. If a backend workload needs cloud permissions, a service account or federated workload identity is a better fit. If an autonomous agent makes decisions across tasks and users, it needs its own stable identity plus task-level delegation.
| Identity type | Best fit | What it proves | Main weakness | Audit requirement |
|---|---|---|---|---|
| API key | Low-risk identification and metering. | Caller possesses a shared secret. | Weak attribution; often copied and long-lived. | Key owner, rotation, source, and request context. |
| OAuth client | Application access and delegated user flows. | Client identity and, with delegation, user consent. | Broad scopes and ambiguous downstream actions. | Client, user, scopes, consent, token audience, action. |
| Service account | Backend jobs, pipelines, and cloud workloads. | Workload acts as an assigned machine principal. | Shared keys hide the actual caller. | Impersonator, token issuance, workload, run ID, action. |
| Workload identity | Dynamic infrastructure and service-to-service calls. | Cryptographically bound runtime identity. | Does not automatically explain business intent. | Workload ID, attestation, environment, policy, request. |
| Bot identity | Chat, repository, and workflow automation. | Named automation actor in a product surface. | May hide the service account or user behind it. | Bot, installation, triggering user/event, permissions, action. |
| Agent identity | Autonomous, delegated, multi-step work. | Stable agent instance, kind, sponsor, and delegated actor. | Novel lifecycle and attribution gaps. | Agent, sponsor, principal, task, scopes, decisions, tools, results. |
Persistent keys flatten identity. Anyone holding the secret becomes the same principal, and the audit log cannot reliably distinguish them. Google recommends service-account impersonation because it starts from an authenticated principal and produces short-lived credentials; most audit logs can then record both the caller and the impersonated service account. SPIFFE follows the same operational direction for workloads with short-lived SVIDs instead of deployed secrets.
For agents, the useful chain is longer: sponsor owns the agent; principal delegates a task; agent requests a task capability; runtime uses it; resource server authorizes it; audit joins all identifiers. Removing any link makes incident reconstruction weaker.
I would build a non-human identity registry that joins IAM data, agent registries, service accounts, OAuth clients, API keys, SPIFFE IDs, repository bots, and CI/CD identities. Every record would require an accountable owner, purpose, environment, allowed resources, credential type, expiration policy, and last-seen activity.
The visible product would be an identity lineage explorer. Starting from any production change, it would walk backward from resource action to runtime, non-human identity, delegated principal, approval, and responsible sponsor. Starting from an owner, it would show every machine identity and privilege they are accountable for.
Authentication answers which credential succeeded. Good non-human identity answers which system acted, under whose authority, for which task, from which runtime, and who must respond when it goes wrong. Audit trails should preserve that full sentence.
Non-human identity article comparing API keys, OAuth clients, service accounts, workload identity, bots, and AI agent identities with accountable ownership, delegation, short-lived credentials, and reconstructable audit trails.