The controls behind every secret we hold.

Every secret is encrypted before it is written anywhere. Plaintext is never kept, never written to logs, and never handed back except through a deliberate, audited reveal.

The keys that protect your secrets are held apart from the secrets themselves, and apart from one another.

Protection is specific to where a secret lives. A value protected for one configuration cannot be read from another, and a value that is copied is encrypted afresh for its destination rather than carried across.

Authorization is checked both before and after decryption. Binding the request to a specific configuration and a specific version happens first; immediately before the value is returned, Redcee revalidates the same session or token, the grants currently in force, and the version that was originally authorized.

An audit record of the access must commit before the plaintext leaves the vault. If that record cannot be written, the request fails and the value is not released.

Every failure mode ends the same way. A revoked session, a withdrawn grant, a secret that has been replaced since authorization, or an expired step-up all cause the request to fail closed.

Membership in an organization grants nothing by itself. Access to a project or environment is granted explicitly, by someone who already holds the authority to grant it, and can be withdrawn at any time with immediate effect.

Multi-factor authentication is mandatory before console access, and sensitive configurations can additionally require a recent password and one-time code before values are revealed or changed.

Service tokens are scoped to a single configuration and are read-only. A token that leaks cannot be used to change anything, to broaden its own reach, or to read a configuration it was not issued for. Sessions and tokens can be revoked individually.

The audit ledger is append-only. Reveals, mutations, grants, and administrative actions are all recorded with the identity of the actor at the time of the action, and existing entries are never edited or removed.

Secret history works the same way. Replacing or deleting a value appends to its history instead of rewriting it, so any earlier state can be inspected and restored, and the record of what was in place at a given moment stays intact.

One organization's secrets are unreachable from another's. That isolation is enforced by more than one independent control, so no single mistake is enough to cross the boundary between two customers.

Privileges are separated and kept as small as the work requires, so a credential that leaks confers narrow access rather than broad access.

Concurrent changes are explicit. If two people change the same value at once, the second change is reported as a conflict rather than silently overwriting the first, and neither edit is lost without someone being told.

If you believe you have found a security issue in Redcee, please write to security@redcee.com. We acknowledge reports, keep you informed while we investigate, and will not pursue action against researchers who report in good faith and avoid harming other customers' data.

Please include enough detail to reproduce the issue, and give us a reasonable opportunity to respond before disclosing publicly.