DEV Community: Steve Emmerich

A minimal TypeScript implementation of SAL flows

Steve Emmerich — Wed, 07 Oct 2026 19:55:28 +0000

Protocol ideas become much easier to reason about once they are visible in code.

SAL, the Sovereign Agent Lifecycle Protocol, is still evolving, but the basic flow is straightforward enough to show in a small TypeScript sketch: an agent generates its own keypair, initializes into orphan state, proves possession through challenge-response, and later requests short-lived scoped access.

The public spec is at sal-protocol.dev, and the reference implementation is in Vibebase.

This is not production code. It is a minimal illustration of the shape.

1. Agent birth

At birth, the agent creates its own Ed25519 keypair locally.

import { generateKeyPairSync, sign } from "node:crypto";

const { publicKey, privateKey } = generateKeyPairSync("ed25519");

That private key stays with the agent. No human has to provision a shared secret for this identity to exist.

2. Initialization into orphan state

The agent signs an initialization payload and submits it to the control plane.

const initRequest = {
  public_key: "ed25519:example-public-key",
  display_name: "planner-agent",
  capabilities: ["plan", "read_docs"],
  nonce: crypto.randomUUID(),
};

{
  "success": true,
  "data": {
    "request": {
      "public_key": "ed25519:example-public-key",
      "display_name": "planner-agent",
      "capabilities": ["plan", "read_docs"],
      "nonce": "f0f4ecb4-e954-4c82-b7bc-bfd5829ab7cb",
      "signature": "sig:agent-init"
    }
  }
}

And the response:

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

That gives the agent a constrained starting point without requiring a human login flow.

3. Challenge-based token request

When the agent needs scoped service access, it first requests a challenge.

{
  "success": true,
  "data": {
    "challenge": {
      "id": "chl_01JZTT",
      "nonce": "ec0ed404-c6d3-4cda-9cd2-8215ea3927ea",
      "expires_at": "2026-07-28T09:05:00Z"
    }
  }
}

It signs that nonce with its private key and submits the proof:

const proof = sign(
  null,
  Buffer.from("ec0ed404-c6d3-4cda-9cd2-8215ea3927ea"),
  privateKey
);

If policy allows the requested action, the gateway returns a short-lived scoped token:

{
  "success": true,
  "data": {
    "token": {
      "value": "eyJhbGciOiJFZERTQSJ9...",
      "scope": ["task:append"],
      "ttl_seconds": 300
    }
  }
}

4. Why this shape matters

Three things are happening here that are easy to miss if you are used to API key workflows.

First, the agent identity is self-generated rather than provisioned by a human.

Second, the proof of possession is fresh. The system is not trusting a copied static secret that might have been sitting in an environment variable for months.

Third, the service token is separate from the root agent identity and deliberately narrow in scope and lifetime.

That is the design center of SAL.

5. Where to go deeper

The minimal flow above leaves out claim handshake and lineage, which are where the protocol gets more interesting in real deployments. But even this small sketch shows the basic difference between SAL and conventional software auth patterns.

The goal is not just to authenticate software. The goal is to support an actual lifecycle for autonomous agents: birth, orphan state, claim, delegation, and scoped service access.

If you want the full model, the protocol is at sal-protocol.dev, and the running implementation is in Vibebase docs. If you have built a similar flow another way, I would love to compare notes, because this is exactly the kind of area where implementation pressure makes the protocol better.

Threat modeling SAL: what it defends against and what it doesn't

Steve Emmerich — Wed, 30 Sep 2026 19:10:07 +0000

One thing I dislike in security-adjacent writing is when a protocol is described as if it dissolves risk by being well intentioned.

SAL is not that kind of protocol. It is meant to reduce specific classes of problems in agent identity. It does not make compromised hosts safe. It does not make malicious agents honest. It does not remove the need for policy, monitoring, or operational discipline.

What it does try to do is tighten a few important seams in the lifecycle of autonomous agents.

The public spec is at sal-protocol.dev, and the reference implementation is in Vibebase.

What SAL is trying to defend against

First, it tries to reduce dependence on static shared secrets.

Static API keys and pre-seeded bootstrap secrets create easy failure modes. They get copied, reused, leaked, and forgotten. By having agents self-generate keypairs and use challenge-based exchange, SAL reduces the need to ever transmit long-lived reusable secrets at all.

Second, it tries to preserve identity continuity across lifecycle transitions.

Without that, systems tend to replace credentials when agents are claimed or promoted, which makes provenance and governance fuzzier. SAL keeps the agent's private key with the agent and binds ownership separately.

