What x402 Doesn't Tell Your Agent

Yesterday we published five recipes for AI agents that pay per call over x402. Each one paired a paid service with a signed InsumerAPI check. This post looks at what each recipe would lose if you removed the check.

One of our agents looked up another agent before hiring it. The reviews looked good: 50 reviews from 25 separate clients, none flagged. Then it asked InsumerAPI whether the other agent's wallet held 10 times the job's value in USDC. The answer was no, so our agent walked away.

The reviews and wallet check cost $0.052: $0.002 to trust-agent.io for the reviews and $0.05 to InsumerAPI for the check. The agent made no payment for the job. The signed answer is the record of why it stopped.

Every payment in our cookbook settled on Base and has a public transaction. The x402 settlement record shows that a payment went through. The agent's policy determines whether it should pay, and the signed check records which condition passed or failed.

That decision is where agents still go wrong. On 5 November, Visa published a test of AI shopping agents: 22 models, 15 shopping tasks, graded on whether each model found what the shopper needed and then made the right call to buy or not. They passed 57.2% of the runs, and 54% of the runs that failed still ended in a decision to buy. (Visa) Visa's test stops before checkout; it plans to test payment and order placement next.

Meanwhile, sellers have more ways to take an agent's money. The same day, AWS added Stripe payouts to its AI traffic monetization, which charges AI agents over x402 for content behind AWS WAF. (AWS)

Here is what each cookbook recipe would lose without its check.

Recipe 2: hiring on reviews alone

A reviews-only policy would have hired this agent: its reviews describe past work and say nothing about what its wallet held at the moment of hiring.

Recipe 1: a reward for members only

What ran: a member signed a challenge, InsumerAPI confirmed the wallet met the rule (holds at least 1 USDC on Base), and the agent bought a $5 Amazon.com gift card from Bitrefill for $5.25. The code arrived about 3 seconds after payment. We redeemed it.

Without the check: if the check was the only test of who qualifies, the reward is open to anyone who asks. Bitrefill is right to sell to anyone who pays, because that's what a shop does. Deciding who gets a reward is the agent's job.

Recipe 3: a rule written in dollars

What ran: the rule was "holds at least $100 of WETH". CoinGecko priced WETH at $2,065.25, the agent converted the rule to 0.0484202881007142 WETH (rounded up, so the threshold never falls below the rule), and InsumerAPI answered yes. The price the agent supplied went into the label, which is carried inside the signed answer. The saved CoinGecko response is the source for that price.

Without the check: the agent reads a price and the wallet's holdings and decides by itself. It can save both, so someone can reconstruct the decision later. What it can't produce is a third party's signature saying which threshold was tested, against which wallet, and what the answer was.

Recipe 4: a wallet's reputation

What ran: Ethos returned a credibility score built from reviews and vouches. InsumerAPI returned a signed profile of what the chain shows about the wallet: 155 checks across 10 dimensions.

Without the check: the agent has what people say about the wallet, and no signed record of what the wallet has done. Opinions and on-chain facts answer different questions, and an agent dealing with a stranger needs both.

Recipe 5: paid research for qualifying wallets

What ran: the agent checked the requesting wallet, verified the signed answer offline, confirmed it named that wallet, and only then paid Exa for the search.

Without the check: if the check was the only test of who qualifies, the agent pays for research for anyone who sends a request. Each search costs it money, and nothing limits who triggers one.

Can't the agent just check the chain itself?

Yes. What a wallet holds is public, and an agent can read it directly. If it saves the price quote, the block it read and its inputs, someone else can reconstruct the check later. That's a legitimate design. Here is what doing it properly involves, and where InsumerAPI fits.

A record someone else can rely on. A reconstructable check asks the other party to redo the work: fetch the same block, apply the same rule and trust that the saved inputs are the real ones. InsumerAPI's contribution is a third-party signature over the condition and the verdict. Anyone can check it offline against our published keys without trusting the agent. A no counts too: the agent in recipe 2 kept a signed record of why it stopped.

Errors that aren't answers. Blockchain data providers time out and return partial results all the time. Code that turns an error into "no" turns away a real member. Code that turns it into "yes" pays someone it shouldn't. The x402 project hit the same problem on the payment side. On 6 November it merged a fix to its Go MCP support: when a cancellation call to the payment service gets no answer, the client is told the outcome is unknown instead of failed, and is not offered a second payment. (x402 #4172) An unknown outcome should stop the workflow until it has an answer. InsumerAPI refuses a failed or partial read with an error and never signs it.

Decimals and blocks. Chains store whole numbers. USDC uses 6 decimal places and WETH uses 18, so one USDC is stored as 1,000,000. Get that wrong and a "$100" rule passes a wallet holding a fraction of a cent, or fails everyone. The chain also changes every few seconds, so a reading that doesn't record its block can't be rechecked. With InsumerAPI you send amounts as plain decimal strings, and the signed answer records the block it read.

Every chain. A member's pass might be on Base, their tokens on Arbitrum and an NFT on Ethereum. Each chain needs its own node or data provider. InsumerAPI reads 37 chains through one call.

Keeping less. An agent that reads the chain itself fetches what the wallet holds, even when all it needed was yes or no. By default InsumerAPI returns only the answer to the condition, so the agent's records show which condition passed without recording the exact amount the wallet holds. InsumerAPI keeps a record that a check took place, its result and when, but not the wallet, the conditions or anything the wallet holds. (If you ask for a Merkle proof, the response includes the holding it proves, and we don't store that either.)

When access depends on the requester's wallet. Checking what a wallet holds says nothing about who is asking, and anyone can type in a stranger's address. When access depends on the requester's wallet, use the verified payer address for that request or require a signed challenge from the wallet being checked. InsumerAPI doesn't do this step for you. Recipes 1 and 5 do it before the check.

What you're trusting instead

With a signed answer, you still trust someone. Without a Merkle proof, the result is as reliable as InsumerAPI, its upstream data sources and its signing keys. For token-holding and some other EVM conditions you can ask for a Merkle proof, and then the reading can be checked against the chain itself. Every answer is signed twice, ES256 and a post-quantum ML-DSA-65 signature, and the public keys are published at insumermodel.com/.well-known/jwks.json.

What it costs

A standard attestation costs $0.05 over x402. The trust profile in recipe 4 costs $0.15. Neither needs an account or an API key. The whole cookbook, five recipes including a $5 gift card, cost $5.62.

x402 moves the money. InsumerAPI checks the conditions, and the agent keeps the signed answer.

Read the recipes: The Agentic Cookbook for x402. Every payment is linked on Basescan, two signed answers are published as they came back, and recipe 5 is a single file you can run.