Security · PG-22
Inspectable, not asserted
This page is written so your security questionnaire can be answered from it: what is enforced in the product today, what is on the attestation roadmap, and what is explicitly out of scope.
- no badge wall
- no certification claims before issuance
- every allow/deny is a provenance event
Ledgerbook AI's security posture starts with what the product enforces today, and states plainly what it does not. Enforced at PH-1: OIDC and delegated authentication against your identity provider, scope-bounded short-lived credentials, row-level access control across every axis, basic separation of duties, chain-hashed tamper-evidence and offline verification. Not yet: SOC 2 Type II and ISO 27001 alignment are roadmap items targeted inside PH-2, and nothing on this page should be read as certified. The controls below are described at architecture level, because that is where they are enforced — server-side, on every surface, including exports. The design keeps personal data off the ledger and commitments on it; erasure and legal-hold mechanics arrive with PH-2.
Verified 2026-09-19 · source: product documentation NFR-15, §6.5
Phase legend: PH-1 shipped now · Roadmap arrives with PH-2. Labels are always present — colour is never the only signal.
Attestation status — the inverse of a badge wall
Badges assert. This table is structured the other way round: what exists today, what is targeted, and what we are not claiming at all.
| Area | Held today (PH-1) | Roadmap — targeted inside PH-2 | Out of scope |
|---|---|---|---|
| Attestations | Product controls below, inspectable today. No certificate is issued yet. | SOC 2 Type II · ISO 27001 alignment Roadmap | Certification claims before issuance — we publish the state, not a badge. |
| Identity & access | OIDC / delegated auth against your IdP; scope-bounded short-lived credentials; row-level access control across every axis; basic separation of duties · FR-800–803/805/807 | Agent-actor administration GA · break-glass GA · FR-804/806 Roadmap — core agent attribution (FR-804) and administrative action provenance (FR-814) ship at PH-1 | — |
| Cryptography | Chain-hashed tamper-evidence, on by default; offline verifier; crypto-agility through versioned, algorithm-tagged payloads · FR-118–122/810/813 | ZKP proving backend (the frozen contract, an interface stub and one published test vector ship at PH-1) · hybrid TLS suites and the post-quantum cutover schedule · external anchoring · BYOK/HSM integration · FR-809/811/812/813 Roadmap — PQ-hybrid wrapping of key-encryption and archive keys, hybrid manifest signatures, key custody and the verifier itself are PH-1 | External anchoring is deliberately off the critical path. |
| Data protection | PII held off-ledger in a separately-keyed vault, commitments on-ledger; erasure by crypto-shredding within 30 days including backups, caches and derived stores; legal hold suspends it; encryption at rest across tier-0, derived, archive and backup bytes · FR-808/815 · NFR-11 | — | The erasure act is itself a provenance event, and the chain over unchanged events still verifies afterwards. |
| Money & models | — | — | No money movement by design — payment systems are ingestion sources (NG-3). No model in the core; agents reach the ledger over MCP (NG-4). |
Controls enforced today
Architecture-level trust: the checks run server-side, identical on every surface — REST, MCP, CLI, streaming and exports alike.
Identity and delegated authorization
Authentication runs through OIDC against your identity provider — Ledgerbook does not become a second directory. Authorization is delegated and scope-bounded: credentials are short-lived, per-tool scoped, and a test-class credential can never write to a production ledger.
FR-800/801/802/807 · PH-1
Row-level access control
Access is enforced per row across tenant → ledger → entity → book → scenario → period → account, with the same rules applied to reads, writes and export — a scoped token cannot see around the model, and every allow/deny decision is itself a provenance event.
FR-803 · FR-234–238 · PH-1
Separation of duties and credential lifecycle
Creators cannot approve their own entries; agents can propose but cannot approve, finalize or correct — enforced at the credential, not the prompt. Credentials expire, rotate and are individually revocable.
FR-219/220 · FR-805 · PH-1
Crypto-agility and tamper-evidence
Every Final entry is chain-hashed with the chain on by default, and hashes are computed over versioned, algorithm-tagged payloads — so the algorithm suite can change without breaking history or verification. Third parties can verify the chain offline.
FR-118–122/810/813 · FR-121 · PH-1
On the roadmap, labelled as such. The agent-actor surface reaching GA Roadmap (FR-804); break-glass access for incident response (FR-806); verified-access ZKP assertions — PH-1 ships the interface stub and one interoperability test vector, the proving backend is Roadmap (FR-809); the post-quantum hybrid suite (FR-811); BYOK/HSM key custody (FR-812); and provenance coverage for administrative actions. Each is targeted inside PH-2, and none of them is claimed as shipping today.
Compliance packs, and what is a contract versus a product
Audit requirements differ by jurisdiction. The architecture keeps that depth out of the core, and the phase label keeps the claim honest.
Versioned contract surface
The core is domain-independent, and packs plug in through versioned contracts — the interface exists today, so integration work is not blocked on the content of the packs.
FR-910 contract surface (interface only) · PH-1
Roadmap The packs themselves
The rules engine, the IFRS baseline and the signed registry — signed and air-gap-installable, so a disconnected deployment can still apply a compliance pack with verifiable provenance — are PH-2 items.
FR-900–904 + signed registry · Roadmap (PH-2)
See the dedicated compliance page for the contract terms, the rules engine and the packs.
Data protection: immutability versus erasure, answered honestly
An append-only ledger and a GDPR-style erasure right pull in opposite directions, and that tension does not disappear because the product is well engineered. Ledgerbook's answer is separation of concerns: the ledger holds financial facts and commitments, while personal data lives off-ledger by design — so erasing a person does not require rewriting a book of record.
That design is not a promise for later: the PII vault, crypto-shredding as the erasure path, and legal-hold handling where retention obligations override deletion all ship at PH-1. An erasure request destroys the per-subject key; PII becomes unrecoverable across the vault, exports, caches and derived stores within 30 days; the chain over unchanged events still verifies; and the erasure act is recorded as a provenance event carrying its legal basis and requester.
FR-808 · NFR-11 · FR-815 · product documentation §6.4 — PH-1.
Artifacts for your review
Verify immutability instead of trusting it — run the chain check yourself, without ledger access.
- This page — written to be lifted into a security questionnaire, including the gaps.
- Invariants and interface specifications — published with the developer preview, generated from one source of truth so the docs cannot drift from the product.
- Chain-verification evidence: the offline verifier checks immutability without ledger access.
- OCEL 2.1 audit export of the whole lifecycle, with an independently runnable verifier — the record can be re-created from the export (FR-905/529/531).
- Provisional disclosure gate: provisional data cannot leak to external channels without an approved gate and a data-quality envelope (FR-229/230/231).
- security.txt — coordinated disclosure, monitored.
NFR-15 · FR-121/813 · OI-20 · PH-1
Coordinated disclosure
Report vulnerabilities to security@ledgerbook.ai. We acknowledge reports, work with you on a fix window, and credit researchers who want to be named. A full published policy page ships with the developer preview; until then this contact is monitored and is the policy (NFR-15).
Run the questionnaire against this page
Send it over with your deployment questions — air-gap included — and we will answer point by point, labelled PH-1 or Roadmap.