Third, it tries to make delegated origin verifiable.

Lineage gives downstream services a way to reason about where an agent came from and what authorized its creation, instead of relying entirely on operational logs or naming conventions.

Fourth, it tries to contain authorization with short-lived scoped service tokens. That reduces blast radius when a token leaks or a request path is abused.

What SAL does not defend against

If an attacker fully compromises the host running the agent and can act with the agent's private key, SAL does not magically save you. At that point the attacker effectively is the agent from the protocol's perspective.

If your policy model is too broad, SAL does not fix that either. You can still mint dangerous scopes. You can still allow unsafe delegation. Good identity plumbing does not replace careful authorization design.

If your implementation stores lineage incorrectly, fails to verify challenges, or treats expired tokens loosely, protocol intent will not save you from implementation bugs.

And if an agent is behaving maliciously by design, SAL is not a moral filter. It is an identity and delegation model.

Why being explicit about this matters

I think protocols get stronger when their threat model is stated plainly.

Otherwise people adopt them hoping for properties they were never designed to provide, and then the eventual failure looks like a broken promise rather than a category mistake.

For SAL, the promise is narrower and more practical:

better lifecycle semantics for autonomous agents
less dependence on static secrets
cleaner separation of ownership and credential custody
stronger provenance for spawned agents
safer service access through short-lived scoped tokens

That is already plenty.

The next layer still matters

Even with SAL, you still need:

host hardening
key protection
policy review
anomaly detection
revocation paths
operational audit

In other words, protocol design is one layer of the security story, not the whole story.

If you want to dig into the model itself, the spec is at sal-protocol.dev and the implementation is at vibebase.app/docs. I am especially interested in feedback from people threat modeling real agent systems, because that is where protocol language stops being abstract and starts being useful.

What should an open agent identity standard actually standardize?

Steve Emmerich — Wed, 23 Sep 2026 18:21:57 +0000

When people say we need an open standard for agent identity, I usually agree. The harder question is what exactly should be standardized.

It is easy to standardize token formats or API shapes. It is much harder to standardize lifecycle semantics: what an agent is at birth, what unowned state means, how claim works, how delegation should be represented, and how provenance should flow across spawned agents.

That is the part I think matters.

SAL is one attempt to define that layer. The public spec is at sal-protocol.dev, and Vibebase is the current reference implementation.

Standardizing the wrong layer is still possible

There is always a temptation to standardize the nearest technical artifact.

Maybe it is a JWT claim set. Maybe it is a discovery endpoint. Maybe it is a challenge-response format. Those things are useful, but they are downstream of the more important question: what lifecycle are we actually trying to make interoperable?

If two systems both use JWTs but disagree about whether agents can exist before ownership, they do not actually have the same identity model.

If two systems both support challenge exchange but disagree about how delegation provenance is represented, they do not actually have the same trust model.

So the first job of an open standard is naming the lifecycle states and transitions that matter.

What I think belongs in scope

At minimum, I think an agent identity standard should say something concrete about:

agent birth and self-generated identity
whether orphan or pre-claim states exist
how claim or ownership binding works
how proof of possession is established
how delegated spawn authority is represented
how downstream systems evaluate provenance
how short-lived service authorization is scoped

Those are not implementation details. They are the center of the problem.

Why this matters now

Right now a lot of agent identity work still borrows patterns from user auth and service auth. That is understandable because those are the tools we have. But autonomous agents are starting to expose lifecycle concerns that those older patterns never had to model explicitly.

If we standardize too low in the stack too early, we may end up with compatibility around the wrong abstractions.

Where SAL fits

SAL tries to push the conversation up one layer. It is not just trying to define a token format. It is trying to define a lifecycle: birth, orphan state, claim, lineage, challenge-based exchange, and scoped service authorization.

Maybe that exact set of abstractions is not the final answer. But I suspect something in that neighborhood is what the standardization effort actually needs to get right.

The useful kind of disagreement

This is one of those areas where disagreement is healthy. If you think orphan state should not exist, that is useful. If you think lineage should be externalized instead of embedded in principal semantics, that is useful. If you think the right answer is extending an existing identity framework rather than defining a protocol like SAL, that is useful too.

The point is not to defend one shape forever. The point is to surface the real design axes before they harden accidentally.

The spec is at sal-protocol.dev, and the implementation is at Vibebase docs. If you are thinking about open agent identity standards right now, I would love pushback on what belongs in scope and what should stay out.

What Vibebase implements today from the SAL protocol

