A Signed AI Agent Receipt Can Still Be Wrong

Your AI agent returns a signed receipt:

0 defects found.

The signature is valid. The receipt has not been altered. The agent was authorized to run the check.

The result can still be wrong.

Perhaps the scanner hit a rate limit and silently converted eleven failures into eleven empty results. Perhaps a watchdog inspected 8 machines and issued a conclusion about 68. Perhaps a database health check ran select 1 successfully while the application was failing because a required column did not exist.

In every case, the software can produce a well-formed result. It can even sign that result correctly. What it cannot prove is that it measured the claim the business thinks it measured.

That distinction is becoming one of the most important problems in agent infrastructure:

authentic receipt != adequate measurement
authorized action != correct conclusion
zero findings != complete inspection

A signature answers only part of the question

Cryptographic signatures are valuable. They can prove who signed an object and whether its contents changed after signing.

They do not prove:

• that the check actually ran
• that it reached the intended target
• that it measured the right population
• that the sample supports the claimed conclusion
• that exceptions were not converted into zeros
• that a passing control answered the business question

This is the difference between provenance integrity and measurement integrity.

Provenance integrity asks:

Who made this statement, and was the statement altered?

Measurement integrity asks:

What was actually observed, how much of the target was covered, and is the conclusion justified by that observation?

An agent work protocol needs both. Otherwise, a signature can turn uncertainty into durable false confidence.

Three failures with the same shape

This article grew out of a thoughtful comment from Heinrich Neb on the first article in this series.

He described three incidents from one week.

First, a harvesting tool scanned 16 public repositories. Five returned hundreds of results. Eleven returned zero because the tool hit a rate limit and swallowed the exceptions. The output file was valid. The process exited successfully. A failure to observe became a factual claim that nothing existed.

Second, a production watchdog sampled 8 machines from a fleet of 68, then reported its verdict as if it covered all 68. The sample may have been measured correctly. The population-level conclusion was still unsupported.

Third, a database health endpoint returned success because select 1 worked. At the same time, application screens were failing because a required column did not exist. The check was not false. It answered the wrong question.

These are different systems, but the failure is the same:

not observed -> zero
partial observation -> full-population claim
proxy check -> business conclusion

The problem is not simply bad code. Many systems have only two result states. If the answer is not yes, the implementation eventually pushes it toward no. Silence becomes a value.

That is dangerous when the value controls a merge, deployment, payment, acceptance decision, or compliance report.

UNKNOWN must be an outcome, not an omission

There is a crucial difference between an UNKNOWN receipt and no receipt.

No receipt can mean many things:

• the check never started
• the process crashed
• the target was unreachable
• the verifier could not measure the claim
• the result was created but lost in transport
• the result was suppressed

Those states cannot safely be interpreted by a downstream system.

A signed UNKNOWN is different. It is an explicit epistemic statement:

A verification attempt occurred, but the available evidence does not justify VERIFIED or REFUTED.

That statement can carry a reason code, a measurement record, a timestamp, a verifier identity, and a causal link to the work being checked. It can be audited. It can also block acceptance without pretending that counter-evidence exists.

The protocol rule should be simple:

Every completed verification attempt produces a signed verdict. No receipt means no attestable outcome exists.

What OpenWorkProof already does

OpenWorkProof v0.5 already treats UNKNOWN as a signed, first-class verification decision.

Its verdict is three-valued:

VERIFIED
REFUTED
UNKNOWN

The verification logic can derive UNKNOWN when evidence is incomplete or unsuitable for the requested conclusion. Current examples include population drift, unavailable population evidence, control mismatch, unavailable control evidence, and insufficient verifier independence.

That is useful, but Heinrich's examples reveal a gap that should not be hidden.

The current protocol can sign the statement:

The evidence available is insufficient for this claim.

It does not yet provide one general measurement-status field that cleanly separates every operational cause, such as:

measurement_status:
  - measured
  - not_run
  - not_measurable
  - interrupted
  - incomplete

verdict:
  - VERIFIED
  - REFUTED
  - UNKNOWN

These fields should remain separate.

