The Human Approval Path That Never Ran

Evidence status: established. All figures are direct queries against a harness database of 542 runs and 46 recorded approvals spanning 2026-07-17 to 2026-08-07.

Scope. One system’s governance machinery and its exercise record. The design conclusions are general; the numbers are not.

Next test. Set the human-review flag on a live run, drive an approval through the operator surface, and confirm a non-system approver appears in the ledger.

We invested heavily in the authority layer of our agent harness. Signed action envelopes. Attested principal identity. Dual sign-off for high-risk operations. Self-approval closed off. Repository identity bound into the authority record for any action that writes code. Each piece was designed, reviewed, specced, and shipped.

Then we queried the approval ledger:

Source dataset: ./data/approval-actors.csv.

One row. Three weeks of operation, 46 approvals, and not a single one made by a human. The human review gate had never fired — not because it was bypassed, and not because it was broken, but because it was never reachable.

1. The two-path problem#

Nearly every capability in a governed agent system exists twice: once on an autonomous path that runs constantly, and once on a human path that runs rarely. They share intent and usually share a name, but they are different code.

This creates a maintenance asymmetry that is easy to state and hard to internalize:

The path that runs constantly is the path that gets fixed. The path that runs rarely is the path with the authority.

We hit this three separate times, which is what convinced us it was a pattern rather than an oversight.

First. The autonomous approval writer had a defect where it fell back to an empty evidence hash — approving an action while recording nothing verifiable about what was approved. We found and fixed it. Weeks later we discovered the human approval path still had the identical empty-hash fallback. The fix had landed on one of two siblings.

Second. The same autonomous approval writer was discarding every exception into a bare failed branch. Fixed. Then the applying node turned out to swallow every apply exception and route it to a node that did not exist — stranding approved runs with no database write at all. Same defect shape, same fix required, third site, never applied.

Third, and worst. The human gate itself had no operator surface. The flag that enables human review, hitl_enabled, appears in 0 of 542 recorded run snapshots:

Source dataset: ./data/hitl-flag-presence.csv.

It was never set because there was no reachable way to set it. With the flag absent, the review gate reads “no human review required” and auto-advances. Every run in the corpus took the autonomous path, which is why every approval says system.

2. Why “never reachable” is worse than “bypassed”#

A bypass is an event. It leaves a trace, it can be alerted on, and its existence proves the gate was at least in the path.

An unreachable gate produces a perfectly clean record. Every run completes, every approval is recorded, the ledger is well-formed and internally consistent, and the compliance story is intact. The absence of human approvals reads as “no run needed human approval” rather than “no run could have received human approval.” The two are indistinguishable from inside the data.

This is the same reporting defect as an audit rule that finds nothing because it matched nothing: a null result that cannot be distinguished from an unevaluated one. The approval ledger had no way to express “this gate did not run”, so it expressed nothing, and nothing looks like success.

The detection that finally worked was a population query — not “were there any bad approvals” but “what is the distribution of approvers, and does it have more than one value?” A single-valued categorical column in a field designed to distinguish actors is a strong smell, and it takes one query to check.

3. What the machinery does, for the record#

None of the above means the authority work was wasted. It means it is untested in production. Here is what exists, so the gap is precise rather than rhetorical.

Attested principal identity. Grants carrying unrestricted tool authority must present a signed principal attestation, and the signer’s identity is persisted into the effective grant rather than checked and discarded. Provenance survives the authorization decision.

Allowlist, not denylist, on principal kind. The check for which principal kinds may hold an unrestricted grant was originally a denylist. It is now an allowlist. This is the single highest-leverage line in the whole subsystem: a denylist fails open for every principal kind invented after it was written, and new principal kinds are exactly what a growing system produces.

Fixed-tier action split. A generic “apply code” action was split into code_commit_candidate and code_promote, each at a fixed risk tier. A single action type whose risk depends on runtime arguments cannot be governed by a static policy, because the policy has to guess.

Repository identity in the authority record. Which repository and remote an action targets is bound into the authority envelope, so an approval for one destination cannot be replayed against another.

Destination-head TOCTOU protection. The promote path checks that the destination head has not moved between approval and application.

Self-approval closed universally, with real requesters. Previously the requester was not always a real identity, which made “requester must differ from approver” unenforceable in the cases that mattered.

