Rhea

Comparison

Where Rhea fits in your data stack.

Storage, key management, encryption and secure exchange solve important parts of the problem. RED combines supported data workflows in one environment. Compare the actual deployment, trust boundary and available capabilities, not just the category name.

Market context

More software. More actors. Who controls the data?

Organizations are using more cloud services and bringing AI into their work. Each system creates another relationship with organizational data: what it may access, what it may change and under whose authority.

Rhea's thesis is that this authority should become reusable infrastructure—so organizations can add supported applications, agents and providers without rebuilding the entire operating and authorization model for each workflow.

52.7%

Paid cloud use

In 2025, 52.7% of EU enterprises in Eurostat's survey used paid cloud services.

Eurostat — cloud services, published 3 February 2026

20.0%

AI in business

In 2025, 20.0% of EU enterprises in Eurostat's survey used AI technologies in their business.

Eurostat — AI use, published 11 December 2025

Identity. Authorization. Interoperability.

An infrastructure concern

NIST's AI Agent Standards Initiative addresses interoperable agents, open protocols, security and agent identity infrastructure.

NIST — AI Agent Standards Initiative

The Eurostat figures cover EU enterprises with at least 10 employees or self-employed persons in the surveyed business sectors. They are not worldwide adoption figures or estimates of Rhea's market. AI use does not necessarily mean autonomous-agent use. NIST's initiative is context, not endorsement or certification of Rhea.

Identity, policy, encryption and data operations are established capabilities. Rhea's direction brings them into one customer-authority architecture: people work through RED, approved software uses supported operations, and customer-controlled connectors independently verify execution authority.

Rhea's architectural distinction: the complete customer-authority model.

Rhea is building a shared operating layer in which useful data operations and customer-owned authority travel together. People use RED. Planned developer interfaces extend supported operations to separately authorized applications, AI agents and workloads. Customer-controlled connectors independently verify authority where those operations execute.

  • Customer-owned authority

    The organization controls the cryptographic authority that permits an operation. The target is not a service that can manufacture sufficient customer authority by itself.

  • Independent customer-side enforcement

    A customer-controlled connector verifies the signed action, resource, constraints, expiry and policy before execution, with customer-side replay protection.

  • Useful operations across supported systems

    The model joins authorization to actual data work—such as reading, writing and moving supported resources—through provider-specific adapters.

  • Separate authority for people and software

    People, applications, AI agents and workloads receive distinct, bounded authority. A new actor does not inherit universal access to connected data.

  • Protection and execution evidence

    Protected data, authorization and signed execution reports are linked within the operating model. Evidence must distinguish what was authorized, what the executor observed and what result was confirmed.

  • Survivability when the vendor is compromised

    The defining target is that compromising Rhea must not enable an attacker to manufacture customer authority. This includes enrollment, recovery and executable-update boundaries—not request signatures alone.

These describe the customer-controlled architecture under development, not a completed guarantee for every current RED connection. Current provider paths, credential handling, available workflows and planned interfaces are documented in Architecture and Product Status.

What this could make possible.

Illustrative planned workflow

A research agent is authorized to create reports in one approved storage location. An analysis agent may read those completed reports and write results to another location. People review the permitted results through RED.

Each participant has separate authority. Each operation is limited to its approved resources and purpose. The customer-controlled execution environment checks the request, and execution evidence records what happened.

The research, reasoning and scheduling can remain in the organization's existing software. Rhea's role is the supported data-operation and authority layer—not a requirement to replace every application with RED.

Rhea is not trying to replace the entire technology stack. It is building a reusable authority and operations layer across supported parts of that stack. Its intended advantage is the combination: useful workflows, customer-owned authority, independent enforcement and verifiable execution.

Market context draws on Eurostat and NIST publications. Sources reviewed 6 September 2026. Rhea's architectural direction is presented separately from current product availability; implementation and security boundaries are documented in Architecture and Product Status.

Capability matrix

Capabilities depend on the product and deployment.

Content protected before the storage provider receives it

Cloud storage with provider-side encryption
Not by server-side encryption alone
Provider key management
Possible with client-side integration
File encryption tools
Core function
Secure transfer and data rooms
Product-dependent
RED
Client-side file encryption

Readable-data authority separate from infrastructure administration

Cloud storage with provider-side encryption
Configuration-dependent
Provider key management
External-key options exist
File encryption tools
Product-dependent
Secure transfer and data rooms
Deployment-dependent
RED
Document keys separate from storage access

