How Rhea works: data, access, and identity

1. Rhea's category and purpose

Rhea builds infrastructure for keeping enterprise data protected and under organizational control across the environments where it is stored and used.

RED is enterprise data protection and management infrastructure — not an encrypted storage service. Organizations keep their chosen storage environment, while RED controls how sensitive data is protected, organized, authorized, accessed, shared, moved and audited.

Storage holds protected objects. RED governs how they become readable and usable.

2. What RED is, and is not

RED is Rhea's enterprise data protection and management infrastructure — not an encrypted storage service. It sits above organization-selected data environments and governs how sensitive data is protected, organized, authorized, accessed, shared, moved and audited.

Client-side encryption is one enforcement mechanism inside RED; RED's category is enterprise data protection and management infrastructure.

3. Storage access versus readability

Storage access is not the same as data readability.

Cloud credentials and storage permissions determine who can reach stored objects. RED adds a separate protection and authorization model around sensitive file content. Possession of a protected object — whether reached through normal administration, copied storage credentials, or a storage incident — is not by itself sufficient to make that content readable.

If protected objects are copied from connected storage without the required decryption authority, the copied encrypted file content is not independently readable. This does not protect plaintext after authorized decryption or eliminate risks on a compromised authorized endpoint.

4. Current RED operating model

This is the currently available RED operating model. Protected file content is encrypted client-side before reaching the organization's AWS S3 environment. RED maintains the verified protection, authorization and audit functions around those operations.

RED gives organizations one environment to protect, organize, authorize, access, share, move and audit sensitive data across supported storage environments. The organization keeps control of where data is stored; RED maintains the protection and access model around it.

Protected file content is encrypted client-side before reaching connected storage. Rhea's infrastructure has no independent ability to decrypt it.

5. RED, Rhea Key and Rhea ID responsibilities

The three lanes describe product responsibilities. They are different from the RED operating model, which describes how an organization currently uses RED with Rhea Key and its selected storage.

• RED — RED is Rhea's enterprise data protection and management infrastructure — not an encrypted storage service. It sits above organization-selected data environments and governs how sensitive data is protected, organized, authorized, accessed, shared, moved and audited.
• Rhea Key — Rhea Key provides user-controlled cryptographic authentication, signing and human approval. Private authentication material remains protected by the user's device and is not transmitted to Rhea.
• Rhea ID — Rhea ID is planned to establish verified identity or specific identity attributes for services that choose to require them, while reducing repeated exposure of unnecessary personal information.

Separating data protection, authorization and identity reduces the amount of sensitive information any one Rhea product needs to handle. Rhea Key and Rhea ID do not receive protected file contents. A storage provider receives encrypted file content rather than readable protected content.

6. Content, key, identity and metadata boundaries

Only encrypted protected-file content reaches connected object storage. RED and Rhea may still process the operational metadata required to provide authorization, organization administration, metering, security and audit functions.

Each protected document is encrypted with its own data-encryption key, which is wrapped for authorized recipients.

Private authentication material remains protected by the user's device and is not transmitted to Rhea. Rhea does not operate a key-recovery service.

• Protected content: the objects a user encrypts with RED. Rhea's services have no independent ability to decrypt protected customer content.
• Encryption keys and private keys: held under the user's control. Private authentication material remains protected by the user's device and is not transmitted to Rhea. Rhea does not operate a key-recovery service.
• Operational metadata: Only encrypted protected-file content reaches connected object storage. RED and Rhea may still process the operational metadata required to provide authorization, organization administration, metering, security and audit functions.
• Audit records: RED records relevant operational metadata for verified categories — actor, action, resource, time and outcome where applicable. Audit records contain operational metadata, not readable protected content.
• Storage provider: sees ciphertext and object metadata such as sizes and access times. It does not see plaintext or encryption keys.

7. Current availability matrix

The tables below are the same product and deployment status used across Rhea's public site, so this article never drifts from other pages.

8. Future controlled-use model (Planned)

Extending organizational control to every authorized actor.

Rhea's direction is to extend RED from human-controlled protected-file operations to supported databases, applications and controlled agent workflows. Planned interfaces are intended to let authorized systems request narrowly scoped operations under organizational policy, required human approval and audit.

Today, RED supports human-controlled protected-file operations with organization-selected AWS S3 storage. Rhea's direction is to extend RED's protection, authorization and audit model to additional storage providers, supported databases, authorized applications and controlled agent workflows. Those integration interfaces are planned and are not currently generally available.

Rhea is building infrastructure for keeping organizational data under controlled use across storage environments, databases, people, applications and agents. RED governs how protected data is accessed and used. Rhea Key provides cryptographic authentication and human approval. Rhea ID is planned to establish verified identity or specific attributes when required. Organizations retain control of their data environments, policies and authorized actors.

9. What remains planned

The following are not currently generally available. These interfaces are not currently generally available. Public technical documentation will be published only when the corresponding integration surfaces are ready.

• Planned. Public RED API or SDK documentation.
• Planned. Generally available application integration.
• Planned. Generally available agent integration.
• Planned. BYOD and database integrations.
• Planned. Multi-cloud object-storage support beyond AWS S3.
• Planned. Rhea ID.
• Planned. Rhea Key iOS.

10. Compliance boundary

Organizations operating under GDPR, NIS2, DORA, EHDS or sector-specific requirements may evaluate RED as one technical and organizational control within a broader compliance programme.

RED does not by itself make an organization compliant, and legal obligations depend on the organization's deployment, policies, processes, contracts and applicable law.

Available vs planned, at a glance

Where to go next

This article introduces the whole system at a high level. For product-specific detail, see RED, Rhea Key, and Rhea ID. For a vocabulary reference, see the Learn glossary.