Give the agent a workload identity

An agent usually arrives with several names. It has a product name in the interface, a model name in configuration, a session identifier in telemetry, a service account in the cloud, and perhaps the user's identity in an access token. These labels are useful. None necessarily identifies the piece of software that is making a request right now.

That gap was manageable when model systems mainly returned text. It becomes dangerous when many agent workers run concurrently, call remote tools, and delegate tasks across organizational boundaries. A receiving service needs to know more than which model family generated an argument. It needs a verifiable identity for the running workload presenting the request.

The SPIFFE standard was built for this class of problem in distributed systems. It defines portable workload identities and short-lived identity documents that software can obtain through a workload API. The model is not specific to agents, which is precisely its strength. An agent process is a workload before it is a persona.

Names belong to different layers

A model identifier says which inference system was requested. An agent identifier may describe a configured bundle of instructions and tools. A conversation identifier groups related messages. A user identity says on whose behalf access may be requested. A workload identity says which deployed process is at the other end of an authenticated connection.

Collapsing these layers produces records that look precise but cannot answer basic questions. “ResearchAgent called payroll” may refer to one configuration deployed in three environments, ten replicas, and two trust domains. It may have been invoked by several users under different scopes. The friendly name does not identify the instance, deployment, or security boundary that actually held the credential.

SPIFFE IDs are URIs assigned within a trust domain. Its concepts specification separates the workload identifier from the trust root that vouches for it. This provides a useful grammar for agent infrastructure: identity can name a role or deployment while verification remains anchored in an administrative domain.

The agent is what the interface calls it. The workload is what the infrastructure can prove is running.

The distinction matters during incident review. If a credential is abused, operators must identify which workload obtained it, on which node, under which attestation policy, and for how long. A session ID may correlate the behavior. It does not authenticate the process. A static API key may authenticate possession. It does not explain how the holder qualified to receive it.

Identity should be issued from runtime facts

SPIFFE uses workload attestation to decide which identity documents a process may receive. The Workload API can serve X.509 or JWT identity documents without shipping a long-lived secret inside the application. Credentials are short-lived and rotated. This changes the operational question from “where did we store the agent's key?” to “what runtime evidence allowed this workload to obtain an identity?”

That evidence might include the deployment namespace, service account, executable, node attestation, or other selectors enforced by the platform. The policy still needs careful design. If every agent worker in a cluster receives the same identity, the cryptography may be strong while accountability remains coarse. If identities are unique per process but no stable deployment identity connects them, review becomes a sea of ephemeral names.

A practical design uses both. A stable identity names the approved workload class; instance and deployment attributes identify the execution context. The decision record binds these to the agent configuration, model route, caller, and task. The identity proves which workload made the request. The surrounding evidence explains why that workload was allowed to make it.

Identity granularity should follow consequence. A read-only fleet that serves public material may reasonably share a workload identity at the deployment level. A worker that approves changes or crosses customer boundaries may need a narrower identity and stronger attestation. More identifiers are not automatically more accountable; the useful identity is the one policy can govern and operators can connect to a real deployment without ambiguity.

Short-lived credentials also create an honest endpoint. An agent that outlives its task should not retain the power accumulated during the task. Expiry limits the value of a captured credential and makes continued access require fresh attestation. Rotation is not merely hygiene; it is a recurring decision that the workload still qualifies.

Federation is a policy choice

Agent interoperability often crosses trust domains. SPIFFE supports federation by distributing the trust bundles needed to verify identities issued elsewhere. Its federation specification is explicit that domains remain independently administered even when they authenticate one another.

Accepting a foreign identity should therefore be visible as policy. Federation proves that another authority issued the credential. It does not require the local service to accept every workload from that authority or grant equal access to similarly named roles. Local authorization should map specific foreign identities to specific resources and preserve the trust-bundle version used during verification.

This creates a clean separation for agent systems. Protocols carry tasks. User tokens carry delegated access. Workload identities authenticate the software endpoints. Policy decides what the authenticated workload may do for the delegated user. Evidence binds the layers without pretending they are one identity.

An agent can change models and remain the same configured service. A conversation can end while the workload continues. A user can revoke delegation while the process remains healthy. Giving the workload its own identity makes those transitions governable instead of hiding them behind a single convenient name.

— Dispatches · Summit Cognitive