Every credential-based authentication scheme has a bootstrap problem: to authenticate, the workload needs a secret, and that secret has to get there somehow. Injected as an environment variable, mounted from a secret store, baked into an image — each path is a place it can leak, and each rotation is an operation someone has to perform.

Workload identity solves this differently. Instead of holding a secret, the workload proves what it is through properties the platform can attest — the Kubernetes service account it runs under, the cloud instance identity, the container image digest — and receives a short-lived credential in exchange. There is no long-lived secret to steal, and rotation happens continuously without intervention.

For agent deployments, this is the right foundation for the transport layer. It is not the whole identity story, and conflating it with agent identity is a common and consequential mistake.

SPIFFE and SVIDs

SPIFFE standardizes workload identity. Two pieces matter.

A SPIFFE ID is a URI naming a workload: spiffe://example.org/ns/prod/sa/summarizer-agent. It is a stable name for a workload class, not for an instance.

An SVID is the credential proving that identity — typically an X.509 certificate with the SPIFFE ID in a SAN URI field, valid for a short period (an hour is typical, minutes are common). The workload obtains it from a local agent over a Unix socket, and the issuing infrastructure decides whether to issue based on attestation: which service account, which node, which image, which cloud instance.

The properties that matter operationally:

  • No secret to distribute. Attestation replaces the bootstrap credential.
  • Automatic rotation. SVIDs are renewed continuously; a leaked one expires quickly.
  • Platform-independent naming. The same identity model spans Kubernetes, VMs, and serverless, which matters because agent fleets rarely live in one runtime.
  • Mutual authentication. With mTLS, both sides present SVIDs, so the caller verifies the callee too — closing the impersonation direction that server-only TLS leaves open.

What This Does and Does Not Establish

Workload identity establishes: this connection comes from a process that the platform attests to be an instance of workload X.

It does not establish:

Which agent. One runtime commonly hosts many logical agents. If ten agents share a deployment, they share a SPIFFE ID. Authorization based only on the workload identity treats them as one principal, and your audit records cannot distinguish them.

On whose behalf. The workload identity says nothing about the user or tenant the current request serves. Authorizing purely on it produces exactly the confused deputy problem: a legitimately-attested workload asking for anything any of its callers might be entitled to.

What the request is for. No scope, no purpose, no bound on the operation.

Trustworthiness of behavior. Attestation covers provenance, not conduct. A workload that has started behaving anomalously still attests correctly.

This is where teams get into trouble. A service mesh with mTLS everywhere feels like it has solved agent identity, and it has solved the transport layer well. The requests an agent makes still authenticate perfectly while carrying no information about which agent, which principal, or which scope — so an SSRF or a confused agent inside the mesh produces authenticated, authorized traffic. See SSRF risks in agent tool calls.

The Layered Model

Three layers, each answering a different question.

Transport: workload identity. SPIFFE SVIDs and mTLS. Answers "what process is this." Enforced by the mesh or by the TLS handshake, with authorization policy stating which workload identities may reach which services.

Logical: agent identity. A per-agent identity distinct from the runtime — internally an identity-provider principal, across organizations a DID. Answers "which agent is acting." Carried in the request, not in the transport, so it survives proxies and asynchronous hops. See how to give an agent an identity and agent identity spoofing and DID verification.

Authority: principal-bound tokens. A short-lived, audience-restricted, scope-limited token naming both the agent and the principal it acts for, obtained by exchange. Answers "on whose behalf, for what." See token exchange for agent-to-tool authorization.

A well-formed internal agent call therefore carries all three: an mTLS connection with an attested SVID, an agent identity, and a principal-bound access token. Each layer fails independently, and each failure is survivable because the others still constrain.

Certificate-Bound Tokens

The layers compose usefully. RFC 8705 defines certificate-bound access tokens: the token carries a thumbprint of the client certificate that obtained it, and the resource server verifies the presenting client's certificate matches. A stolen token is then useless without the corresponding private key — and with SPIFFE, that key never leaves the workload and rotates hourly.

