BrainVault

A secrets vault written in Rust — a Braincap MSSP product, currently in development.

What sets it apart: a capability broker, not a credential store

Most vaults (HashiCorp Vault, Infisical, OpenBao) hold a secret and hand it over on request. That moves the problem, it doesn’t solve it — the client still ends up with the secret in its own memory.

• Store: the client asks for the SMTP key → the vault hands it over → the client sends the email
• Broker: the client asks to “send this email” → the vault sends it, with its own key

BrainVault makes the broker the default path. Compromising an application exposes the capability (a limited, audited, seconds-to-revoke action), not the credential (which would work from anywhere, forever). The store model stays supported, as a documented exception.

Already built

• mTLS + identity from the certificate — tenant from the issuer, role from the OU, subject from the SAN
• Envelope encryption — master → tenant → element → secret, with rotation and no downtime
• Chained audit log — SHA-256; detects tampering, chain breaks and deletion
• Email broker — a generic model, extensible beyond mail
• Read API + RBAC + audit — the store, as a documented bridge
• redb persistence — pure-Rust, no C; secrets and the audit chain survive a restart (the disk holds only ciphertext)
• Tenant key rotation via API — re-wraps element keys without touching the secrets, atomically
• Dual-control (2P) — proposal and approval by different identities (separation of duties, BNR Norma 9)
• Master rotation via 2P, with a crash-resistant keyring
• Shamir unlock (k-of-n) — the master is split into shares

Second factor: OTP (TOTP, RFC 6238)

A compromised certificate alone is not enough. OTP comes in as a second factor, bound to a human’s authenticator:

• On read — the seed is returned once (for the authenticator), encrypted at rest, and never leaves to the application; reading then requires the code. A stolen certificate alone cannot read the secret.
• On privileged operations — installing, rotating the tenant key and exporting require the code from the authenticator; routine reads stay automatic so the workload doesn’t break.
• Enforced at onboarding for the regulated tier — a regulated tenant starts with OTP enabled; install/rotate/export require the code from day one.
• Break-glass with two-person approval — if the authenticator is lost, a reset needs a proposal (TenantAdmin) + an approval by a different identity (SoD); the new seed goes to the approver, not the proposer. A compromised admin certificate alone cannot reset it.
• Loud SIEM alert — break-glass events go out at high severity with a dedicated MSGID so a correlation rule catches them immediately — they don’t get lost in the audit noise.

The limits, stated plainly

Root on the vault host remains unsolvable. Anyone with root and patience can read the unlocked master key from process memory (/proc/<pid>/mem). Vault has exactly the same limitation; we state it plainly. What we do to shrink the window and raise the detection bar:

• Secrets never hit the disk — swap disabled or mlock on the sensitive pages; core dumps off (RLIMIT_CORE=0) so a crash cannot write the address space to disk.
• zeroize + secrecy everywhere — in-memory copies are wiped the moment they are no longer needed; this shrinks the window, it doesn’t close it.
• Split master (Shamir) — there is no persisted unlocked master; it is reconstructed in memory only, at quorum.
• Detectable, not silent — the SHA-256 chained audit log makes any tampering visible, and exception operations go out loud to the SIEM. A malicious MSSP operator is detectable, even if not preventable.

The correct guarantee: a compromised application exposes the capability, not the credential — a limited, audited, seconds-to-revoke action — for the duration of the loan, with a complete audit trail.