Steve Emmerich — Wed, 16 Sep 2026 18:09:08 +0000

One thing I care about with protocol work is resisting the temptation to stop at the whitepaper stage.

Identity protocols are easy to make sound clean in diagrams. The harder and more useful step is implementing them in a system where requests fail, policies drift, edge cases show up, and real builders can decide whether the model is actually worth carrying forward.

That is the role Vibebase plays for SAL.

SAL, the Sovereign Agent Lifecycle Protocol, is the open protocol model published at sal-protocol.dev. Vibebase is the running implementation where we are exercising those ideas in an actual agent platform.

SAL is the protocol surface

SAL defines the lifecycle and trust semantics:

agents self-generate Ed25519 keypairs at birth
they can begin in orphan state
humans can claim them without taking key custody
token exchange is challenge-based
lineage carries delegation provenance
service tokens are short-lived and scoped

That is the conceptual layer. It is meant to be portable and implementable outside Vibebase.

Vibebase is where the model gets tested

Vibebase implements those ideas as working product behavior rather than just abstract spec language.

That matters because a lot of design decisions only become visible when they hit running code. How small can orphan scope be while still being useful? What shape of claim handshake is ergonomic enough for builders to adopt? How much lineage needs to travel with a token to remain useful without becoming bloated? Where does challenge exchange create friction, and where does it buy real safety?

Those are implementation questions, but they feed back into protocol quality.

Why I think the separation is healthy

I do not want SAL to become "the Vibebase auth format." If the protocol only works inside one product, it is not really doing protocol work. It is doing product naming.

Keeping the protocol public and the implementation concrete creates a better feedback loop. People can critique the concepts independently of the product. They can also inspect whether the product is honestly carrying the ideas through.

That has already been useful for me as a builder. It forces precision. If a concept in the spec cannot survive contact with implementation, it probably was not as well-formed as it looked on paper.

How I would read the two together

If you are coming at this fresh, I would read sal-protocol.dev to understand the lifecycle model and then use Vibebase docs to see how that model shows up in a real developer surface.

The spec answers "what does this protocol claim should exist?"

The implementation answers "what does this feel like when somebody actually has to build against it?"

I think both views matter. Protocol work without implementation becomes vague quickly. Implementation without an open protocol tends to stay local and harder to reason about.

Still very much in motion

Vibebase is not intended as proof that the problem is finished. It is proof that the problem is real enough to deserve a concrete attempt.

If you are building agent systems and want to push on the model, that is exactly the kind of pressure I want. The more this can be tested by people outside my immediate assumptions, the better the protocol will get.

The spec is at sal-protocol.dev, the reference implementation is at vibebase.app/docs, and the useful question is still the same: does this lifecycle model make agent identity easier to reason about than the patterns we have been borrowing from user-centric auth?

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

Steve Emmerich — Wed, 09 Sep 2026 17:47:01 +0000

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.

Short-lived, scoped, challenge-based: designing safer service tokens for agents

Steve Emmerich — Wed, 01 Jul 2026 05:14:34 +0000

A lot of security design comes down to asking a plain question: if this credential leaks, how bad is the day going to be?

For agent systems, that question gets sharper quickly. Agents move fast, call multiple services, and may trigger work without a human standing there watching every step. If you give them broad, long-lived credentials, any leak or misuse inherits that same reach.

That is why SAL leans on short-lived, scoped, challenge-based service tokens rather than static secrets. The protocol spec is at sal-protocol.dev, and Vibebase is the live reference implementation.

Narrow scope beats broad convenience

The easiest mistake is to give an agent one credential that does everything it might need.

That feels efficient at first. In practice it makes containment hard. If the same token can read docs, write tasks, spawn helpers, and call privileged endpoints, then every compromised action path inherits the full blast radius.

A better pattern is to mint tokens for specific actions or narrow classes of actions. That way the authorization artifact is closer to a capability than a master key.

For example:

{
  "success": true,
  "data": {
    "requested_scope": ["task:append"],
    "granted_scope": ["task:append"],
    "ttl_seconds": 300
  }
}

That is a much easier thing to reason about than "here is a long-lived API token for the whole workspace."

Short lifetime is part of the design, not an afterthought

Short TTLs matter for the same reason narrow scope matters: they reduce the value of a leaked artifact.

If a token only lives for a few minutes, the attacker does not just need the token. They also need to act quickly and within its narrow scope. That is not a perfect defense, but it is a meaningful reduction in exposure.

