Zero-knowledge data protection built for environments where trust alone is no longer enough

​

RED is Rhea’s data protection platform.

 

It is built to protect sensitive data before storage, keep access under explicit cryptographic control, and reduce reliance on infrastructure trust, provider trust, backend privilege, and administrative visibility.

 

RED does not exist to replace existing cloud infrastructure, storage systems, or enterprise environments. It exists to apply a stronger protection model above supported environments, so organizations can keep using their infrastructure while reducing unnecessary plaintext exposure and strengthening control over access.

 

Most systems still depend on a weak assumption: that whoever controls the platform, backend, storage layer, or administrative environment can ultimately be trusted with the data.

 

RED is built on a different assumption:

 

sensitive data should remain protected even when infrastructure is shared, distributed, outsourced, or exposed to multiple internal and external systems.

 

That is the purpose of RED.

 

 

 

The problem RED is built to solve

​

Sensitive data now moves across cloud platforms, SaaS systems, internal workflows, employee devices, backup environments, vendors, analytics pipelines, AI tooling, and external processors.

 

In most environments, that creates a structural security problem.

 

Too many systems and too many parties can potentially access plaintext data, encryption keys, or the operational context around protected information. Even where traditional security controls exist, organizations still end up depending on broad backend permissions, privileged services, infrastructure visibility, provider-side trust, and administrative assumptions.

 

That model becomes weaker as environments become more distributed.

 

The issue is not that existing infrastructure is useless. The issue is that infrastructure alone is not a sufficient protection boundary for highly sensitive data.

 

RED is designed to solve that problem at the protection layer itself.

 

​

​

What RED is

​

RED is a zero-knowledge data protection layer.

 

It is designed to protect data before it leaves the user’s environment, keep plaintext access out of the default infrastructure path, and enforce access through cryptographic authorization rather than relying only on backend permissions, storage provider trust, or admin-level visibility.

 

RED is not simply another storage platform.

 

RED is not just server-side encryption.

 

RED is not a collaboration product with security features added later.

 

RED is a dedicated protection layer designed to keep security attached to the data itself across supported environments.

 

At its core, RED is built around three principles:

 

Protection before storage

Sensitive data is encrypted before storage, sharing, or controlled processing.

 

Explicit cryptographic access

Access should require authorization under the protection model itself, not just trust in whoever controls the environment.

 

Separation between storage and protection

The system storing the data should not automatically be the system that can read the data.

 

 

 

What RED does

​

RED is designed to let organizations:

 

• protect sensitive data before it is stored

• reduce default plaintext exposure across infrastructure

• keep encryption control separate from the storage provider

• enforce access through cryptographic authorization

• manage internal and external sharing under stronger control boundaries

• apply policy-based protection to sensitive workflows

• maintain auditability and governance around access and data handling

• support controlled processing and external system interaction without default broad exposure

• deploy across supported environments without forcing infrastructure replacement

 

 

The result is a stronger protection model for modern enterprise data handling.

 

 

 

How RED protects data

​

RED is built around a zero-knowledge architecture.

 

Sensitive data is encrypted locally before storage. Encryption is designed to happen before the data becomes dependent on the storage environment for protection. This means the protection model begins before the storage provider, backend environment, or infrastructure administrator would otherwise become the default trust boundary.

 

At a high level, RED uses:

 

• client-side encryption before storage

• AES-256-GCM encryption

• unique random IVs per chunk

• per-document data encryption keys rather than one broad shared key

• wrapped-key architecture for stronger key separation

• controlled key release flows for authorized access

• explicit authorization boundaries around decryption-related operations

 

 

This is designed to create a much stronger model than environments where the server, storage provider, or broad internal platform roles can access plaintext by default.

 

The objective is straightforward:

 

control over infrastructure should not automatically mean control over sensitive data.

 

 

Core technical architecture

RED’s protection model is built around layered cryptographic controls rather than a single shared trust point.

 

 

Client-side encryption

Sensitive data is encrypted on the client side before storage. This is intended to reduce the risk created when plaintext becomes visible inside storage, provider, or general backend environments.

​

AES-256-GCM

RED uses AES-256-GCM as the primary encryption primitive for protected data.

 

 

Per-document DEKs

