Most security pages are a list of things a vendor wants you to believe. Ours has a second list — the things we explicitly don't claim. We think the second list is more useful than the first.
The Problem With Security Marketing
Walk through any infrastructure vendor's security page and you'll find some version of the same pattern: badges, buzzwords, and a confident paragraph about "enterprise-grade, zero-trust, bank-level security." It reads well. It tells you almost nothing.
The reason is structural, not malicious. Security pages are written to close deals, and closing deals rewards confidence over precision. "We use zero-trust architecture" sounds stronger than "mTLS and workload identity are enforced on these specific hops, and not yet on these others." But only one of those sentences is something you can actually verify.
We decided early on to write the second kind of sentence, even when it's less impressive.
What a Non-Claim Actually Is
A non-claim is a direct, public statement of something our product does not do, or has not yet proven. Not a hedge buried in a terms-of-service document — a first-class entry, sitting right next to the claims it's bounded by.
On our security page, every protection we claim is paired with a validation status: proven in local/sandbox testing, validated with passing negative tests, or explicitly not yet proven in production. And every section ends with a list of things we are not claiming at all — API inventory, anomaly detection, bot mitigation, 24-hour offline survival, exactly-once delivery. Not "coming eventually" in vague marketing language. Named, scoped, and dated.
Here's an example from our own non-claims registry:
Mutual TLS and SPIFFE/SPIRE are part of the internal security model and are being validated path-by-path before production-live claims.
That sentence is less exciting than "we use zero-trust architecture everywhere." It's also true in a way the exciting version usually isn't.
Why This Is Harder Than It Sounds
Writing a non-claim requires admitting, in public, on a page prospective customers will read, that something isn't finished. Every instinct in building a product pushes against this. You want the page to sound strong. You want the comparison table to look favorable. You want the badge row to be impressive.
The discipline is in resisting that pull at the exact moment it costs you something. A claim with no evidence behind it is cheap to write and expensive to discover later. A non-claim is the opposite — expensive to write, because it's an admission, but it's the thing that makes everything next to it trustworthy.
We apply this rule internally as: no product claim without runtime evidence. If a claim doesn't have a passing test, a validated artifact, or an explicit scope behind it, it doesn't go on the page as a claim. It goes on the page as a non-claim instead, or it doesn't go on the page at all.
What This Looks Like in Practice
A concrete example. We run negative tests — tests specifically designed to prove an attack is prevented, not just that a feature works. Our security page lists exactly which ones currently pass:
- API-key enumeration resistance
- Draft/apply race protection (does a double-apply double-commit a change?)
- Tenant isolation under manipulated IDs
- Permission parity across UI, API, CLI, and MCP surfaces
Each of those is a named test with a named outcome. None of them say "we are secure." They say "this specific attack, we checked, here's what happened."
The same discipline applies internally before anything reaches the page. If we have scoped, tested evidence for one specific code path but haven't proven the broader claim, we either publish the narrower statement with the gap explicitly named, or we don't publish a claim about it at all yet. "Partially proven, scope named" is a publishable state. "Probably fine" is not.
That's a smaller bar to clear than "we're secure against X." It's also the only kind of statement we're willing to stand behind in writing.
The Machine-Readable Version
We don't just write this for humans. The core claims and non-claims on our security and trust pages also exist as structured JSON — a manifest that an AI agent or an automated security reviewer can parse directly, without trusting our prose at all.
This matters more than it might seem. As more infrastructure decisions get made or pre-screened by AI agents — reading vendor docs, comparing security postures, recommending tools — the agents doing that work need something more reliable than marketing copy to evaluate. A structured claim with an evidence reference is something an agent can check. A confident paragraph is not.
We'd rather be the vendor whose claims survive that kind of scrutiny than the one whose page just reads well.
Why We Think This Is the Right Trade
The honest version of a security page is less persuasive in the first ten seconds. It doesn't have the confident, finished feeling that "zero-trust, enterprise-grade" gives you. What it has instead is something that holds up the longer someone looks at it — which, for the kind of person evaluating infrastructure for a production system, is exactly the part that matters.
We'd rather earn that trust slowly and keep it, than borrow it quickly and lose it the first time someone checks.
Zen Mesh publishes a machine-readable evidence manifest, claim-maturity index, and non-claims registry for both human reviewers and AI agents. See zen-mesh.io/security, zen-mesh.io/evidence, and zen-mesh.io/llms.txt.
