Autonomy is not just a capability question. It is a delegation question.
If an AI agent can act on our behalf, its authority should be explicit, bounded, signed, and independently verifiable.
AI agents are moving from answering questions to changing the world around them. They can edit files, call APIs, operate business systems, deploy code, and coordinate with other agents. That is useful. It also changes the trust problem.
A chatbot can give a bad answer and a person can reject it. An agent can take an action before anyone notices that the instruction, permission, or acceptance standard was unclear.
"Technology does not exist in a vacuum."
That sentence is especially important for agentic systems. Agent autonomy always exists inside a human, organizational, and economic context. Someone defines the task. Someone grants access. Someone bears the cost of failure. Someone decides whether the result counts as delivered.
My argument is simple: human authority should be a protocol property, not a checkbox in a product interface.
Autonomy changes the business question
Most discussion about agent autonomy starts with capability: Can the model plan? Can it use tools? Can it recover from errors? Can multiple agents collaborate?
Those are engineering questions. Once the agent touches real work, businesses ask a different set of questions:
Before execution
- Who authorized this action?
- What exact task and scope were approved?
- Which tools, data, budget, and time window were permitted? After execution
- What actually happened?
- Did the evidence support the claimed result?
- Who verified it, and who accepted delivery?
These questions are not solved by making the model smarter. They require a durable relationship between human intent, machine permission, observed execution, verification, and acceptance.
Without that relationship, autonomy becomes ambiguous delegation. The agent may be capable of acting, but nobody can later prove whether it was entitled to act in that way.
Why "human in the loop" is not enough
The Model Context Protocol is an important open standard for connecting AI applications to external systems. Its tool specification says that there should always be a human in the loop who can deny tool invocations. The same specification also makes clear that the protocol does not mandate one specific user interaction model.
That is a reasonable boundary for a connectivity protocol. MCP helps an agent discover and invoke tools. It should not be blamed for every governance problem above it.
But a confirmation dialog is not the same thing as verifiable human authority.
| A UI approval can show | A verifiable authority layer must prove |
|---|---|
| A user clicked "Allow" | Which identity authorized which action under which work order |
| A tool call was displayed | Whether the call stayed inside the signed scope, limits, and deadline |
| A result appeared in the same product | Whether a third party can verify the evidence without trusting that product |
| A person reviewed something | Whether verification and business acceptance were performed by distinct authorities |
A prompt such as "ask me before doing anything important" is useful behavioral guidance. It is not a portable authorization record. It can be interpreted differently by different models, lost across systems, or hidden inside a vendor's private event log.
The stronger the agent becomes, the less we should rely on informal intent as the only boundary.
What verifiable human authority looks like
OpenWorkProof is exploring this missing layer as an open protocol for agent work contracts and verifiable execution. Its Human Agency Profile treats human choice as a machine-verifiable authorization boundary.
The effective authority of an agent is not determined by one broad permission. It is the intersection of three signed objects:
WorkOrder
∩ CapabilityGrant
∩ HumanAgencyProfile
= allowed actions at this moment
- WorkOrder defines the task, acceptance criteria, and delivery context.
- CapabilityGrant defines which capabilities the system may grant to the agent.
- HumanAgencyProfile records the human authority that remains active for this specific work.
Every proposed action can then resolve to one of three outcomes:
Allowed
The action is inside the current signed authority and may proceed.
Reserved
The action requires a fresh human decision before execution.
Denied
The action is outside the authority boundary and must not execute.
A reserved action returns AGENCY_HUMAN_DECISION_REQUIRED before execution. This is different from detecting a policy violation after the damage is done.
The profile is bound to a work order, signed by an Acceptor, and independently verifiable. An appeal is also explicit: it is a signed request for review, not a hidden mechanism that silently expands the agent's rights. Only an authorized, signed transition can supersede or revoke the active profile.
This design does not make the human infallible. It makes the delegation legible.
Verification is not acceptance
A cryptographic signature can prove who signed an object and whether it was altered. It cannot prove that the task was worth doing, that the test checked the right thing, or that the customer accepts the result.
That distinction matters enough to make it explicit:
VERIFIED != ACCEPTED != PAID
VERIFIED != SETTLED
VERIFIED != LEGAL AUDIT
VERIFIED != ADOPTION
In OpenWorkProof, a Verifier evaluates evidence. An Acceptor makes the independent delivery decision. The verifier can conclude that the available evidence supports a claim, while the acceptor can still reject the delivery because the work does not meet the agreed business standard.
This separation also exposes a harder problem: what if the receipt is authentic, but the judgment was based on the wrong test or the wrong population? Verification Integrity addresses that failure mode by preserving the evidence population and the control logic used by the verifier. When evidence is incomplete or the control does not match, the protocol can return UNKNOWN rather than manufacture confidence.
A signed receipt proves integrity and origin. It does not automatically prove correctness, customer acceptance, legal compliance, or payment.
Why a business would care
Businesses are unlikely to buy cryptography for its own sake. They pay when a system lowers the cost and risk of delegation.
Today, important agent work is often trapped between two weak choices. A company can keep a human manually checking every step, which removes much of the promised efficiency. Or it can trust the agent platform's own dashboard as the final account of what happened.
A portable work contract and evidence layer creates a third option. The company can delegate defined work while preserving independent proof of authority, execution, verification, and acceptance.
| Business friction | Protocol-level response |
|---|---|
| Fear of giving an agent excessive permission | Task-bound, time-bound, capability-bound authority |
| Manual review of every action | Machine-verifiable receipts and reserved human decisions |
| Disputes over whether work was completed | Separate verification and acceptance records |
| Vendor dashboard as the only source of truth | Offline verification using portable signed bundles |
The commercial promise is not "trust every agent." It is narrower and more useful: delegate important work without granting unlimited authority and without making the agent provider the sole judge of delivery.
What exists today
OpenWorkProof is open source under Apache-2.0. The repository currently contains a local 1.3.0 candidate with the Human Agency Profile, six-role key separation, signed protocol objects, offline verification, and distinct verification and acceptance decisions.
The local candidate has passed 4,265 required-live tests and 183 candidate tests with zero failures or skips in the recorded repository snapshot. These numbers are engineering evidence for that code and environment. They are not evidence of customer adoption, paid deployment, legal effect, or production reliability in another organization.
The currently published public package and MCP Registry version remain 1.2.0. The 1.3.0 candidate has not been released at the time of writing.
Evidence boundary: implementation and local verification exist. Customer adoption, payment, production deployment, and upstream standard adoption require separate evidence.
The design question for the agent ecosystem
Connectivity protocols make agents useful. Authority and acceptance protocols can make their work governable across organizational boundaries.
The open design question is where this layer should live. Should signed authority remain inside the host application? Should it travel with a tool request? Should an agent carry a portable human authority profile? Should execution receipts be understandable across MCP hosts, agent frameworks, and independent verifiers?
I do not think every tool call needs bureaucracy. Low-risk actions should remain cheap. But when an agent changes code, moves money, handles sensitive data, or delivers work across organizations, "the model decided" is not an adequate chain of authority.
Human agency should survive the transition from conversation to execution.
If you are building MCP servers, agent runtimes, approval systems, or multi-agent workflows, I would like to hear where you think verifiable human authority belongs.
Explore OpenWorkProof on GitHub
Top comments (4)
The part of this design I would put at the top is the one you buried near the bottom: UNKNOWN.
"When evidence is incomplete or the control does not match, the protocol can return UNKNOWN rather than manufacture confidence." That single sentence is doing more work than the signatures around it, and I would argue it is the load-bearing piece.
A signature proves who said it and that it was not altered. It cannot prove that anything was measured. So a signed receipt over an unmeasured verdict is not neutral - it is a certificate. It converts "I don't know" into a durable, portable, cryptographically attested claim, and the next system downstream has no way to tell the difference.
Three from my own week, all the same shape:
A harvesting tool ran across sixteen public repositories. Five returned 260–277 results. The remaining eleven returned zero, reporting "no issue has a linked pull request" - for repositories with tens of thousands of them. The cause was an hour rate limit and one line: } catch { return null; }. Every error became the statement "this one has nothing". It then wrote a valid, empty file and exited 0.
A production watchdog judged a fleet of 68 from a random sample of 8 and reported the verdict as a fact about all 68. It had no state for "I cannot know this from this sample", so it said something else.
A health endpoint answered database: true because select 1 succeeded - while three screens were returning 500 on a column that did not exist. The check was true. It was answering a different question than the one asked.
None of those would have been caught by an authority layer, because no boundary was crossed. In all three the system was entitled to act and its output was well-formed. What was missing was a third state. There was "found" and "found nothing", and silence had to become one of the two - so it became zero. And a zero looks like a result.
So the question I would put back to your design: is UNKNOWN a first-class signed outcome, or is it the absence of a receipt? Those are very different. If a verifier that could not measure simply emits nothing, then downstream "no receipt" is ambiguous between not run, not measurable, and lost in transit - and the ambiguity lands exactly where you built the protocol to remove it.
One more, offered as a shared risk rather than a criticism, because you already drew the evidence boundary yourself: 4,265 tests with zero failures and zero skips is the shape that should prompt "can this suite fail?" I had a 17-item benchmark that scored 92.3% and ranked two rankers in exactly the reverse order from the 499-item one. It was not a weak eval. It was a painting of one, and it held up under review because nothing about it was inconsistent.
Part 2 of your article has the sentence I would put on the wall: "A reserved action needs a safe timeout. Silence should not become implicit permission."
That is the same failure with the sign flipped. Yours: silence becomes permission. Mine, three times this week: silence becomes zero — a rate limit booked as "this repository has no linked pull requests", a sample of 8 booked as a verdict about 68, a select 1 booked as "the schema is fine".
Both are the same missing state. There is "yes" and "no", and nothing said has to become one of them. So it becomes whichever one the code path reaches first — and in an authority system that is permission, which is the worse of the two defaults.
Heinrich, I think you are right to make UNKNOWN the load-bearing part.
OpenWorkProof v0.5 already treats UNKNOWN as a signed, first-class decision. Missing, mismatched, or incomplete population and control evidence can produce a signed VerificationDecision with explicit reason codes, and downstream acceptance gates must not treat that result as success.
But your examples expose a remaining gap in the model.
Today, OWP can sign the statement: "The evidence available is insufficient for this claim." It does not yet cleanly distinguish between:
Those states should not all collapse into the absence of a receipt. Absence is a transport or execution ambiguity. UNKNOWN is an epistemic conclusion.
I think the next schema needs two separate fields:
measurement_status: measured | not_run | not_measurable | interrupted | incomplete
verdict: VERIFIED | REFUTED | UNKNOWN
The signed result should also bind what was actually measured: the declared population, observed population, sampling rule, coverage, verifier version and commit, control ID, and negative-control result.
Your 8-of-68 example makes the distinction concrete. "Eight items were measured under this sampling rule" may be a valid statement. It is not a valid conclusion about all 68 unless the verification contract explicitly permits that inference.
Your criticism of the "4,265 tests passed" claim is fair as well. That number proves only that the registered suite passed in the recorded environment. It does not prove that the suite is representative or that every guard can fail.
OWP already uses reason-bound negative controls for conclusion-bearing verification, but raw test count is still the wrong headline metric. We should report falsifiability coverage alongside it: how many conclusion-bearing guards were challenged with known-bad inputs, and how many rejected them for the expected reason.
The protocol rule I would write now is:
Every completed verification attempt should produce a signed verdict and a signed measurement status. No receipt should never be interpreted as UNKNOWN. It should mean that no attestable outcome exists.
Would you be open to reviewing a small schema proposal for this split? Your three examples would make excellent acceptance cases.
Yes, gladly - send the schema and I'll review it against real cases rather than opinions.
Your split is right, and I want to hand you the one case that survives it, because it's the one that cost me the most today.
Two of my three examples are status problems. The third is not.
The harvest: the check ran, got an HTTP error, and booked it as data. Under your schema that is not_measurable - if the producer can tell. It couldn't, and that is the whole bug. So the schema is correct and the hard part moves one step earlier: a producer that cannot distinguish "error" from "empty result" will emit measured with full confidence. The field is necessary; it is not sufficient.
The watchdog, 8 of 68: incomplete plus a sampling rule. Your schema closes it cleanly.
The health endpoint is the one that gets through. select 1 succeeded. Status: measured. Verdict: VERIFIED. Both honest. And three screens were returning 500 on a column that did not exist.
Nothing in measurement_status × verdict catches that, because the measurement was real and the verdict was true - of a different claim. The control was "can I reach the database". The claim was "the schema matches the code". A signed receipt for the first reads, downstream, as evidence for the second.
You already have the fix in your list and I'd promote it to the same rank as the two fields: control ID. My sharpening would be that the acceptance gate must compare the control to the claim, not just read the verdict. Otherwise the receipt is honest, complete, signed - and answering a question nobody asked. That is a harder failure than UNKNOWN, because every field in it is true.
So the third field I'd argue for is not a status. It is: what claim does this verdict license? If that isn't in the signed object, an acceptance gate has to infer it, and inference is where the ambiguity comes back.
On falsifiability coverage - you're right that raw test count is the wrong headline, and I'd rather demonstrate that than agree with it. Our test suite has a convention: every guard that draws a conclusion carries a counter-probe, marked KONTROLLE:, that feeds it a known-bad input and asserts it rejects it for the expected reason. It exists because a guard that finds nothing and a guard that has nothing to find produce identical output.
I have never measured the ratio. I'll count it this week and post the number here, whatever it turns out to be - including if it's embarrassing. If it's useful, "conclusion-bearing guards with a passing negative control / conclusion-bearing guards" might be a workable definition for your metric, because it's mechanically countable rather than a judgement call.
One caveat on my own three examples before you build acceptance cases on them: they are one repository, one week, and I found all three because someone from outside asked why a number was zero. They're real, but they're not a sample.
Three follow-ups since my last comment - all new, none of them opinions.
First: I promised you the number "this week." Here it is early, and it's embarrassing: 11 %. Counting method, so you can reject it: a "conclusion-bearing guard" = any test file that reads source, config, or system state and asserts a conclusion about it (204 files across three repos). A negative control = our KONTROLLE: convention - a probe that feeds the guard a known-bad input and asserts rejection for the expected reason. 22 of 204 files carry one (54 probes total). The convention I bragged about exists; the coverage doesn't. Which is precisely your point: "we have a pattern for this" and "this property holds" are different claims, and until yesterday I had a signed-feeling belief in the second based on evidence for the first. Caveat: the counter is a proxy (marker-based; some guards may have unmarked controls, some counted files may not truly conclude), so treat 11 % as ±a few points - the shape survives any correction.
Second: your interrupted state earned its keep at my place within 24 hours of you naming it. An autonomous harvester of ours judged runs by exit code. A run that wrote seven good records and then hit a non-fatal warning exited non-zero - and was booked as "failed, retry later." The machine threw away its own completed work because interrupted-with-partial-results had no representation; there was only success and failure, and silence about the partial artifact became "failure." We caught it because the result file sat on disk next to the exit code. The rule we wrote afterwards might be useful for OWP's receipt semantics: bind the receipt to the artifacts produced, not to the process that produced them. Exit codes, summaries, logs - messengers. The artifact is the evidence.
Third, one structural request for the draft: make it impossible to serialize a verdict without its measurement_status - one wrapper object, both fields required, rather than two optional siblings. Optional siblings drift: someone will emit verdict: UNKNOWN with no status, every consumer will invent its own default, and the collapse you're designing against comes back through the parser. If the schema enforces it, the bug class disappears instead of relocating.
Practical bit: best door for the proposal is github.com/cachly-dev/cachly-mcp/issues - issues are open, and I'll review it there against the three cases plus the harvester one above as acceptance cases.