Abstract digital technology illustration for ERC-3668 CCIP Read for AI Agents: Gateway Trust and Offchain Evidence Tests

This article provides an independent engineering checklist for AI agents interacting with established Ethereum standards. All example controls and tests are proposed designs, not claims about deployed products.

A read protocol is not a proof of real-world truth

An AI treasury agent may need token metadata, credentials, or business evidence that is not economical to place onchain. ERC-3668, also called CCIP Read, specifies an OffchainLookup revert and a gateway callback flow. That gives client software a standardized way to obtain an offchain response and submit it to a contract for validation. It does not make the gateway’s facts correct by itself. The ERC was created on July 19, 2020, and explicitly leaves response verification to the contract implementation. Build your threat model around that distinction: the agent chooses a target contract, the contract names a gateway, and the callback decides whether the response can be trusted. The critical engineering question is not whether an HTTPS endpoint answered. It is whether the contract verified a response bound to the exact request and authorized interpretation.

Trace every hop and record its trust boundary

A disciplined test harness logs the original eth_call target, calldata hash, OffchainLookup sender, gateway hostname, callback selector, and response hash. Never assume an offchain response can be reused with a different contract or account. A compromised gateway may return a plausible object that describes an unrelated asset. A manipulated URL may also leak wallet context to a destination an agent did not intend to contact. The specification describes substitution parameters for sender and calldata, while client behavior varies by library. Implement a strict allowlist of gateway domains for money-moving workflows, and explain why each domain is needed. An AI model should never invent a new URL and then treat it as protocol-authorized evidence. Keep network logs sparse: the hashes and decision outcome are usually sufficient for audit without recording personal prompts.

Test callback binding rather than happy-path retrieval

Start with a valid response and then mutate one element at a time. Change the sender address; alter a byte of calldata; replay a response from another chain; substitute an expired data record; make the callback revert; return malformed bytes; and provoke a nested OffchainLookup. A safe client should reject mismatched sender context rather than blindly follow nested errors. The ERC explicitly discusses nested-call risks and warns against letting unrelated reverts appear to originate from the top-level contract. For each mutation record the expected revert and the actual result. A red status must stop the AI agent before any transaction is proposed. This harness is more informative than a single green check showing that an offchain ENS-style lookup succeeded. The test is about provenance and request binding, not throughput.

Keep reading separate from spending authority

There is a material difference between using offchain data to display an account label and using it to approve a swap or release collateral. Ethereum’s oracle documentation explains why external information expands smart-contract applications, but it also describes oracle trust models. For financial actions, require an independent transaction policy with asset, amount, recipient, deadline, and maximum fee. The agent may read a CCIP response to inform a proposed action, but its result must not grant spending permission. When a contract’s eth_call asks for offchain information, do not silently turn that request into a transaction-signing step. An operator can review a compact evidence summary and a simulation result. If either the evidence signature or the independent policy fails, the transaction should be blocked regardless of model confidence.

Measure freshness and failure as first-class outcomes

A gateway can be correctly authenticated yet stale. Define maximum age by evidence type rather than using one global timeout. A static name record and a time-sensitive collateral price require different acceptance windows. Run controlled delay tests at the edge of each window and verify what the client displays: stale data should be labeled stale, not upgraded into a current fact. Simulate DNS failure, gateway 429 responses, disagreement between two endpoints, and partial availability. Track error budgets separately for lookup failure, callback rejection, and user cancelation. Do not interpret temporary unavailability as a reason for the AI agent to guess values from training data. Ethereum’s broader oracle discussion makes clear that external inputs come with explicit trust assumptions, even when the blockchain execution itself is deterministic.

An evidence packet for security reviewers

A useful review packet contains the contract address and chain, gateway allowlist, original call hash, return-data hash, contract verification path, age limit, simulated transaction, and human approval status. Include a table mapping each mutation test to its result and a link to reproducible test code. Classify failures by whether an attacker could make the agent display a false fact, propose an unauthorized transaction, or only temporarily lose availability. Peer review should cover the smart contract and the client-side CCIP library configuration, because a secure callback can still be undermined by unsafe client defaults. This article proposes a security-testing method, not an assertion that a specific wallet or gateway is safe. The acceptance criterion is demonstrated rejection of malicious evidence under clearly stated assumptions.

Sources

Cover photo: A Chosen Soul / Unsplash. Examples are hypothetical tests, not market data or investment advice.