Help Center / Security & privacy
Security & privacy
Klaxon is designed so an active breach never has to leave the building. This page explains the local-first architecture, the zero-network core, exactly what does and does not leave your machine, and the guarantee that no PII ever ends up in a cloud payload.
Local-first by default
Every incident — its facts, timeline, tasks, roles, evidence hashes, comms log, and obligation statuses — lives only in your browser's localStorage, under a single key. There is no account, no server, and no network dependency for the core console. You own the data because it never leaves your device unless you take an explicit, opt-in action.
The zero-network core
After the page and its static content packs (the jurisdiction, playbook, scenario, and letter data) load, the core console makes no network calls. All of the following happen entirely in-browser, offline:
- Computing obligations and deadlines (the deterministic engine).
- The live countdown clocks and the reminder cascade preview.
- Sealing and verifying the timeline hash chain (SHA-256 in the browser).
- Hashing evidence files (SHA-256 in the browser).
- Rendering and exporting letters, the PIR, the auditor bundle, and the .ics calendar.
- The what-changed feed and tabletop scoring.
This is deliberate: during an incident your network may be compromised, so the tool that runs the response must not depend on it.
What leaves the machine (and what never does)
| Action | Leaves the machine? |
|---|---|
| Declaring incidents, setting facts, computing obligations | No. Local only. |
| Timeline, evidence file contents, comms bodies, affected-individual data | Never. Not even with cloud enabled. |
| Generating / exporting letters, PIR, auditor bundle, .ics | No. Files are produced locally and downloaded. |
| Opt-in scheduled push (you enable it + enter a target) | Yes, but only secret-free reminder metadata — see below. |
| Opt-in evidence publish of a closed incident | Yes, but only non-sensitive metadata — see below. |
| Opt-in AI copilot (you enable it + add a key) | Yes, scrubbed prompt, directly to your provider — never via a DosanjhLabs server. |
Evidence: hash, not upload
When you attach an evidence file, Klaxon computes its SHA-256 hash in your browser and stores only the filename and that hash. The file content is never uploaded — not to a DosanjhLabs server, not anywhere. The hash is a chain-of-custody fingerprint you can use later to prove a file is unchanged. See Evidence.
The opt-in cloud: no PII in payloads
If you opt in to the cloud tier (see Scheduled push), the payloads are secret-free by construction:
- Reminder cascade push carries only the incident id/title, obligation label, recipient role, deadline, cascade stage, proposed flag, and countdown. No affected-individual data, no timeline bodies, no evidence blobs, no letter contents.
- Evidence publish (for a closed incident) sends a canonical evidence object with non-sensitive metadata (title, severity, status, dates, obligation counts, and PHI/CUI booleans) plus control/framework references (NIST CSF RS/RC, SOC 2, ISO 27001, and HIPAA / CMMC references when applicable). It never sends the timeline body, evidence blobs, affected-individual data, or letter contents.
- No tenant id is ever sent by the client — the server derives it from your verified session.
The AI copilot: client-direct, scrubbed
The optional AI copilot is off by default and is mandatory client-direct: your browser calls your chosen provider (OpenRouter / OpenAI / Anthropic) directly with your own key, which is stored only in your browser's localStorage. No prompt ever transits a DosanjhLabs / Keystone server. Before any prompt leaves:
- A hard "AI on" switch must be flipped — a key alone is not enough; while off, no key is read and no call is made.
- A data-minimization scrubber blocks or redacts likely PII / PHI (SSN, MRN, email, phone, DOB-like, card-like, street address) by default.
- Affected-individual rosters and evidence blobs have no parameter in any AI flow — they cannot be sent.
- Legal facts (deadlines, who to notify, required elements) always come from the rules engine; the model only writes prose.
Where data is stored
All incident state lives under a single localStorage key in the browser profile you use. That means it is scoped to that browser, on that machine, for that profile / user. It is not synced across devices or browsers automatically.
Backups & durability
Because data lives in browser storage, it is as durable as that storage — clearing site data, using a different browser/profile, or a wiped machine will lose it. To keep durable records:
- Export the auditor bundle (JSON) for a full machine-readable snapshot of an incident, including the timeline integrity result.
- Export the PIR (Markdown) for a human-readable record.
- Export letters and the .ics deadline calendar as you go.
Store those exports in your normal secure document system. The exports are your portable system of record.
Shared-machine hygiene
If you run an incident on a shared or temporary machine, remember the data persists in that browser profile until cleared. On a shared device, use a private/locked profile, export what you need, and clear site data when done.