Metadata and credentials
What Rhea can access, and what stays outside its backend.
This page separates protected document contents and keys from the metadata, provider credentials and client-delivery responsibilities involved in operating RED.
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.
Objects written by RED into storage you own can be read directly out of your storage account.