Security products should speak in boundaries

Security products earn trust in a strange way: not by sounding complete, but by being precise about where they are complete. The tempting version of a launch page says every acronym, every checkbox, every enterprise expectation. The useful version tells you what can be relied on today, what is still preview work, and what is not part of the product yet.

Three different promises

In ZKAuth we separate shipped capability, partial capability, and non-claims. Shipped means the code path exists, is wired into the product surface, and has evidence behind it. Partial means the foundation is real, but some production expectation is intentionally not promised yet. Non-claim means exactly that: we do not use the phrase as a selling point, even if it would make the page look fuller.

That distinction changes product decisions. A hosted sign-in page can be presented as hosted auth because the flow exists. A federation foundation can be described as preview work because selected OAuth and OIDC paths are implemented while broader enterprise identity work is still being prepared. A certification badge cannot be implied because an external audit has not happened. These are not copywriting details; they are customer expectations.

Boundaries are part of the interface

The same posture shows up in the product. Hosted pages allow branding, but not arbitrary page code. Redirects are allowlisted. Email copy is configurable inside a bounded template model. API keys are environment slots, not user identities. The system keeps trying to make the secure thing the obvious thing, and when a surface can become dangerous, the surface gets smaller.

The public list still matters

Our docs still include a limitations page that names the important gaps in plain language, and a threat model that names non-goals out loud. Those pages are not apologies. They are part of the contract. A developer should be able to decide whether ZKAuth fits their launch without needing a sales call to discover the edges.

Trust compounds when the pitch stays smaller than the code

We want the product to feel ambitious, but not inflated. The ambition is in the cryptography, the fail-closed behavior, the hosted flow, the SDKs, and the operational evidence around them. The restraint is in refusing to call future work finished. In authentication, restraint is not modesty; it is part of the security model.