SEAL — the cryptographic perimeter of trust

01The cryptographic perimeter of trust #sec_af09b142

SEAL is the service that concentrates the sensitive cryptographic operations of REVIEWIT: storing secret references, deriving values, signing seals, governing key generations, and authorizing their destruction. Business modules request an operation from it; they do not obtain the secret material that makes it possible.

This boundary prevents each application from inventing its own key storage, receipt formats, and rotation rules. The underlying vault protects secrets; SEAL adds the REVIEWIT doctrine: isolation by tenant, authorized capabilities, lifecycle, proof of operation, and state of authority.

SEAL does not decide on a certification, a right, or a retention period. It applies a previously authorized cryptographic operation and returns a verifiable result or receipt.

02The key does not leave, the result does #sec_3b5f0896

A consumer handles a stable reference, never a clear secret. To sign an Audit Trail header, SEAL makes the key used within its perimeter and returns the signature. For sign-off, it derives the randomness necessary for inclusion proofs without returning the attestation secret.

This rule greatly reduces exposure paths: no private key travels in the memory of a business application, in its parameters, or in its logs. It also facilitates changing the vault provider, as consumers depend on a capability and not a proprietary API.

Operations are isolated by usage. An audit seal key, a document signature key, and an attestation derivation secret belong to different domains. Reusing the same key because the three operations "sign something" would mix incompatible responsibilities and durations.

03Generations, rotation, and destruction #sec_52bf3522

A secret has a class and generations. The class policy decides if rotation is allowed, at what cadence, and with what validations.

Some values are intentionally non-rotatable. The secret that participated in an attestation commitment must remain stable: replacing it would make future proofs impossible. A new generation can serve subsequent attestations, but the old one remains available as long as a living attestation depends on it.

Destruction follows the inverse rule: it must be easy to request when legitimate, difficult to cancel, and impossible as long as a protected dependency remains. The state of authority prevents a silent return to a revoked or destroyed generation.

SEAL thus distinguishes the business duration and the cryptographic cycle. Retention may make a generation eligible for destruction; it does not directly destroy it or bypass governance controls.

04Authorize the operation, not just the caller #sec_6d9b6b65

The control concerns the identity of the requester, the tenant, the requested capability, and the current state of authority. An application authorized to derive a value does not automatically receive the right to sign, rotate, or destroy a key.

The most sensitive human acts may require TrustGate elevation and double validation. Repetitive service operations follow a regime adapted to their nature, with machine identities, minimal capabilities, and receipts. A non-mutating operation is not artificially treated as a governance operation, but it remains bounded and observable.

Product roles are not sufficient to administer the authority account. The separation of powers extends to IAM policies and the operational chain: the person capable of altering the proof storage must not, alone, be able to produce a seal that would mask this alteration.

05Receipts, resumption, and degraded state #sec_40421e1a

Operations that modify the state are idempotent. A "get or create" request with the same logical identity finds the same generation; a restart does not create two concurrent secrets. Receipts allow the consumer and the audit to link the request, the authority decision, and the result without exposing the secret value.

The audit remains proportionate. A derivation concerning thousands of elements is traced by batch or by tranche, not by elementary value. The system proves that a construction took place without overwhelming the trail.

In a degraded situation, SEAL fails closed for a cryptographic operation it cannot guarantee. The calling module can maintain a resumption state, but must never present as sealed or signed what is not. Read or service operations already explicitly authorized do not, therefore, become governance bypass gates.

06In summary #sec_f94675c2

SEAL gives REVIEWIT a single boundary to protect, authorize, and prove its cryptographic operations. Applications use capabilities, not keys; generations follow their dependencies; sensitive operations respect the separation of powers; and no result is presented as sealed when the authority could not guarantee it.