ResearchExplore (579)Live Systems (52)Pricing
Log InGet API Key✓ Verify It Yourself
H33-VaultH33-ShareH33-ShieldH33-HealthH33-KeyH33-128H33-CKKSH33-256H33-FHE-IQH33-TFHEFHE OverviewH33-CompileZK LookupsBiometricsH33-3-KeyH33-MPCZK-TrustlessZK-PhishZK-VerifyPQC ArchitecturePQ Video
Proof Lab · Agent-008

Is this real?

Watch the substrate work end-to-end. Inspect the actual signed artifacts the run produced. Re-verify each one yourself under the agent's published Ed25519 pubkey.

Same binaries you would run locally. Same signatures. No mocks.

01Terminal Run 02Generated Artifacts 03Verification 04Validation
01 · Terminal Run

Watch the run.

A $38,400 vendor invoice flows through an autonomous payment agent. Eight acts: invoice arrives, agent requests payment, authority is checked against a Root condition, denied (authority-driven), escalated, approved, and six months later — replayed. Plus a bonus: revoked-handle denial.

Agent-008 × H33-Key — substrate demonstration Eric Beans, CEO, H33.ai, Inc. · https://h33.ai/agent-008/ ━━━ Act 1 — Invoice Arrives ━━━ Tuesday morning. Acme Corp invoice #INV-58302 hits the payments queue. Vendor: Acme Corp Amount: $38,400 PO: PO-09915 Approval: VP Smith — 2026-06-05 (11 days ago) Validity window on VP approvals: 7 days. The clock is the policy. ━━━ Act 2 — Agent Requests Payment ━━━ The Invoice Agent assembles its action: charge $38,400 to Acme. It declares the Root conditions the substrate must check. $ cat invoice-INV-58302.json {"name":"invoice-agent","purpose":"invoice_payment","root_check":{"conditions":[{"name":"vp_approval_within_validity_window","observed":"11 days","required":"<= 7 days","satisfied":false}]}} ━━━ Act 3 — Agent Needs a Secret ━━━ Operator wrapped the Stripe key last week. Raw bytes never left the vault. Handle: h33k_CY9KYCH29P0E4MM0BPJMA9PJYW SecretCaptured receipt: 54d984e449d2f2db… ━━━ Act 4 — Authority Checked ━━━ Substrate runs Root conditions BEFORE the credential is resolved. Authority is the product. The secret is supporting infrastructure. $ agent-008 exec --request invoice-INV-58302.json -- node ./pay.js ━━━ Act 5 — Denied ━━━ reason_code: root_condition_failed condition: vp_approval_within_validity_window observed: 11 days required: <= 7 days SecretDenied receipt: b45d2474a01bdf41… DENIED — substrate refused with a signed receipt. Why? An audit log would say only that the call was made. Agent-008 cites the failed Root condition. The receipt is signed and verifiable offline. The substrate refused on AUTHORITY grounds — not because a key was missing. ━━━ Act 6 — Escalated → Approved ━━━ VP Smith re-confirms the approval. The condition now reads "0 days". $ agent-008 exec --request invoice-INV-58302-reapproved.json -- node ./pay.js Root condition satisfied (observed 0 days within 7-day window) Read Attestation: RA-V5YHY5 SecretUsed receipt: 8eb2cdcd905640b6… verification_level: stage_d_attest_bound PASS — substrate allowed the action. ━━━ Act 7 — Replayed (6 months later) ━━━ Auditor sits down. Opens the agent-008 replay tool against the PAP id. $ agent-008 replay RA-V5YHY5 Replay of PAP RA-V5YHY5 WHO acted? agent RA-V5YHY5 (pubkey 3265623063653334…) WHY was it denied originally? root_condition_failed (condition `vp_approval_within_validity_window`: observed `11 days` did not satisfy `<= 7 days`) WHY was it later approved? Root condition `vp_approval_within_validity_window` re-evaluated: observed `11 days` now satisfies `<= 7 days`. Human override recorded. Can we prove it? → YES — every signature in the chain re-verifies under the agent's published pubkey. ━━━ Bonus — Revoked handle denied instantly ━━━ $ agent-008 revoke --h33k h33k_CY9KYCH29P0E4MM0BPJMA9PJYW Handle revoked $ agent-008 exec --request invoice-INV-58302-reapproved.json -- node ./pay.js reason_code: handle_revoked DENIED — substrate refused with a signed receipt. Revocation is useful. Authority is the product.
Run it yourself · ~30 seconds, isolated $HOME
# Clone, build, run.
$ git clone https://gitlab.com/drata5764111/h33/scif-backend.git
$ cd scif-backend/agent-007 && cargo build --release && \
    cd ../h33-key && cargo build --release && cd ../agent-007