RED uses distinct data encryption keys for documents rather than one broad key covering everything. This improves blast-radius control and makes the protection model more granular.

 

 

Wrapped key architecture

Data encryption keys are wrapped through higher-order key control logic rather than left exposed as broad reusable secrets. This separation is a core part of RED’s architecture.

 

 

Key derivation and authorization model

RED’s architecture is built around cryptographic authorization and derived key control, rather than simple password-based trust or broad server-side decryption privilege.

 

 

Controlled key release

Decryption-related access is designed to occur through controlled key-release paths rather than through unrestricted backend access patterns. That allows access to be bounded, authorized, and enforced under the protection model.

 

 

Storage and protection separation

Storage is treated as infrastructure. Protection is treated as a separate security layer. That separation is fundamental to RED.

 

 

 

Why this model matters​

​

In a traditional architecture, organizations often end up trusting that:

 

• the provider behaves correctly

• administrators behave correctly

• privileged services are never abused

• backend logic never overreaches

• exposed environments remain clean

• third-party systems only use what they are meant to use

 

 

That may be operationally necessary in parts of the stack, but it is a weak foundation for highly sensitive data.

 

RED is designed to reduce how much the organization must rely on those assumptions for plaintext protection itself.

 

That is why RED is different.

 

It is not only about encrypting files. It is about building a system where the protection boundary is more closely tied to the data and the authorization model than to broad infrastructure control.

 

 

 

Access, sharing, and control

​

In most systems, access control is still mostly administrative.

 

A user gets a role. A service gets a permission. An internal system gets broad access. A database policy says yes. A backend function runs with elevated authority. The result is often that many more things can see the data than the business actually intends.

 

RED is designed to make access control stronger by tying it to the protection model itself.

 

When access is granted, it is meant to be granted explicitly.

 

When access is revoked, the boundary is not intended to be only a UI setting or an administrative checkbox. It is meant to be enforced through the same protection model that secures the data.

 

This is important for:

 

• internal sharing

• external sharing

• partner access

• vendor interaction

• controlled review workflows

• sensitive business collaboration

• regulated data handling

• high-trust organizational environments

 

 

The real question is not only who is supposed to have access.

 

The real question is:

 

what technically prevents everyone else from having it?

 

RED is built to answer that question properly.

 

 

 

Internal and external sharing

​

RED is designed to support secure sharing across different operational realities.

 

That includes:

 

• sharing within teams

• sharing across departments

• sharing between administrators and members under controlled boundaries

• sharing with external partners

• sharing with processors or controlled third-party environments

• revocation-sensitive access patterns

 

 

The goal is not casual file sharing. The goal is to support sharing without collapsing back into a broad-trust model where the system, provider, or general admin layer can read everything by default.

 

 

 

Controlled processing workflows

​

Modern organizations do not only store data. They move it through workflows.

 

Sensitive data may need to be:

 

• reviewed

• approved

• passed across internal roles

• handled by external processors

• used in automation

• involved in AI workflows

• processed under policy conditions

• accessed in temporary or bounded ways

 

 

RED is designed to support this through controlled access paths rather than permanent broad visibility.

 

That matters because modern data protection is not only about storage. It is about governing how sensitive data is accessed and used across live business operations.

 

​

AI, automation, analytics, and external systems

​

This is one of the most important parts of RED.

 

Organizations increasingly want to use:

 

• AI tools

• automation platforms

• analytics systems

• external processors

• workflow engines

• vendor environments

 

 

At the same time, many of them are handling regulated, confidential, strategic, or operationally sensitive data.

 

That creates a major contradiction.

 

The business wants faster workflows and more intelligence. The security reality is that every additional system that touches sensitive data expands risk.

 

RED is designed to help resolve that contradiction by supporting a more controlled interaction model.

 

Instead of assuming that operational use requires broad plaintext exposure, RED is built to support stronger authorization boundaries around how protected data is accessed and processed.

 

For organizations adopting AI or automation in security-sensitive or regulated environments, this is not optional window dressing. It is becoming a fundamental requirement.

 

The future question is not whether organizations will use AI.

 

It is:

 

under what protection model they will allow AI and external systems to interact with sensitive data at all.

 

RED is built for that future.

 

 

 

RED and existing infrastructure

​

RED is not designed to force migration.

 

