ARCHITECTURE
What each part of the system can see — and what it cannot.
Most vault products describe what they protect. This page describes the boundaries: where data crosses from one trust zone to another, what an attacker holds after compromising each zone, and which failures we do not defend against. If any of it looks wrong to you, tell us.
Three zones, not one system
Your application
Holds tokens and nothing else. Compromise here yields references with no meaning outside the vault. This is the zone attackers actually reach — through injection, an over-broad API, a stolen session — and it is deliberately the zone with nothing worth taking.
The data layer
Holds personal data and documents, encrypted per record. It can decrypt only what it is handed a key for, and it is never handed the key that protects the others. Compromise yields ciphertext and the ability to answer requests it is authorised to answer.
The key layer
Holds key material and enforces licensing. It never stores personal data, and nothing in the other zones can read from it. Compromise here is the serious case, which is why it is the smallest, quietest and least connected part of the system.
The separation is the point. A single compromised component is not enough to reconstruct a person's record.
Trust boundaries
Every call between zones is mutually authenticated — both sides prove who they are, with short-lived certificates that rotate on their own. There is no internal channel that runs unauthenticated or unencrypted, including between machines sitting in the same rack. Traffic between nodes runs over an encrypted mesh regardless of what your own network already provides, on the assumption that your network is not trustworthy either.
Keys
The key that protects everything else is never held whole in one place. It is split into shares distributed to separate custodians and separate storage, and reassembling it requires more than one person and a deliberate ceremony. There is no automatic path that reconstructs it, no recovery service, and no copy held by us. That is the trade: losing enough shares means losing the data, and we would rather tell you that plainly than pretend a vendor-held escrow is safety.
What crosses your perimeter
Nothing. No telemetry, no usage reporting, no licence validation call, no error reporting, no update check that carries identifying information. Your licence arrives by email and is loaded locally. A packet capture on a running node will show you this in under a minute, and we would rather you ran one than took our word for it.
What this does not defend against
An attacker with root on the machine while the vault is unsealed can read what the vault can read. Nothing changes that, and any vendor claiming otherwise is selling you something. Nor does the design protect against an authorised operator misusing their access — it records what they did, in an audit trail, which is a different guarantee and a weaker one. Below Enterprise there is no replication, so a node failure means downtime until it is restarted.
The design assumes your application will eventually be breached. It is built so that this is survivable, not so that it never happens.
See what Core0 does