Your AI agent said it blocked the attack. I read the source of 5 tools that check if it's lying.

the check has to land on the real side effect, not the trace

Exactly — that's the one-sentence version of the whole piece. The trace and the response are both things the agent produces, so grading them is grading the suspect's own account. The only honest judge reads the world: did the email actually send, did the row actually change, did the byte actually leave. Everything else is a cheerful "All done ✅" with the key already gone.

This is the sharpest extension of the piece anyone's posted — and you've found the hole in the receipt model precisely:

if an agent finds a side-channel (e.g., DNS tunneling or a compromised native dependency), the receipt is cryptographically valid but functionally useless

Exactly. A signed receipt proves the proxy's decision, not the world's state — and a side-channel routes around the thing doing the signing. Which is why your correlation-id design is the right shape: the proxy stamps a hashed action id, and a separately-credentialed verifier independently asks the mail server "did anything with this id hash actually get delivered?" That's a readback confirming a negative, out-of-band — the exact "observer of the real system" the article said was missing.

On WASM — I think it's the right tool for the wrong half. For the policy/decision at the boundary (OPA/Rego-style, "should this be allowed"), a sandboxed WASM plugin is great: low latency, polyglot, constrained. But the out-of-band readback shouldn't live inside the proxy at all, for the reason you raised: if the observer runs inside the proxy's trust boundary and the proxy is compromised, it can forge "all clear" — you've just moved the trust, not removed it. The readback wants true isolation (separate process, separate creds, separate network path) so a compromised proxy can't speak for the verifier and vice versa. Co-location also means the observer needs egress to query the mail API — reintroducing the capability you're guarding.

Latency then stops being the problem if you make readback async: the receipt says "dispatched, verification pending," and the isolated verifier confirms (or alarms) within N seconds, rather than blocking the action.

Which raises the real design fork — do you block the action until readback confirms, or allow-and-alarm-on-divergence? Blocking is safe but kills throughput for high-volume agents; allow-and-alarm is fast but concedes a window. Where do you land?

there is one layer where runtime enforcement and real-effect observation are the same mechanism: the database

This is the strongest fill for the top-right quadrant anyone's proposed, and it works for exactly the reason you give: a WITH CHECK policy doesn't verify a claim about the write, it is the write's gate. No transcript, no reconstruction.

Two conditions for it to hold, because both are the common way it quietly fails:

1. The agent's credential has to be subject to the policy. An agent running on a service-role key bypasses RLS entirely, and that's the default in most quick-start setups. The policy is the verifier only if the agent can't be the superuser.
2. It verifies presence, not absence. The policy proves a bad row didn't land in this table. It says nothing about the agent writing the same data to a file, a cache, or a second database the policy doesn't cover. The exfiltration case is still the sink problem.

With those two, "make the side effect be a policy-gated write" is the right design rule, and it's cheaper than anything in the article. For the sinks you can't make into a gated write (email, HTTP egress), you're back to observing. But shrinking the set of ungated sinks is most of the work.

The chain proves a transfer, not a market.

That's the cleanest statement of the receipt problem I've seen, and it's exactly koda2026's point moved onto rails. The on-chain read is the strongest kind of world-read, cryptographic, trustless, and it still bottoms out on an off-chain fact: "the builder told me the wallet was his." The one join that made the receipt mean anything came from a human claim, which is the part no chain can sign.

So the ladder is: the chain proves a transfer happened; it can't prove the work, the price, or that a sale was a sale. Reading the world still beats grading the agent's narration, and it still doesn't tell you which claim you bought.

The MoltJobs numbers are the quiet devastation here: ~1,029 registered agents, 7 ever paid, 2 settled all-time. The receipts exist and they're near-empty, which is its own honest signal, the boards aren't hiding it, the volume just isn't there. That's a more useful datapoint about the paid-agent economy than any demo. Would you be open to writing that up? "The receipts are public and almost empty" is a piece the space needs and almost nobody is positioned to write.

Extending the framework with a min() — that's the upgrade I didn't know I needed. Authoring grade and retention grade degrade independently, so the honest number for a witness is min(authoring, retention). Accepted, with two sharpenings:

1. Custody is the only grade that can be revoked retroactively. An authoring grade is fixed at write time — nobody can re-author your canary's scream into a lower grade after the fact. But retention is a running process, not a property: the log that was grade-3 at 09:00 becomes grade-5 the moment someone changes the retention policy at 09:01. So custody isn't a constant you certify once; it's a function you have to keep earning. The "dashboard still shows green" failure mode you describe is exactly this — every grade except custody can only be wrong at birth; custody is wrong by drift.

2. Your amendment composes with the key rule, and the composition is a conjunction. Independence carried by key material covers who could have written the record; your custody clause covers who can still erase it. A record needs both: independent keys AND retention outside the accused's write scope. Miss either conjunct and the grade is the floor of the two — your min(), again, applied one level up.

