Ogentic-VaultUnlocking
0/ 100
Sealing every matter to its own key000%
ogentic·vault
GitHub ↗
Open source · Apache-2.0 · Planned

One matter.
One key.
One vault.

The encrypted, matter-scoped local store for privileged work. One SQLCipher database per matter, one key borrowed from your keychain — records stay on the device, and every open, put, and get is chained into ogentic-audit for court-defensible custody.

Apache-2.0On-deviceSQLCipherPer-matter keysPlanned
Scroll to unlock
Live

Every op leaves a trail.

Open a matter, put and get typed records, export a custody bundle — and every operation appends a chain-of-custody event to ogentic-audit. The vault stores what was audited about; Audit owns the HMAC chain.

The key is borrowed from your keychain for the session — an idle-lock zeroizes it and re-seals the matter when you step away.

CASE-2026-0042 · unlockedSQLCipher
call
vault.open("CASE-2026-0042", key)
returns
<Vault matter="CASE-2026-0042" state="unlocked" records=847>
vault──▶ogentic-audit·vault.unlocked
SQLCipher database opened · key resolved from the keychain, never minted.
✓ Chain-of-custody event appended · matter re-sealed on idle
The vault stores what was audited about; ogentic-audit owns the HMAC chain.
// illustrative — the API is being finalizedFollow the repo ↗
Why it exists

Five things a vault has to be.

Encrypting a folder protects bytes. A vault scopes every matter to its own key, refuses to mint keys, seals itself when idle, and leaves a trail of every access. These are the properties that turn storage into custody.

01per-matter encryption

One database per matter

A SQLCipher-encrypted SQLite database, one file per matter, one key per file. Nothing is plaintext at rest, and matters are cryptographically isolated — a cross-matter read fails closed.

02key handles only

It accepts a key, never mints one

Keys come from your OS keychain or a KMS, resolved through ogentic-audit-keychain / -kms. The vault takes an opaque key handle and never derives, mints, or persists a raw key of its own.

03idle-lock

Unlocks for a session, then locks

A matter unlocks for a working session and auto-locks on idle — the in-memory key is zeroized and the SQLCipher handle closed. Built for a desktop that steps away from the machine.

04open · put · get · list

Typed records, four classes

put and get typed records across four classes — privileged documents, dataroom records, redaction mappings, and conversation history. list enumerates ids and metadata without decrypting payloads it doesn't need.

05chain-of-custody

Custody, not just storage

Every open, put, get, and export is appended to the ogentic-audit HMAC-SHA256 chain. export emits a chain-of-custody bundle — the matter's contents plus the audit segment that proves custody, verifiable on its own.

The vault stores what was audited about — it is not the audit log and not a global secret store. Audit owns the chain; the keychain owns the keys.

The API

Open a matter. Put, get, export.

A small, typed surface over an encrypted per-matter database. Give it a matter id and a key handle; it hands back an open vault. Nothing to configure, nothing minted.

ogentic_vault
vault = open(matter_id, key)   # SQLCipher DB · key from keychain

vault.put(record)               # typed record -> its class
vault.get(cls, id)              # decrypt one record, in-session
vault.list(cls)                 # ids + metadata, no payloads
vault.export(audit_chain=True)  # court-ready custody bundle
key handle in — the vault opens the matter's database and borrows the key. It never mints or persists one.
The shape
Store
one SQLCipher DB per matter
Keys
opaque handle · keychain / KMS
Records
four typed classes
Audit
every op → ogentic-audit
Lifecycle
session unlock · idle-lock
Core
Rust · Python & TS bindings

A Rust core does the SQLCipher work; Python and TypeScript bindings expose the same open / put / get / list / export surface with matching error mapping.

Where it fits

Built for matters that can't leak.

Legal privilege, psychotherapy notes, deal rooms, reversible redaction — each is a matter with its own key and its own custody trail. One store, isolated per matter, on the device.

Legal

Privileged legal matters

A per-matter encrypted store for privileged documents and attorney work product — sealed on the device, with a custody trail behind every access.

privilege
Therapy

Psychotherapy notes

A separate encrypted store for the most sensitive PHI — physically isolated per patient, never round-tripped to a cloud model, held to the higher bar the notes require.

PHI-isolated
Finance

Deal & dataroom records

Keep dataroom records and deal artifacts in a matter-scoped vault, each under its own key and with an exportable chain of custody for the file.

dataroom
Redact

Reversible-redaction mappings

Backs ogentic-redact: the reversible token → original mappings live in the vault under a per-matter key, so a redaction can be undone only inside its own matter.

redact-backing
Lifecycle

Open, store, audit, lock, export.

