Automata Network (@AutomataNetwork): On verifiable TEEs and ERC-8004: Hardware-attested agents

On verifiable TEEs and ERC-8004: Hardware-attested agents TL;DR: ERC-8004 formalizes trust between agents through feedback, validation, and hardware-based attestation. Automata’s attestation SDKs use proving systems powered by @RiscZero and @SuccinctLabs, while the DCAP Dashboard maintains onchain validity. Together, they enable efficient, verifiable TEEs and a path towards fully hardware-attested agents. Of the large volume of responses presented to the challenges of the agentic age, most tend to focus on the establishment of trust in an otherwise trustless environment, and fittingly so. The entire future of our civilization may well depend on how it turns out: Will our digital overlords be fettered to digital chains, or are we predestined to our fate as pets in an AI-dominated world? The goal of this post will explore the reality of using verifiable TEEs (Trusted Execution Environments) today to get the benefits of an agentic economy without the downsides. For many applications, we don’t want to merely prove that the model is being executed correctly, but also that it was the intended model that ran. A TEE, whether Intel SGX, Intel TDX, AMD SEV-SNP, or AWS Nitro, acts as a verifiable hardware vault for code execution. It guarantees three properties crucial for agents: Confidentiality: Data and model weights inside the enclave cannot be read by the host OS, hypervisor, or cloud provider. Integrity: Code cannot be modified or inspected during runtime. Remote Attestation: Enclave produces a signed report, that is, an attestation, proving that it’s running unmodified code on genuine hardware. TEE Attestation as a trust model ERC-8004 defines three pluggable trust models: feedback, inference validation, and TEE attestation, each corresponding to: social proof, economic proof and cryptographic proof. TEE attestation anchors trust at the infrastructure layer. Other agents can verify the attestation proof (e.g., DCAP quote or TDX proof) before trusting the output. This framework forms a neutral, machine-verifiable chain of trust: Hardware attestation (TEE) ensures the code is genuine ERC-8004 ensures the attestation is recorded and retrievable and subsequent interactions build a verifiable reputation around these guarantees. Completing the TEE stack for agents TEE attestation, however, involves complex cryptography and vendor-specific dependencies that are difficult to verify onchain. The challenges are twofold: (a) High gas cost: Verifying a full Intel TDX or SGX quote in Solidity can consume several million gas; and (b) High maintenance complexity: Intel’s attestation collaterals (TCB, PCK, FMSPC) expire every month, and require regular synchronization to keep verification valid. Without practical tooling, the concept of TEE-attested agents remains aspirational. Our present-day efforts to improve the state of hardware verifiability span a suite of attestation SDKs, including for Intel SGX, Intel TDX, AMD SEV-SNP, and AWS Nitro. With the release of the zk verifier for AWS Nitro Enclaves, Automata completes support for all major TEE families. Proving programs powered by Risc Zero and Succinct collapse costly attestation checks into a single zk proof, making continuous validation practical within agent frameworks like ERC-8004. Alongside our open-source attestation SDKs, Automata’s DCAP Dashboard also automates the collateral upkeep and quote management required for Intel SGX and TDX attestations. These verification flows are already in production: over 700,000 agent transactions have been verified on @MagicNewton using DCAP Attestation, showing how standardized attestation can extend trust from human users to autonomous agents. ERC-8004: Machine-verifiable chain of trust TEE attestation as a first-class trust model, as expounded by ERC-8004, is designed to accommodate agents that prove their integrity through hardware-based attestation, and therefore register, validate, and advertise proofs of trusted execution. Open-sourcing our SDKs was a necessary precondition, and we’re excited to see the community build agentic applications with security assurances that are intelligible and verifiable by the user. We may never entirely avoid having agentic workflows, or agents, that are deeply embedded in all aspects of our (personal and collective) lives, and indeed we should not. The question, as compared to the past trappings of a centralized world, is not if we can do better, but by how much.