What Identity Should Survive When an Agent Process Does Not?

An agent process is not an organizational actor. It is one temporary expression of an actor: a container, worker, browser session or service process that will eventually be restarted, redeployed, patched or replaced. Treating its name as the universal answer to authentication, authorization, observability and accountability makes that replacement invisible precisely when it should be examined.

Autonomous organizations need a more deliberate answer to a basic question: when a process disappears, what identity should remain—and what identity must be retired? The answer is not one permanent agent ID. It is an identity stack, with distinct identifiers for the governed role, the executing workload, the particular runtime incarnation, the bounded execution and the authority under which it acted.

One name cannot do five jobs

A name such as “vendor-payment-agent” is useful. It gives people and policies a stable reference to a business role. The organization may want that role to persist for years, through changes in model, prompt, code, infrastructure and operator ownership. But a stable role name cannot prove which software made a request this morning, which process produced a disputed payment, or whether that process still has permission to act now.

The existing standards already point away from a universal identifier. NIST SP 800-207A moves cloud-native access decisions away from network location and toward application and service identities, alongside user identities. SPIFFE defines workload identities and SVIDs—the cryptographically verifiable documents through which workloads prove those identities. OpenTelemetry separately defines a service name and service.instance.id for a particular service instance. Kubernetes permits an object name to be reused after deletion while assigning a UID that distinguishes historical occurrences.

These are not competing forms of the same thing. They answer different questions. A workload identity answers which authenticated software workload is asking. A runtime-instance identifier answers which incarnation of that workload produced an event. An organizational actor identifier answers which governed role the organization recognizes. None should be silently substituted for another.

The five-part action binding

AES recommends that every consequential action carry, or resolve to, five identifiers. This is an architectural recommendation assembled from distinct concepts in the standards; it is not a record format prescribed by NIST, SPIFFE, Kubernetes, OpenTelemetry or W3C PROV.

1. Organizational actor ID: a stable identifier for the governed role, such as the organization’s vendor-payment agent. It is the identity to which responsibility, operating purpose and long-lived policy relationships attach.
2. Workload identity: a cryptographically verified identity for the executing software. A SPIFFE ID and its short-lived SVID are a concrete pattern for this layer, though they identify workloads rather than legally or organizationally accountable actors.
3. Runtime-instance ID: a non-reusable identifier for this particular deployment or process incarnation. It must change when an instance is rebuilt or restarted, even if its logical name and workload identity remain the same.
4. Execution ID: an identifier for a bounded run of work—one task, workflow attempt or action sequence. It distinguishes two operations performed by the same live instance.
5. Authority-grant ID: the current, bounded grant that allowed the action. The actor ID does not itself confer authority; a valid grant must be checked at the point of effect.

The binding should travel with externally visible effects: a submitted payment, changed customer record, transmitted filing, issued order or access request. It should also be retained in the durable evidence for the effect. An operator investigating a result must be able to ask two separate questions without inference: which organizational role acted, and which exact workload instance performed the action?

Continuity is a recorded relationship, not a matching label

A replacement process may legitimately continue the work of its predecessor. That does not make the two processes identical. A new container receiving the name “vendor-payment-agent” after an outage is a new runtime instance. It should receive fresh short-lived credentials, obtain current authority, and receive a new runtime-instance ID. A matching agent name, prompt or model version is not evidence of continuity.

Instead, the runtime should record continuity explicitly: instance B succeeds instance A for a stated actor, workload and scope, at a stated time. The relationship may include the handoff state or work lease that B inherited, but it must not erase A’s historical identity. Kubernetes offers a useful precedent here: a reusable object name is not enough to distinguish historical objects, so the system-generated UID preserves the distinction. The UID itself is not a cross-cluster organizational identity. The principle is what matters: logical sameness and historical occurrence are separate facts.

This discipline also prevents a common audit failure. If a later instance overwrites the identity of an earlier one, an incident review can establish only that “the payment agent” acted. It cannot determine whether the action came from the pre-patch workload, the replacement workload, a compromised instance, or an unauthorized duplicate. The stable actor ID preserves business accountability; the instance ID preserves forensic precision.

Versions describe the execution; they do not replace the actor

Model version, prompt version, software build, tool configuration and policy version belong in the execution record. They are necessary context for reproducing conditions, interpreting behavior and reviewing the applicable controls. They are not identity. A model provider is not the organizational agent that made a decision on the organization’s behalf, and a model version does not establish responsibility or present authority.

This distinction becomes operational during upgrades. An organization may preserve the organizational actor ID while changing the model or prompt, because the governed role remains the same. But each resulting runtime instance must be distinguishable, and each execution must show the versions actually used. That permits a precise question after an incident: did the role act within its grant, and did this particular execution use the approved workload and configuration?

Authority must be current and specific

W3C PROV provides a useful conceptual separation between agents, activities and responsibility relationships. It allows activities to be associated with multiple agents, including people, software and organizations, and can describe one agent acting on behalf of another. A governed runtime should apply the same separation to control decisions: the organizational actor may be responsible for a business action; the workload may execute it; a human or policy service may issue the authority; and the execution is the bounded activity where these relationships meet.

The authority-grant ID is essential because stable identities tempt organizations into permanent permission. An actor may be approved to manage vendor payments in general, yet a particular execution may lack authority for this payment amount, recipient, jurisdiction or time. A current grant connects the action to its limits. When the grant expires, is revoked or falls outside scope, the actor’s long-lived identity should not keep the action alive.

Build the identity record at the effect boundary

The practical control point is not the chat interface or the planning trace. It is the effect boundary: the point where an agent changes an external system, spends funds, communicates a commitment or exposes data. At that boundary, the runtime should validate the workload credential and the current grant, attach the five-part binding, and persist the evidence before or together with the effect according to the system’s reliability design.

• Maintain an organizational actor registry independent of deployments, model providers and credential issuers.
• Issue workload credentials to authenticated software workloads and rotate them as designed; do not use a credential as the durable business identity.
• Generate runtime-instance IDs that are never reused, and retain predecessor-to-successor continuity records.
• Create execution IDs at a bounded unit of work, then record model, prompt, code, tool and policy versions as execution attributes.
• Require a live, scoped authority grant for consequential effects, and make the grant identifier part of the durable action evidence.
• Expose actor ID, workload identity and instance ID separately in audit and observability views. service.instance.id can help with observability, but it is not an authentication credential.

The result is not bureaucratic metadata. It is a workable division between continuity and replacement. The organization can say that its vendor-payment role endured a platform migration, while also proving that no pre-migration process retained credentials or authority after it was retired. It can preserve accountable roles without pretending that a restarted process is the same historical actor.

Autonomous organizations will replace agent processes constantly. Their identity model should make that ordinary operational fact visible. Preserve the role. Verify the workload. Retire the instance. Bound the execution. Check the grant. Then every material effect can carry both the continuity the organization needs and the precision its operators will eventually need to investigate it.