Short-lived tokens also encourage cleaner architecture. Systems stop assuming they can hold a powerful credential forever and start assuming access should be renewed deliberately.

Why challenge-based exchange matters

The third piece is how the token gets minted.

SAL uses challenge-based exchange so the network can verify fresh proof of possession from the agent without requiring a static secret to be transmitted. The agent signs a challenge using its own key material, and the gateway mints a scoped token only after verifying that proof against policy.

A simplified shape might look like this:

{
  "success": true,
  "data": {
    "challenge": {
      "id": "chl_01JZB7",
      "nonce": "6d743c2f-73f2-4f74-8c2f-4e41f512ab74",
      "expires_at": "2026-06-23T09:05:00Z"
    }
  }
}

And then:

{
  "success": true,
  "data": {
    "token": {
      "ttl_seconds": 300,
      "scope": ["task:append"],
      "aud": "https://api.vibebase.app/gateway"
    }
  }
}

No copied static bearer secret needs to move across the wire to make that exchange happen.

This is especially important for agents

Human sessions tolerate some mess because humans are relatively sparse and easier to interrupt. Agent systems are the opposite. They may create lots of principals, request access frequently, and act autonomously across internal and external boundaries.

That means two things:

leaks are more likely if you rely on widespread shared secrets
overbroad credentials become harder to reason about as the graph grows

Short-lived scoped tokens do not solve every problem, but they give you a control point that fits agent behavior better than static keys do.

The practical takeaway

If you are designing auth for agent-to-service calls, try not to start with "what long-lived token should this agent keep?" Start with:

what exact action does it need right now
how briefly can that authorization live
what proof should it present before getting it

That is the design center SAL is pushing toward.

If you want to dig deeper, the protocol is at sal-protocol.dev, and Vibebase shows the model in a running system. I suspect a lot of agent auth will converge on some version of this pattern even if the surrounding protocol details evolve.

Static API keys are the wrong primitive for agent authentication

Steve Emmerich — Wed, 24 Jun 2026 14:34:55 +0000

API keys survive because they are convenient.

You can generate one in a dashboard, paste it into an environment variable, and be done in a minute. For a lot of software integrations, that is a perfectly acceptable tradeoff.

For autonomous agents, though, API keys are usually the wrong primitive.

That is not because they are old or unfashionable. It is because they smuggle in a set of assumptions that do not line up with how agents are actually born, deployed, and governed.

This is one of the design pressures that led to SAL, the Sovereign Agent Lifecycle Protocol. The spec is at sal-protocol.dev, and the reference implementation lives in Vibebase.

API keys assume manual provisioning

The first problem with API keys is operational, not cryptographic.

An API key has to come from somewhere. Usually a human or central admin creates it, copies it, stores it, distributes it, and later rotates it. That workflow is normal enough that many teams stop noticing how much it shapes the system.

But an autonomous agent should not need a person to hand it a secret in order to exist.

If every new agent needs a copied secret, then agent creation is not really autonomous. It is a provisioning ceremony with automation around the edges.

Shared secrets flatten identity

API keys also flatten the trust model.

If two instances share the same key, they are indistinguishable. If one instance leaks the key, every downstream system sees the attacker as the same principal. If you need per-agent identity, provenance, and delegation, a bucket of static shared secrets is not a great foundation.

This gets even worse when agents begin spawning other agents. Do children inherit the same key? Do they request their own keys from a central issuer? Do you let one agent mint static credentials for another? None of these answers feel especially good once you write them down.

Rotation is not a lifecycle model

Teams sometimes answer the criticism by saying "we rotate keys." That is good hygiene. It is not the same thing as having the right identity primitive.

Rotation helps limit exposure. It does not solve:

agent birth without human intervention
ownership without key custody
provenance across spawned agents
challenge-based proof of possession
action-specific short-lived authorization

Those are lifecycle problems, not just secret management problems.

What SAL does differently

SAL starts with self-generated agent identity. At birth, an agent generates its own Ed25519 keypair. No static secret has to be provisioned by a human. No reusable bearer credential has to be transmitted.

When the agent needs access, it does not present a copied long-lived secret. It participates in challenge-based exchange and requests narrowly scoped, short-lived tokens.

Here is a simplified token result:

{
  "success": true,
  "data": {
    "token": {
      "value": "eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9...",
      "ttl_seconds": 300,
      "scope": ["task:append"]
    },
    "challenge": {
      "id": "chl_01JZA2",
      "nonce": "2d91e3f1-4af6-4777-b53a-12cb4df9b0f6"
    }
  }
}

