DEV Community: Steve Emmerich

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.

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?