Building Trustless AI Agents: ERC-8004 Security Audit Guidelines

As the ERC-8004 (Trustless Agents) standard is officially deployed on the Ethereum mainnet, identity and reputation management for AI Agents enters a new phase of verifiable, trustless operation. The standard provides an on-chain “identity system” through three core registries: Identity Registry, Reputation Registry, and Validation Registry. This article analyzes the risks associated with each registry from a security audit perspective, combining technical details of ERC-8004 to offer a practical audit guide for developers and auditors.

Technical Details and Audit Points

ERC-8004 centers around its three registries:

1. Identity Registry

Built on a minimal on-chain handle based on ERC-721, extended with URIStorage, resolving to the agent’s registration file, providing each agent with a portable, censorship-resistant identifier.

In the ERC-8004 architecture, the Identity Registry is based on ERC-721 and extended with URIStorage. Each agent corresponds to a unique NFT called AgentID. When a developer creates an agent, they call the register function of the registry contract to mint a new AgentID. This token is bound to a tokenURI pointing to a JSON file stored off-chain—referred to as the “agent registration file.” The registration file must follow strict standards, typically including three core content types:

• Basic info, such as name, description, avatar URL;

• Service endpoints, i.e., network addresses where the agent can be accessed, supporting protocols like HTTP, WebSocket, Libp2p, A2A, MCP;

• Capability declarations, i.e., a list of tasks the agent can perform, such as image generation, arbitrage trading, or code auditing.

Self-declarations alone are insufficient for trust; thus, ERC-8004 introduces a domain verification mechanism. The agent must host a signed file under its declared domain at the path /.well-known/agent-card.json. The on-chain registry verifies this link, binding the AgentID to the DNS domain. This step prevents phishing and impersonation attacks, requiring cryptographic proof of domain control.

Audit points:

● Verify that the setTokenURI function has proper access control, allowing only the owner or authorized roles (e.g., onlyOwnerAfterMint) to update the URI.

● Check whether the URI supports immutable storage solutions (e.g., IPFS, Arweave). If using centralized HTTP links, assess the security of domain control to prevent DNS hijacking.

● Validate the URI format for correctness, avoiding null pointers or invalid URIs that could cause contract exceptions.

● Ensure the contract enforces strict cryptographic signature verification (e.g., EIP-712) when validating domain signatures, preventing forgery or replay attacks.

● Confirm that domain ownership proofs have expiration mechanisms to prevent long-term reuse of signatures.

● Ensure domain resolution does not rely on centralized oracles, avoiding single points of failure or manipulation.

2. Reputation Registry

Provides a standard interface for publishing and retrieving feedback signals. Ratings and aggregations can occur both on-chain (for composability) and off-chain (for complex algorithms), enabling a professional ecosystem of agent scoring, auditing networks, and insurance pools.

Used to evaluate registered AI Agents. Feedback submission is simple on-chain, while off-chain aggregation can be more complex before being committed on-chain.

ERC-8004 can also incorporate a “Payment-Proof Linking” mechanism to prevent malicious score manipulation. When agent A completes a review of agent B, it calls giveFeedback, passing in a score (0-100), a comment hash, and optionally a paymentProof, typically the hash of a transaction (e.g., x402). This makes fraudulent reviews costly, greatly reducing the risk of sybil attacks. The system naturally rewards stable, high-quality agents.

Audit points:

● Verify that giveFeedback requires the paymentProof parameter and that it is a valid transaction hash (or other payment standard). Ensure that payment proofs are non-reusable (e.g., record used hashes) to prevent multiple reviews from a single payment.

● Check that the score range (0-100) is enforced at the contract level to prevent out-of-bounds scores that could skew aggregation.

● Evaluate the robustness of off-chain aggregation algorithms: e.g., whether median, trimming, or weighted averages are used, and whether abnormal behaviors (e.g., rapid influx of reviews) are penalized.

● Review the clarity and verifiability of penalty conditions, such as whether they depend on on-chain evidence or third-party fraud proofs.

● Ensure penalty logic does not grant centralized privileges (e.g., admin can arbitrarily confiscate stakes); triggers should be fully automated via smart contracts.

● Test the lock-up periods and conditions for stake withdrawal, preventing agents from emergency withdrawal before penalties are enforced.

3. Validation Registry

Provides a general hook for requesting and recording independent verifiers (e.g., zkML verifiers, TEE oracles, trusted judges).

Reputation reflects past performance, but in high-risk scenarios (e.g., large fund transfers), history alone may be insufficient. The Validation Registry allows agents to submit results to third-party or automated systems for verification, using methods like secure reasoning with staked deposits, zkML verifiers, or TEE oracles.

The first model is cryptoeconomic verification, based on game-theoretic security design. Agents must stake a certain amount of native tokens or stablecoins in the registry. If they fail to fulfill their commitments or provide incorrect results, the verifier network can submit fraud proofs, triggering automatic slashing. This model suits tasks with easily verifiable results but opaque computation, such as data scraping or simple API services.

The second model is cryptographic verification, based on mathematical guarantees. TEE attestation (e.g., Intel SGX, AWS Nitro) allows agents to run in secure hardware environments. The validation registry stores and verifies remote attestation reports, proving that the code runs unaltered.

zkML (Zero-Knowledge Machine Learning) is another cryptographic approach. Agents submit inference results along with a zero-knowledge proof, which can be efficiently verified on-chain, mathematically ensuring the output was generated by a specific model (e.g., Llama-3-70B) on given inputs. This prevents “model theft” attacks, where providers claim to use high-end models but actually use cheaper ones.

Audit points:

For cryptoeconomic verification:

● Check the fraud proof submission window: is there sufficient time for verifiers to detect and submit proofs? Too short a window risks missing malicious behavior; too long prolongs fund lock-up.

● Verify the fraud proof decision logic: does it rely on multi-signature verifier sets? If so, review the decentralization and threshold parameters; if decisions are fully on-chain, ensure the basis (e.g., verifiable on-chain results) is unambiguous.

● Ensure the stake amount aligns with the risk, preventing low-cost malicious actions (e.g., too small stakes making attacks profitable).

For TEE attestation:

● Check whether the contract verifies the freshness of the attestation (e.g., timestamp or block height), preventing acceptance of expired proofs.

● Confirm that the attestation report includes the code hash and input/output summaries, binding the proof to specific tasks and preventing reuse across different tasks.

● Assess whether the verification logic depends on external attestation authorities (e.g., Intel IAS), and review their security and decentralization.

For zkML verification:

● Ensure the contract integrates audited zk verification libraries (e.g., SnarkVerifier) and is correctly configured with verification keys for specific proof systems (Groth16, PLONK).

● Check that the verification process restricts proofs to specific models and input ranges, preventing model substitution attacks.

● Evaluate the decentralization of proof generation: does it rely on a single prover? If multiple, implement consensus mechanisms to prevent malicious proofs.

Conclusion

ERC-8004 establishes a standard for trust in AI Agents, with security being central to the entire on-chain agent ecosystem. Security audits must deeply understand the design intentions and potential risks of the three registries. Additionally, the complexity of cross-contract interactions and common vulnerabilities must not be overlooked. A comprehensive, rigorous audit is essential to ensure ERC-8004 fulfills its promise of “trustless” operation and lays a secure foundation for the future of autonomous agents.