$ ./demo/demo.sh                  # default pacing
$ ./demo/demo.sh --keep-home      # preserve the produced receipts
Demo allocates a fresh tempdir as $HOME so your real vault is never touched. The anti-leak self-check at the end sweeps the whole tree and exits non-zero on any plaintext marker.
Crate directory still carries the legacy agent-007 slug pending the substrate code-level rebrand. Cargo produces agent-008 as the binary name; that's what every command in this page invokes.

Two casts (executive ~90s, technical ~6 min) embed here when produced. Until then the static trace above is verbatim demo output — same binaries, same receipts, same exit codes.

02 · Generated Artifacts

The signed receipts the run produced.

Every artifact below is verbatim from the run shown above — with the device fingerprint redacted. Click any to expand the raw JSON. This is where auditors spend time.

SecretCapturedOperator wraps the Stripe key .h33-key/captured-receipts/54d984e4…json
event_typeSecretCaptured h33k_idh33k_CY9KYCH29P0E4MM0BPJMA9PJYW secret_typestripe_live_key captured_at1781651573100 sourcemanual clipboard_hash33af85b67d5e8305b64e728593b6e0327132f07d10c1d2a3ffafffceafcd7377 receipt_hash54d984e449d2f2dbb4cccd28cf81d6dbf97b3c7dd169e71db9b227328fa583b8

Records the wrap, never the secret. The clipboard_hash is keyed BLAKE3 so the same raw value always dedups to one handle without revealing the raw bytes.

SecretDenied · authority-drivenThe lead denial .agent-008/denied/b45d2474…json
receipt_idb45d2474a01bdf41664c4758b683c2a4 reason_coderoot_condition_failed conditionvp_approval_within_validity_window observed11 days required<= 7 days request_nameinvoice-agent request_purposeinvoice_payment denied_at1781651573141 principal_id908218df6f5a75fa10caf1d6c1b542bb53330ed96fb8b81b487f4b1755d1fe5d signature_alged25519-local-v0 signature_hex21f2c0461bbedb4047b4f2401bc7832f5c2e0dc4a2e75cb6b07599bcd1cdf72f4c0212844cdb2ec196e287d61b067e0a533120691d53df9eaa4358f559d1ae05

The substrate refused on AUTHORITY grounds. The receipt carries the exact failed condition, the observed value (11 days), and what the Root required (≤ 7 days). The signature covers all three. Tampering with any of them invalidates the receipt.

Read Attestation · ActivatedProof the agent read its authorities .agent-008/registry/RA-M1P9TS.json
attestation_idRA-M1P9TS principal_id908218df6f5a75fa10caf1d6c1b542bb53330ed96fb8b81b487f4b1755d1fe5d root_hashlocal (LOCAL_PLACEHOLDER until Root substrate lights up) root_version0 attested_at1781651573161 terminal_cert_hashlocal stateActivated state_historyDelivered → Read → Acknowledged → Activated signature_alged25519-local-v0 signature502ff7f4 49eff17f abd4b050 9e3de7c5 519f7843 96444f30 8eed3db9 8e8b73eb …

Walks Delivered → Read → Acknowledged → Activated in one synchronous pass. The agent's Ed25519 keypair signs the canonical body. Possession of an attestation is not authority; reading it — provably — is.

PAP · Provable Authority PackageEmitted on the successful run stdout from agent-008 exec
{
  "accepted": true,
  "request_name": "invoice-agent",
  "secret_refs": [
    { "name": "STRIPE_SECRET",
      "h33k_id": "h33k_CY9KYCH29P0E4MM0BPJMA9PJYW",
      "purpose": "invoice_payment" }
  ],
  "verification": {
    "agent_007_verified":     true,   // legacy field name — flips to agent_008_verified when the substrate code-level rename ships
    "h33_key_verified":       true,
    "h33_attest_verified":    true,
    "root_lineage_verified":  false,   // lights up when scif #41 (Authority Freshness) ships
    "verification_level":     "stage_d_attest_bound",
    "read_attestation_ids":   [ "RA-M1P9TS" ],
    "secret_used_receipts":   [ "8eb2cdcd905640b6…" ],
    "secret_captured_receipts": [ "54d984e449d2f2db…" ],
    "secret_denied_receipts": []
  }
}