How a matter lives in the vault — from a keychain-backed unlock to a court-ready custody bundle. Every step leaves an entry in the audit chain.

1 · openopen

Open a matter

Give a matter id and a key handle from your keychain; the vault resolves or creates the per-matter SQLCipher database and returns an open handle.

2 · put / getput·get

Store typed records

Put privileged docs, dataroom records, redaction mappings, or conversation history; get them back by class and id — decrypted only in-session.

3 · auditaudit

Every op is chained

open, put, get, and export each append a chain-of-custody event to ogentic-audit's HMAC chain. The vault stores; Audit proves.

4 · locklock

Idle-lock the matter

On idle the key is zeroized and the database handle closed. The matter is sealed again until the next session unlock.

5 · exportexport

Emit a custody bundle

export(audit_chain=True) writes the matter's contents plus its audit segment — a verifiable, court-defensible chain-of-custody bundle.

open put·get audit lock export

// The key is never minted here — it comes from ogentic-audit-kms or your OS keychain, and the vault only borrows it for the session.

Record classes

Four kinds of record, one vault.

Everything a matter accumulates — privileged documents, dataroom records, reversible redaction mappings, and conversation history — stored as typed records under one per-matter key.

class◆ sealed

PrivilegedDocument

scopeper-matter
auditput · get

Attorney-client and work-product material, encrypted at rest and access-logged.

class◆ sealed

DataroomRecord

scopeper-matter
auditput · get

Diligence and deal-room documents held under the matter's own key.

class◆ sealed

RedactionMapping

scopeper-matter
auditput · get

The reversible mappings ogentic-redact produces — un-redactable only inside the matter.

class◆ sealed

ConversationHistory

scopeper-matter
auditput · get

On-device conversation and session state, paginable without decrypting payloads.

// list() enumerates ids and metadata across classes without decrypting the payloads it doesn't need — paginable for large conversation histories.

How it compares

A vault, not a folder.

Encrypting a folder protects bytes at rest. A vault scopes every matter to its own key, refuses to mint keys, and leaves a court-defensible trail of every access — that's the difference between storage and custody.

An encrypted folder / generic store
encrypted-at-best
Scope
One key for everything
Keys
App mints & stores the key
At rest
Files you remember to encrypt
Access trail
None, or ad-hoc app logs
Export
Copy the files out
Lifecycle
Open until you close it
ogentic-vault
matter-scoped · audited
Scope
One key per matter
Keys
Accepts a keychain/KMS handle; mints none
At rest
SQLCipher-encrypted per matter
Access trail
Chained into ogentic-audit
Export
Court-defensible custody bundle
Lifecycle
Session unlock · idle-lock

The vault is the custody layer. It stores what ogentic-audit ↗ proves, and it holds the reversible mappings ogentic-redact ↗ produces — each sealed under its matter's own key.

Code

Open, store, export — a few lines.

A Rust core with Python and TypeScript bindings, Apache-2.0. The examples below are illustrative — the API is being finalized ahead of the first release.

open.pyOpen
from ogentic_vault import open_vault
from ogentic_audit_keychain import key_for

# the key comes from the OS keychain — the vault never mints one
vault = open_vault(
    matter="CASE-2026-0042",
    key=key_for("CASE-2026-0042"),
)
# → SQLCipher database, unlocked for this session
records.pyStore
from ogentic_vault import PrivilegedDocument

rec = vault.put(PrivilegedDocument(
    title="Deposition summary",
    body=pdf_text,
))                       # → chain-of-custody event: vault.put

doc = vault.get("privileged_document", rec.id)   # decrypt in-session
exportCustody
ogentic-vault export --matter CASE-2026-0042 \
    --audit-chain --out custody.bundle

# matter contents + the ogentic-audit segment that proves
# custody — a bundle you can verify on its own.
installGet it
pip install ogentic-vault        # planned — not yet released

# Rust core with Python & TypeScript bindings:
#   crates.io · PyPI · npm
The ogentic stack

The store the suite trusts.

Composable Apache-2.0 primitives for regulated AI. Shield classifies, Redact masks, Router routes, Audit proves — and Vault is where the sensitive artifacts actually live, sealed per matter and chained to Audit.

The encrypted store behind ogentic-audit ↗'s custody trail and ogentic-redact ↗'s reversible mappings — alongside ogentic-shield ↗, part of the OgenticAI ↗ OSS suite.

Roadmap

The vault lands with Sotto Desktop.

The encrypted, matter-scoped store for the OgenticAI suite — Rust core, Python & TypeScript bindings, Apache-2.0. It backs the desktop app's per-matter storage and Redact's reversible mappings; the standalone package is on the way. Follow the repo.

$pip install ogentic-vaultSoon