Built to be verified.

Every evidence record is hashed using SHA-256 at the point of generation. Each record's hash is incorporated into the next record, forming an append-only chain. Tampering with any record in the chain breaks every subsequent hash, making any modification immediately detectable.

Evidence is recorded when your integration sends it to the ledger, not reconstructed afterwards. Each record carries the time the service wrote it, and that time is part of the hashed content. Independent RFC 3161 timestamps are taken later, over the ledger root, when the ledger has changed; they do not timestamp each record at the moment it is written.

The verification page recomputes record hashes and chain links for a synthetic sample package, in your browser; it does not look up your own records and does not check a timestamp. A full bundle, including the RFC 3161 timestamp, is checked with the independent verifier and the authority's own certificate, described at how-verification-works.

kaironull.com is served through Cloudflare Pages over HTTPS. The site sends an HSTS header with preload in its configuration; this page does not claim a minimum TLS version, which is a Cloudflare setting.

The site's configuration sets X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin and a Content-Security-Policy that allows the site's own scripts, Cloudflare analytics and Google Fonts.

We set no cookies of our own and use no device fingerprinting. We do hold personal data you submit through our forms (for example an access request: name, work email, organisation, role and use case) and, briefly, a network address used for rate limiting. The Privacy Policy lists what is collected, why, and which providers process it.

API calls that write or export evidence need a bearer API key. Keys are random, belong to one organisation, are stored by KairoNull only as a SHA-256 digest, and can be revoked. They do not expire on their own. Keys are issued by KairoNull by hand after an access request, and revoked on request. The organisation a record belongs to is taken from the key, never from the request body.

Ledger records cannot be updated or deleted through the API, and the database blocks updates and deletes with triggers. The database owner can still bypass triggers, and further privilege restrictions are prepared but not yet applied. There are no per-role or per-range read permissions: a key can read its own organisation's records through the export endpoint. Read access is not recorded in the ledger.

Customer API keys are per organisation. Tenant separation is enforced in the application, which scopes every read and write to the organisation of the key; the service itself runs with a database credential that is not tenant-limited. Treat tenant isolation as an application control, not a database-level guarantee.

Cloud-hosted deployments are designed for HSM-backed key stores using AWS KMS, so signing keys never exist in plaintext in application memory or storage, with automated key rotation on a defined schedule. This is on the deployment roadmap and not yet deployed. The ledger today does not sign records with a key; integrity comes from hashes and from timestamps issued by an outside authority.

Verification does not depend on a KairoNull key. A verifier recomputes record hashes and chain links from an exported bundle, and checks the RFC 3161 token against the timestamp authority's own certificate, which you obtain from that authority. The checks do not call KairoNull systems.

No third-party penetration test has been completed. It is planned, and scheduling with an independent security firm is in progress; no firm or date is confirmed. The planned scope covers API endpoints, authentication flows, cryptographic record generation and infrastructure configuration.

KairoNull holds no SOC 2 report and no ISO 27001 certificate. This page makes no claim of progress toward, or alignment with, either standard.

No availability commitment is made on this page. The ledger runs in a single Supabase project in the EU, and the site on Cloudflare; there is no multi-region failover. Availability terms, if any, are agreed in a customer contract.

No incident-notification commitment is made on this page; any such terms are agreed in a customer contract. The status page shows reported ledger, scheduler and anchoring state; it is not an incident history.

The evidence ledger currently runs in one Supabase project in the EU (Ireland, eu-west-1). Other regions and on-premises or private-cloud deployment are not currently offered as a standard service; any such arrangement would be scoped and agreed separately before any commitment.