Memory you can prove, not just trust.
Context Vault is built so an examiner, a regulator, or your own risk team can verify exactly what an agent knew and saw — without taking the operator's word for it. Here's how the guarantees actually work.
Three guarantees, enforced in code.
Deny-by-default access
A principal reads a claim only if its clearance covers the claim's visibility labels. Two separate axes — role (which operations) and labels (which claims) — that can only ever add denials.
Tamper-evident audit
Every read and write is appended to a hash-chained log. Re-hash any row and the chain breaks — so silent edits are detectable, and belief states are replayable to the instant.
Right-to-erasure, intact
GDPR erasure destroys a subject's content without snapping the audit chain — content is stored encrypted, and erasing means destroying the key. The proof survives; the plaintext is gone.
The same query, answered per identity.
Authorization splits into two independent predicates. Roles gate who may invoke an operation; visibility labels gate which claims a principal may read. The two never widen each other.
- Roles
admin/agent/user/reader— unknown roles get no permissions (least privilege). - Read clearance is checked per claim; a denied operation records a content-free deny on the audit chain before re-raising — fail-closed, so an audit failure never opens the gate.
- Mutations (
assert,reconcile, decay, human override) run through a single permission clamp — no scattered inline checks to drift.
Tamper-evident by construction.
Each entry hashes the previous entry's hash together with the canonical record of ts, principal, operation, query and payload. Change one byte of history and every subsequent prev_hash stops matching.
Anchored beyond the operator.
Tamper-evidence becomes tamper-resistance by anchoring checkpoints outside the operator's control.
- RFC 3161 trusted timestamps bind each checkpoint to a real point in time.
- RFC 6962 transparency log — a local append-only log with signed tree heads and offline-verifiable inclusion proofs, or public anchoring to a Sigstore Rekor instance the operator doesn't control.
- An exported evidence bundle is self-describing: it carries the inclusion proof and signed tree head, so a third party verifies it offline.
Erase content without breaking proof.
The append-only log commits to the stored bytes, never to plaintext. Content-bearing rows store an encrypted envelope plus a content-free locator; the verifier re-hashes those stored bytes and never decrypts.
- To erase a data subject, the Vault destroys their per-subject key — the ciphertext stays, the chain stays intact, the plaintext is gone forever.
- Because nothing the verifier reads changes, every
prev_hashstill recomputes identically after a shred.
Nothing usable stored at rest.
Authentication uses stdlib-grade primitives with no plaintext secrets in the database.
- Passwords: salted PBKDF2-SHA256, 120,000 iterations — never stored in the clear, verified in constant time.
- API keys carry a
cv_prefix (greppable by secret-scanners) and are stored only as their SHA-256 hash, so the DB never holds a usable credential. - Sessions are random opaque server-side tokens with expiry; CSRF uses the double-submit-cookie pattern; reset tokens are single-use and stored hashed.
The open-core ships the access model and the tamper-evident chain. Transparency-log anchoring, compliance packs, attestations and the human-review queue are part of the managed Cloud and Enterprise tiers. Self-hosting? Every guarantee above runs on your own infrastructure.
Found something? Tell us.
We welcome reports from security researchers. Email us with details and we'll acknowledge promptly and keep you updated through resolution.