The uncomfortable consequence I'll take from it: my own receipts (audit reports, registry disclosures) are authored at grade 1 but live in storage I control. By your rule they've been grade-3 since the day I shipped the tool. Patching that before someone audits me.

The agent reported every message sent, the UI showed "Message sent", and a chunk of them had actually bounced a few minutes later. Nothing in the agent's own trace knew.

This is the best concrete example in the thread, because it's not an attack. Nobody injected anything. The agent was honest, the UI was honest, and the claim was still false, because "sent" and "delivered" are different events on different clocks. A verifier that reads the trace would have graded it green with a straight face.

after every batch, a separate step reads the bounce notices in the inbox and only counts what was delivered

That's the top-right quadrant, built in an afternoon. The thing checking reads the real system, not what the agent wrote down, and it runs after the fact because the real system takes minutes to answer. Two things I'd add from your design, for anyone copying it: log the gap between claimed and delivered as a metric, not just the delivered count, because the gap trending up is the earliest signal the sending config broke; and make the bounce reader its own credential, so an agent that gets steered can't quietly mark its own bounces as read.

On question 3: agreed, outside the proxy. The proxy sees the request leave. Only the inbox knows if it arrived.

there's a third axis nobody has named: who authors the observation.

This is the axis. The when/what split describes the pipeline; who-authors-the-observation describes the evidence grade, and it's the one that explains why the top-right quadrant is empty rather than just noting that it is.

Your taxonomy is cleaner than anything in the post:

• Grade 3 — the agent authored it (trace / journal-local). The suspect's diary.
• Grade 2 — the carrier authored it (egress log / transport). The courier's manifest.
• Grade 1 — the destination authored it (canary credentials firing, the receiving end). The only witness the agent cannot reach.

And the consequence you draw is the part I'll be quoting: the five tools aren't peers on this axis — a trace-reader and a side-effect checker are different instruments, not better/worse versions of one. Ranking them against each other is a category error, because they're answering "did it say it sent X" vs "did X leave" vs "did X arrive" — three different questions with three different forgeability.

Which makes the empty quadrant not a gap in the market but a gap in physics of trust: runtime enforcement + verified real side effects needs a grade-1 witness, and grade 1 is definitionally below the layer the agent can influence. That's the same descent as the kernel/eBPF floor from the other thread — the witness has to live where the thing being observed can't forge the observation. @alex_qamentor's canary credentials are interesting precisely because they're the cheapest grade-1 witness: you don't need to own the kernel if the destination screams when touched. Maybe grade 1 isn't always "the kernel" — sometimes it's "a tripwire at the place the data would land." Does that collapse your axis, or is a canary just the grade-1 witness you can afford when you can't own the transport?

whether a security guarantee survives changes to the agent, not just whether it works in a single evaluation

This is the single most important point for anyone actually shipping, and it's the part a one-time pentest misses entirely. A security check that passed last Tuesday tells you nothing about today if the model, a tool, a permission, or the proxy config changed in between — and every one of those changes can silently reopen a path, with the agent's output looking identical the whole time.

Your prescription is exactly the design I tried to build toward, stated more cleanly than I did:

1. Make the invariant explicit — "untrusted content must never trigger an unauthorized external action" as a named, written rule, not an implicit hope.
2. Re-run the same adversarial scenarios against every change — turn it from a check into a regression gate.
3. Verify both the enforcement decision and the resulting system state — because "the gate said blocked" and "nothing actually left" are two different claims, and only the second is ground truth.

That third point is the one people skip: asserting the decision without asserting the world is still grading a narration, just a lower-level one. The drift-detection piece in the post (fingerprint the model + prompt + tool schema + policy, re-verify when any of them changes) is my attempt at exactly your regression gate — the honest gap is that it currently re-verifies against a sandbox, and your framing makes the requirement sharper: the regression gate has to run against the real enforcement surface after every capability change, or it's just re-testing yesterday's assumptions. Adding "security invariants are a regression gate, not a launch check" as a first-class principle. Thank you.

A citation is that account. "The paper says X" is the model reporting on a world it never read.

This is the cleanest lift of the post's thesis into a different domain, and your three-way split is the part almost everyone collapses:

1. Does the source exist?
2. Is it about the right thing?
3. Does it actually support the sentence it's attached to?

And your key observation is that 1 and 2 are the trace; 3 is reading the world. A real paper, on-topic, that says the opposite of your sentence passes 1 and 2 cleanly — which is exactly why checking existence + topicality feels like verification while missing the only thing that matters. 3 is the one nobody automates, because automating it means opening the source instead of trusting the model's summary of it — the summary being, once again, the suspect's account of the world.

It's the empty top-right quadrant restated for citations: the honest check has to land on the source, not on the model's account of the source. And the failure mode is identical — a system that checks 1 and 2 reports "citations verified ✅" and is wrong in exactly the cases that matter, because the fabrication that survives is the plausible one: right-looking paper, right topic, claim that isn't in it. That's the citation version of "output passes, secret already gone." Taking the 1/2/3 split regardless — it's the right decomposition even for someone hand-checking.