Organizational authorization model for named members

Cloud storage with provider-side encryption
Provider IAM
Provider key management
Key policies / provider IAM
File encryption tools
Product-dependent
Secure transfer and data rooms
Available in many products
RED
Roles, permissions and approvals

Revocation of an individual participant's access

Cloud storage with provider-side encryption
Provider access controls
Provider key management
Key and policy controls
File encryption tools
Product-dependent
Secure transfer and data rooms
Product-dependent
RED
Future access through RED, within documented limits

Controlled inbound collection instead of email attachments

Cloud storage with provider-side encryption
Requires a configured workflow
Provider key management
Not a collection workflow alone
File encryption tools
Product-dependent
Secure transfer and data rooms
Common capability
RED
Secure File Requests

Recorded evidence of access, approval and administration

Cloud storage with provider-side encryption
Provider logging
Provider key management
Key-operation logging
File encryption tools
Product-dependent
Secure transfer and data rooms
Service logging
RED
Recorded activity; scope varies by event type

Data stays in storage the customer owns

Cloud storage with provider-side encryption
Customer account options
Provider key management
Depends on storage integration
File encryption tools
Depends on destination
Secure transfer and data rooms
Customer-storage options exist
RED
Supported customer-owned storage

One protection model across multiple connected storage locations

Cloud storage with provider-side encryption
Configuration-dependent
Provider key management
Service and configuration-dependent
File encryption tools
Product-dependent
Secure transfer and data rooms
Product-dependent
RED
Connected AWS S3 locations

Governed movement between connected storage locations

Cloud storage with provider-side encryption
Native or integrated workflows
Provider key management
Requires an operational workflow
File encryption tools
Product-dependent
Secure transfer and data rooms
Available in some products
RED
S3 copy and location update; source retained

Protected structured data in a database

Cloud storage with provider-side encryption
Service-dependent
Provider key management
Via supported database integration
File encryption tools
Product-dependent
Secure transfer and data rooms
Outside typical file-exchange scope
RED
Planned

Application and AI-agent authority

Cloud storage with provider-side encryption
Provider and workload controls
Provider key management
Service/workload authorization
File encryption tools
Product-dependent
Secure transfer and data rooms
Product-dependent
RED
Planned unified actor model

Public API, SDK or integration programme

Cloud storage with provider-side encryption
Provider-dependent
Provider key management
Service-dependent
File encryption tools
Product-dependent
Secure transfer and data rooms
Product-dependent
RED
Planned public interfaces

Completed independent third-party security audit

Cloud storage with provider-side encryption
Provider-dependent
Provider key management
Provider-dependent
File encryption tools
Product-dependent
Secure transfer and data rooms
Product-dependent
RED
Not published yet

This is a category-level orientation, not a benchmark of every vendor. Products and configurations differ, and capabilities overlap. RED entries follow the published product scope. Revocation limits future access through the enforcing system; it does not erase plaintext or copies already obtained by an authorized recipient. This limitation also applies to RED.

Key management

Keys are one part of the operating model.

Key-management products control cryptographic keys and their use, including customer-controlled and external-key configurations. Rhea's direction combines authority with supported data operations, delegation and execution evidence across systems. It does not require dismissing or replacing the key-management tools a customer already uses.

File protection

Protection becomes useful through controlled work.

File protection is essential, and some products also offer access control, revocation and audit. RED brings protected documents, collection, sharing, movement and recorded activity into one operating environment. The broader architecture extends that model through customer-controlled execution and planned software interfaces.

Secure exchange

Useful workflows. Explicit trust boundaries.

Secure-transfer and data-room products support controlled exchange; some also connect customer-owned storage. Compare where keys and provider credentials sit, who enforces authority and which operations are supported. Rhea's intended distinction is the complete combination of useful workflows and independently enforced customer authority, not one feature in isolation.

Current fit

What to check before choosing RED.

  • You need a machine-secrets manager that injects credentials into application runtimes.
  • You need protected structured data in a database today — database connectivity is Planned.
  • You need a completed third-party certification or audit report as a procurement gate today.
  • You cannot operate your own storage account and want the vendor to hold the data.

See the operating model inside RED.

Explore supported document workflows, connected storage and recorded activity. Use the architecture and product-status pages to check the boundaries relevant to your organization.

Enter RED ↗(opens Rhea application in a new tab)
Explore the architectureSee product status