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.
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.
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 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.
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 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:
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. 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.
At a high level, SAL defines:
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.