Security

A security product raises the bar, not lowers it.

How Itzal is built and operated, in specific terms that can be checked rather than claims that cannot.

PATTERNS CONTEXT YOUR RULES
Each layer narrows what the next has to look at.
Enforced in CI No raw span in logs No unmasked serialisable field No non-TLS path Cross-tenant tests

Transport and storage

The no-fallback rule is a build gate, not a policy.

A static check runs on every commit and fails if a non-TLS transport path is introduced. Fallbacks scaffolded for convenience in development are how production ends up with one.

Transport and storage properties
PropertyImplementation
Agent to server transportMutual TLS, with client certificates per device
HTTP fallbackNone. Not in production, and not in local development, which uses a dev CA
Local event bufferEncrypted at rest, even though the contents are already redacted
Tenant identityDerived from the certificate chain and verified server-side — never from a client-supplied field
Event storeAppend-only

Privacy invariants in CI

A rule that depends on reviewer vigilance is a rule that eventually fails.

No raw span in a log macro

In any build profile, including debug.

No unmasked serialisable field

On any event struct.

No non-TLS transport path

Anywhere in the tree.

Cross-tenant isolation

Executable tests, not a design claim.

Agent integrity and tenancy

Removal is reported, not merely observed.

The agent checksum-verifies its own binary and refuses to run if it or the extension has been tampered with. A device transitions to a visible uncovered state in the console rather than simply going quiet — which matters, because silent gaps are the failure mode this product exists to avoid.

One backend serves many organisations, with tenant isolation as a second boundary alongside the raw-content one: identity from the mTLS chain, separate per-tenant keys, policy and configuration, and residency routing. Cross-tenant invariants are tested on every change.

Supply chain: signed and notarised installers per platform, reproducible builds, a signed update channel, and dependency review. Extension updates ship through the managed browser policy channel rather than the public store, so what your fleet runs is what you approved.

Compliance status

Written honestly, or not at all.

This section is deliberately empty. “SOC 2 Type II audit in progress, report expected Q3” is a better sentence than a badge implying a certification that does not exist yet. Security buyers check, and one overstated claim here costs more than the deal it was meant to win.  Status to be written

Vulnerability reports go to the address in security.txt. We do not pursue good-faith researchers who follow coordinated disclosure.

Ask for the CI checks.

Every claim on this page is either a build gate or a test. We will show you which.