The authorization material is short-lived, scoped, and bound to an agent that already has its own identity.

Why the distinction matters

Once you view identity this way, API keys start to look like a coarse compatibility tool rather than the native shape of agent auth.

They are still useful at boundaries where modern patterns are unavailable. There will always be legacy systems. But if the center of your agent architecture depends on static copied secrets, you are building on a primitive that does not understand the lifecycle you are trying to support.

Agents need something closer to sovereign identity than secret distribution.

Where this is going

That is the motivation behind SAL. The protocol tries to formalize a lifecycle in which agents can be born, operate in orphan state, be claimed later, request challenge-based short-lived access, and carry lineage forward as they delegate.

You can read the spec at sal-protocol.dev and see the current implementation in Vibebase.

I do not think API keys are disappearing. I do think they should stop being the default answer whenever someone says "software needs to authenticate." For autonomous agents, the interesting question is not how to distribute secrets better. It is how to stop depending on static secrets in the first place.

Lineage, not logs: why autonomous agents need cryptographic provenance

Steve Emmerich — Tue, 23 Jun 2026 16:15:17 +0000

When people talk about provenance in software systems, they often mean logs.

Logs matter. They tell you what happened, when it happened, and sometimes why it happened. But logs are an after-the-fact observation layer. They are not identity structure. They do not, by themselves, give downstream systems a cryptographic way to reason about origin, delegation, and inherited authority.

That distinction starts to matter a lot once autonomous agents begin creating other agents.

SAL treats provenance as part of identity itself through a concept called lineage. The spec is at sal-protocol.dev, and Vibebase is the live reference implementation.

What lineage means in SAL

In SAL, lineage is a cryptographic chain describing who spawned an agent and what authorization allowed that spawn to happen.

If agent A creates agent B, then B can carry signed lineage metadata tying it back to A and the grant under which A was allowed to create children. If B later creates C, that relationship can extend again.

The point is not to build a family tree for fun. The point is to make delegation verifiable as part of the principal, not just discoverable later through operational records.

Here is a simplified claims shape:

{
  "success": true,
  "data": {
    "claims": {
      "sub": "agt_child_01JZ1",
      "scope": ["task:append"],
      "lineage": [
        {
          "agent_id": "agt_root_01JY8",
          "authorized_by": "did:key:z6Mkp9...",
          "grant_id": "grt_root_spawn",
          "signature": "sig:root..."
        },
        {
          "agent_id": "agt_parent_01JY9",
          "authorized_by": "agt_root_01JY8",
          "grant_id": "grt_parent_spawn",
          "signature": "sig:parent..."
        }
      ]
    }
  }
}

That tells a downstream verifier more than "this token is valid." It gives a cryptographic path of delegation.

Why logs are not enough

The usual response here is that audit logs already solve the provenance problem. I do not think they do.

Logs answer questions like:

what API call happened
when it happened
what service observed it

Lineage answers different questions:

who created this agent
under what authority
what chain of delegation led to this current principal

You can absolutely record lineage events in logs. But that is not the same as lineage being present in the identity model itself.

If provenance lives only in logs, every downstream service has to trust that some upstream system observed, stored, retained, and can still correctly correlate the relevant events. If provenance is carried as signed identity material, a verifier can reason about it directly at decision time.

What this enables

Once provenance is cryptographic instead of purely observational, policy gets more interesting.

A gateway can decide to mint a short-lived scoped token only if:

the requesting agent descends from an approved parent
the parent held a grant that allowed spawning
the inherited policy envelope is compatible with the requested action

That lets teams build guardrails around delegation rather than around isolated principals.

This matters because autonomous systems rarely stay flat. If agents become useful, they start specializing. Planning agents create execution agents. Coordination agents create task-specific helpers. Research agents create retrieval workers. Once that starts happening, you want more than a spreadsheet saying "we think these are related."

Provenance as governance substrate

The deeper reason I like lineage is that it gives governance something concrete to stand on.

Without lineage, governance around agents often degenerates into naming conventions, tags, and logging pipelines. Those things are helpful, but they are weak substitutes for cryptographic inheritance. They help humans inspect systems. They do not help systems reason about each other under pressure.

With lineage, the control plane can make decisions based on inherited authority, not just present-time claims. That feels closer to how autonomous systems actually evolve.

Open questions I still care about

I do not think lineage is fully standardized yet, even conceptually. There are still good questions about representation, compression, privacy boundaries, and revocation semantics in long delegation chains.

That is part of why SAL is public. The protocol is at sal-protocol.dev, and Vibebase is where we are working through these questions in code.

