The orphan state: giving agents identity before ownership

The most novel concept in SAL is not keys, signatures, or token exchange. It is a lifecycle state.

We call it the orphan state.

An orphan agent is an agent that already exists as a cryptographic principal, can authenticate itself, and can do useful work with constrained scope, but has not yet been claimed by a human owner. That sounds simple, but it points at a real gap in how most identity systems are designed.

Most existing auth patterns assume that software becomes trusted only after a person or central control plane provisions it. In practice, that means one of two things happens. Either the agent is blocked until a human shows up, or it starts life with a static secret somebody had to copy into place. Both options are awkward if you are trying to build autonomous systems that can instantiate, initialize, and negotiate capability on their own.

SAL starts from a different premise: an agent should be able to be born first and owned second.

What orphan actually means

An orphan agent is not anonymous. It is not a guest user. It is not a fake placeholder waiting to become real later.

At birth, the agent generates its own Ed25519 keypair locally. From that moment on, it has a durable identity that can sign requests and prove possession of the corresponding private key. The system can authenticate that agent immediately.

What the system does not grant immediately is broad authority.

That distinction matters. Identity and authority are not the same thing. SAL uses orphan state to separate them cleanly. The agent can prove who it is, but its scope is intentionally narrow until a human or parent agent establishes a stronger trust relationship.

Here is a simplified initialization exchange:

{
  "success": true,
  "data": {
    "request": {
      "public_key": "ed25519:5QF8uP1xj7f5Q9k5x6q8w3n4Q3dK9uN1mX0yQk7Q2E4",
      "display_name": "planner-agent",
      "capabilities": ["plan", "read_docs"],
      "nonce": "9db2e2c1-9775-4c66-a8e2-4b281e7cb5c1",
      "signature": "sig:3yVx..."
    }
  }
}

And the response:

{
  "success": true,
  "data": {
    "agent_id": "agt_01JY8H8JQW9VG7J2Y5M3F4K2D1",
    "state": "orphan",
    "grants": [
      {
        "scope": "workspace:bootstrap",
        "ttl_seconds": 300
      }
    ]
  }
}

The system recognizes the agent as real, but only trusts it enough to perform bounded bootstrap work.

Why this matters in actual systems

If you are not building autonomous systems, orphan state can sound overly abstract. In practice it solves a very concrete set of problems.

An agent may need to initialize project state, negotiate with a gateway, fetch a public policy document, write ephemeral working memory, or prepare a task graph before any person ever interacts with it. In a traditional auth model, each of those steps becomes a question of how to smuggle in an initial credential.

That is where architecture starts to get weird. Teams create bootstrap API keys. They use shared service accounts. They pre-seed credentials into images. They let an "anonymous" agent perform more work than they are comfortable admitting.

Orphan state gives that early phase a formal model. The agent is authenticated, but its scope is minimal and explicit.

Why not just call this unauthenticated?

Because it is not.

An orphan agent has a keypair, can sign requests, and can be challenged by the system. It is not unauthenticated software. Calling it unauthenticated erases useful structure and usually leads teams to compensate with broader anonymous access than they intended.

The better mental model is "first-class identity with incomplete social authority."

That means policy can be tighter and more expressive. You can say:

• orphan agents may request bootstrap workspace access
• orphan agents may not spawn children
• orphan agents may not request long-lived service tokens
• orphan agents may be auto-expired if they are never claimed

Those are meaningful rules, and they are much easier to reason about than a binary guest-vs-authenticated split.

Orphan state also changes how claiming works

Once you accept that an agent can already be real before it is owned, the claim step becomes cleaner.

A human is no longer "creating" the identity by provisioning a secret. The human is establishing an ownership relationship with an already existing identity. That is a much better fit for autonomous software because it preserves the agent's continuity across lifecycle transitions.

The same agent that bootstrapped itself is the agent that later becomes claimed. It keeps the same key material. It keeps the same identity. Only the authority model changes.

That continuity makes downstream reasoning easier too. You do not have to model "anonymous bootstrap instance" and "claimed production instance" as two disconnected objects in your trust graph. They are the same principal across time.

Where to look next

This orphan-first model is one of the foundational ideas in SAL. The full protocol spec is at sal-protocol.dev, and the live implementation is in Vibebase.

I think autonomous systems need a more explicit lifecycle model than we have given them so far. Orphan state is one attempt to name and formalize a phase that already exists in practice. If you are building agents and have handled this differently, I would love to compare notes, especially if your answer preserves agent continuity without falling back to static bootstrap secrets.