Workload Identity

What is Workload Identity?

Workload identity is a verifiable, cryptographic identity given to a piece of software, such as a service, container, script, or AI agent, so it can authenticate to other systems without a shared secret. Instead of handing a workload an API key or password that can be stolen or copied, workload identity proves what the software is through a short-lived certificate or token issued at runtime. Proving identity at runtime is how service-to-service authentication works when no human is in the loop. 

The guide covers what workload identity is, how it works and how it differs from human and machine identity, the SPIFFE standard, SPIRE, and workload identity federation, and why AI and GPU pipelines have made it urgent.

Understanding workload identity

Workload identity is an identity that belongs to software rather than a person. A workload is any running unit of code, whether a microservice, a container, a serverless function, a batch job, or an AI agent, and each one needs to prove who it is when it calls a database, an API, or another service. Workload identity gives that software a verifiable name and the cryptographic proof to back it, so the system it calls can confirm the caller is who it claims to be.

The problem workload identity solves is that most software still authenticates with secrets. Services share API keys, database passwords, and tokens that sit in config files, environment variables, and repositories, where attackers can find them and reuse them. Non-human identities now outnumber human ones by a wide margin, which means the largest population of actors in most infrastructure authenticates with the weakest method. Workload identity replaces those shared secrets with cryptographic identity that is issued at runtime and expires on its own.

Why workloads need their own identity

Software that authenticates with static secrets creates a large attack surface that is difficult to account for. A single leaked API key lets an attacker act as the service that owned it, and because the same key is often copied across environments, one leak reaches many places. Secrets may rarely be rotated on schedule, offboarding a decommissioned service is unreliable, and there is seldom a clean record of which workload actually made a given call. The differences between these stored secrets and issued identity is explained out in our article Credentials vs Cryptographic Identity.

Giving each workload its own identity addresses the root of the problem by eliminating static or shared secrets. A workload that presents a short-lived certificate can be authenticated on every request, authorized for only what it needs, and traced in an audit log by name. Nothing long-lived sits in a config file to be stolen, access ends when the certificate expires, and a compromised workload is contained to what its identity was authorized for. The reasoning is the same as zero trust, applied to software instead of people, which you can read about in our article on Zero Trust Architecture.

The difference between a static secret and an attested workload identity is easiest to see side by side.

How does workload identity work?

Workload identity works by proving what a workload is at runtime, then issuing it a short-lived credential based on that proof. The first step is attestation, where an identity authority checks properties of the workload and its environment, such as the Kubernetes service account, the node it runs on, or a cloud instance identity document. Attestation answers the question of whether this really is the workload it claims to be without relying on a secret the workload holds.

After attestation succeeds, the authority issues a short-lived credential, usually an X.509 certificate or a signed token such as a JWT. The workload presents that credential when it calls another service, and the receiver validates it the same way a browser validates a website certificate, by checking the signature and the chain of trust. Two services authenticating each other this way use mutual TLS (mTLS), where both sides present certificates and both verify the other. Because the credential is short-lived, a fresh one is issued as needed and the old one expires, so there is no standing secret to leak. The certificates themselves come from a certificate authority, described in our article What is a Certificate Authority.

Workload identity vs human, machine, and service account identity

The terms around non-human identity overlap, and keeping them distinct helps. The following table lays out how workload identity relates to the identities around it.

A service account is a name a workload authenticates as, and traditionally that name comes with a long-lived key. Workload identity keeps the name but replaces the stored key with cryptographic identity issued at runtime, which removes the secret while preserving the account. The broader category of machine and workload actors is covered in our article What are Non-Human Identities?

What are SPIFFE and SPIRE?

SPIFFE, the Secure Production Identity Framework For Everyone, is an open standard for giving workloads cryptographic identity. SPIFFE defines a universal identifier for a workload, written as a URI such as spiffe://example.org/payments-api, and a document called an SVID (SPIFFE Verifiable Identity Document) that proves it, delivered as an X.509 certificate or a JWT. SPIFFE has become the common language for workload identity because it works across clouds, orchestrators, and service meshes rather than locking a team into one vendor.

SPIRE, the SPIFFE Runtime Environment, is the reference software that issues SPIFFE identities. SPIRE handles attestation and hands out SVIDs to workloads, and it is powerful and widely used, including by service meshes such as Istio. SPIRE is also involved to run and maintain, because a team has to deploy the server and agents, define attestation policy, and keep it available, and SPIRE covers workload identity without addressing how humans reach the same infrastructure. Teleport implements the SPIFFE standard so teams get SPIFFE-based workload identity without operating SPIRE separately, and unifies it with human and machine identity on one platform.

Learn how Teleport differs from SPIRE in this side-by-side comparison .

What is workload identity federation?

Workload identity federation is a way for a workload to access cloud resources without a long-lived cloud key. Instead of storing an AWS, Azure, or Google Cloud access key, a workload presents an identity token it already holds, such as a GitHub Actions token or a Kubernetes service account token, and the cloud provider trusts that token through a federation relationship built on OpenID Connect. The provider exchanges the token for short-lived cloud credentials on the spot.

Federation is popular because it removes the most dangerous secret in many pipelines, the static cloud key that grants broad access and often ends up in a CI configuration or a repository. AWS calls the mechanism IAM roles for service accounts and web identity federation, while Google Cloud and Azure offer their own workload identity federation. Each cloud provider shares the same idea of trusting an existing identity rather than storing a new secret. Federation and workload identity work toward the same goal, which is authenticating software by proof rather than by a stored key.

Workload identity for AI, ML, and GPU pipelines

AI has made workload identity urgent. Training and inference pipelines chain many services together, pulling data, calling inference endpoints, moving results between GPU clusters, and increasingly invoking AI agents that act on their own. Every one of those steps is a workload that needs to authenticate, and doing it with shared API keys spread across a pipeline is exactly the sprawl workload identity was built to remove. Identity for these training and inference workloads is the focus of securing AI infrastructure.

AI agents raise the stakes further, because an agent takes actions rather than returning text, and its behavior is non-deterministic. An agent that reaches tools, databases, and other services has to prove what it is on every call and be limited to only what it needs, or a compromised or misbehaving agent inherits whatever its shared key allowed. Giving each pipeline stage and each agent a short-lived cryptographic identity is what makes an AI system auditable and containable. The same principle carries into the Model Context Protocol, covered in our article What is the Model Context Protocol, and into agentic AI security more broadly.

Workload identity use cases

Use cases for workload identity include processes that require software to authenticate to other software. Service-to-service authentication inside a microservices deployment is the most common use case for workload identity, where mTLS is used to ensure every call is mutually verified rather than trusted by network location. Securing CI/CD pipelines is another, which replaces the static cloud keys and registry tokens that pipelines accumulate with short-lived identity issued per run.

Two more are growing fast. Machine-to-machine access to databases and APIs increasingly uses workload identity to ensure a service authenticates with a certificate instead of a stored password, and AI and agent workflows frequently use workload identity to give every inference call and agent action a verifiable identity.

The benefit of workload identity in each of these use cases is authentication by cryptographic proof, least-privilege authorization, and an audit trail that identifies the specific workload.