Non-human identity vs. workload identity

A non-human identity represents an actor other than a person, such as software or a device. A workload identity represents a running software workload, such as an application, service, script, or container. An agent identity is a workload identity used to represent an agent in a particular system.

Machine identity is another term used for software and devices, though its scope varies by system. Microsoft's workload identity overview distinguishes software workloads from device identities and notes that industry terminology varies.

Explore Dome: Access · Docs: Agent identity.

Separate the workload, identity, and credential

Suppose a nightly finance job runs in a container and reads a reporting database. The container is an execution environment. The job is the workload. Its identity is how the receiving system recognizes the job.

A machine or non-human identity may also represent a physical device, so not every identity in that category is a workload identity. Similarly, the name of a service account is not necessarily the name of one deployed agent. If several workloads share an account, it can be harder to tell which one acted or to retire one without affecting the others.

The finance job can rotate its database key and still be recognized as the same workload. The credential changes; the identity need not.

Explore Dome: Agent Registry · Docs: Manage agents.

A short-lived token still has a lifecycle

A workload may authenticate with a key, certificate, or token from a trusted identity system. The term “workload identity” describes the software being identified, not a particular protocol or a promise that the system has no secrets.

Short-lived credentials give an attacker less time to use a stolen credential. Their protection still depends on who can obtain them, where they are accepted, how they are replaced, and whether access can be withdrawn when the workload changes.

For the finance job, inspect who can obtain a credential and whether another deployment could use the same identity. Giving each job a different display name doesn't separate their access if they all use the same credential.

Dome's identity documentation describes its agent credential and session-token model. Check that model against any federation or attestation requirements for your deployment.

Explore Dome: Access · Docs: Agent identity.

Trace one deployed job back to its owner

Find one workload and connect its deployment to its identity, credentials, permissions, and owner. Then ask:

• Can activity be attributed to this workload without guessing from a shared account?
• Who approves changes to its access?
• What happens when its deployment is replaced?
• Which credentials and grants remain after it is retired?

Distinguish the workload's identity from any person it acts for. A job may perform approved service work under its own authority, while an interactive agent may need delegated authorization for a person. Both have software identities. The difference is whether the request uses the workload's own permissions or acts on someone's behalf.

Use agent lifecycle management for how to retire an agent and credential isolation for where downstream secrets live.

Explore Dome: Agent Registry · Docs: Agent lifecycle.