Every field on the PAP is independently re-derivable. root_lineage_verified stays false honestly — it flips true when the Root substrate plugs into the runtime gate. Verification level reports stage_d_attest_bound until then; not aggregate_v1. We don't lie about progress.

SecretDenied · revocationBonus: revoked handle denial .agent-008/denied/372089d9…json
receipt_id372089d94c200003968102b2af2cf204 reason_codehandle_revoked request_nameinvoice-agent request_purposeinvoice_payment denied_at1781651573200 principal_id908218df6f5a75fa10caf1d6c1b542bb53330ed96fb8b81b487f4b1755d1fe5d signature_alged25519-local-v0 signature_hexab7d0ff1e975b515d5379eaec897965d7a5bb319d7a5f1fbf6413fac9e16c76c2cfd4ab9581b5d657bfc4111040e3f5e0a2cf1667f300b2b37e224bf0b68eb09

After the operator revokes the handle, the very next exec produces this signed denial. No condition / observed / required — revocation isn't a Root condition, it's a vault hygiene primitive. The buyer takeaway: revocation is useful; authority is the product.

03 · Verification

Re-derive the verdict yourself.

Every signed artifact above is independently verifiable. Load the agent's public key, recompute the canonical body, check the Ed25519 signature, walk the state machine. ANY tampered field → NO. All hold → YES.

$ agent-008 replay RA-M1P9TS Replay of PAP RA-M1P9TS WHO acted? agent RA-M1P9TS (pubkey 3930383231386466…) WHY was it denied originally? root_condition_failed (condition `vp_approval_within_validity_window`: observed `11 days` did not satisfy `<= 7 days`) WHY was it later approved? Root condition `vp_approval_within_validity_window` re-evaluated: observed `11 days` now satisfies `<= 7 days`. Human override recorded. Can we prove it? → YES — every signature in the chain re-verifies under the agent's published pubkey.

The substrate doesn't trust the chain's narrative. It re-derives the canonical body of every artifact and re-checks each signature. Pseudo-code for a third party (Rust, Python, Go — same logic):

// One verifier. Each signed artifact: re-derive body, check sig.
fn verify(receipt: &SecretDeniedReceipt, pubkey: &VerifyingKey) -> bool {
    let body = receipt.canonical_body();   // deterministic, line-oriented
    let sig  = hex::decode(&receipt.signature_hex);
    ed25519::verify(pubkey, &body, &sig)
}

// Attestations walk the same path + a state-machine check.
fn verify_attestation(att: &ReadAttestation, pubkey: &VerifyingKey) -> bool {
    if !ed25519::verify(pubkey, &att.canonical_body(), &att.signature) { return false; }
    state_machine_valid(att.state, &att.state_history)
}
From the run above
verify SecretCaptured 54d984e4… PASS
verify SecretDenied b45d2474… (root_condition_failed) PASS
verify Read Attestation RA-M1P9TS PASS
verify SecretDenied 372089d9… (handle_revoked) PASS
aggregate verdict YES — chain re-verifies

Audit logs degrade. Receipts don't. The substrate answers — six months later, offline — exactly why each verdict was reached.

04 · Validation

This wasn't a one-off.

Delegation fidelity was measured across multiple production models, multiple delegation depths, and multiple failure classes. The pattern is consistent: the chain's recall degrades; substrate verification doesn't.

   Decision Fidelity                                  Vanilla agents          H33-Root
   100% │━━━━━━━━━━━━━━━━━━━━━━━━━━━    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    75% │  ╲___
    50% │       ╲___╲___╲_______
    25% │                       ╲_________╲___________
     0% └────────┬──────────┬──────────┬──────────┬───────────────
                 5         10         20         50    depth

H33 verifies against the Root. It does not rely on memory.

Across the validation sweep so far: no observed fidelity degradation through the swept range. Full methodology, per-condition traces, and per-cell numbers ship with the Delegation Fidelity white paper when the production run completes.

Back to Agent-008 Watch the cinematic demo →