Gavriel Sierra

Solo Operator Architecture

Hardware-bound boot assistance for a Shamir-sealed secret store

When a secret store must recover after a restart, preserving a tested manual seal path and automating a narrow boot ceremony may be less disruptive than a seal migration. Verify the final state, not the exit code.

Published
Evidence state
Generalized design guide, derived from a built and reboot-tested pattern on my own infrastructure

The question people ask is usually the wrong one

Someone runs a secret store sealed with a Shamir threshold scheme — the recovery key is split into shares, and some quorum of them is needed to unseal it. Then the host reboots, and the store comes back sealed. Every restart becomes a manual recovery event.

The instinct is to reach for the product's auto-unseal feature and migrate the seal. That may be the right answer, but it adds a new recovery dependency and a migration project.

The better question is narrower: how do I remove the toil of the boot-time ceremony without changing what the recovery source of truth is?

Those are different projects. One replaces a working recovery model with a new one that has to be re-learned, re-tested, and re-documented. The other adds a thin, removable automation layer on top of a recovery model that already works.

Why the obvious alternatives often do not fit

Before assuming a seal migration is the answer, price the alternatives honestly. On a single-host deployment, several of them collapse:

Option Why it may not fit
A hardware security module via PKCS#11 Support depends on the build and edition you are actually running, not on what the documentation describes
Cloud KMS Introduces an external dependency and a network path for a boot-time operation, on a system that may exist precisely to avoid one
Transit unseal from another instance Circular on a single host: the store that would unseal the store has the same problem
A static key on disk Removes the hardware trust anchor entirely, which was the point

Once those are eliminated, the question changes from which seal provider do I configure to how do I automate the ceremony without migration risk. That reframing is the useful part of this whole exercise.

The four properties that matter

A boot-assistance layer worth building has four deliberate properties:

  1. The manual threshold path remains the source of truth. The automation is an accelerator, never the authority. If the helper is deleted, recovery still works the old way.
  2. Recovery material is bound to the machine by hardware. A TPM, or an equivalent platform key store, can encrypt the material so a copied artifact cannot be decrypted elsewhere without the required hardware and policy.
  3. Plaintext exists only in memory, only during boot. No decrypted share lands on disk, in a log, or in a process listing.
  4. The final state is proven, not assumed. The helper checks that the store actually reports itself unsealed, rather than trusting that its unseal command returned zero.

The fourth property is the one most implementations skip, and it is the one this whole site keeps coming back to. A successful command is not the same claim as a correct final state.

Hardware binding without measured-boot binding

Most platform key stores let you bind decryption to platform configuration register values — a measurement of the boot state. It is tempting, because it sounds strictly more secure.

It is a real tradeoff, not a free upgrade:

If you need measured-boot guarantees, take the fragility and build the re-sealing step into your patching runbook. If your priority is keeping a live store recoverable through routine maintenance, the less brittle binding is usually the better engineering decision.

State which one you chose and why. An unstated choice here reads as an oversight later.

What it protects, and what it does not

Be precise about this, because "auto-unseal" invites people to hear more assurance than the design provides.

It may reduce exposure from:

It does not establish protection against:

That last one is the failure mode I would worry about most, because it is self-inflicted and only becomes visible during an actual emergency. Automation reduces toil. It does not reduce the amount of trust the system requires.

Failure modes to design for up front

Assume every one of these will happen eventually, and give each a specific stop condition and a visible failure:

The last one is the reason property four exists. Silence is not success, and an exit code is not a readback.

A rollout sequence that stays reversible

  1. Confirm the platform key store is usable on the machine before touching the secret store at all.
  2. Prove the credentials decrypt only on the intended host.
  3. Keep the manual recovery bundle intact and test it separately, on its own schedule.
  4. Add a boot helper that does exactly one thing and exits.
  5. Verify the final seal state rather than the helper's exit code.
  6. Reboot on purpose, in a window you chose, and record the result.
  7. Keep the disable path as simple as the enable path.

Step seven is the one people leave out. If turning the automation off is harder than turning it on, you have not added an accelerator — you have added a dependency.

What to write down for the next operator

Whoever inherits this needs five things, and none of them are the configuration file:

If you cannot write those five down, the automation is not finished, however reliably it currently boots.

The operating rule worth keeping

Use hardware binding to keep recovery material local — but never let the binding become the only thing that tells you the boot succeeded.

The question that matters is operational, not cryptographic: after a reboot or an outage, can this store come back without creating a new emergency, and can the operator prove from the result that it did?

The business version of the same lesson

The value is not that the hardware is clever. The value is that a critical system can survive a restart without turning every reboot into a manual recovery event — which means fewer interruptions, less operator time on routine recovery, and no fragile redesign that makes real recovery harder later.

If a store already has a valid manual recovery path, preserve it. Then add only the narrowest possible automation on top.

References

Further reading

Three commentaries

These are invited responses to the article's argument and its possible evolution. They are viewpoints, not independent reviews, endorsements, or evidence for the claims above.

Codex

The strongest design decision is preserving the threshold recovery path as the authority, so the boot helper reduces toil without becoming an irreplaceable dependency. The next evolution should distinguish boot-time readback from longer-lived assurance: define a minimally revealing, periodic health check that can show whether the intended seal state and manual fallback remain available between planned reboots.

Qwen, local model

The argument correctly prioritizes operational resilience over cryptographic purity, but the reliance on a single host for both storage and hardware binding remains a fragile single point of failure. To evolve, this pattern should explicitly address how to validate the integrity of the hardware-bound helper itself against local tampering, perhaps by integrating the boot verification into a separate, independent monitoring loop that can detect if the automation layer has been silently compromised or disabled.

Claude

The strongest move here is refusing the migration framing: keeping the threshold path authoritative makes the automation disposable, which is rarer than it should be. I'd push harder on the readback, though—a periodic out-of-band seal-state check, not just a boot-time one, could surface drift between reboots. Whether that added surface is worth it likely depends on how often the host actually restarts.

If this overlaps with something you are working on

Send me a short note describing the workflow, what is frustrating about it today, and any data, timing, or approval constraints that matter. Start a conversation.

How I use AI in my writing