Attestation Trail

The Trust Problem

When an AI agent executes a trade, who proves it followed the rules?

• Software logs can be tampered with by operators
• Database records can be modified after the fact
• API audit trails depend on the integrity of the logging service

ZeroCopy produces hardware-attested evidence — signed by the Nitro Enclave itself, not by any software layer the operator controls.

Every 5 seconds (and on every sign request), the enclave generates a Nitro Attestation Document containing:

Attestation Document Fields

| Field | Description | |-------|-------------| | PCR0 | SHA-384 hash of the enclave image (code + config). Proves exactly which code was running. | | PCR1 | Hash of the Linux kernel inside the enclave. | | PCR2 | Hash of the application inside the enclave. | | Timestamp | Monotonic enclave clock. Cannot be set by the parent instance. | | User data | Application-specific payload (e.g., the hash of the signed transaction). | | Certificate | Signed by the AWS Nitro Attestation PKI (root of trust). |

Verification Chain

1AWS Nitro Root CA
2  └── Regional Intermediate CA
3        └── Instance Attestation Certificate
4              └── Enclave Attestation Document
5                    └── PCR0 = sha384(your_enclave_code)

Anyone can verify the attestation document against the AWS Nitro root certificate. No trust in ZeroCopy required.

Beyond the attestation envelope, each signing operation produces a policy evaluation record:

1{
2  "request_id": "req_8f3a2b1c",
3  "timestamp_us": 1712534400000000,
4  "payload_hash": "sha256:3a1f...9c2d",
5  "rules_evaluated": [
6    { "rule": "notional_limit", "result": "pass", "value_usd": 4200.00 },
7    { "rule": "rate_limit", "result": "pass", "rate": 42, "limit": 100 },
8    { "rule": "contract_whitelist", "result": "pass", "address": "0x7a25..." },
9    { "rule": "time_window", "result": "pass", "preset": "crypto_24_7" },
10    { "rule": "ai_risk", "result": "pass", "score": 0.12, "threshold": 0.85 }
11  ],
12  "jitter_us": 41.2,
13  "circuit_breaker": "normal",
14  "signature": "0x3044...",
15  "attestation_hash": "sha384:7b2e..."
16}

This record is signed by the enclave and included in the attestation document's user data field. The operator cannot modify it without invalidating the attestation signature.

SEC 17a-4: Record Retention

SEC Rule 17a-4 requires broker-dealers to retain records in a non-rewritable, non-erasable format ("WORM" — Write Once, Read Many). The attestation trail satisfies this:

• Non-rewritable: Attestation documents are signed by hardware. Cannot be modified.
• Non-erasable: Hash-chaining makes deletion detectable. Documents can be replicated to immutable storage (S3 Object Lock, on-chain anchoring).
• Retrievable: Each document is indexed by timestamp and request ID.

MiCA (EU): Operational Resilience

The Markets in Crypto-Assets regulation requires "adequate internal control mechanisms" for custody providers. The attestation trail provides:

• Proof of policy enforcement at the signing layer
• Continuous health attestation (every 5 seconds)
• Hardware-verified uptime and configuration integrity

Independent Verification

Any party (auditors, regulators, counterparties) can verify attestation documents:

1# Verify a specific attestation document
2zcp verify-attestation ./attestation_2026-04-07T14:30:00Z.cbor
3
4# Verify the full chain integrity
5zcp verify-chain --from 2026-04-01 --to 2026-04-07

No access to the enclave or ZeroCopy systems is required. The verification is purely cryptographic — trust the math, not the operator.