1sealsemantic last-mile verification

document · §1 the gap

The signature was valid. The provenance was clean. The thing you signed was wrong.

Across different systems the same failure shows up. Each verification layer answers its own question correctly. Their checks do not, by themselves, answer the intent question: does this match what I meant?

1.1

What existing tools verify

Each check answers a bounded question; configured policy can overlap with intent checks. Which checks are required depends on the deployment.

layercatchesmisses
identityPKI · Fulcio · SPIFFEimpersonation, unsigned contentlegitimate signer, wrong payload
integritydigests · Merkle · Rekorbit-flips, modification after signingbytes that were already wrong
provenanceSLSA · in-toto · GUACbuild tampering, missing attestationscorrect provenance, manipulated content
authorizationOPA · Cedar · Regopolicy violationspermitted action on the wrong target
1.2

The gap: semantic verification

Checking that the payload matches the stated intent — not that it is signed by the right entity, came from the right place, or is permitted in general. Historically identity plus integrity looked sufficient. Pipelines changed; the bottleneck moved to intent.

worked example · container signing
CI builds an image and produces digest D_ci. The operator approves “sign image X from repo R at commit C”. An illustrative pre-sign control would check three local invariants: digest == D_ci, repo == R ∧ commit == C, base ∈ allowlist. A mismatch or incomplete check requires an explicit policy decision; an operational override is not a verified match.

This assumes trusted sources for the expected digest, repository, commit and allowlist, with explicit authority to approve or change them. The approval and result must remain bound to the exact artifact and signing action; changed bytes require a new check. Unstated requirements are not covered.

This is a conceptual example, not a shipped implementation. Try the registry-only illustration or check current availability.

The full ladder — with the semantic layer highlighted — is on the front page.

1.3

How the gap is exploited

Five patterns. A valid signature alone need not prevent these patterns.

Payload substitution

The payload submitted for signing is not what the operator intended: artifact swapped, transaction parameters modified, config replaced.

Signatures verify what was presented, not what was intended.

Look-alike targets

Identifiers that resemble legitimate ones: address poisoning, typosquatting, homoglyphs.

The attacker's address is cryptographically valid.

Policy drift

Configuration changed without review: settings weakened, permissions widened, thresholds lowered.

The new config is signed by an authorised entity.

Context injection

Manipulating what influences the signing decision: agent memory, environment, metadata.

A signature authenticates signed data, not the truth of its claims. External context must be bound and checked separately.

Parameter tampering

Change between intent and payload: amount, recipient, timestamp.

The tampered version is what gets signed.

1.4

Scoping the gap

Semantic verification before commitment. Local invariants. Deterministic checks. Scoped evidence. Explicit non-goals. And operational protocols that keep the verifier useful without turning a scoped PASS into a broad trust claim.