There is a growing market for governing agent work.
That makes sense. Agents call tools, touch credentials, operate in repositories, and can chain actions faster than a human review loop can keep up. Companies want policy, visibility, and evidence.
I think that whole category is real.
I also think it is downstream of a more foundational problem: agents need a lifecycle identity model.
That is the problem SAL is trying to address. The spec is at sal-protocol.com, and Vibebase is where I am testing the model in running code.
Governance starts from an existing principal
Governance systems generally assume the principal already exists.
They ask:
- what can this principal do
- under what policy
- what happened when it acted
- how should exceptions be reviewed
That is all useful.
But an autonomous agent forces earlier questions:
- when does the principal begin
- can it exist before ownership
- how does ownership attach
- how does delegated authority propagate
- how does authority get revoked or retired
Those are lifecycle questions, not only governance questions.
The missing transition model
The place where older auth patterns feel weakest is transitions.
Human auth is good at login.
Service auth is good at provisioning credentials.
Governance layers are good at policy and review.
What none of those models handle especially well is a principal that:
- self-generates identity at birth
- starts unowned but constrained
- gets claimed later without key custody transfer
- spawns children under delegated authority
- accumulates lineage that downstream systems can evaluate
- loses authority through revocation, suspension, or expiry
That is the lifecycle SAL is trying to make explicit.
Why orphan state changes the frame
The most important wedge is still orphan state.
If an agent can exist and do useful bootstrap work before a human claims it, then the identity system has to represent an intermediate trust state. It cannot just jump from "does not exist" to "fully governed principal."
That one design choice pushes you away from a governance-only model and toward a lifecycle model.
Why lineage also pushes in the same direction
Lineage creates the same pressure from the delegation side.
Once agents can spawn other agents, the system needs more than a flat permission check. It needs provenance about who created whom and under what authority.
A governance platform may inspect or enforce around that. But the identity model still has to represent the delegation chain itself.
That is why I keep treating lineage as part of identity rather than as a logging add-on.
The distinction I would keep
I would separate the stack like this:
- identity lifecycle: birth, orphan, claim, delegation, lineage, retirement
- governance: policy, review, evidence, exception handling
- enforcement: what gets allowed or blocked at runtime
All three matter. They should talk to each other. But I do not think they should be treated as the same layer.
Where Vibebase fits
Vibebase is not trying to be only a security wrapper around agent work. The center of gravity is an agent-native backend control plane where agents start first, humans claim later, and service access is minted through scoped challenge-based flows.
That is a different thesis than "control what agents do once they are already in motion."
The latter is useful. I just do not think it is the full identity problem.
If you want to understand the model, the protocol is at sal-protocol.com and the implementation is at vibebase.app/docs. The question I keep coming back to is simple: are we governing agent work, or are we finally defining what an agent principal is across its whole lifecycle?
