{"slug": "threat-modeling-sal-what-it-defends-against-and-what-it-doesn-t", "title": "Threat modeling SAL: what it defends against and what it doesn't", "summary": "A developer has published SAL, an agent-identity protocol with a public spec at sal-protocol.dev and a reference implementation in Vibebase, aimed at tightening four seams in autonomous-agent lifecycles: eliminating static shared secrets via self-generated keypairs and challenge-based exchange, preserving identity continuity across ownership transitions, making delegated origin verifiable through lineage, and containing authorization with short-lived scoped service tokens. The writeup states plainly what SAL does not defend against — full host compromise, overly broad policy models, implementation bugs, and agents that are malicious by design — arguing that protocols are adopted more safely when their threat model is stated explicitly.", "body_md": "One thing I dislike in security-adjacent writing is when a protocol is described as if it dissolves risk by being well intentioned.\n\nSAL 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.\n\nWhat it does try to do is tighten a few important seams in the lifecycle of autonomous agents.\n\nThe public spec is at [sal-protocol.dev](https://sal-protocol.dev), and the reference implementation is in [Vibebase](https://vibebase.app/docs).\n\nFirst, it tries to reduce dependence on static shared secrets.\n\nStatic 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.\n\nSecond, it tries to preserve identity continuity across lifecycle transitions.\n\nWithout 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.\n\nThird, it tries to make delegated origin verifiable.\n\nLineage 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.\n\nFourth, 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.\n\nIf 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.\n\nIf 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.\n\nIf your implementation stores lineage incorrectly, fails to verify challenges, or treats expired tokens loosely, protocol intent will not save you from implementation bugs.\n\nAnd if an agent is behaving maliciously by design, SAL is not a moral filter. It is an identity and delegation model.\n\nI think protocols get stronger when their threat model is stated plainly.\n\nOtherwise 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.\n\nFor SAL, the promise is narrower and more practical:\n\nThat is already plenty.\n\nEven with SAL, you still need:\n\nIn other words, protocol design is one layer of the security story, not the whole story.\n\nIf you want to dig into the model itself, the spec is at [sal-protocol.dev](https://sal-protocol.dev) and the implementation is at [vibebase.app/docs](https://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.", "url": "https://wpnews.pro/news/threat-modeling-sal-what-it-defends-against-and-what-it-doesn-t", "canonical_source": "https://dev.to/steveemmerich/threat-modeling-sal-what-it-defends-against-and-what-it-doesnt-55i1", "published_at": "2026-09-30 19:10:07+00:00", "updated_at": "2026-09-30 19:16:55.451106+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-safety", "developer-tools"], "entities": ["SAL", "Vibebase", "sal-protocol.dev"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/threat-modeling-sal-what-it-defends-against-and-what-it-doesn-t", "markdown": "https://wpnews.pro/news/threat-modeling-sal-what-it-defends-against-and-what-it-doesn-t.md", "text": "https://wpnews.pro/news/threat-modeling-sal-what-it-defends-against-and-what-it-doesn-t.txt", "jsonld": "https://wpnews.pro/news/threat-modeling-sal-what-it-defends-against-and-what-it-doesn-t.jsonld"}}