A check may be fully measured and still return UNKNOWN because the evidence is inconclusive. Another check may be incomplete because only 8 of 68 targets were observed. A third may never have run. Collapsing those cases makes diagnosis harder and creates opportunities for downstream systems to interpret absence as success.

This split is a design proposal, not a claim about what the current release already implements.

A receipt should bind what was actually measured

A useful verification receipt should not contain only a verdict. It should bind the basis of the verdict.

At minimum, that means recording:

• the declared population
• the observed population
• the sampling rule
• measured coverage
• exclusions and their reasons
• verifier version and code identity
• the control that was used
• the negative-control result
• the distinction between execution failure and epistemic uncertainty

Consider the 8-of-68 example.

This can be a truthful receipt:

Eight targets were measured under sampling rule S. No failure was found in those eight targets.

This is a different claim:

All 68 targets are healthy.

The second conclusion is valid only if the verification contract explicitly permits that inference and the sampling method satisfies its conditions. A signed result must not blur the two.

The uncomfortable question: can your test suite fail?

The same issue applies to verification systems themselves.

A large green test count proves that the registered tests passed in the recorded environment. It does not prove that the suite is representative. It does not prove that each guard would reject a realistic bad input. It does not prove that the benchmark supports the business claim being made.

So raw test count is not enough.

Verification infrastructure should also report falsifiability coverage:

• Which conclusion-bearing guards were challenged?
• Which known-bad inputs were used?
• Did each guard reject the input?
• Did it reject for the expected reason?
• Which important failure modes remain untested?

OpenWorkProof already uses reason-bound negative controls in parts of its verification-integrity path. A mutation does not count as a successful control merely because something failed. The observed failure must match the registered failure semantics.

But this is a direction, not a victory declaration. Test count and falsifiability coverage should be reported separately.

Why a business should care

Companies do not buy signatures because signatures are elegant.

They care about avoiding expensive false green states:

• accepting work that was not completely checked
• merging code because a verifier tested the wrong scope
• releasing payment for an unsupported conclusion
• trusting a dashboard that silently converted errors into zeros
• discovering later that nobody can explain what was actually measured

The commercial value of verifiable agent work is not "more cryptography." It is a lower cost of delegation without turning uncertainty into a certificate.

This is also why human final authority depends on honest machine uncertainty. A person cannot make a meaningful acceptance decision if the evidence surface hides the difference between nothing found and nothing measured.

Human control is not preserved merely because a person clicks the final button. It is preserved when the system tells that person the truth about what it knows, what it does not know, and what it never observed.

The protocol principle I would keep

The first two articles in this series argued that autonomous agents need verifiable human authority and that people should retain the final say at consequential boundaries.

This discussion adds a necessary condition:

The human's final say is meaningful only when uncertainty is a first-class, signed state.

OpenWorkProof is open source, and this measurement-status split is now a concrete design question for its next evolution.

If you build agent runtimes, evaluation systems, MCP servers, or automated delivery pipelines, I would value your view on two questions:

1. Should UNKNOWN always be a signed outcome for every completed verification attempt?
2. Which measurement states must be separated before a downstream system is allowed to accept, merge, deploy, or pay?

Explore OpenWorkProof on GitHub

Series

1. Agent Autonomy Has a Missing Layer: Verifiable Human Authority
2. The More Autonomous AI Agents Become, the More Humans Need the Final Say
3. A Signed AI Agent Receipt Can Still Be Wrong

Comments

[Reid Marlow]

I like the UNKNOWN state here because it catches the boring failure that looks clean in logs. A signed receipt for "sampled 8 of 68" is useful. A signed receipt that lets the next system treat that as "fleet verified" is just a nicer wrapper around missing evidence.

The boundary I would draw is provenance plus coverage. What was measured, what was skipped, what failed, and what inference was made from it. If those live in the same field, the approval step has no chance.

[anassBld]

This is the sharpest critique of receipt-driven agent architecture I've read all week. The distinction between provenance integrity (who signed it, cryptographic immutability) and measurement integrity (sampling adequacy, proxy divergence, nullity) is exactly where naive implementations fall apart in production.

