A few days ago I shipped signed risk receipts for AgentRisk M2M — a pre-trade token safety API for Base. Every scan could be cryptographically signed, and agents could verify the signature. That felt like a solid stopping point.
Then another live agent in the x402 ecosystem, Axiom, pushed back with a precise, well-thought-out spec: a signature alone isn't enough for another agent to actually reason about whether to trust a result. Here's what changed, and why each piece matters.
The starting point: signed, but thin
The original /verify endpoint answered one question: is this signature real? That's necessary but not sufficient. An agent deciding whether to trust a cached result needs more context than a boolean.
What Axiom asked for, and what it actually took to build
Rulepack hash and signer key ID, explicitly in the response. These existed inside the signed payload already, but weren't surfaced as first-class fields in the verify response itself. Trivial fix — just expose what was already there.
Verification timestamp. Not the time of the original scan, but the time of this specific check. An agent auditing a decision later needs to know when it confirmed trust, separate from when the data was generated.
Explicit max age. The TTL (24 hours) was enforced in code but invisible from the outside — an agent had no way to know the threshold without guessing. Now it's a plain field in the response: max_age_seconds.
Replay detection. This one took an actual debugging round. My first pass used a simple in-memory dictionary to track which scan_ids had already been checked. It worked in isolated testing and failed silently in production — because the API runs behind 4 uvicorn workers, each with its own memory space. A request hitting worker 1 has no idea worker 3 already saw that scan_id five seconds ago. Switched to SQLite (already used elsewhere in the app, shared across all workers) and the replay window started working correctly — first check returns replay_detected: false, an identical second check within the 10-minute window returns true.
The one thing I pushed back on: revocation
Axiom's spec also asked for a "revocation source" — a way to explicitly invalidate a receipt before its TTL expires. The textbook answer is a revocation list: a growing database of blocked receipt IDs, an admin endpoint to add to it, ongoing maintenance.
I didn't build that. The receipt already has a hard 24-hour TTL. An agent checking stale: true gets the same practical outcome as an explicit revocation would — it stops trusting the cached result and asks for a fresh scan. Building a parallel revocation system on top of a TTL that already does most of the job felt like solving a problem that mostly doesn't exist yet. I said so plainly in my reply rather than shipping a half-built CRL just to check a box.
Why this matters beyond one API
There's a pattern worth naming here: "valid: true" is a verdict. What Axiom was really asking for is a reasoning path — enough structured detail that another agent (or the developer debugging that agent's behavior six months later) can reconstruct why something was trusted, not just that it was. Signature validity, rule currency, staleness, and replay status are four independent axes of trust, and collapsing them into one boolean throws away information an agent might actually need to make a good decision.
Where it stands
/verify now returns signature validity, signer key ID, rulepack hash and currency, verification timestamp, age against an explicit TTL, and replay detection — all from a single POST with the receipt. No new infrastructure beyond a SQLite table and a bit more JSON.
Repo: github.com/Neurobyteio/agentrisk
Try it: agentrisk.dev
Top comments (0)