HALTSEAL • HALT real actions. SEAL the evidence.

Verifier → Permit → Fail‑Closed Gateways

Block real actions (egress / privileged I/O / accelerator dispatch) until a verifiable, scoped, expiring permit is installed at a non‑bypassable gateway — with audit‑ready receipts.

Updated 14 Feb 2026 • Public‑safe draft

Why now Security boundary

Model output becomes action

Agentic systems create “allow‑by‑default” failure modes under drift, misconfig, or bypass. HALTSEAL enforces pre‑action control.

The posture Fail‑closed

No permit, no side effect

Missing/stale/unverifiable prerequisites → HOLD/DENY and the action is blocked at non‑bypassable chokepoints.

Architecture (3 control primitives)

Simple to explain. Hard to bypass.

Download deck (PDF)
1Verify‑to‑Activation

Freshness + inclusion + consistency

Runtime validates that the committed deployment logic is included under a current signed head and that the log evolved append‑only.

2Permit‑before‑Action

Mint only after PASS

On PASS, mint a short‑lived permit bound to audience (agent/tenant/mission), record a receipt, and require it at execution time.

3Fail‑Closed gateways

Enforce at chokepoints

Gateways require a valid permit identifier before network egress, privileged I/O, or accelerator dispatch — otherwise fail closed.

Where enforcement lives

Non‑bypassable chokepoints. Pick one for a pilot.

Control pointsNon‑bypassable
  • Kernel egress / dispatch intercept (syscall paths, cgroups/eBPF, network gateways)
  • Driver path (queue/doorbell before device or accelerator action)
  • Firmware / microcode (before dispatch)
  • Hypervisor intercept (VM‑exit / egress gateway)
Security invariantsTested
  • Fail‑closed default: missing permit → DENY
  • Revocation overrides allow (immediate + provable)
  • TTL enforced (short‑lived permits)
  • Bypass attempts (loopback/proxy) deterministically denied

The 60‑second proof

What we show in the meeting — optimized to earn the security‑attended deep dive.

1
No permit → DENY (fail closed)
2
Bypass attempt (loopback/proxy) → DENY
3
Verifier mints permit → permit installed
4
TCP/UDP egress → ALLOW (in scope)
5
Revocation overrides allow → DENY
6
TTL expiry → DENY

Meeting outputs

A short report plus machine‑readable receipts (e.g., JSONL) and readable deny reasons — designed for Security review.

Buyer‑run Pilot (30 minutes, self‑serve)

Run a fail‑closed gateway locally. No meeting. No uploads. Outputs a portable evaluation bundle + DSSE signing request for an identity‑anchored report.

  • Deterministic dispositions: PASS / FAIL / HOLD with stable reason codes.
  • Fail‑closed semantics: missing/unverifiable prerequisites block side effects.
  • Portable evidence: receipts (JSONL) + summary report for internal procurement/security tickets.

Pilot outputs you can attach to a Jira ticket: Conformance Pack .zip + receipts .jsonl + DSSE signing request .signing_request.json.

Download Pilot‑in‑a‑Box Verify offline (/verify) Verify procurement kit

Design partner pilot (6–12 weeks)

Start with one gateway (egress or dispatch). Prove non‑bypassable control + receipts. Expand after.

Schedule a 30‑minute technical deep dive (Security present)