每月 99 美元能證明你的 AI 智能體甚麼？

When an AI agent spends money, two artifacts exist. The first is the transaction: a hash on a chain, visible to anyone. The second is the decision to allow it — and when the decision was no, almost nobody keeps the second one.

Ask a team what their agent refused last month and you usually get a dashboard, a screenshot, or a log where every row says allowed. A dashboard is a claim made by the same system that is being questioned. That is why the interesting artifact is not the allow list. It is the refusal, written down in a form someone else can check.

What a refusal record has to contain

The record has to answer four questions without help from the service that produced it: what was asked, which policy decided, who asked, and can this file be changed after the fact.

{
  "v": 1,
  "prev": "<sha256 of the previous record>",
  "ts": "2026-10-29T09:14:02+00:00",
  "decision": "deny",
  "reason": "payee not in allowlist",
  "policy_id": "E03-allowlist",
  "task_id": "task_7f21",
  "artifact_hash": "sha256:9c1e...",
  "actor": "agent:research-1",
  "meta": {"requested_amount": "12.50", "allowed_max": "0.05"},
  "hash": "<sha256 of this body>",
  "signature": "<Ed25519 signature>",
  "public_key": "<base64 key>",
  "algorithm": "ed25519"
}

Three properties do the work. prev chains each record to the one before it, so deleting a row breaks every row after it. The signature covers the body including prev, so a record cannot be rewritten and re-signed without the key. The public key is embedded, so verification needs no network call and no account with the vendor.

Writing one is a single request:

curl -X POST https://attest.rta.lat/deny \
  -H 'content-type: application/json' \
  -d '{"reason":"payee not in allowlist","policy_id":"E03-allowlist",
       "task_id":"task_7f21","artifact_hash":"sha256:9c1e","actor":"agent:research-1"}'

Reading them back is the other one: GET /deny?since=...&limit=100. Offline check is a function call against the exported log, not a login:

from attest.deny import read, verify_log
verify_log(read())

What it proves, and what it does not

This table is the reason the product exists, and it is more useful than any feature list:

Read the right column twice. A signed refusal log is evidence that a specific decision happened and was recorded in a way that cannot be quietly edited. It is not a certificate of good judgement, and it is not a control: it records what was stopped, it does not stop anything. If you need enforcement before the action, that is a separate layer — a mandate checked against the proposed action, not a log written after it.

Anyone who sells you "compliance" as a single artifact is selling you the left column and hoping you do not read the right one.

Why it costs money at all

Recording a refusal is cryptography, not inference. There is no model in the path: Ed25519 signing and a SHA-256 chain cost nothing per record, which is why the price is flat rather than metered.

The paid plan is $99 for 30 days, unlimited records, one-time payment, no auto-renewal. A trial key starts at 0.01 USDC and covers 100 records over 7 days; free evaluation is 20 records a day. Payment is USDC on Base to the address on the page, and the page issues the API key after the transfer.

Now the honest part about the subscription: the price is not the proof. Paying monthly proves you had $99 and a reason. What proves something is the artifact, and the artifact does not expire with the subscription. Records you already hold keep verifying offline after the plan ends, because verification uses the public key inside the record, not a call to the vendor. If a service's evidence stops working when you stop paying, it was never evidence — it was a rented dashboard.

So what does $99 a month actually prove? That you decided the question "what did the agent refuse, and can I show it later" is worth a fixed line item rather than a screenshot. The rest is arithmetic: signing a record is Ed25519, not inference, so the five-hundredth refusal in a month costs the same as the first — zero.

Where it fits in a real conversation

An auditor asks for a refusal and gets a signed chain with the policy and the numbers. An incident review needs a timeline; the gap is usually exactly where the agent was stopped, and this is the file that fills it. A customer asks what your agent is not allowed to do; the answer is a set of policy ids with the records that applied them.

None of those conversations are won by a dashboard. They are won by a file the other side can check without trusting you.

The contract, the offline verifier and the pricing block are here: https://attest.rta.lat/deny-evidence