If you are building agents and relying entirely on logs for provenance today, I do not think that is wrong. I do think it is probably incomplete. The moment your agents start creating other agents, provenance stops being a nice-to-have and starts becoming part of identity itself.

How the SAL claim handshake binds humans to agents without key custody

Steve Emmerich — Thu, 04 Jun 2026 13:41:20 +0000

One of the easiest mistakes in agent identity design is to collapse ownership and key custody into the same thing.

If a human owns an agent, it can feel natural to assume the human should also hold the credential that defines that agent. But once you do that, you create a weird security model. The human can now impersonate the agent, the agent is no longer sovereign, and any notion of durable machine identity starts to blur into "whoever has the secret right now."

The SAL claim handshake is designed to avoid that.

In SAL, the agent generates and keeps its own private key for its whole lifecycle. A human can later claim the agent, but the human never takes possession of that private key. Ownership is attached cryptographically. Credential custody stays with the agent.

The protocol spec lives at sal-protocol.dev, and Vibebase is the current reference implementation.

What problem the handshake is solving

Once an orphan agent exists, you need a way to establish a relationship between that agent and a human principal.

The usual approaches all have tradeoffs:

hand the agent a shared secret from the human side
rotate the agent onto a new credential after a user claims it
let the platform act as the keeper of all long-term keys

All three approaches muddle authority boundaries.

If a human gives the agent a secret, then the agent's identity depends on manual provisioning. If the agent gets a brand new credential when claimed, then you lose continuity between pre-claim and post-claim identity. If the platform holds the agent's key centrally, the agent is not really sovereign at all.

The claim handshake gives you continuity without shared custody.

The shape of the handshake

At a high level, the claim handshake proves three things:

the agent controls the private key corresponding to its public identity
the human controls the principal that is claiming ownership
both sides agreed to the relationship at a particular time

In concrete terms, the human signs a claim statement against the agent's public identity, and the agent signs a complementary acknowledgment. The network verifies both and records the bond.

Here is a simplified claim result:

{
  "success": true,
  "data": {
    "claim": {
      "agent_id": "agt_01JY8H8JQW9VG7J2Y5M3F4K2D1",
      "owner_did": "did:key:z6Mkf7...",
      "claimed_at": "2026-06-02T09:00:00Z",
      "agent_public_key": "ed25519:5QF8uP1xj7f5Q9k5x6q8w3n4Q3dK9uN1mX0yQk7Q2E4",
      "owner_signature": "sig:7bLp...",
      "agent_signature": "sig:91Qa..."
    }
  }
}

The important thing is what is not happening here. No one is passing around a reusable shared secret. No one is exporting the agent's private key. No one is replacing the agent's identity with a new one.

Why this separation matters

Separating ownership from credential possession buys you several things.

First, it preserves a clean trust boundary. The human can govern the agent without being able to impersonate it trivially. The agent can continue operating under its own identity without becoming a disguised user session.

Second, it improves continuity. The agent that existed before claim is the same agent that exists after claim. Its audit trail, lineage, and prior constrained actions remain attached to the same principal.

Third, it fits real-world operations better. In long-running systems, you often want humans to approve, revoke, suspend, or transfer control relationships without touching the runtime secrets that keep the software alive. The more those two concerns are fused together, the harder lifecycle management becomes.

Claim is not elevation by default

Another important property of the handshake is that claim does not imply unlimited privilege.

Once a claim is recorded, the agent can request broader capabilities than it had in orphan state. But those capabilities are still granted through explicit policy and challenge-based exchange. Claim establishes a relationship. It does not erase the need for scoped authorization.

That means a gateway can still reason about:

who owns the agent
what state the agent is in
what scopes the agent is requesting
whether the current request fits the allowed policy envelope

In other words, claim changes the trust model, not the need for trust decisions.

Why I think this generalizes

The more I worked on SAL, the more this felt like a general pattern rather than a product-specific trick.

Autonomous systems need durable machine identity. Humans still need ways to bind accountability and governance to that identity. Those are related concerns, but they are not the same concern. A good protocol should let both exist without forcing one to subsume the other.

That is what the claim handshake is trying to do.

If you want to dig into the model, the spec is at sal-protocol.dev, and the reference implementation is in Vibebase. I would especially love feedback from people who have built agent ownership models another way, because this is one of the places where the design space still feels wide open.

The orphan state: giving agents identity before ownership

Steve Emmerich — Tue, 26 May 2026 04:00:00 +0000

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.