Organizations should not have to abandon their cloud provider, rebuild their storage strategy, or redesign their core systems just to apply stronger data protection.

 

RED is designed to operate above supported environments.

 

That means organizations can strengthen protection while continuing to use existing infrastructure.

 

This matters:

 

Operationally

because full replacement is disruptive

 

Financially

because forced migration is expensive

 

Strategically

because security adoption is faster when it works with real environments

 

RED is built to improve protection without demanding unnecessary architectural disruption.

 

 

 

BYOS: Bring Your Own Storage

​

RED supports a bring-your-own-storage model for organizations that want to keep storage under their own infrastructure control.

 

This is especially important for enterprises, governments, regulated environments, and organizations with strict data governance requirements.

 

With BYOS, RED’s protection layer can operate while the organization retains control over where protected data objects are stored.

 

Supported storage environments include:

 

• AWS S3

• Google Cloud Storage

• Microsoft Azure Storage

• Oracle Cloud storage environments

• MinIO and compatible object storage environments

 

 

This gives organizations flexibility to align RED with their own infrastructure, cloud policy, procurement model, jurisdictional requirements, or operational standards.

 

BYOS matters because many serious buyers do not want a security vendor to force them into one storage dependency model. They want stronger protection while preserving infrastructure choice.

 

RED is built to support that.

 

 

 

Managed storage options

​

For organizations that prefer not to bring their own storage immediately, RED can also support managed storage models.

 

This gives buyers flexibility based on maturity, internal capacity, procurement timing, or deployment preference.

 

That means organizations can choose the model that fits them best:

 

• use their own storage infrastructure

• start with managed storage

• align storage strategy with the pace of internal adoption

 

 

This is important commercially and operationally because not every buyer wants the same deployment path.

 

Some want full infrastructure control from day one.

Some want a faster adoption path.

RED is designed to support real-world flexibility.

 

 

 

Storage philosophy

​

RED should be understood correctly here:

 

RED is not fundamentally a storage replacement product.

 

RED is a protection layer that works with storage.

 

That distinction matters.

 

Storage answers where data lives.

RED answers how that data remains protected, how access is controlled, and how exposure is reduced.

 

That separation is one of the reasons RED is structurally stronger than ordinary “secure storage” positioning.

 

 

 

Deployment flexibility

​

RED is designed for different organizational realities.

 

Deployment and operational models may vary depending on:

 

• infrastructure ownership preferences

• storage requirements

• governance obligations

• internal security policy

• procurement constraints

• scale requirements

• integration path

 

 

RED is built to support deployment across supported environments without reducing the protection model to a generic one-size-fits-all SaaS trust structure.

 

This is important for:

 

• enterprises

• regulated industries

• government-related environments

• organizations with strict data locality concerns

• teams with custom cloud or object-storage standards

• buyers who require deeper control over infrastructure decisions

 

 

 

 

Governance, auditability, and accountability

​

Serious organizations need more than encryption.

 

They need to answer questions like:

 

• who had access

• who granted access

• when access occurred

• under what conditions access was allowed

• how protected data moved

• how policy was applied

• what actions were taken

• how the system can support accountability

 

 

RED is designed to support those needs through structured governance and audit-oriented controls.

 

This includes support for:

 

• audit visibility

• event tracking

• access accountability

• policy-aware control models

• governance-oriented operational administration

 

 

RED is built for environments where protection must stand up not only technically, but also operationally and organizationally.

 

That makes it relevant not only to engineers, but also to:

 

• security leadership

• legal teams

• procurement stakeholders

• compliance functions

• risk managers

• executive decision-makers

 

 

 

 

Tamper-evident audit model

​

RED is built with a serious view of audit integrity.

 

Audit should not just exist as a convenience log. It should support stronger trust in what was recorded and how events can be verified.

 

RED’s architecture includes tamper-evident audit concepts designed to strengthen the reliability of security-relevant event history and make auditability more defensible in serious environments.

 

For organizations that care about accountability, this matters.

 

A weak audit model can say something happened.

A stronger audit model helps defend the integrity of that record.

 

 

 

Policy-based security model

​

RED is designed to support policy-driven protection rather than relying only on static permissions.

 

That matters because sensitive environments are rarely governed well by simple role assignments alone.

 

Organizations often need conditions around:

 

• who can access what

