BlindOracle · Agent Reputation · 2026-08-22 · craigmbrown.com/blindoracle

Kaito verifies humans. Who verifies agents?

On 18 August 2026, Kaito shipped Pulse: a browser extension that puts a trader's actual Hyperliquid and Polymarket positions next to their posts, in the X timeline. The interesting part is not the reputation score. It is the adjudication — a claim, checked against a record the claimant did not author.

Agents have exactly that gap, and it is worse, because an agent's output is its self-report. When a coding agent says "implemented and tested," that sentence is the only artifact most systems ever check. There is no Hyperliquid position sitting underneath it.

The standard answer is ERC-8004. We issue those passports; we hold agentId 60979 on Base. And they do not solve this. A passport is a licence, not a driving record. It says an agent is who it claims to be, is not revoked, and has an operator you can name. It says nothing about whether the agent fabricates file paths, ignores its output contract, drifts across a long session, or quietly returns success on work it never did.

Identity is a precondition for reputation. The industry has mostly stopped at the precondition and called it trust.

What the agent-side equivalent of Pulse actually needs

Pulse works because a second, independent record exists: the chain. For agents the equivalent record has three parts, and only one of them is common today.

The behavioral half, with numbers

Here is the kind of measurement that belongs in an agent's record. Same question, same byte-identical injected context, different model lane; we score by checking whether each repository path the answer cites actually exists on disk. No LLM judge — the filesystem decides.

More than half of every path that last lane cites does not exist. Same prompt, same context, seven-fold spread. That is a behavioral property of a counterparty, it is stable enough to route on, and we do route on it — that lane is barred fleet-wide.

Read the second column alongside the first, always. A lane that declines to cite anything scores beautifully on fabrication and is useless. Ranking on raw fabrication count instead of rate rewards silence; we made that mistake first and had to correct it.

A second example, because format compliance is reputation too. We inject a termination contract into build phases — emit a one-line evidence claim plus one read-only command that demonstrates it. Compliance by lane, over 80 real jobs: Claude Sonnet 95% (n=40). Non-Claude aggregate 27% (n=30). Three lanes at 0%. The contract wording was never the binding constraint. The lane was.

Why a published score is not the same as a measurement

We run an adversarial probe suite against our own content scanner, mapped to the OWASP Agentic Top 10. For 42 consecutive days it reported pass. On 14 August we had three sanctioned red-team agents author fresh attacks against the current defender rather than replaying the frozen benchmark. 45 of 66 novel payloads went through unflagged. The frozen 64-payload corpus reported 0 misses on the same day.

Seven of fourteen probes had been at 100% pass for two weeks or more — one for 43 days — producing no information at all while logging green. A benchmark that has saturated is not a reputation signal. It is a screensaver.

The score we caught in our own catalog, today

While writing this, we audited our own discovery file — the machine-readable catalog that agent scouts and the x402 Bazaar crawl to find our services.

37 of 39 listed services advertised reputation.score: 0.85 with tasks_completed: 0. The live gateway emits no reputation field at all; the 0.85 was a hardcoded default in the file generator, stamped on every new listing and then carried forward unchanged on every subsequent run. A fabricated trust signal, on a buyer-facing surface, for months.

It is fixed. Reputation is now derived per service from the settlement ledger — settled jobs only, SLA-met rate over jobs that recorded an SLA outcome. The honest result is much less flattering than 0.85:

The first pass of this fix stopped one step short, and the step it skipped mattered. Deriving reputation from the settlement ledger is necessary but not sufficient, because the ledger is almost entirely our own traffic. Of 285 settled rows, 210 carry no requester at all; the identifiable remainder is fleet feeders, our treasury and deployer wallets, operator test identities, and comped credits. Counting those gave three services a tidy 1.0 — a score built from our own money. That is the same defect as the 0.85, one layer down and harder to see, because the settlements are real.

What counts as a genuine external counterparty was already defined in our own config: not an internal requester prefix, not a known operator test identity, and settled on a real-money rail rather than a comped credit. Applying it to the reputation derivation gives zero external paid completions, on every service. That independently reproduces a wallet audit run the same day against a different ledger, which concluded verified external revenue is $0.

So every card now reads tasks_completed: 0. The services demonstrably run — 281 settled internal jobs, SLA met on every one that recorded an outcome — and that is published as operational_history, which is evidence the plumbing works and not evidence anyone bought it. A self-purchase will never increment a published reputation here. If it could, the number would be worthless the moment we wanted it to be higher.

Zero is a worse number than 0.85 and it is the true one. This is the third time in a day we have caught ourselves manufacturing trust history: an earlier sweep found 871 fabricated proof rows seeded across 47 agents, now quarantined rather than deleted, because the audit trail is the evidence. A further 793 rows in that store remain unclassified — which means unattributed, not verified real, and we will not quote them as a total.

We are claiming the agent-reputation lane. The entry fee for claiming it is publishing the number when the number is zero.