Private keys stay local
The key that unwraps secret material stays with the browser, app, or runtime.
Public security overviewZero-trust briefing
Zero-trust secret access, designed so policy and storage do not require server-side decryption.
R4 is designed so identity, policy, auditability, and encrypted delivery can live in the control plane without making the control plane the place where plaintext secrets must live.
Server stores ciphertext
R4 stores encrypted values, wrapped DEKs, and signed metadata instead of plaintext.
Access is least-privilege
Sessions, AGENT API keys, shares, projects, and security groups scope who can request data.
Clients verify what they receive
Clients check trust metadata before they accept and decrypt a payload.
Trust Boundary
What stays local
These materials are meant to remain with the browser, app, or runtime that needs the secret.
Private RSA key material
Unwrapped vault DEK
Plaintext secret at the moment of use
Trust Boundary
What R4 can do without decrypting
The control plane still handles identity, policy, storage, and delivery of encrypted material.
Authenticate users and runtimes
Resolve scoped permissions
Store ciphertext, wrapped keys, checkpoints, and audit events
Decrypt Path
The request lifecycle
Authenticate the actor
A human signs in normally, or a runtime uses an AGENT API key with explicit permissions.
Authorize the request
R4 checks scoped access before returning encrypted material.
Deliver encrypted payload
The client receives ciphertext, wrapped key material, and trust metadata.
Verify and decrypt locally
The browser, app, CLI, or SDK verifies the payload and decrypts it locally.
Zero-Trust Summary
R4 can mediate access without becoming the place where plaintext must live.
The platform still matters for identity, policy, auditability, and encrypted delivery. The final decryption authority stays with the device or runtime that owns the private key.