Executive Summary
This claim is filed as a dependent of Claim 8 (Multi-Gate Validator Bootstrap), narrowing the independent claim to the specific mechanism used for its image-integrity gate. Rather than trusting that a registry pull was authenticated and therefore safe, the fleet agent independently fetches a pinned digest manifest from the fleet controller over an HMAC-authenticated channel, inspects the actual content digest of every image it has pulled locally, and compares each one against the manifest entry for that image and tag.
Any mismatch is a hard failure - the node refuses to proceed to service startup, and a separate direct-deploy endpoint independently re-checks the pulled digest against an expected value on every image-push request, refusing the deploy outright on mismatch rather than logging a warning and continuing.
Problem Statement
A validator node that can successfully pull a container image from an authenticated registry has only proven that the registry authenticated the pull request - not that the specific image content matches what the fleet operator intended to ship. Tag-based deployment (e.g. "latest" or a mutable version tag) is a well-known supply-chain weakness: a compromised registry, a compromised CI pipeline, or a mid-flight tag repoint can silently substitute a different image behind the same tag a node believes it is running.
Why Registry Auth Alone Is Insufficient
- Registry auth proves access, not content: A credentialed pull can still return a poisoned image if the registry or upstream build pipeline is compromised.
- Tag mutability: Without digest pinning, the same tag can silently resolve to different content over time.
- Soft-fail scanning: Many image-scanning tools log or alert on a mismatch without blocking the deployment from proceeding.
Technical Architecture
Two Independent Enforcement Points
| Enforcement Point | Mechanism | On Mismatch |
|---|---|---|
| Bootstrap-time gate | Fetch a pinned digest manifest (image tag → expected content digest) over an HMAC-signed request; compare against each locally-pulled image's actual repo digest | Abort the boot sequence before any service starts; consensus never comes up on an unverified image |
| Per-deploy push endpoint | An operator-triggered image push independently verifies the pulled digest against the digest supplied in the deploy request itself | Reject the deploy request outright with a digest-mismatch error; the running node is left untouched rather than restarted onto unverified content |
Production Fail-Closed Default
If the fleet controller endpoint that serves the pinned-digest manifest is unreachable in a production environment, the gate does not silently pass - it is treated as an inability to verify, which is itself a failure. The gate only passes by default in the specific case where the controller returns an empty pinned-digest set (nothing has been pinned yet for that deployment), which is a distinct, explicit condition rather than a network-failure fallback.
Relationship to Claim 8
This gate is one of the four independently-tracked checks composed in Claim 8's multi-gate bootstrap; this claim covers the digest-verification mechanism itself as a standalone, separately practicable invention.
Prior Art Differentiation
Generic image-scanning and admission-control tooling (e.g. registry-side vulnerability scanners, Kubernetes admission webhooks) typically evaluate an image at push or admission time and often support soft-fail (warn-only) modes. JIL Sovereign's gate is distinguished by (1) re-deriving trust from a locally observed content digest rather than a registry-reported one, (2) fetching the expected-digest manifest over an independently authenticated channel rather than trusting the registry's own metadata, and (3) treating verification failure - including inability to verify at all - as an unconditional hard stop for a validator node specifically, where the cost of running a compromised consensus-critical binary is materially higher than for general workloads.