One pattern I keep seeing in the agent infrastructure market is security and identity getting collapsed into the same bucket.
That is understandable. The same teams often care about both. The same incidents often expose both. The same products may eventually touch both.
But the categories are still different, and I think the difference matters.
Security for agent work is about what an agent is allowed to do, what it actually did, and how that work gets reviewed or contained.
Agent identity is about what the agent is as a principal over time.
Those are related. They are not interchangeable.
SAL, the Sovereign Agent Lifecycle Protocol, is my attempt to make the identity side explicit. The public spec is at sal-protocol.com, and Vibebase is the current reference implementation.
Security answers a different question
Security systems around agents usually focus on questions like:
- what tools can this agent call
- what policies apply in this environment
- what evidence was produced
- what should be blocked, quarantined, or reviewed
Those are good questions. They matter a lot once agents start touching real systems.
But they are not the same as asking:
- how did this agent come into existence
- did it exist before any human owned it
- who claimed it
- what authority does it carry now
- who spawned this child agent
- what provenance chain led to this current principal
That second set is identity work.
Identity starts earlier than enforcement
The clearest example is birth.
In SAL, an agent self-generates an Ed25519 keypair at birth. That gives it an identity before a human logs in, before a service account gets copied, and before a control plane decides what broader authority it should have.
That early identity matters because autonomous systems do not begin at the first policy check. They begin when the principal comes into existence.
If you only model the agent once it reaches an enforcement boundary, you are already entering the story late.
Governance is not the same thing as ownership continuity
Another place the distinction shows up is claim.
SAL treats claim as a cryptographic ownership transition where a human binds to an existing agent without taking custody of the agent's private key.
That preserves continuity across a real lifecycle:
- the same agent exists at birth
- it can operate in constrained orphan state
- it can later be claimed
- it can later delegate or spawn children
A governance or policy system may govern that agent after the fact. It does not automatically explain how the principal stayed continuous across those transitions.
Why I care about keeping the categories separate
If we collapse security and identity into one concept, we usually standardize the wrong layer.
We end up talking only about enforcement points, policy bundles, approval gates, audit logs, and runtime controls. Those are important, but they sit around the principal. They do not fully define the principal.
For autonomous agents, I think the identity layer has to say something explicit about:
- birth
- orphan state
- claim
- lineage
- delegated authority
- scoped service authorization
Without that, we may secure agent work while still leaving the underlying principal model vague.
The practical framing
I do not think companies should choose between agent security and agent identity.
They need both.
But I do think the market is early enough that it is worth being precise about what each product is actually trying to solve.
If your product is about governing agent work, say that clearly.
If your product is about giving autonomous agents a durable lifecycle identity model, say that clearly too.
For SAL and Vibebase, that second category is the center of gravity.
The spec is at sal-protocol.com, and the implementation is at vibebase.app/docs. The useful question for me is not whether security matters. It does. The useful question is whether we are finally modeling agents as principals with lifecycles, or only surrounding them with controls once they start acting.