• in what context

• under what policy

• for what type of workflow

• with what type of authorization

• with what degree of restriction or auditability

 

 

RED is designed to support a stronger policy-aware access model for serious environments.

 

 

 

Enterprise operating model

​

RED is built for real organizational complexity.

 

That includes support for environments where data is handled across:

 

• multiple users

• multiple teams

• internal administrative roles

• external parties

• varying sensitivity levels

• different operational workflows

• cloud and object storage environments

• audit and governance expectations

 

 

It is built to give organizations stronger command over how protected data is stored, shared, accessed, governed, and processed.

 

The objective is not simply to encrypt objects.

 

The objective is to improve the operating model around sensitive data itself.

 

 

 

Zero-knowledge means something specific here

​

RED’s zero-knowledge model is not cosmetic language.

 

It means the architecture is designed so that plaintext access is not meant to be available by default to the platform, storage provider, or general backend environment simply because they are involved in storage or control flow.

 

That is a major distinction.

 

Many products claim strong security while still depending heavily on trusted server visibility, broad backend decryption capability, or provider-side trust for normal operation.

 

RED is built to reduce that dependence.

 

That is the difference between “we secure your data” as a marketing statement and a system that is architected to reduce who can actually see the data at all.

 

 

 

What makes RED different

​

RED is different because it starts from a stronger assumption:

 

the system storing or managing the data should not automatically be the system that can see the data.

 

That leads to a different architecture and a different operational model.

 

RED is not:

 

• just another cloud storage vendor

• just another collaboration platform

• just another encryption checkbox

• just another admin-trust model

• just another backend-visible system dressed up as security

 

 

RED is built around:

 

• protection before storage

• separation between storage and protection

• explicit cryptographic access control

• reduced default plaintext exposure

• infrastructure flexibility

• stronger alignment with enterprise governance needs

• controlled interaction with modern workflows, external systems, and AI environments

 

 

This is not a cosmetic improvement to old models.

 

It is a different model.

 

 

 

Who RED is for

​

RED is built for organizations and environments where ordinary trust assumptions are not good enough.

 

That includes situations where sensitive data is:

 

• confidential

• business-critical

• operationally sensitive

• legally sensitive

• regulated

• shared across multiple parties

• processed across different systems

• handled by vendors or external processors

• involved in automation or AI workflows

 

 

RED is for organizations that understand a simple fact:

 

if sensitive data can become visible too easily inside the system, then the system is weaker than it looks.

 

 

 

What RED gives organizations

​

RED is designed to give organizations:

 

 

Stronger control

​

Access is intended to be explicit and cryptographically bounded rather than broadly assumed through infrastructure trust.

 

 

Lower exposure

​

Plaintext is not meant to become broadly visible across the platform and storage layers by default.

 

 

Better separation of concerns

​

Storage and protection are treated as distinct concerns rather than collapsed into one trust layer.

 

 

More flexible infrastructure choices

​

Organizations can align RED with supported cloud and object storage environments instead of being forced into a single provider path.

 

 

Stronger audit and governance posture

​

Protection is supported by accountability, visibility, policy enforcement, and operational control expectations relevant to serious buyers.

 

 

Better alignment with modern workflows

​

RED is built for environments where data moves across teams, systems, vendors, automation, and external processing paths.

 

 

 

The core idea behind RED

​

At its core, RED is built on a simple belief:

 

sensitive data should remain protected even when it moves.

 

Not only when it sits in one trusted environment.

Not only when the provider behaves correctly.

Not only when the admin layer is assumed to be safe.

Not only when no external system touches it.

 

Sensitive data should remain protected across modern operating reality.

 

That is what RED is built for.

 

 

 

Conclusion

​

RED is Rhea’s zero-knowledge data protection platform.

 

It is designed to protect sensitive data before storage, reduce unnecessary plaintext exposure, keep access under explicit cryptographic control, support stronger governance and auditability, and operate across supported infrastructure without forcing storage or cloud replacement.

 

It is built for organizations that need stronger control over how sensitive data is protected, accessed, shared, processed, and governed across clouds, systems, teams, vendors, and external environments.

 

RED exists for organizations that need more than trusted infrastructure.

 

RED exists for organizations that need protection to remain intact even when data moves.

 

 

​

 

​​