Security

Security model

WardenKit is SDK-first, so the default is code running inside your process with nothing to call. Where a requirement genuinely cannot be met that way, the hosted component is narrowly bounded and its data boundary is stated on that product's own page — not generalised away here.

Design rules across the portfolio

These are the rules WardenKit builds to. Each product documents its own runtime and topology, network behaviour, data boundary and dependency footprint on its own product and documentation pages, so the security posture of any given SDK is stated precisely where you evaluate it rather than inherited from this page.

Local execution is the default: a requirement is evaluated from data you already hold wherever that is feasible.
Hosted execution is used only where a requirement genuinely cannot be satisfied locally, and is kept narrowly scoped to that requirement.
Where processing is hosted, it is designed to be stateless where practical: customer payloads are not deliberately retained and request bodies are not logged.
Inputs are validated against strict schemas, with unknown fields rejected and payload sizes bounded.
Where a product distributes rule or reference data separately from its code, those packs are signed, versioned and derived from committed source data; products that do not use that topology state their own update and data model on their own product page.
Each product publishes its own data boundary; no portfolio-wide zero-network guarantee is claimed.

Per-product disclosure

Each released product publishes, on its own product and documentation pages, what data it processes, where that processing runs and what — if anything — it transmits.
Dates that affect a rule outcome are explicit parameters, never read from the system clock, so results do not drift silently.
Where a product uses activation, it is a deliberate out-of-band step that exchanges an activation credential for signed artefacts and sends no business data.
Telemetry, network behaviour and dependencies are stated per product, on the product's own pages, as verifiable facts about that SDK.

Supply chain

Each released product states its runtime dependency footprint on its own page.
Published archives contain package metadata, the README, the licence and built output only.
Where a product ships rule profiles, they are generated from committed source data, so the shipped catalogue is reproducible from the repository.
Published npm versions are immutable: defective versions are deprecated and replaced by a corrected version, never overwritten.

Entitlement artefacts

This is the entitlement design that products using activation are built to. Production signing and production entitlement issuance for a given product are operational only once that product is released; for a product in release preparation, no production signing authority, production keyring or production entitlement exists yet, and its product page states that status.

Production entitlements and production packs are designed to be Ed25519-signed and verified locally against a public keyring compiled into the SDK and the activation CLI.
Signing private keys are held outside this repository and are never distributed, never in a test fixture and never supplied to tooling.
Artefacts are subject- and product-bound, verified before installation and written atomically with restrictive file permissions.
The activation credential is opaque, revocable and product-scoped. It is never a signing key and never an argument to the evaluator.
Verification fails closed: an artefact that does not verify is not installed and does not authorize production use.
Cancellation and expiry are non-destructive: nothing installed is remotely deleted or disabled.

This website

Static HTML and CSS, generated at build time.
WardenKit ships no analytics, advertising or tracking scripts, uses no third-party fonts and sets no cookies through this website.
As hosting, network and security provider, Cloudflare may apply strictly operational or protective functionality to the pages it serves — such as email-address protection — as disclosed in our Privacy Notice. WardenKit does not use any of it for advertising, analytics or visitor profiling.
No accounts, no login and no forms: nothing is submitted to a WardenKit server from this site.

Reporting a vulnerability. Email security@wardenkit.com with a description, affected package and version, and reproduction steps. Please report privately and give us a reasonable opportunity to investigate before public disclosure. Do not include customer data, credentials or activation keys in a report. For everything that is not a security report, use support@wardenkit.com.