Machine vs Workload vs Agent Identity: The Differences

Machine identity, workload identity, and agent identity are three distinct answers to three distinct questions — which device is this?, which running software is this?, and which autonomous AI principal is this? — and treating them as synonyms produces real architectural mistakes, the most common being the reuse of workload identity for AI agents because it already exists. This post defines each term, shows where they stack, and pins down exactly what agent identity requires that the other two never had to provide.

For the broader architecture these identities plug into, see the complete identity and access guide for AI; for lifecycle discipline across all non-human identities, see NHI credential lifecycle management.

Machine identity: which device is this?

Machine identity authenticates physical or virtual infrastructure — servers, VMs, laptops, network devices, IoT endpoints. Its classic instruments are X.509 certificates, TPM-backed keys, and device attestation; its classic use cases are mutual TLS between hosts, device trust in zero-trust network access, and certificate lifecycle management at fleet scale.

The defining property: machine identity attaches to the substrate, not to what runs on it. A server certificate says "this is host db-prod-3," and says nothing about which of the forty processes on that host originated a request. That coarseness is fine for its purpose — transport security and device trust — and useless for authorizing anything finer than the box.

Workload identity: which running software is this?

Workload identity authenticates a unit of running software — a container, pod, function, or service — independently of the host it happens to be scheduled on and, critically, without long-lived secrets. The pattern that defines the category: the platform attests to what the workload is (its service account, namespace, image, environment), and an identity provider exchanges that attestation for short-lived credentials. SPIFFE/SPIRE, cloud IAM roles for compute, and Kubernetes service-account tokens are the canonical implementations.

Workload identity was the answer to secret sprawl: no API keys baked into images, no shared credentials in config files — identity derives from the platform's knowledge of what it is running. Its defining property is that behavior is assumed deterministic: the workload is code, the code was reviewed, so authenticating which code is running is treated as sufficient to trust what it will do. Authorization can therefore be coarse (service-to-service scopes) and static (set at deployment).

Agent identity: which autonomous principal is this?

Agent identity authenticates an AI agent as a first-class principal — and exists because the workload-identity assumption breaks: an agent's behavior is not determined by its code. The same agent binary, with the same model, does different things depending on prompts, retrieved content, tool responses, and memory — inputs that an attacker can shape. Authenticating which software is running no longer predicts what it will do, so identity has to carry more:

• Per-action verification and authorization. Because intent can be corrupted mid-run, authorization is evaluated continuously — each action checked against current policy and task context, not a deployment-time grant. This is the continuous authorization model.
• Delegation semantics. Agents spawn sub-agents and hand off tasks. Agent identity must express delegation chains: scoped tokens bounded by the delegator's authority, expiring with the task, attributable end-to-end — a concept neither machine nor workload identity ever needed.
• Behavioral trust. Since code identity doesn't predict behavior, agent identity pairs with a dynamic trust layer — trust scores reflecting verification status and behavioral history — that authorization decisions can consult.
• Instant, surgical revocation. A manipulated agent must be stoppable in seconds, individually, across every capability surface — the kill-switch requirement. Workload revocation (redeploy, scale to zero) is far too blunt and too slow.
• Registration and ownership metadata. Who owns this agent, what is it for, what tools may it call — governance fields that turn identity into an enforcement perimeter rather than a name.

The stack, and the boundaries between layers

The three identities compose rather than compete. A production agent typically involves all three at once:

The layering in practice: the host the agent runs on holds machine identity (mTLS to your network); the runtime (container, function) holds workload identity (which is how the agent platform itself authenticates to cloud services without secrets); and the agent holds its own registered identity, which is what tools, models, MCP servers, and peer agents actually see. Each layer authenticates to the one below and is authorized by the one above.

The mistake to avoid: workload identity as agent identity

The tempting shortcut is to let agents authenticate as the service that hosts them — one workload identity for the agent platform, shared by every agent it runs. This recreates the shared-service-account problem one layer up, with familiar consequences: no attribution (the audit log says the platform did everything), no surgical revocation (stopping one compromised agent means stopping the platform), no per-agent scoping (every agent holds the union of all agents' needs), and no delegation semantics at all. It also fails the newer requirements arriving from outside: MCP's authorization model expects per-client credentials and audience-bound tokens, and compliance frameworks increasingly expect per-principal attribution in agent audit trails.

The rule of thumb: workload identity authenticates your infrastructure to itself; the moment the software starts making its own decisions about what to do — the moment it becomes an agent — it needs its own identity with agent-grade properties.

Common questions

What is the difference between machine identity and workload identity? Machine identity authenticates devices and hosts (certificates, TPM keys — "this is host X"); workload identity authenticates running software units independent of host, via platform attestation exchanged for short-lived credentials ("this is service Y's deployed code"). Machine identity secures the substrate; workload identity secures the software on it.

What is agent identity? A first-class identity for an autonomous AI agent: registered per-agent credentials, per-action authorization, scoped delegation tokens, behavioral trust signals, ownership metadata, and instant individual revocation. It exists because agent behavior is non-deterministic and manipulable, so authenticating the code (workload identity) no longer predicts what the principal will do.

Can't SPIFFE or cloud IAM roles cover AI agents? They cover the platform layer well — how your agent runtime authenticates to infrastructure without secrets — and they are worth using there. What they lack is the agent grain: per-agent attribution, task-scoped delegation, behavioral trust, and per-action revocation. Use workload identity beneath the agent platform, and agent identity for the agents themselves.

Do AI agents count as non-human identities (NHIs)? Yes — agents are the fastest-growing NHI class, alongside service accounts, API keys, and MCP servers. They inherit all standard NHI lifecycle needs (ownership, scoping, rotation, decommissioning, per the NHI lifecycle guide) and add autonomy-specific requirements on top.

Which identity layer should we invest in first for agent deployments? Agent identity, because it is the layer nothing else provides by default. Your infrastructure almost certainly has machine and workload identity in some form already; agents piggy-backing on those layers is precisely the gap. Registering every agent as its own principal is the move that makes scoping, attribution, trust, and kill switches possible.