Authorization
Authority to read is granted deliberately, and can be withdrawn.
Holding infrastructure access is not the same as holding the authority to read. In RED that authority is issued for a short window, for a limited number of uses, and can be revoked.
The lifecycle
How a read is authorized.
- 01
Authenticate
The member proves who they are.
- 02
Evaluate policy
The organization's policy is evaluated for the requested action.
- 03
Approve sensitive actions with Rhea Key
Sensitive operations require an explicit approval rather than an implicit permission.
- 04
Issue short-lived authorization
Authorization is time-boxed and limited in use, not a standing grant.
- 05
Decrypt on the authorized device
Key material is used on the device; the server does not perform the decryption.
- 06
Record the decision
Authorization decisions and approvals are recorded as evidence.
Failure behaviour
A policy lookup that fails denies.
If policy evaluation cannot complete, the request is denied rather than allowed. Failing closed is the only defensible behaviour for a control that decides whether sensitive data becomes readable.
One honest caveat: an organization that has configured no policy at all is treated as unrestricted for its own members. Configure policy before treating RED's authorization layer as a restriction on internal access.
LimitationWith no policy configured, an organization's own members are not restricted by policy evaluation. Role and membership controls still apply.
Separation
Administrative role is not decrypt authority.
An Owner or Admin can manage the organization, its members and its settings. That authority does not let them decrypt another member's document. Governance and readability are separate powers, deliberately.
See it against your own environment.
Connect your own storage, protect a document, and read the recorded evidence yourself.