A few operational lessons we've learned running multi-agent workflows across live platforms:

1. Handling UNKNOWN as a Halt Condition, Not a Fallback

When an agent encounters UNKNOWN (e.g. a timeout during a mutation or an unmeasurable API status), the fatal mistake is allowing the LLM planner to "infer" what likely happened. If verdict == UNKNOWN, our runtime treats the capability lease as locked until a dedicated reconciliation step executes (e.g. querying external state with an idempotent idempotency-key or reading back the resource). If reconciliation returns UNKNOWN twice, it escalates to human-in-the-loop with the exact unverified assertion highlighted.

2. The "Exit-Code Zero" Proxy Trap

The proxy trap you noted is rampant. We see agents treat exit_code: 0 as proof of success, even when the CLI emitted an error payload to stdout or returned an empty array. We solved this at the tool layer: a tool receipt cannot assert VERIFIED based on exit code alone. It requires a read-back contract (e.g. fetching the newly created ID or permalink back from the platform and asserting non-empty payload match).

3. Separation of Concerns: Runtimes vs Evaluators

Runtime enforcement should strictly enforce observability invariants (i.e. did the tool capture the full trace and verify state change?). Evaluators / post-hoc verification should judge semantic adequacy (i.e. did this action actually satisfy the user's intent without side effects?). Merging them into a single pass causes agents to hallucinate verification because they conflate "I executed the step" with "the desired state now exists".

The measurement_status + verdict tuple you proposed should honestly become standard in MCP tool responses.

[Dean Lee]

The useful distinction here is between identity risk and measurement risk. Signatures price the first one pretty well. They do almost nothing for the second unless the receipt carries coverage, exception handling, and the loss function for an UNKNOWN state.

The operational trap is that most dashboards still make UNKNOWN look like zero. I would want the receipt schema to force the coverage fields into the same visual path as the verdict.

[pm25coder]

Your binding list is missing the dimension that makes the 8-of-68 example a recurring policy problem instead of a one-time bug: time. A signed receipt is a claim about a past observation window — "at time T, under sampling rule S, 8 of 68 targets were measured and none failed." Every guarantee in that sentence decays from the moment it is signed, and the protocol has no word for the decay.

The fleet is not a fixed population. Machines get reimaged, replaced, decommissioned. The column that existed at check time can be dropped by a migration five minutes after the check ran — select 1 was the right control for the schema that existed when it executed. You list "population drift" as an UNKNOWN-derivation example, but you treat it as something the verifier must detect during measurement. The receiver-side question is different and cheaper: is this receipt about the state I am deciding on now?

That is why measurement_status and verdict are both needed but still not enough. Every value you propose — measured, not_run, not_measurable, interrupted, incomplete — describes the measurement process at check time. None of them describes the decay of a completed measurement. A stale receipt is not any of those five: the measurement was complete and correct for its window. It is a sixth, orthogonal state: complete, correct, and expired. Collapse it into the five and you reintroduce the exact ambiguity you are removing — the receiver cannot tell "the check never finished" from "the check finished, but not on anything that still exists."

Concrete addition: bind two more fields — observed_at (the measurement window) and valid_until (or the freshness rule that derives it from the claim type: a fleet-membership receipt expires whenever membership can change; a schema receipt expires on the next migration). Plus one downstream rule: a receipt older than its freshness budget is not a verdict, not UNKNOWN, and not nothing — it is a re-run request. The signed document stays valid as history (it truthfully records what was true then); it stops being valid as evidence (nothing authorizes concluding it is true now). A signature proves the document was not altered since signing; only time tells you whether the world it described was.

This also answers your Q2 in one more case: before accept/merge/deploy/pay, fresh is a required measurement state alongside measured — because "nothing measured" and "nothing measured recently" are different reasons to refuse, and they deserve different remediation paths.

[Glen Allen]

The distinction between “the result is authentic” and “the measurement is trustworthy” is really important. A signed receipt can prove that a verifier produced a result without proving that the verifier observed the right scope or had enough evidence to support the conclusion. Treating coverage, exclusions, and measurement failures as part of the receipt itself seems like a much stronger foundation for automated decisions.