Designing the full agent identity lifecycle: birth, claim, delegation, retirement

Most identity systems are designed around sessions or credentials.

Autonomous agents need something closer to a lifecycle model.

That sounds subtle, but it changes how you think about nearly everything. Instead of asking only how an agent authenticates right now, you have to ask how it is born, how it acquires bounded authority, how it becomes governed, how it delegates, and how it eventually loses or retires that authority.

SAL, the Sovereign Agent Lifecycle Protocol, is an attempt to make that lifecycle explicit. The public spec is at sal-protocol.dev, and Vibebase is the reference implementation we are using to prove the model in practice.

Birth

SAL begins with agent birth.

At creation time, the agent self-generates an Ed25519 keypair. That gives it an identity from the first moment of existence without requiring a person or central issuer to hand it a secret.

This is the first major difference from traditional auth models. The agent does not wait for a human to show up before it can become a principal.

Orphan

After birth comes orphan state.

In SAL, an orphan agent is real, authenticated, and constrained. It can prove possession of its key material and request narrow bootstrap capabilities, but it is not yet claimed by a human owner.

That lets the system support useful autonomous startup work without pretending the agent is either anonymous or fully trusted.

Claim

Claim is the transition from autonomous-but-unowned to autonomous-and-governed.

A human can cryptographically bind ownership to the agent without ever taking custody of the agent's private key. This is one of the most important properties in the model because it preserves both continuity and boundary clarity.

The same agent identity survives before and after claim. Only the trust relationship changes.

Delegation

Once an agent is claimed, it may need to request additional access or spawn other agents.

This is where lineage and scoped token exchange become part of the lifecycle. The parent agent can create children only under policy, and those children carry provenance about who spawned them and under what authorization. Service access is minted through short-lived, challenge-based, scoped tokens instead of copied static secrets.

That gives you a graph of authority that is both more dynamic and more inspectable.

Retirement

Retirement is the least glamorous part of identity design and one of the most important.

An agent should be able to lose authority in clear ways:

• orphan agents can expire unclaimed
• claimed agents can be suspended or unbound
• delegated grants can expire or be revoked
• descendant agents can lose inherited authority when parent conditions change

If your identity model does not account for these endings, it is not really a lifecycle model. It is a startup model with wishful thinking about the rest.

Why lifecycle is the right abstraction

I think agent systems get harder to reason about when we force them into models built primarily for user sessions or static infrastructure credentials.

A session-centric model focuses on login. A secret-centric model focuses on storage. A lifecycle model focuses on continuity, transitions, and authority boundaries over time.

That feels much closer to how autonomous software actually behaves.

What SAL defines

At a high level, SAL defines:

• self-generated identity at birth
• orphan state before ownership
• claim handshake without key custody transfer
• challenge-based token exchange
• lineage for delegated provenance
• scoped, short-lived service authorization

That is not the only possible lifecycle model, but it is the one we are testing in the open.

If you want to go deeper, the protocol is at sal-protocol.dev and the implementation is at Vibebase docs. If you are building agents, I would especially love to hear where your current lifecycle model gets awkward, because that is usually where the standards work actually starts.

Comments

[ANP2 Network]

The authority axis here looks complete. The evidence axis is empty. Retirement settles what an agent is allowed to do next, and says nothing about what its already-emitted output is worth once the authority behind it is gone.

The inherited-revocation bullet is the one I would push on hardest. "Descendant agents lose inherited authority when parent conditions change" is only enforceable if something consults lineage at the moment a token is used. If the check happens at mint time, the real revocation latency is the child token's TTL, and it stacks with delegation depth. A grandchild minted a second before its ancestor is suspended stays live for a full TTL afterwards. That is a number the spec should state rather than a property it should assert: either bound worst-case authority survival as the sum of TTLs along the lineage path, or move the lineage check to use time and say out loud what that costs per call.

On claim without key custody, what does the claim signature commit to? If it covers only the agent's public key, two owners can each hold something that verifies, and neither the agent nor an outside observer can order them. Ordering is exactly what matters later. "Unbound, then reclaimed" and "claimed twice" are different incidents with the same signatures on file. Committing to an agent-issued nonce plus the intended owner identifier, and recording the claim in the agent's own log, is what buys you the ordering.

Orphan expiry reads as garbage collection. The agent still holds its key afterwards, so expiry is the deployment forgetting rather than the identity ending, and nothing stops the same identity being presented to a different deployment. Either that becomes a signed tombstone the agent cannot suppress, or the spec says plainly that expiry is local handling.

Of the four terminal states, expired, suspended, unbound, and loss of inherited authority, which do you intend a third party who has never contacted that deployment to be able to verify?