Every computation leaves a signed fingerprint.
HATP is a protocol that produces a cryptographic receipt for every computation — from the hardware the code ran on, through the hypervisor, the binary, and the result. Anyone holding the public key can verify it offline. The provider cannot forge it.
"We used Claude" is not verifiable.
When an AI provider tells you which model ran your inference, you are taking their word for it. Their logs are under their control. Their audit reports describe controls that existed at audit time — not what happened on the specific call your customer is asking about.
This is acceptable when the stakes are low. It is not acceptable when an AI model makes an automated credit decision, generates a medical recommendation, or signs a legal document. In those cases, the affected party has a right to know — and to verify independently — what ran.
EU AI Act Article 50 enforcement begins August 2026. DORA has been in force since January 2025. The question "can you prove, cryptographically, what ran?" is no longer theoretical.
A chain of signatures, starting at the metal.
HATP does not trust the operating system, the hypervisor, or the application to report honestly. It starts from hardware identity — the physical server's TPM chip, CPU serial, and firmware measurements — and builds a chain of cryptographic signatures upward to the individual computation. Each link signs the one below it.
Hardware fingerprint
At boot, the physical server's TPM 2.0 measures the firmware, bootloader, and kernel. The CPU serial and SMBIOS UUID are recorded by the fingerprint service running on the bare metal. This is the root of trust — it cannot be forged in software.
Hypervisor attestation
DE:SH (the Decent Edge secured hypervisor) is measured against its published manifest at first boot. The hardware fingerprint signs this measurement. If DE:SH is tampered with or replaced, the chain breaks here.
Binary admission
When a service binary (a Borz actor, an AI gateway process, or any other workload) is loaded, its SHA-256 hash is recorded and signed by the hypervisor. The binary is the exact code that will run — not a description of it.
Per-call dispatch receipt
Every individual invocation — an API call, an agent tool use, a compilation — produces a receipt. The receipt carries: the input hash, the output hash, the binary identity, the timestamp, and the chain back to the hardware. This is what HATP is known for.
Evidence pack
For a time range (a day, a sprint, a compliance period), receipts are bundled into a JSON-LD evidence pack. An auditor can take this pack offline, run the open-source verifier, and confirm every receipt in the bundle is genuine — without asking the provider for anything.
One receipt per call.
An HATP receipt is a signed JSON document. It is returned alongside the API response. The customer stores it. When an auditor or regulator asks "what ran?", the customer produces the receipt — no provider involvement required.
receipt_id Unique identifier for this invocation actor + msg The binary and handler that executed input_hash SHA-256 of the exact inputs — immutable proof of what was asked output_hash SHA-256 of the exact response — proves nothing was altered in transit hardware_ref Links to the L1 hardware attestation — ties this call to a physical machine sig (Ed25519) Signature by the service VM key, which is signed by DE:SH, which is signed by hardware {
"v": "1",
"type": "dispatch.complete",
"receipt_id": "rcpt_3f7b9a4e…",
"actor": "InferenceGateway",
"msg": "ChatCompletion",
"model": "claude-3-5-sonnet",
"input_hash": "sha256:a3f8…c12d",
"output_hash": "sha256:7b91…e44a",
"hardware_ref": "hatp:host:h0a3…",
"ts": "2026-05-26T14:30:00.187Z",
"customer_id": "cust_eu_9xk2…",
"chain": {
"l1_host": "hatp:l1:e0a4…9c87",
"l2_binary": "sha256:5b2c…d044",
"l3_vm": "hatp:vm:8f3a…"
},
"sig": "ed25519:9bvk3rqx4mwz…"
}
Verify with: hatp verify --receipt receipt.json --key keys.decentedge.com/pub.key
Anywhere a computation needs to be provable.
HATP is not a compliance checkbox. It is a primitive — the same way a digital signature is a primitive. These are the places where the primitive solves a real problem today.
AI inference audit
A company using Claude or GPT-4 for automated customer decisions needs to prove which model version ran, on what infrastructure, with which inputs. An HATP receipt captures all three — verifiable by the customer, not just by the provider.
Regulated financial decisions
A trading algorithm makes an automated position change. Under DORA Article 18, the bank must produce an ICT incident trail for the regulator. An HATP receipt chain covers every automated decision in the sequence, cryptographically.
Medical AI recommendations
A diagnostic AI suggests a treatment. The hospital must be able to prove which model version made the recommendation, that it ran on certified infrastructure, and that the output was not tampered with. HATP provides this without requiring the model vendor's cooperation.
Legal document generation
A contract summary or legal opinion drafted by an AI must carry provenance: which model, which version, which jurisdiction hosted the computation. An HATP receipt makes the provenance claim verifiable — not just asserted.
Pharmaceutical serialisation
Drug packaging lines under EU Falsified Medicines Directive require audit trails for every serialisation event. An HATP receipt ties each serialisation to the hardware that ran it — unbroken chain from silicon to regulatory submission.
Agentic AI pipelines
An AI agent makes dozens of tool calls — web search, code execution, database queries — to complete a task. Each tool call produces an HATP receipt. The full chain reconstructs the agent's reasoning, tool by tool, for any auditor or affected party.
Why not use what already exists?
Each existing approach solves part of the problem. None covers hardware identity, per-call granularity, and offline verifiability simultaneously on commodity hardware.
| Approach | What it proves | Offline verify | Per-call | Commodity HW |
|---|---|---|---|---|
| API access logs Provider (e.g. OpenAI) | A request was made Cannot prove inputs/outputs were not altered. Provider controls the log. Customer cannot verify independently. | ✗ | ✓ | ✓ |
| SOC 2 / ISO 27001 Third-party auditor | Controls existed at audit time Periodic, not per-call. Does not prove what ran for any specific inference. Audit is of processes, not of individual computations. | ✗ | ✗ | ✓ |
| Intel TDX / AMD SEV-SNP CPU vendor | Code runs inside a hardware-isolated enclave Requires specific CPU generation. Vendor-specific SDK. Does not produce a portable, auditor-readable receipt format. Hard to deploy at scale without specialised infrastructure. | ✓ | ✓ | ✗ |
| C2PA (content provenance) Open standard (Adobe, Microsoft, etc.) | A media artefact's origin and edit history Designed for content, not for compute. Does not cover the compute environment (what hardware ran the inference). Useful alongside HATP but not a substitute. | ✓ | ✗ | ✓ |
| HATP Decent Edge | Hardware identity + hypervisor + binary + inputs + outputs — all in one signed chain Currently Decent Edge infrastructure only. Open format; third-party implementations possible. | ✓ | ✓ | ✓ |
AI is making decisions that matter. The infrastructure hasn't caught up.
For the first twenty years of the internet, digital signatures solved the "who sent this message?" problem. HATP solves the "what computation produced this output?" problem — which is the question the AI era makes urgent.
When a credit score, a medical diagnosis, or a legal summary is generated by AI, the recipient has three needs: to know what model was used, to know the model was not tampered with or substituted, and to be able to prove this to a third party without relying on the provider's goodwill. Current infrastructure satisfies none of these.
HATP is the infrastructure layer that makes AI outputs provable in the same way that TLS certificates make websites trustworthy. Not a compliance add-on — a foundational primitive that should underlie every high-stakes AI deployment.
The window to build this into your stack is now.
DORA in force
Digital Operational Resilience Act covers EU banks, insurers, and payment firms. Article 18 requires ICT incident reporting with audit trails for automated decisions. HATP receipts are the audit trail.
EU AI Act Art. 50
High-risk AI system operators must disclose AI involvement and maintain logs of all automated decisions affecting natural persons. Per-call HATP receipts cover Article 12 logging and Article 50 disclosure simultaneously.
NIS2 enforcement ramp
National cyber authorities are ramping enforcement of NIS2 Article 21, requiring essential entities to maintain cryptographic audit trails for autonomous security decisions. HATP chains cover Articles 21.2(j) and 21.2(k).
See a real receipt in under 60 seconds.
Open the playground, compile a Borz actor, and run it against the EU-hosted backend. The response includes a real HATP receipt. Copy it, verify it offline with the open-source verifier.