设计完整的代理身份生命周期：诞生、声明、委派与退役

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.