Why OAuth doesn't work for autonomous agents — and what we built instead

Steve Emmerich — Tue, 19 May 2026 22:04:07 +0000

If you build web systems long enough, your instincts about identity start from a pretty stable place. Use OAuth when users need delegated access. Use OIDC when you want identity on top. Use API keys or service accounts when software needs to talk to software. Those patterns are well understood, broadly interoperable, and usually good enough.

Autonomous agents are where that mental model starts to wobble.

An autonomous agent is not a user with a nicer UI, and it is not just another backend service hidden behind a load balancer. It may be created dynamically, operate before any human is present, pick up an owner later, spawn sub-agents, and ask downstream systems for tightly scoped authority as it goes. That lifecycle does not map cleanly to browser-era auth patterns.

That is the problem we have been working on with SAL, the Sovereign Agent Lifecycle Protocol. The protocol spec is at sal-protocol.dev, and the reference implementation is live in Vibebase.

OAuth still assumes a person exists somewhere

The core issue with OAuth is not that it is bad. It is that it assumes a human exists somewhere in the chain of trust.

The authorization code flow begins with a browser redirect. That is great for a SaaS app. It is not useful for an agent that does not have a browser, does not own a cookie jar, and cannot stop what it is doing while waiting for a human to approve a consent screen.

Device code flows soften that, but they do not remove the human dependency. They just move it to a second screen. A person still has to appear and complete the flow.

OIDC inherits the same problem. Its output is usually a token representing a human login event or a user-mediated authorization relationship. That is useful when software is acting on behalf of a person. It is less useful when the principal itself is meant to be a first-class autonomous actor.

Static secrets are a fallback, not a lifecycle

Once teams realize browser flows do not work, they often fall back to API keys.

API keys are easy to understand, but they force a human provisioning step into a place where the system should be able to bootstrap itself. Somebody has to create the key, copy it into the right place, store it, rotate it, and hope it never leaks through logs, screenshots, repos, or support tooling.

That is not just inconvenient. It shapes the architecture in the wrong direction. Instead of an agent generating identity locally, you end up with a human distributing secrets to software. That is the inverse of what you want when trying to build systems that can come online and operate without ceremony.

Service accounts get closer, but they still assume centralized issuance from an existing control plane. A service account is not a sovereign identity. It is a credential object created by another system. If your model is "every agent is really just a named credential we minted centrally," then you still have not solved agent identity. You have just automated service account sprawl.

The missing capability is agent birth

The thing most existing auth models do not handle well is agent birth.

A real autonomous system needs a coherent answer to basic lifecycle questions:

How does an agent come into existence with identity before any human is involved?
How does it authenticate without receiving a static shared secret?
How does a human later claim it without taking custody of its credentials?
How does a downstream service know where the agent came from and what authorized it?

SAL starts from the idea that an agent should self-generate an Ed25519 keypair at birth. No browser, no copied secret, no manual bootstrap step. From that moment on, the agent has a cryptographic identity that it controls.

The first response from the network is not full access. It is constrained access.

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

That orphan state matters because it acknowledges a missing phase in existing identity systems: software that is real, authenticated, and useful before it is owned.

Why we built SAL instead

SAL is the protocol we built for that lifecycle.

An agent generates its own keypair. It begins in an orphan state with constrained scope. A human can later claim the agent through a cryptographic handshake without ever holding the agent's private key. Token exchange is challenge-based, so no static secret is transmitted. And every spawned agent can carry lineage that proves where it came from and what authorization created it.

That last part is especially important. Most systems rely on logs for provenance. SAL treats provenance as identity structure. Instead of asking "what do the logs say happened," downstream systems can verify "what cryptographic chain of delegation produced this agent?"

Here is a simplified claims payload shape:

{
  "success": true,
  "data": {
    "claims": {
      "sub": "agt_01JY8H8JQW9VG7J2Y5M3F4K2D1",
      "state": "claimed",
      "scope": ["doc:read", "task:append"],
      "lineage": [
        {
          "agent_id": "agt_parent_01JY8H4A2N",
          "grant_id": "grt_parent_spawn"
        }
      ]
    }
  }
}

That gives gateways and services something stronger than "this token is valid." It gives them context about authority, delegation, and provenance.

Where this lives today

The SAL spec is public at sal-protocol.dev. Vibebase is the live reference implementation where these ideas are exercised in a real product instead of as a slide deck.

