What this decides. Where the key-encryption key lives once it leaves the process environment. The Levels A+B change request makes the KEK pluggable — obtained through an interface with an environment-backed implementation for now. Level C swaps that implementation so the KEK lives in, and is used inside, a key-management service the running process never holds in the clear. This note lays out the realistic options against the actual DUNIN7-M4 / Cloudflare-tunnel deployment.
Why it is its own decision. A and B are engine code. Level C is an infrastructure and trust choice the engine work cannot make and should not be rushed into the same unit. It also interacts with the confidentiality-posture work: a key-management service DUNIN7 controls is custody hardening (Rung 1); it is not the customer-held-key Rung 2. Level C makes DUNIN7's own custody much stronger; it does not, by itself, make a confidentiality claim against DUNIN7.
What the Operator decides. One of four options. A lean is given.
In envelope encryption (built by A+B), data is encrypted with a data encryption key (DEK); the DEK is wrapped by a key-encryption key (KEK); the wrapped DEK is stored beside the ciphertext. Today the KEK would sit in the process environment — readable wherever the environment is readable.
Level C: the KEK never exists in the clear in the process. The process generates a DEK locally, encrypts data with it, and asks the service to wrap the DEK; to read, it asks the service to unwrap. The KEK stays inside the service. The consequence: reading the process environment, or a memory dump of the running engine, no longer yields the KEK — an attacker, a compelled production, or a malicious insider must also compromise the key-management service, which logs the access and can revoke it. The strongest custody posture short of the customer holding the key (Rung 2, a different arc).
Loomworks runs on DUNIN7-M4 (a Mac Mini) behind a Cloudflare tunnel — owned hardware reached through the tunnel, not inside a cloud provider's compute. So:
No free option; each trades custody strength against operational burden, latency, and external trust.
Buys: strong, audited, revocable custody with no hardware to run; rotation is a service operation; mature integration.
Costs: a cloud dependency on the cryptographic path — latency per wrap/unwrap (mitigated by wrapping DEKs not data, and caching DEKs per session); an availability dependency; and a trust relationship — the provider mediates key access and is a point of legal reach. "We moved the keys to a third party's cloud" is a posture some confidentiality-sensitive buyers will question.
Buys: the strongest custody — keys never leave tamper-evident hardware you physically control; no third party; low, predictable local latency; no external availability dependency.
Costs: highest operational burden — procuring, installing, maintaining, securing physical hardware; a single physical site is a single point of physical failure unless replicated; HSM backup and disaster-recovery is non-trivial. A real infrastructure commitment.
Buys: no third-party trust relationship; keys stay on your infrastructure; more control than cloud, less hardware than an HSM; can later be backed by an HSM root.
Costs: you run and secure another service — its own attack surface, availability, and key-custody problem one level down (what protects its root?). Done carelessly it relocates the single-key problem; done well (hardware root or secret-sharing) it is strong, but "done well" is real work.
Buys: the operational convenience of a cloud KMS plus defense against Option 1's mediation concern — the provider cannot unilaterally use a key it does not solely control.
Costs: the most complex to operate correctly (split custody, M-of-N, ceremonies); operational burden approaches Option 2's without fully escaping the cloud dependency. Strongest on trust, heaviest on setup.
Option 1 (cloud KMS) as the near-term move, designed so Option 4 (split/BYOK root) is reachable later — and Option 2 (on-premise HSM) named as the destination if the confidentiality positioning demands maximal custody.
The pluggable KEK seam (built by A+B) makes the integration the same regardless of which service backs it — so the decision is reversible and the cheapest correct first step is the managed cloud KMS, which gets the KEK out of the process environment (the actual exposure) with the least burden. The cloud-mediation concern is real but addressable by moving to Option 4's split-root model later without re-architecting (same seam). Option 2 is the strongest custody and the right destination if the regulated-domain buyers make "keys never leave hardware we physically control" a selling requirement — but it is a heavy commitment that should be demand-pulled by a real buyer, not adopted speculatively, exactly as Rung 2 is.
So: Option 1 now, Option 4 as the trust-hardening upgrade path (same seam), Option 2 as the maximal-custody destination if a buyer requires it. Mirrors the rung-ladder discipline — cheapest correct step, stronger ones kept reachable, pulled by real demand.
One caution on the lean. Option 1 introduces a cloud dependency on the cryptographic path and a third-party trust relationship. Before committing, confirm: (a) the wrap/unwrap-per-DEK-with-session-caching pattern keeps latency and availability acceptable for the engine's access patterns (a CC/infra check); and (b) the cloud-mediation trust posture is acceptable for near-term buyers, or the Option 4 upgrade path is credible enough to satisfy them. If either fails, Option 3 or Option 2 moves up.
This note does not pick for you — it is the menu and the lean. The decision is an infrastructure and trust judgment properly the Operator's (and the founder's, since it touches the broader DUNIN7 program's posture, not just the Loomworks engagement).