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](/compliance) 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](/provenance-ocel2) 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](/.well-known/security.txt) — coordinated disclosure, monitored. NFR-15 · FR-121/813 · OI-20 · PH-1 ## Coordinated disclosure Report vulnerabilities to [security@ledgerbook.ai](mailto: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). [Contact security](mailto:security@ledgerbook.ai) [Open security.txt →](/.well-known/security.txt) ## 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.