This is the strongest practical anti-replay posture available for internal agent traffic, and it comes almost free once workload identity is deployed. For agents outside a mesh — third-party integrations, external counterparties — DPoP achieves the same sender-constraint over plain HTTPS. See agent session hijacking and token replay.

Authorization Policy Is the Part That Matters

Deploying a mesh and enabling mTLS everywhere is the visible work. Writing restrictive authorization policy is the work that provides security value, and it is frequently deferred indefinitely.

Concretely, for each service: which workload identities may call it, on which paths and methods. Default deny. Without that, mesh membership means every workload can reach every service with a valid certificate, and you have upgraded unauthenticated internal traffic to authenticated internal traffic without reducing reachability.

For agent runtimes specifically, this is where you enforce that the browsing agent's workload cannot reach the payments service and that the analysis sandbox can reach nothing at all. Those constraints are cheap to express in mesh policy and expensive to enforce anywhere else. See tool use safety and sandboxing agent actions.

Practical Notes

One workload identity per agent where feasible. If agents are deployed as separate services, they get separate SPIFFE IDs and mesh policy can distinguish them. Co-locating many agents in one runtime for efficiency means giving up that distinction, and it should be a deliberate trade rather than an accident of packaging.

Attest on image digest, not just service account. Digest-based attestation ties the identity to specific verified code, which is what makes a supply-chain compromise visible as an attestation failure rather than as normal traffic. See securing the agent supply chain.

Keep SVID lifetimes short and verify rotation actually works. A rotation mechanism that has never been exercised under load is a mechanism that fails during an incident. Test by forcing early expiry in staging.

Expect non-mesh participants. External agents, SaaS integrations, and serverless functions outside the mesh need a boundary where workload identity is translated into an internal principal. That boundary is a gateway, and it should perform DID or token verification and then issue internal credentials — not extend mesh membership outward.

Common questions

Do I need a service mesh to use SPIFFE?

No. SPIFFE and its reference implementation issue SVIDs to workloads independent of any mesh; applications can use them directly for mTLS or to obtain tokens. A mesh adds transparent mTLS and centralized policy without application changes, which is convenient, but the identity layer stands alone. For a small agent fleet, direct SVID use avoids a large operational commitment.

Is cloud-provider workload identity enough?

For calls to that provider's own services, generally yes — it is the same model with the provider as the attestor, and it removes stored credentials, which is the main win. Where it falls short is cross-cloud and hybrid deployments, and service-to-service authentication between your own workloads, where you end up back at shared secrets. SPIFFE's value is a single identity model across all of it.

Does mTLS everywhere hurt performance?

Handshake cost is real but amortized by connection reuse, and modern implementations add low single-digit milliseconds on connection establishment with negligible per-request overhead thereafter. Against agent workloads dominated by model inference latency, it is not a factor. The genuine costs are operational: certificate lifecycle, debugging encrypted traffic, and the failure modes when rotation breaks.

How does this interact with per-tenant isolation?

It does not provide it. Workload identity is about the process, and a multi-tenant agent runtime serves all tenants under one workload identity. Tenant isolation has to be enforced at the data layer and in the request-scoped authority — row-level security keyed on the tenant from the authenticated session, and tokens whose subject is the principal being served. Treating mesh identity as tenant isolation is a serious error. See tenant isolation with row-level security.

How Praesidia approaches the identity layers

Praesidia separates the three layers rather than collapsing them. Agents hold a logical identity distinct from their runtime, and every governed call carries the acting agent plus the asserted principal, with authority conveyed by short-lived, audience-restricted, scope-limited tokens obtained through exchange. Credentials for downstream systems are held at the proxy and attached after policy evaluation, so no long-lived secret sits in an agent's environment or context.

That model composes with whatever workload identity your platform provides: attested transport underneath, agent attribution and principal-bound authority above it, and every decision recorded with all three identities. See authenticate apps, agents, and MCP servers and the Praesidia documentation.