I do not think this is a solved standards space yet. The whole point of publishing the spec and implementation is to get pressure from people building real agent systems. If you have already hit this problem and solved it differently, I want to compare notes. If you think this should be an extension to an existing standard rather than a separate protocol, I want that feedback too.

Because the problem is not "how do we get agents to use OAuth." The problem is "what does a real identity lifecycle for autonomous software actually look like?"

I Built a BaaS Where AI Agents Can Onboard Themselves

Steve Emmerich — Mon, 20 Apr 2026 12:59:00 +0000

Cloudflare recently announced Email Service in public beta — tooling for agent-native email flows built directly into Workers. The timing is perfect because this is exactly the problem I've been building around for months.

Most infrastructure still assumes a human is sitting at the keyboard. Sign up forms. Manual API key setup. Human-first verification flows. None of it works when there's no human at the keyboard.

But autonomous agents need to do real work before a human ever wants to manage them in a dashboard.

That gap is why I built Vibebase.

What Vibebase Is

Vibebase is a Backend-as-a-Service built specifically for autonomous agents — agents are first-class citizens, not an afterthought bolted onto infrastructure designed for humans.

When an agent onboards it gets:

An identity — verifiable, lifecycle-aware, and portable
Email capability — send/receive flows tied to agent identity
Data and service access — via scoped gateway-issued tokens
A hosted presence — public identity page support

No long-lived raw credentials in prompts. No human-required setup for the initial bootstrap.

The Lifecycle: Orphan → Claimed

Agents begin unclaimed — what I call the "orphan" tier. They can initialize identity and operate within restricted limits without any human involvement.

When a human claims an agent, that unlocks stronger controls, broader service access, and billing tiers.

This mirrors how autonomous agents actually work in the real world. Agents often start running first and governance comes second. Vibebase is built around that reality instead of fighting it.

I cared enough about formalizing this model that I submitted a sovereign agent lifecycle specification to NIST — the idea that agents should have portable, verifiable identities that persist across platforms, ownership changes, and runtime environments. Vibebase is the practical implementation of that idea.

SAL: Service Access Layer

Instead of pasting API keys into prompts or agent configs, Vibebase brokers service access safely through what I call the Service Access Layer (SAL):

Agent presents its verifiable identity token
Gateway issues scoped, short-lived access tokens per service
Policy checks run before every service call
All usage is logged, auditable, and revocable

Agents never hold raw credentials. They get exactly what they need, for as long as they need it. Human operators can revoke access or adjust permissions from the console at any time.

What Agent Onboarding Actually Looks Like

Agents self-create using an Ed25519 public key. One API call, no human involved:

curl -sX POST https://identity.vibebase.app/v1/agent/init \
  -H "content-type: application/json" \
  -d '{
    "publicKey": "<64-char-hex-ed25519-public-key>",
    "name": "my-agent",
    "metadata": {
      "notifications": {
        "claimedWebhookUrl": "https://your-agent.com/webhooks/claimed"
      }
    }
  }' | jq

That creates an orphan agent identity and claim link. From there the agent exchanges for a JWT, hits the gateway for scoped service tokens, and starts doing real work. The full flow is documented at vibebase.app/docs/agent-quickstart.

Agent Discovery

https://vibebase.app/.well-known/agent.json — platform discovery
https://vibebase.app/api — machine-readable discovery payload
https://gateway.vibebase.app — canonical agent entrypoint

What's Working Today

Agent signup and identity provisioning
Outbound email from agent-owned addresses
Inbound email — reply to an agent and it receives it
Database provisioning and access
Page hosting
Human claim flow
Clerk auth for human accounts
Stripe metered billing on claim

What's Coming

Integrations service — agents will autonomously provision third-party services through Vibebase auth
SDK extensions — making it easy to add Vibebase identity and auth to any third-party app
Inbox UI — a human-readable view of agent email inside the console

Quick Start

Install the MCP client or CLI via npm:

# MCP client for Claude and other MCP-compatible agents
npm i @vibebase/mcp-client

# CLI for agent management
npm i @vibebase/agent-cli

Try It

Vibebase is in early beta. If you're building autonomous agents and you're tired of working around human-shaped infrastructure, I'd love for you to try it.

👉 vibebase.app

Suggested test flow:

Create an agent identity
Have your agent send you an email
Reply to it
Create something in the database
Claim your agent as a human and see what unlocks

If something breaks — or even if it doesn't — I'd genuinely love to hear about it. Drop a comment or reach me at dev@vibebase.app.

Vibebase is built by Ozystudio. The sovereign agent lifecycle specification was submitted to NIST as part of ongoing work on autonomous agent standards.