← All posts

Why We Publish What Our Product Doesn't Do

Zen Mesh publishes claims and non-claims. Security claims require evidence. Partial evidence must be scoped.

Why We Publish What Our Product Doesn’t Do

The same way it matters which claims we do make, it matters which ones we don’t.

Claims Require Evidence

Every security claim we make is backed by evidence. A claim without evidence is not a claim—it’s a guess. When we say “zen-ingester and zen-egress are protected with mTLS,” the evidence is the cryptographic handshake proofs, the SPIFFE/SPIRE identity verification, and the HMAC signature validation across the data-plane path.

Evidence comes in three flavors:

  1. Complete proof: Full test coverage across all code paths
  2. Partial proof: Evidence for a scoped subset of paths
  3. No evidence: No testing or coverage in this area

Non-Claims Require Evidence Too

If we don’t test it, we don’t claim it. The security page contains a “What Zen Mesh Does NOT Protect” section, and it’s populated by the same evidence-driven process that determines what we do protect.

The non-claims registry isn’t magical—it’s a reflection of what we’ve systematically checked and found to be out of scope or untested. When the security page lists “no SSRF protection,” it means we’ve run the SSRF test suite (409 lines of negative tests, fully passing) and validated that the tested code paths are protected, while being explicit that this doesn’t automatically prove the entire dispatch surface.

Partial Evidence Must Be Scoped

A partially proven control still needs to say so. If one code path has evidence and another does not, the claim has to say that. “Partially proven, scope named” is publishable. “Probably fine” is not.

The distinction matters most for attack classes such as SSRF, where one validated path does not automatically prove the whole dispatch surface. We explicitly state what we’ve tested and where the gaps remain, rather than leaving those gaps as vague assumptions that no one will challenge. When we say ‘no SSRF protection outside the tested code paths,’ the evidence is the 409-line negative test suite we ran and validated.

We apply the same rule to partially proven controls. If one code path has evidence and another does not, the claim has to say that. ‘Partially proven, scope named’ is publishable. ‘Probably fine’ is not.

Machine-Readable Structured JSON

The core claims and non-claims on our security and trust pages also exist as structured JSON files. You can find the claim-maturity manifest (claims and non-claims organized by maturity level) and the non-claims manifest (evidence-backed exclusions) in the source repository.

This is a machine-readable reflection of what we’ve tested and what we’ve deliberately avoided claiming. You can find the claim-maturity manifest (claims and non-claims organized by maturity level) and the non-claims manifest (evidence-backed exclusions) in the source repository.

The manifest shows exactly which claims are fully proven, partially proven, or intentionally out of scope. It’s a machine-readable reflection of what we’ve tested and what we’ve deliberately avoided claiming.

This makes the claims machine-readable, auditable, and updateable. Anyone can verify that a claim exists, whether it’s still in progress, or whether it’s fully proven or intentionally excluded from scope.

”not publishable” Is Not Publishable

No security claim should ever be “not publishable.” Either there’s evidence backing it, or there isn’t. Partial evidence with explicit scope is fine. Partial evidence without scope is guesswork.

When we say “zen-ingester and zen-egress are protected with mTLS,” we mean it. When we say “no SSRF protection outside the tested code paths,” we mean it. We don’t hide gaps. We document them.

The Benefit

Publishing what our product doesn’t do is not a weakness. It’s a commitment to honesty, to evidence, and to making it impossible to misunderstand what Zen Mesh guarantees and where the boundaries lie.

It also makes it easier for people to decide whether our tool is right for their use case. If your application has specific security requirements around SSRF or other attack surfaces, see our security page and evidence page for full details. You can also explore our LLM discovery file to understand how our architecture is described to AI systems.