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