last-mile verification
verify semantic integrity before commitment
1seal formalizes the deterministic discipline behind our public trust-infrastructure security research into pre-commit checks for signing, deployment, releases, and other high-trust operations.
LMV is the draft specification/model behind this work. 1seal is the private-beta toolkit for applying it.
Declared intent → 1seal → ✓ PASS → Commit
│
└─ ✗ FAIL → Blocked (with reason code)how the pieces fit
LMV is the draft model for checking declared intent against payload before commitment.
public 1seal/verifier repository is a minimal offline DSSE/JCS evidence verifier. it is not the full semantic LMV verifier.
semantic/accountable LMV verifier remains private/pre-release.
1seal is the product toolkit for applying semantic last-mile checks to real receipts, releases, SBOMs, provenance, transactions, and other high-trust commitments.
the problem: what you intend ≠ what gets signed
the most dangerous attacks don't break your signature. they make you sign the wrong thing.
You intend: "deploy container from approved registry"
Payload has: "deploy container from attacker registry"
Identity: ✅ valid signer
Provenance: ✅ clean build chain
Integrity: ✅ bytes match
Result: 💣 supply chain compromisethis is payload substitution. the signature is cryptographically perfect. the provenance is clean. the artifact is wrong.
Payload: "deploy from attacker-registry.io"
1seal: registry not in allowlist → BLOCKED
"registry mismatch: expected approved-registry.io"
Signature: ❌ never happens
Result: 🛡️ attack prevented1seal compares payload against local invariants—your allowlists, bounds, schemas. mismatch triggers block before signing.
same gap, different manifestations
the semantic gap exists everywhere signing exists. attack patterns vary by domain.
container signing
the gap: digest substitution, base image swap, registry manipulation
example attack: ci artifact swapped between build and sign → malicious image signed by legitimate key
1seal check:
digest == ci_output_digest, base_image in approved_list
financial transactions
the gap: field manipulation, counterparty swap, amount tampering
example attack: counterparty account modified between approval and submission → funds to wrong destination
1seal check:
counterparty in verified_list, amount <= approved_limit
firmware updates
the gap: rollback attacks, device class mismatch, version manipulation
example attack: firmware downgrade to vulnerable version → cryptographic signature valid, device bricked or compromised
1seal check:
version >= current_version, device_class == expected
where 1seal fits in the trust stack
┌─────────────────────────────────────────────────────┐
│ layer 5: authorization │
│ "is this action permitted?" │
│ (OPA, Cedar, Rego) │
├─────────────────────────────────────────────────────┤
│ layer 4: semantics ← LMV │
│ (implemented by 1seal) │
│ "does this match intent?" │
│ (last-mile verification) │
├─────────────────────────────────────────────────────┤
│ layer 3: provenance │
│ "where did this come from?" │
│ (SLSA, in-toto, GUAC) │
├─────────────────────────────────────────────────────┤
│ layer 2: integrity │
│ "were the bytes tampered?" │
│ (checksums, Merkle trees, Rekor) │
├─────────────────────────────────────────────────────┤
│ layer 1: identity │
│ "who is this?" │
│ (PKI, Sigstore/Fulcio, SPIFFE) │
└─────────────────────────────────────────────────────┘LMV doesn't replace Sigstore or SLSA. 1seal implements LMV as the product layer that complements them. identity, provenance, and integrity are necessary but not sufficient. the semantic layer catches what they can't: the payload that's correctly signed but wrong.
what a 1seal PASS does not mean
a 1seal/LMV PASS is scoped.
it means the evaluated payload matched the declared intent under the configured invariants and available evidence.
it does not mean the action is ethical, lawful, safe, compliant, institutionally approved, socially legitimate, or generally trustworthy.
no layer's PASS should be silently consumed as another layer's PASS.
what 1seal does
status: private beta (details).
1seal is designed to perform semantic verification immediately before signing, deployment, release, execution, acceptance, or reliance:
- invariants: rules that define "what should be true" about a payload. allowlists, similarity checks, range bounds, schema conformance, freshness. similarity is a red-flag against a local baseline (contacts/allowlist/recent recipients); no baseline → off.
- verdict: deterministic pass/warn/fail with evidence bundle.
- offline-first: no network calls in verification path. your invariants are local.
- no llm: deterministic logic only. auditable, reproducible, explainable.
the goal is simple: catch the mismatch between what you intended and what you're about to commit to, before commitment.
operational safety protocols
security controls must include brakes. a verification layer that breaks production is worse than no verification at all. these protocols make the verifier operable under uncertainty and failure.
degraded mode policy
what happens when verification cannot complete? explicit fail-closed or fail-open with audit.
appeal and resolution
what if legitimate operations get blocked? time-bounded review with full audit trail.
invariant lifecycle
how do rules get created, updated, and retired? experimental → active → deprecated → retired.
error cost framework
how do you choose thresholds? domain-specific calibration based on C_fp and C_fn costs.
research foundation
1seal is grounded in public vulnerability research across trust infrastructure: certificate validation, transparency, signing, update security, attestation, and policy enforcement.
the same deterministic discipline used to validate these findings is being formalized as LMV: semantic last-mile verification before commitment.
public work follows coordinated vulnerability disclosure (cvd). every entry below links to upstream artifacts.
exact live counts hydrate from portfolio.json; the canonical crawlable totals live on /research/.
how findings are found: method (deterministic, reproducible).
selected examples (top by cvss where available):
current status
1seal is in private development with selected design partners. not yet available as a generally available product.
interested in design partner conversations or have questions about the research?