DEV Community: Steve Emmerich

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.

Sound Scape

Steve Emmerich — Mon, 11 Nov 2024 05:59:13 +0000

This is a submission for the Open Source AI Challenge with pgai and Ollama

What I Built

I built a Chat bot that accepts and generates audio files and provides analysis about the sound files. It can also generate mashup of the audio files.

Demo

Sound Scape
github

Tools Used

pgai Vectorizer is used for generating the embeddings for ollama. pgvectorscale is used to for the similarity checks.
Ollama is used for chat, mashup generation, and analysis.
Docker was used to host ollama, postgres, and the vectorizer worker

Technology Used:

Next.js
Shadcn
Langchain
Langgraph
Langsmith
Prisma

Final Thoughts

Overall I found the tools to be very interesting and useful. being able to trigger the embedding generation as soon as records are entered into the Database is very useful.

Prize Categories

This submission qualifies for:

Open-source Models from Ollama
Vectorizer Vibe
All the Extensions

Remote workers, how do you handle at home distractions?

Steve Emmerich — Fri, 21 Sep 2018 21:44:01 +0000

I work remotely and juggle two kids (6mo, 3yr). I am basically a stay at home dad that moonlights as a tech lead. I am curious how others manage their remote work vs family life?

To start things off I have two workstations one in my kitchen, and one in my office. My general day consists of many meetings; I mostly float between the two depending on what the noise level is like plus what the kids are doing. Trying to split my concentration between the two. (FYI not a good idea.)

What about you?