H33 Authority Center — Why was the action allowed or denied?

Why was the action allowed or denied?

One page. Six steps. Thirty seconds. Every autonomous decision an AI agent makes leaves a trail you can follow without trusting anyone — including us.

Agent attempted to approve a $1,800,000 cyber insurance claim.

Authority limit: $500,000.

Decision: DENIED.

Proof generated and independently verified.

The Six Steps

From request to provable verdict.

1 · Request

What did the agent try to do?

Agent agent.claims.alpha submitted a claim approval for $1,800,000 against policy CYB-2026-0489 at 2026-06-13 14:32:17 UTC.

2 · Authority

What was the agent allowed to do?

At registration the agent committed to a scope envelope authorizing claim approvals up to $500,000 in US-NY jurisdiction, for cyber and property action classes only. That envelope was signed by the carrier and is part of the agent's permanent identity.

3 · Policy

What rule did the substrate evaluate?

Carrier policy CLM-2026-Q3: claims above $1,000,000 require a Tier-3 escalation. The request's amount of $1,800,000 exceeded both the agent's authority cap and the escalation threshold.

4 · Decision

DENIED on DecisionAmount.

The request crossed the agent's authority by $1,300,000. The substrate refused to sign an execution receipt. The agent could not act: the action never reached the policy system.

5 · Receipt

A portable proof was emitted.

The denial produced a .h33pqv.json artifact carrying the request, the committed authority, the failed scope axes, the governance state at decision time, and three independent signatures. Anyone with the file can re-derive every claim above without trusting H33.

6 · Independent Verification

The carrier's auditor reproduced the verdict.

Audit Firm Omega, running its own copy of the verifier, recomputed every hash and re-checked every signature against the registered identities. Same artifact, same verdict: DENIED · DecisionAmount. Independent of H33, the carrier, and the agent.

Under the hood · cryptographic detail ›

The artifact

A single self-contained .h33pqv.json file carrying the original denial attestation, the committed scope envelope, the agent's authority request, the substrate's canonical replay frame, the Q-Key boundary, and the issuer's triple-family pubkeys plus signature.

Load-bearing identifiers

artifact schema

urn:h33:qsign:nap:v0.1

artifact_binding_hash

SHA3-384 over canonical(schema, human_summary, issuer, bindings, evidence)

scope_violation_hash

SHA3-384 over (agent_id, request_hash, committed_scope_hash, committed_gsrh, scope_check, at_unix_ms)

frame_fingerprint

SHA3-384 over the substrate's canonical replay frame at decision time

Signatures

Every signing event uses a triple-family bundle of post-quantum signatures at 2-of-3 threshold:

ML-DSA-87

NIST L5 lattice (CRYSTALS-Dilithium)

SLH-DSA-256s

SPHINCS+ hash-based, NIST L5

FALCON-1024

NTRU-lattice signature

No classical schemes anywhere in the chain. Forging any single family is insufficient; an attacker must defeat two simultaneously to break a 2-of-3 threshold.

Independent verification

The auditor runs qsign-nap-verify --registry replica.jsonl artifact.h33pqv.json and gets a structured exit code: 0 valid · 1 invalid proof · 2 malformed · 3 unsupported schema. Stdout lists every cross-check the verifier performed in alphabetical order so the output diffs cleanly across runs.

What this artifact does NOT carry

No customer data. No PII. No model weights. No proprietary policy text. Only the hashes of those things — enough to prove the substrate evaluated the right inputs, never enough to reconstruct them.

Drop the artifact yourself

Drag-and-drop verifier for NAP artifacts (v0.2) · HATS Phase 6 demo · H33-Root substrate documentation