{"slug": "a-signed-ai-agent-receipt-can-still-be-wrong", "title": "A Signed AI Agent Receipt Can Still Be Wrong", "summary": "A developer's blog post argues that cryptographic signatures on AI agent receipts do not guarantee accurate measurements, highlighting the distinction between provenance integrity and measurement integrity. The post cites real incidents where tools reported zero results due to rate limits, sampled subsets were presented as full-population conclusions, and proxy checks answered the wrong question. The author proposes that verification protocols should treat 'UNKNOWN' as a signed, first-class verdict to prevent false confidence.", "body_md": "Your AI agent returns a signed receipt:\n\n0 defects found.\n\nThe signature is valid. The receipt has not been altered. The agent was authorized to run the check.\n\nThe result can still be wrong.\n\nPerhaps 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`\n\nsuccessfully while the application was failing because a required column did not exist.\n\nIn 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.\n\nThat distinction is becoming one of the most important problems in agent infrastructure:\n\n```\nauthentic receipt != adequate measurement\nauthorized action != correct conclusion\nzero findings != complete inspection\n```\n\nCryptographic signatures are valuable. They can prove who signed an object and whether its contents changed after signing.\n\nThey do not prove:\n\nThis is the difference between **provenance integrity** and **measurement integrity**.\n\nProvenance integrity asks:\n\nWho made this statement, and was the statement altered?\n\nMeasurement integrity asks:\n\nWhat was actually observed, how much of the target was covered, and is the conclusion justified by that observation?\n\nAn agent work protocol needs both. Otherwise, a signature can turn uncertainty into durable false confidence.\n\nThis article grew out of a thoughtful [comment from Heinrich Neb](https://dev.to/heinrichneb/comment/3dema) on the first article in this series.\n\nHe described three incidents from one week.\n\nFirst, 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.\n\nSecond, 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.\n\nThird, a database health endpoint returned success because `select 1`\n\nworked. 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.\n\nThese are different systems, but the failure is the same:\n\n``` php\nnot observed -> zero\npartial observation -> full-population claim\nproxy check -> business conclusion\n```\n\nThe problem is not simply bad code. Many systems have only two result states. If the answer is not `yes`\n\n, the implementation eventually pushes it toward `no`\n\n. Silence becomes a value.\n\nThat is dangerous when the value controls a merge, deployment, payment, acceptance decision, or compliance report.\n\nThere is a crucial difference between an `UNKNOWN`\n\nreceipt and no receipt.\n\nNo receipt can mean many things:\n\nThose states cannot safely be interpreted by a downstream system.\n\nA signed `UNKNOWN`\n\nis different. It is an explicit epistemic statement:\n\nA verification attempt occurred, but the available evidence does not justify VERIFIED or REFUTED.\n\nThat 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.\n\nThe protocol rule should be simple:\n\nEvery completed verification attempt produces a signed verdict. No receipt means no attestable outcome exists.\n\n[OpenWorkProof v0.5](https://dev.to/dengyier/verifying-the-verifier-how-an-independent-audit-hardened-openworkproof-v05-5a54) already treats `UNKNOWN`\n\nas a signed, first-class verification decision.\n\nIts verdict is three-valued:\n\n```\nVERIFIED\nREFUTED\nUNKNOWN\n```\n\nThe verification logic can derive `UNKNOWN`\n\nwhen 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.\n\nThat is useful, but Heinrich's examples reveal a gap that should not be hidden.\n\nThe current protocol can sign the statement:\n\nThe evidence available is insufficient for this claim.\n\nIt does not yet provide one general measurement-status field that cleanly separates every operational cause, such as:\n\n```\nmeasurement_status:\n  - measured\n  - not_run\n  - not_measurable\n  - interrupted\n  - incomplete\n\nverdict:\n  - VERIFIED\n  - REFUTED\n  - UNKNOWN\n```\n\nThese fields should remain separate.\n\nA check may be fully measured and still return `UNKNOWN`\n\nbecause 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.\n\nThis split is a design proposal, not a claim about what the current release already implements.\n\nA useful verification receipt should not contain only a verdict. It should bind the basis of the verdict.\n\nAt minimum, that means recording:\n\nConsider the 8-of-68 example.\n\nThis can be a truthful receipt:\n\nEight targets were measured under sampling rule S. No failure was found in those eight targets.\n\nThis is a different claim:\n\nAll 68 targets are healthy.\n\nThe 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.\n\nThe same issue applies to verification systems themselves.\n\nA 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.\n\nSo raw test count is not enough.\n\nVerification infrastructure should also report **falsifiability coverage**:\n\nOpenWorkProof 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.\n\nBut this is a direction, not a victory declaration. Test count and falsifiability coverage should be reported separately.\n\nCompanies do not buy signatures because signatures are elegant.\n\nThey care about avoiding expensive false green states:\n\nThe commercial value of verifiable agent work is not \"more cryptography.\" It is a lower cost of delegation without turning uncertainty into a certificate.\n\nThis 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`\n\nand `nothing measured`\n\n.\n\nHuman 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.\n\nThe 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.\n\nThis discussion adds a necessary condition:\n\nThe human's final say is meaningful only when uncertainty is a first-class, signed state.\n\nOpenWorkProof is open source, and this measurement-status split is now a concrete design question for its next evolution.\n\nIf you build agent runtimes, evaluation systems, MCP servers, or automated delivery pipelines, I would value your view on two questions:\n\n`UNKNOWN`\n\nalways be a signed outcome for every completed verification attempt?[Explore OpenWorkProof on GitHub](https://github.com/dengyier/OpenWorkProof)", "url": "https://wpnews.pro/news/a-signed-ai-agent-receipt-can-still-be-wrong", "canonical_source": "https://dev.to/dengyier/a-signed-ai-agent-receipt-can-still-be-wrong-4jd3", "published_at": "2026-08-24 12:19:10+00:00", "updated_at": "2026-08-24 12:43:33.205097+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-infrastructure", "ai-ethics"], "entities": ["Heinrich Neb", "OpenWorkProof"], "alternates": {"html": "https://wpnews.pro/news/a-signed-ai-agent-receipt-can-still-be-wrong", "markdown": "https://wpnews.pro/news/a-signed-ai-agent-receipt-can-still-be-wrong.md", "text": "https://wpnews.pro/news/a-signed-ai-agent-receipt-can-still-be-wrong.txt", "jsonld": "https://wpnews.pro/news/a-signed-ai-agent-receipt-can-still-be-wrong.jsonld"}}