MINERVA
Privacy policyTerms of useSecurity

Legalupdated 2026-09-12

Security

The short version. Every claim here was checked against the code on the date above; the long version for procurement is available on request.

01Architecture

One process and one database file on one volume, per deployment. Your browser talks only to that deployment. No third-party processor by default: single sign-on, a language-model provider, anchoring and office editing each exist only when your administrator configures them.

02Sign-in and sessions

Passwords are hashed with scrypt and compared in constant time; an unknown email takes as long as a wrong password. A session is a random token in an httpOnly cookie, stored only as a hash, sliding for 30 days. Sign-in is rate limited. A password an administrator chose for you must be replaced before anything else.

Single sign-on is OpenID Connect with PKCE. The ID token must be RS256, signed by a key your directory publishes, with the issuer, audience, expiry and nonce each checked.

03Who may do what

Four roles — viewer, member, admin, owner — say what a person may do at all. Gates on sheets say who may act where, at view, edit, decide or manage; the nearest gate up the tree decides, and a person the gate does not name does not see the sheet. Owners and admins pass every gate, and that pass is recorded.

An agent may propose and post. It may not decide, record, sign or grant, and that refusal is written down.

04The record

Every change is one event, hashed with SHA-256 over canonical text and chained to the event before it; every page revision chains the same way. The verifier (npm run verify) recomputes all of it offline, with no application running, and names the first break.

A hash chain catches a local edit. It does not catch a consistent rewrite of the whole file by an administrator — append-only is an application-layer property, not a storage guarantee. Anchoring to a public timestamp authority closes that gap when configured. A gap in the record is shown as UNSPECIFIED, never filled with an invented number.

05Data handling

Export at any time: the gap report, the binder, the register as CSV, the dossiers, the evidence extract, the ledger. Deletes are marked and undoable; deleting a workspace removes the file and its backups inside the agreed window. Client IP addresses are not stored; the application keeps its trail in the record, not in log files.

06Headers and input

A Content-Security-Policy that names only the deployment's own origin, HSTS, no framing, nosniff, and a strict referrer policy. Every request body is validated against a schema before it is read; every database statement is prepared with bound parameters; every id is resolved inside the caller's workspace.

07Reporting a weakness

Write to minerva@minerva-ca.com with "security" in the subject and, where it helps, the ledger sequence numbers involved. We acknowledge within two business days. Public disclosure follows a fix or ninety days from the report, whichever comes first, unless we agree otherwise with you.

08What we do not claim

No SOC 2 report and no third-party penetration test exist today; when they do, this page will say so. No certification, no seal, no coverage figure. The record proves what was recorded and that it has not moved since — nothing about what was never recorded, and nothing about the store beneath it.

MINERVA issues no certification, attestation or opinion. Management still writes its own assertion; your auditor still selects, tests and concludes. What is shown is evidence about this workspace only.

© 2026 Minerva Software Inc. · minerva@minerva-ca.com