Durable signed receipts. The signed envelope is persisted as a receipt rather than existing only for the duration of the decision.

Every one of these is a real control. All of them have been exercised exclusively by system.

4. Worked example: how a fix misses its sibling#

Consider the empty-hash evidence fallback concretely.

approve(action):
    evidence = collect_evidence(action)
    if evidence is None:
        evidence_hash = ""        # <-- the defect
    else:
        evidence_hash = sha256(evidence)
    record_approval(action, evidence_hash)

An empty hash means the approval record cannot be tied to what was approved. Anyone auditing later sees an approval with no verifiable subject.

The fix is obvious once seen: refuse the approval when evidence is missing. The autonomous path got exactly that.

Now: how would you have known the human path needed it too? Not by grepping for the function name — the two paths had diverged enough that the code was not textually similar. Not from the test suite — the human path had no test exercising the missing-evidence case, because nothing had ever driven it. Not from production telemetry — no human approval had ever been recorded, so there was no data in which the defect could appear.

Every ordinary detection channel was blind for the same underlying reason: the path does not run. The only thing that would have worked is a structural check — an assertion that both approval writers converge on one evidence-validation implementation — and that is a much stronger design requirement than “fix the bug.”

5. Counterfactuals#

Was the human path dead code? No, and this matters. It was live, reachable in principle, and would have executed if the flag had ever been set. Dead code can be deleted; this could not. It was a cold path, which is strictly more dangerous, because it will eventually run — probably during the incident that makes someone turn human review on.

Would tests have caught it? Tests would have caught the empty-hash fallback if anyone had written one for the human path. They would not have caught the missing operator surface, because that is a gap between the configuration schema and the interface, not a defect inside either. A test asserting “the flag can be set through a supported surface” is an odd test to think of writing before you know the answer is no.

Is 46 approvals too small a sample to conclude anything? For the claim being made, no. The claim is not statistical — it is that the distinct count of approvers is one. A single counterexample would refute it, and across three weeks there is not one.

Could system be a legitimate approver identity for automated policy decisions? Yes, and it is. The finding is not that system approvals are wrong; it is that they are the only kind, in a system built on the premise that some actions require a human.

6. What we changed, and what remains open#

Fixed: the human path’s empty-hash fallback now refuses an approval whose evidence is missing, matching the autonomous path. The applying node’s swallowed exceptions now terminalize properly instead of routing to a nonexistent node and stranding approved runs.

Still open: hitl_enabled has no operator-reachable surface. This is the load-bearing gap and it is deliberately called out as unresolved. Until it is fixed, everything in section 3 remains machinery with no exercise record, and this article’s central number does not move.

We are stating that plainly rather than presenting the fixed items as a resolution, because the fixed items are the easy half.

7. Limitations#

• One system, one corpus, three weeks. The three instances establish a pattern within this codebase; they are suggestive rather than conclusive elsewhere.
• We cannot show the human path is otherwise correct. We have shown it had two defects its sibling did not. There may be more; the absence of exercise means the absence of evidence either way.
• hitl_enabled presence was detected by substring match on stored policy and task specifications. A differently-named or nested equivalent would not have been found, though the approver distribution independently corroborates the conclusion.
• No claim is made about whether human review would have improved outcomes. This is about a control that could not operate, not about its efficacy.

8. Takeaways#

1. Query your governance ledger for actor diversity, today. SELECT approver, COUNT(*) GROUP BY approver is a five-second query, and a result with one row in a system designed for multiple actors is a finding.
2. When a capability has an autonomous and a human path, fixes will land on the autonomous one. Plan for it structurally: converge them on a shared implementation, or add a test that asserts they agree, because your normal detection channels are all blind to the cold path.
3. An unreachable gate is worse than a bypassed one. It produces clean records and a compliance story with nothing behind it.
4. A denylist on principal kind fails open for every kind invented later. Allowlist.
5. Shipping a control is not exercising it. Between “the code exists” and “the control operates” sits a configuration surface, and ours had a hole in it for three weeks and 542 runs without anything noticing.

The uncomfortable general form: the more carefully you build a human-in-the-loop control, the more confidently everyone assumes it is working — and the less likely anyone is to check whether it has ever actually run.