Your Key Locks the Data — Even From Us

What This Actually Is

Every piece of sensitive data the system stores is encrypted with an inner key. That inner key is itself locked — "wrapped" — by an outer key: the Customer-Managed Key (CMK). The system supports three ways to hold that outer key: locally, for our own use today, or through a customer's own AWS or Azure key vault.

What this makes possible:

• To read the data, the system must first unwrap the inner key using the outer CMK
• If the CMK is deactivated, that unwrap step fails — the system cannot decrypt the data, full stop
• The failure mode is "fail closed": any error, any missing key, any deactivated key, and the system refuses to proceed rather than falling back to an unprotected default

Why "Fail Closed" Is the Point

Many systems fail open when something goes wrong — better to keep working than to break. This system does the opposite for anything touching a customer key:

• No active key on file for a tenant → the system stops, it does not silently skip encryption
• Missing the software needed to talk to AWS or Azure → that path refuses to start, rather than quietly falling back to a weaker method
• This was verified directly: deactivating a key causes the lock/unlock operation to fail, exactly as designed, and this behavior is certified

What This Proves, and What It Doesn't

This proves the mechanism is real, tested, and certified — a key structure where deactivating the outer key blocks access to the data underneath. Today, this runs on our own local key for our own single-tenant use; the AWS and Azure paths are built and functional but not yet holding a real external customer's own key. The honest claim is: the off-switch exists and works. The claim we're not making yet is that a customer is using it in production today.