The problem rime solves

When an AI agent executes critical operations accessing funds, signing transactions, or managing sensitive data there is no trustless way to verify that its code hasn't been tampered with, that it's running on genuine secure hardware, or that its security posture is current

Challenges we ran into

The hardest bug was invisible to every unit test.

Our AgentRegistry contract calls Automata's DCAP verifier to validate TDX hardware quotes. We had 20 passing Foundry tests but the first real deployment silently failed every time with "execution reverted for unknown reason" and zero decodable error data.

The root cause: we had declared verifyAndAttestOnChain as view in our interface. Automata's real function is external payable it writes state. Solidity compiled our call as a STATICCALL, which the EVM silently reverts the moment the callee touches storage. No revert data. No useful error. Three different RPC providers, same result.

We diagnosed it by splitting the call: calling verifyAndAttestOnChain directly from an EOA (no STATICCALL restriction) succeeded; calling certify() from our contract failed every time. One word change removing view fixed it. We then made the mock's callCount actually increment, so this class of bug fails a unit test if it ever regresses.

Getting TDX attestation right on real hardware was the second challenge. The report_data mode (raw vs sha256), the exact byte offset of report_data in the quote (568), and whether Automata's verifier would actually accept a real quote none of these could be confirmed from documentation alone. We had to spin up a GCP c3-standard-4 TDX Confidential VM, pull a real quote via configfs-tsm, and verify each assumption empirically against the live on-chain verifier