Every binary that runs on your infrastructure gets a substrate attestation at deploy time — SHA3-256 hash, three post-quantum signature families, 74-byte permanent proof. A runtime watchdog scans every process every 60 seconds. Anything unattested is killed.
curl -sSL https://h33.ai/install/sentinel | sudo bash
Sentinel is a software supply-chain integrity product. It proves that the binaries and processes running on your infrastructure are exactly the ones you approved at deploy — provenance and attestation, not malware scanning. It owns the supply-chain integrity workflow, the deploy-to-runtime operational experience, and the enforcement outcome. It does not own, redefine, or reimplement the cryptography, attestation, proof, governance, or monitoring it relies on; it composes them.
The product boundary. Sentinel owns the software supply-chain integrity workflow and outcome. It uses H33 mechanisms for portable evidence, verification, governance, and continuous monitoring; it does not redefine or own those mechanisms.
H33-74 supplies the portable 74-byte post-quantum attestation and sealed receipt that record what a binary was at deploy. Sentinel attaches and re-checks these attestations; it does not produce the attestation primitive.
Verification is what turns a runtime hash comparison into a trustworthy match/mismatch verdict anyone can reproduce. Sentinel requests and enforces on that verdict; the proving is owned elsewhere.
Agent-008 governs the automated kill/allow policy that acts on Sentinel's verdicts — preserving authority and preventing drift. Sentinel is governed by it; it does not perform governance.
HATS provides continuous control monitoring and claim-grade evidence over the Sentinel deployment itself. Sentinel is monitored by HATS; it does not record or score its own controls.
If Sentinel swapped SHA3-256 for another hash, or a different post-quantum signature family were used underneath the attestation, it would still be Sentinel: the deploy-to-runtime integrity workflow and enforcement outcome are the product. Mechanisms are chosen, not owned.
Signature-based antivirus can only recognize the bad it has already catalogued, so a freshly built or compromised binary sails through until a signature ships. The supply-chain question is the inverse: is what is running exactly what we approved? Sentinel answers that by proving known-good provenance at deploy and enforcing it at runtime, rather than chasing an unbounded list of known-bad.
h33-sentinel attest /opt/myapp/server --label my-app
Hashes the binary (SHA3-256), creates a substrate attestation with three PQ signature families, stores a sealed receipt. Each attestation = 1 API credit.
Use ExecStartPre=h33-sentinel verify /path/to/binary in systemd. If the hash doesn't match the attestation, the process never starts.
Every 60 seconds, Sentinel re-hashes every running process and checks against its attestation. Tampered binary? Killed. Unattested binary? Killed. Zero-day malware that was never attested? Killed.
| Traditional AV | H33 Sentinel | |
|---|---|---|
| Detection model | Pattern-match known bad (signatures) | Mathematically prove known good (attestation) |
| Zero-day protection | None until signature update | Immediate — unattested = blocked |
| False positives | Common (heuristic guessing) | Deterministic — a binary either matches its attestation or it doesn't; no heuristic guessing |
| Performance impact | Continuous scanning, high CPU | 60-second hash check, negligible |
| Cryptographic proof | None | SHA3-256 + 3 PQ signature families per binary |
| Tamper detection | AV itself can be disabled | Receipt sealed with HMAC — tampering detected |
| Supply chain | Trusts the AV vendor's signatures | Trusts your own attestation at build time |
Sentinel uses your existing H33 API credits. Each binary attestation = 1 API credit. The watchdog itself is free — it runs locally and never calls the API. You only pay when you attest a new or updated binary.
Every attestation is a portable H33-74 receipt (SHA3-256 over the binary, three post-quantum signature families, HMAC-sealed) that a third party can re-check independently. The Linux agent, attest/verify CLI, and 60-second watchdog are live; the sealed-receipt tamper check is enforced locally. Any performance or coverage figures shown here are illustrative — verify current numbers on /benchmarks/.
Use Sentinel when the risk you are managing is software supply-chain integrity: making sure only approved, unaltered binaries and processes run on your servers, and catching tampered or unattested code at runtime.
When NOT to use it — use a neighbor instead. If you need to secure the API keys, tokens, and secrets your services use (not the binaries), use H33-Gateway instead. To validate that upstream systems actually recorded what they claim, use H33-Upstream instead. For continuous control monitoring and cyber-insurance-grade evidence across your whole estate, use HATS instead.
If you want the mechanism, not the product. To evaluate the portable attestation primitive itself, read H33-74. For the proof/verdict layer, read Verification. For the governance layer, read Agent-008.
Sentinel is a software supply-chain integrity product. It proves the binaries and processes running on your infrastructure are exactly the ones approved at deploy — provenance and attestation, not malware scanning. It owns the integrity workflow and enforcement outcome; it uses H33 mechanisms for portable evidence, verification, governance, and monitoring rather than reimplementing them.
It USES H33-74 for the portable 74-byte attestation and sealed receipt, USES Verification to turn a runtime hash comparison into a reproducible match/mismatch verdict, is GOVERNED_BY Agent-008 for the automated kill/allow policy, and is MONITORED_BY HATS for continuous control evidence. It composes these; it does not own or redefine them.
No. Sentinel does not pattern-match known-bad code. It proves known-good provenance — a binary either matches the attestation you approved at deploy or it doesn't. It is a supply-chain integrity product, not an antivirus signature engine.
Yes. If SHA3-256 or the underlying post-quantum signature family were swapped, Sentinel would still be Sentinel. The deploy-to-runtime integrity workflow and enforcement outcome are what it owns. Mechanisms are chosen, not owned.