Metadata and credentials
The uncomfortable list, published on purpose.
Any vendor can say what it protects. This page says what it can see, because that is the part a security team actually needs in order to make a decision.
Visible to Rhea
What Rhea can see.
- Filenames, folder names and file types, stored today as plaintext metadata
- Document identifiers, file sizes, chunk counts and encryption generation
- Organization identifiers, membership and roles
- Wallet addresses used for authentication and key wrapping
- Timestamps and access, administrative and security audit events
- Storage configuration: provider, bucket, region and endpoint
- Usage and metering records used for billing
- Wrapped key material — as ciphertext that Rhea cannot unwrap
LimitationFilenames, folder names and MIME types are stored as plaintext metadata today. Encrypted metadata is planned, not shipped. Do not put sensitive information in a filename.
Not visible to Rhea
What Rhea cannot see.
- The plaintext contents of any protected file
- Per-document data encryption keys
- The wallet-derived key that unwraps them
- Recovery shares in plaintext, or any guardian private key
- Anything that would let Rhea reconstruct a document on its own
Credentials
The credential boundary, stated plainly.
Rhea holds a server-side key that decrypts customers' storage provider credentials. This is what makes an operating storage connection possible, and it means Rhea's backend can reach your bucket.
It does not mean Rhea can read your files. Document keys are wrapped by key material derived on your device and are not recoverable server-side. Reaching the bucket yields ciphertext.
Check it against your own bucket.
The verification lab lists tests you can run yourself, including reading raw objects out of your storage account.