AI decision models
The new middle layer nobody has audited yet
A pattern is crystallising: an AI agent, mid-task, needs to know whether a counterparty is sanctioned, whether a vendor's SOC 2 claim is current, or whether a wallet has been flagged. Instead of a human fetching that answer, the agent buys a signed attestation per call — paying in stablecoin over x402, an HTTP 402-based micropayment flow settled on Base — and continues.
That is genuinely useful plumbing. It is also, right now, mostly unaudited plumbing. The chain gives you settlement and provenance. It does not give you truth, legal standing, or a control your auditor will accept. Those have to be engineered on your side.
This checklist is written for the team that has to sign off on that engineering. Each item is pass/fail. No partial credit, no vibes.
What an oracle is — and is not
A compliance oracle returns a machine-readable claim about a subject: a verdict, a schema version, an issuer, a timestamp, an expiry. Good ones sign it so you can verify it offline. Bad ones are a JSON endpoint with a nice logo.
What it is not: a legal opinion, a substitute for your own due diligence, or a defence you can hand a regulator on its own. "Blockchain-verified" is an architecture description, not a compliance argument.
Figure: Editorial context image from the source page (preview only; rights remain with the publisher) · Credit / further reading: github.com
The 12-point checklist
1. Attestation provenance
Pass: every response carries an issuer identifier (DID or address), schema version, issuance timestamp, expiry, and a signature your own service verifies against a pinned key — not against a key fetched from the same endpoint that served the claim.
Fail: you trust the TLS connection and call it verification.
2. Claim semantics
Pass: the schema is published, verdict values are enumerated, and there is an explicit unknown or insufficient data state that is structurally distinct from denied. Agents will collapse these into one bucket if you let them.
Fail: free-text verdicts, undocumented enums, or a boolean.
3. Freshness and revocation
Pass: maximum staleness is stated in the contract, there is a revocation or epoch mechanism, and your client rejects expired attestations before the agent ever sees them.
Fail: an attestation with no TTL, or a TTL you never check.
4. Payment integrity
Pass: you can cap price per call and per session, the payment path is replay-protected, and every payment maps to an idempotency key so a retried tool call cannot be billed twice. Payment receipts reconcile to response IDs in your ledger.
Fail: a retry loop inside the agent that pays again on timeout.
5. Settlement and key risk
Pass: you have written down your finality assumptions for Base, you monitor for reorgs beyond your threshold, and the payer key lives in a KMS or HSM with hard spend limits and no unlimited allowances.
Fail: a hot wallet with a funded balance and a permissive approval sitting in an agent's environment.
6. Fail-closed default
Pass: a missing oracle, a timeout, a signature mismatch, or a budget exhaustion all resolve to block or escalate to a human — never to allow. The default is encoded once, in the policy layer, not in the prompt.
Fail: the agent decides what to do when verification fails.
7. Tool-call hardening
Pass: the verification step runs in your service, outside the model's context. The model receives a boolean plus a signed evidence reference; it cannot read a JSON blob and reason its way to "looks valid". Tool arguments are validated against a schema before any paid call fires.
Fail: the attestation is pasted into the prompt and the model grades it.
Figure: HEXOPS original illustration inspired by the topic (not a copy of the source article imagery) · Credit / further reading: github.com
8. Data minimisation
Pass: you send a hashed or tokenised subject identifier wherever the issuer's schema allows. Nothing personally identifying is written to calldata, and logs redact the subject.
Fail: names, dates of birth, or document numbers in a transaction payload that is permanent and public.
9. Auditability
Pass: every decision record stores the request hash, response hash, issuer, verifier version, payment transaction reference, and outcome — retained for the period your regime requires, exportable without vendor cooperation.
Fail: evidence exists only in application logs with a 14-day retention.
10. Issuer and jurisdictional fit
Pass: you know who the issuer is as a legal entity, which screening lists or frameworks their claims map to, how often those lists refresh, and your own compliance function has signed off on that mapping.
Fail: nobody on the team can name the issuer's regulator or data sources.
11. Cost and latency budget
Pass: you have measured p95 latency and cost per call under realistic concurrency, set a circuit breaker at the budget ceiling, and alert on cost-per-decision drift.
Fail: unbounded spend, discoverable only when an agent loops on a flaky endpoint.
12. Exit plan
Pass: you can add a second issuer, the response format is portable (or trivially mappable), and the contract permits migration with data export.
Fail: one oracle, one proprietary schema, no export.
Scoring your run
Count the passes honestly, in writing, with the name of whoever verified each one.
- 12/12 — clear to ship on a regulated decision path.
- 9–11 — ship only in an advisory or human-in-the-loop mode, with each gap documented as a compensating control and an owner.
- 8 or fewer — do not let this touch a regulated workflow. Use it for internal triage only, behind a hard block.
Red flags that mean walk away
- The issuer cannot or will not show you how a signature is verified offline.
- Pricing is opaque or has no ceiling.
- The only documented integration path is "put the API key in the agent's environment".
- No revocation story — a status that was true last quarter is still served as current.
- Marketing leans on the chain rather than on data sources.
Key takeaways
- x402 on Base solves payment for machine-to-machine compliance lookups. It does not solve assurance.
- The single highest-leverage control is fail-closed: an unverifiable attestation must block, not pass.
- Verification belongs in your own service layer, never in the model's context where a prompt injection can argue with it.
- Auditability is the deliverable. If you cannot export the evidence without the vendor's help, you do not own the control.
- Assume the issuer is a counterparty, not an authority: name them, map their claims to your obligations, and keep a second source available.
Next steps
- Assign an owner for each of the twelve items and a deadline for evidence.
- Build a stub oracle that returns tampered, expired, and unknown verdicts — then confirm your agent blocks on all three.
- Write the spend-limit and idempotency policy before the first production call, not after.
- Add the decision record schema to your data model this sprint; retrofitting audit trails is far more expensive.
- Re-run this checklist whenever the issuer, the schema version, or the settlement chain changes.
Sources
- Algernon — a B2B compliance and security oracle for AI agents on Base via x402: https://github.com/tobiaslofton/algernon-x402-oracle
