-
Notifications
You must be signed in to change notification settings - Fork 0
Enterprise: Compartmented Stores
Public overview of SERAPH's enterprise (Gov) mode. For deployments where classification, compartmentation, and per-operator accountability are requirements rather than preferences, intelligence, defense, law enforcement, and regulated enterprise.
SERAPH's enterprise tier extends the substrate's trust model from what was recorded and by whom to who was cleared to record it, at what classification, in which compartments and whether all of that can be proven at the level of an individual record.
Gov mode is a distinct security posture fixed when a store is created. It is part of the substrate, not a layer bolted on top: a standard SERAPH engine will not open a Gov-mode store at all, only the enterprise engine can create or operate on one. The separation is architectural, not a configuration toggle.
A Gov-mode store carries three independent cryptographic trust chains, each answering a different question. They are orthogonal: compromising one does not weaken the others, and all three are checked together.
| Chain | Answers | Anchored by |
|---|---|---|
| Software license | Is this an authorized engine at the correct tier? | SERAPH licensor signature |
| Operator identity | Who wrote each record? | The customer's own PKI |
| Time anchor | When was it written? | RFC 3161 TSAs / OpenTimestamps |
A forged operator credential cannot invalidate the license chain; a lapsed license cannot erase signatures already committed; neither can move a record in time. Each chain stands on its own.
Every record in a Gov-mode store is attributed to the individual operator who committed it, not the software license, not a shared service account, but the specific person or system principal.
Operator credentials come from the customer's own PKI (typically an X.509 certificate). The customer's application validates the certificate against its trust anchors and derives the operator's clearance; SERAPH then signs each record with that operator's key and records enough to let any future verifier confirm authorship offline, no live certificate or directory lookup required.
That attribution is tamper-evident: an operator's identity is sealed into the same cryptographic chain as the content it signs, so authorship cannot be altered, swapped to another operator, or stripped after the fact without breaking the record's seal. A verifier confirms not merely that a record was signed, but that it was signed by the operator the chain itself names.
Crucially, the private key never leaves the customer's control. SERAPH only ever asks the operator's provider to produce a signature; it never holds, ships, or stores a private key. The same model covers software keys and hardware-backed keys (smartcard / HSM / TPM via PKCS#11), with identical guarantees — the engine is indifferent to where the key lives.
| Algorithm | Standard | FIPS posture |
|---|---|---|
| RSA-3072 (PKCS#1 v1.5 / SHA-256) | FIPS 186-4 | FIPS-approved |
| ECDSA P-384 / SHA-384 | FIPS 186-4 | FIPS-approved |
| Ed25519 | RFC 8032 | Supported (not FIPS-approved in most agency guidance) |
| ML-DSA-87 (post-quantum) | FIPS 204 | On the roadmap |
Different operators may use different algorithms within the same store; verification selects the right one automatically.
Every record carries its own classification level, compartments, dissemination controls, and special-access markings. These are not labels stored beside the data, they are folded into the record's tamper-evident cryptographic seal, the same seal that chains each record to the one before it.
The consequence is decisive: a classification cannot be silently changed. Altering a record's marking, downgrading TOP SECRET//SI//TK to SECRET, for example, breaks the cryptographic chain at exactly that record and is detected at verification. Classification integrity is not a matter of policy or trust in the operator; it is enforced by the same mechanism that protects the content itself.
By default a SERAPH store guarantees integrity that nothing was altered but not confidentiality. For data that must also be protected on disk, Commercial and Enterprise stores can be created as encrypted capsules: content, embeddings, and metadata are encrypted with AES-256-GCM under a key the customer controls, a passphrase, a raw 256-bit key, or (on the roadmap) a post-quantum key. Encryption is transparent: once the key is supplied, search and reasoning behave exactly as on an open store.
A capsule's integrity skeleton, each record's place in the chain and its signatures, stays verifiable without the content key. A recipient can confirm a capsule is intact and correctly attributed before decrypting it, or without ever decrypting it at all.
The protection is scoped honestly: it defends the file at rest against someone who holds the file but not the key. It is not a substitute for runtime memory protection, and searching a capsule requires the key, there is no search over still-encrypted content. Someone with the file alone can still see the store's structural shape, but none of what it contains.
A Gov-mode store enforces Bell-LaPadula mandatory access control inside the engine, not as a check the integrating application is trusted to remember to call. The engine refuses a disallowed operation before any data crosses the API boundary.
- Read-down. An operator sees only records at or below their clearance, and only in compartments they hold. This holds on every retrieval path, direct lookup, similarity search, and graph traversal alike. There is no path that returns a record an operator is not cleared for.
- Write control. An operator cannot record above their clearance.
- Compartments and special-access programs are enforced independently of classification level: holding TOP SECRET does not grant a compartment the operator has not been read into.
Access is decided by the standard lattice dominance rule, a clearance must meet or exceed the record's level and hold every compartment, special-access marking, and dissemination caveat the record carries.
An authorized auditor can verify an entire store — chain integrity, classification distribution, and operator attribution across every record, without being able to read content they are not cleared for.
The audit sees that a record exists, what its classification is, and who signed it. It does not expose what the record says: content and embeddings never cross the compartment boundary, even for the auditor. The audit walks around the boundary rather than through it. An auditor can confirm, for instance, the distribution of records across classification levels and compartments, and that every operator signature is valid, without reading a single classified record.
A Gov-mode SERAPH store is a single, portable file that answers, with cryptographic proof rather than institutional trust all of the following at once:
- What was recorded — every record, in order, with content commitments.
- At what classification — bound into the chain, so silent reclassification is impossible.
- In which compartments — enforced on every access.
- Who recorded it — the individual operator, verifiable offline.
- When — bounded by trusted external time, independent of the local clock.
- Whether anything changed after the fact — any tampering with content, classification, attribution, or ordering breaks the chain at the exact point it occurred.
The store is the evidence; the chain is the proof. A recipient can verify a sealed Gov-mode store's entire provenance, integrity, classification, attribution, and temporal bounds, using only the file and the verification tool, with no database, no network, and no trust in the sender's environment.