Architecture
The system model, boundary by boundary.
Rhea Data brings protection, permissions, data operations and evidence together around customer-owned infrastructure. This page explains the deployment model, its trust boundaries and the customer-controlled execution model.
System model
Where each responsibility sits.
Who uses the layer
People · Applications · AI agents · Workloads — each with its own bounded authority
Rhea
Protection · Authority · Operations · Evidence
Client-side cryptography, authorization evaluation, operational metadata, storage orchestration and the audit record.
Infrastructure holding the data
Object storage · Clouds · Databases · Private infrastructure
Six object-storage families and relational databases, governed from one access point.
Trust boundaries
What sits inside the organization's control, and what does not.
Inside the organization
- Per-document data keys
- The Rhea Key–derived key that wraps them
- Guardian recovery keys and Recovery Kits
- Plaintext, on authorized devices only
Rhea's side
- Operational metadata, including filenames
- Wrapped key material, as ciphertext
- Authorization policy and decisions
- Storage credentials, decryptable by Rhea
- The delivered web application
Storage provider's side
- Encrypted objects and chunk layout
- Bucket, region and access logs
- No plaintext Rhea Data document decryption keys
- Stored Rhea Data ciphertext alone does not reveal the file contents
In Standard mode Rhea holds a server-side key that decrypts the storage-provider credentials you supply, so Rhea Data can perform storage operations on your behalf. That key does not decrypt file contents, recovery shares, or any document key.
Protection flow
What happens before storage receives anything.
- 01Select
A file is chosen in Rhea Data on an authorized device.
- 02Key
A per-document data key is generated in the browser.
- 03Encrypt
Content is encrypted in 5 MB chunks with AES-256-GCM, each with a fresh IV.
- 04Bind
Each chunk is bound to its document, generation and position; the manifest is authenticated.
- 05Store
Ciphertext is written to the organization's own storage. The data key is wrapped and stored separately.
Every encrypted chunk is cryptographically bound to its document, its encryption generation and its exact position in the file. Reordering, duplicating, deleting or substituting chunks inside the bucket is detected and the file refuses to open.
The chunk manifest is authenticated with HMAC-SHA-256 under a key derived from the file's own encryption key. Only a party who can already decrypt the file can produce a valid manifest.
Authorized read
How protected data becomes readable again.
- 01Request
An authenticated member asks to open a document.
- 02Evaluate
Organization and resource policy are evaluated. A lookup failure denies.
- 03Authorize
A short-lived, limited-use, revocable authorization is issued and consumed atomically.
- 04Unwrap
The wrapped data key is unwrapped in the browser with the member's own key.
- 05Open
Chunks are verified and decrypted locally. The event is recorded.
Each decryption is gated by a short-lived, limited-use, revocable authorization evaluated against organization and resource policy. Use is consumed atomically in the database, so a token cannot be replayed beyond its limit. If policy cannot be read from the database, access is denied. A lookup failure is treated as a denial, never as an absence of policy.
Rhea's API exposes no decryption endpoint. Custody tier is chosen per deployment.
Key hierarchy
Which key opens what.
Data key (per document)
Generated in the browser. Encrypts the document's chunks. Never transmitted in the clear.
Wrapping key (per member)
Derived in the browser from a Rhea Key signature. Wraps the data key. Never held by Rhea.
Recovery envelopes (per guardian)
Shares encrypted to each guardian's own P-256 key. Reconstruction happens only in the initiating administrator's browser.
The keys that make file contents readable — the per-document data key and the key that wraps it — are generated on your device and are never generated, held or derivable on Rhea's servers.
Rhea's backend and its entire database, taken together, cannot reconstruct a recovered key. The only keys that open recovery shares are guardian keys held outside Rhea and a session key that never leaves the initiator's browser.
Authorization
Rhea Key carries the authority to approve.
Rhea Key authenticates with signatures over a canonical message using server-issued single-use nonces and short, revocable sessions. Biometrics gate the local vault on the device only — they never leave it and never replace the signature.
Administrative role and decryption authority are separate. An organization Owner or Admin cannot decrypt another member's document — administration does not grant readability.
Rhea Key provides authentication and approval for supported Rhea Data workflows. Proving control of a key does not by itself grant access to every organization or resource; the applicable authorization still determines permitted use.
Storage model
Bring Your Own Storage.
Rhea Data uses a Bring Your Own Storage model. Your organization connects storage it already owns and controls. Rhea does not provide, host or operate customer storage.
Data movement
Moving protected data between locations.
- 01Check
Source, destination and credentials are validated.
- 02Transfer
Encrypted objects are copied to the destination.
- 03Verify
Integrity is checked against the authenticated manifest.
- 04Cut over
Rhea Data points to the new location; keys and policy are unchanged.
- 05Record
The operation is written to the audit record.
No independent third-party security audit or certification has been completed. Independent source, build and operational review has not yet been completed. This page will state the result when an external audit exists.
Architectural direction
The same operations. Customer-controlled execution.
Current Rhea Data model
Rhea Data already brings supported document operations, protection, permissions and recorded activity together. Current connection modes can use reusable provider credentials processed by Rhea's backend. A customer-owned storage account is not, by itself, independent customer-side enforcement.
Customer-controlled execution model
Your organization owns the cryptographic authority. Rhea coordinates supported operations. A connector in your environment independently verifies the signed action, resource, scope, expiry and policy before it runs, with customer-side replay protection and signed execution evidence. Reusable provider credentials remain outside Rhea in this target mode.
A shared actor model will let people, approved applications, AI agents and workloads use supported operations under separate, bounded authority. Provider adapters will extend that model across AWS, Azure, GCP, S3-compatible storage and additional environments. Database connectivity begins with PostgreSQL and extends to MySQL, SQL Server and selected data platforms.
The defining requirement is that compromising Rhea must not let an attacker manufacture customer authority. Achieving it includes customer-controlled enrollment, recovery and executable-update approval, not just request signatures. Protected execution must refuse invalid authority rather than silently switch to a weaker path. Policy narrows and never grants; only a Rhea Key signature grants, and the customer connector can still refuse. An agent signature is never a human approval. Rhea Data Relay remains an explicit compatibility option where the trust model differs. These are target requirements, not a completed production guarantee.
Rhea delivers the web application that performs browser-side cryptography. That delivery path and authorized endpoints remain trusted components. A malicious client update can affect future uploads and authorized opens; separating stored keys from the backend does not remove this risk.