last-mile verification
verify intent before you sign
the semantic layer for trust infrastructure — complementing identity, provenance, and integrity.
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.
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 ← 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
status: private beta (details).
1seal is designed to perform semantic verification immediately before signing or authorization:
- 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. 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
public work follows coordinated vulnerability disclosure (cvd). every entry below links to upstream artifacts.
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?