One thing I dislike in security-adjacent writing is when a protocol is described as if it dissolves risk by being well intentioned.
SAL is not that kind of protocol. It is meant to reduce specific classes of problems in agent identity. It does not make compromised hosts safe. It does not make malicious agents honest. It does not remove the need for policy, monitoring, or operational discipline.
What it does try to do is tighten a few important seams in the lifecycle of autonomous agents.
The public spec is at sal-protocol.dev, and the reference implementation is in Vibebase. First, it tries to reduce dependence on static shared secrets.
Static API keys and pre-seeded bootstrap secrets create easy failure modes. They get copied, reused, leaked, and forgotten. By having agents self-generate keypairs and use challenge-based exchange, SAL reduces the need to ever transmit long-lived reusable secrets at all. Second, it tries to preserve identity continuity across lifecycle transitions.
Without that, systems tend to replace credentials when agents are claimed or promoted, which makes provenance and governance fuzzier. SAL keeps the agent's private key with the agent and binds ownership separately.
Third, it tries to make delegated origin verifiable.
Lineage gives downstream services a way to reason about where an agent came from and what authorized its creation, instead of relying entirely on operational logs or naming conventions.
Fourth, it tries to contain authorization with short-lived scoped service tokens. That reduces blast radius when a token leaks or a request path is abused.
If an attacker fully compromises the host running the agent and can act with the agent's private key, SAL does not magically save you. At that point the attacker effectively is the agent from the protocol's perspective.
If your policy model is too broad, SAL does not fix that either. You can still mint dangerous scopes. You can still allow unsafe delegation. Good identity plumbing does not replace careful authorization design.
If your implementation stores lineage incorrectly, fails to verify challenges, or treats expired tokens loosely, protocol intent will not save you from implementation bugs.
And if an agent is behaving maliciously by design, SAL is not a moral filter. It is an identity and delegation model.
I think protocols get stronger when their threat model is stated plainly.
Otherwise people adopt them hoping for properties they were never designed to provide, and then the eventual failure looks like a broken promise rather than a category mistake.
For SAL, the promise is narrower and more practical: That is already plenty.
Even with SAL, you still need:
In other words, protocol design is one layer of the security story, not the whole story.
If you want to dig into the model itself, the spec is at sal-protocol.dev and the implementation is at vibebase.app/docs. I am especially interested in feedback from people threat modeling real agent systems, because that is where protocol language stops being abstract and starts being useful.