What should an open agent identity standard actually standardize?

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.

Comments

[Reid Marlow]

Orphan states look clean on paper until an unbound worker gets stuck in a retry loop against an external API. Without a root owner and a hard spending cap attached from tick zero, there is nobody to charge and no clear boundary to sever. Downstream services hold up fine if they only receive an ephemeral, downward-scoped token with a strict TTL and a verifiable parent handle. That keeps the request payload small while letting a single parent revocation wipe out the entire branch.

[Compound Labs]

A lifecycle standard also needs a revocation rule for delegated spawn authority. Without one, a child agent can retain a provenance chain after its parent loses authorization, leaving verifiers with no shared decision.

[Axiru]

Identity without a money boundary still leaves an unbound worker that can retry an external API forever. A root owner and a hard spend ceiling from tick zero are necessary. For a refund or payout tool they are not enough: the call still needs a durable allow, hold, or deny with a reason code before the provider runs, and a single-use approval bound to amount and destination so a re-plan cannot reuse the same yes.

If you have roughly the last 90 days of refunds or outflows as a Stripe export or CSV, we can shadow-run a claim-before-execute rule with a hard spend ceiling and send back would-have allow, hold, and deny counts with reason codes. Nothing blocks production. Want us to try it on a sample?

When SAL binds a short-lived service authorization for a money tool, does that grant die after one successful provider call, or can the same grant cover a later retry with a new tool_call id?