last-mile verification

verify intent before you sign

the semantic layer for trust infrastructure — complementing identity, provenance, and integrity.

17 published CVEs (incl. Sigstore, TUF, Cert-manager, Chainguard) 14 security PRs (incl. prometheus ~62k* and google/certificate-transparency-go)

Intent → 1seal → ✓ PASS → Sign & Execute
                 │
                 └─ ✗ FAIL → Blocked (with reason code)

the problem: what you intend ≠ what gets signed

the most dangerous attacks don't break your signature. they make you sign the wrong thing.

🔴 the attack (semantic gap):

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 compromise

this is payload substitution. the signature is cryptographically perfect. the provenance is clean. the artifact is wrong.

🟢 with 1seal (pre-sign check):

Payload: "deploy from attacker-registry.io"
1seal:   registry not in allowlist → BLOCKED
         "registry mismatch: expected approved-registry.io"

Signature: ❌ never happens
Result: 🛡️ attack prevented

1seal compares payload against local invariants—your allowlists, bounds, schemas. mismatch triggers block before signing.

explore the semantic gap →

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

see all 6 domains →

where 1seal fits in the trust stack

┌─────────────────────────────────────────────────────┐
│  layer 5: authorization                             │
│  "is this action permitted?"                        │
│  (opa, cedar, rego)                                 │
├─────────────────────────────────────────────────────┤
│  layer 4: semantics              ← 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)                     │
└─────────────────────────────────────────────────────┘

1seal doesn't replace sigstore or slsa. it 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 1seal does

1seal is designed to perform semantic verification immediately before signing or authorization (private beta):

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 sign, before you sign it.

operational safety protocols

security controls must include brakes. a verification layer that breaks production is worse than no verification at all.

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.

read full protocols →

17 published CVEs

all public work follows coordinated vulnerability disclosure (cvd). published across sigstore, tuf/go-tuf, chainguard, cert-manager, and spicedb ecosystems.

want to see how findings are found? method (deterministic, reproducible).

see full CVEs →

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?

project status professional services contact