Human Confirmation for AI Write Operations: Why "Yes" Can't Just Be a Boolean

When an AI system wants to execute a write operation, the flow looks simple: it sends a request, the user sees a confirmation dialog, clicks "agree," and the operation executes. But the thinnest link in this chain is precisely what the system retains after the user clicks "yes."

This article focuses on that single point: confirmation should not be a boolean. If you reduce a human's "agreement" to confirmed = true, every subsequent step in the authorization chain will quietly patch over it.

Human Confirmation Cannot Be a Boolean

Two Problems with Booleans

Collapsing "yes" into a boolean creates problems at two levels.

The smaller one is reuse risk: can the same "yes" approve a second thing? This isn't a new problem — marking a confirmation as one-shot solves it.

The larger one is more insidious: a boolean is a word, not a credential. The word "yes" cannot answer any of the following:

Which request was approved?
Approved to write what?
Approved to write where?
Approved to change how much?
Valid until when?

If the confirmation itself can't answer these questions, the answers get decided at the moment of execution. And there's a gap between when the user nodded and when execution happens — anything that changes in between is invisible to the user.

The solution proposed here: turn "yes" into a row in a database, bound to five things. Let's go through each one — and what breaks if you skip it.

Binding "What to Write": Exact Parameters

A confirmation binds the parameters of that specific call, character-for-character exact. Not "parameters must fall within some range," but "parameters are exactly these." Whatever they were at the time must be what gets executed — differ by one character and it's rejected.

This is far stricter than value domain constraints, and the trade-off must be stated clearly: the entire parameter set is either accepted or rejected as a unit.

It cannot express "status can change in this approval, but owner cannot" — because parameters are bound as an encapsulated whole. Expressing that kind of granularity requires a separate mechanism (see writable field scope below).

Binding "Where to Write": Target System

This is the dimension the author admits was pointed out by readers. The original version recorded tool name and parameters — which seemed sufficient. The content to be written was locked down, so what else could move?

The answer: where it gets written.

Tool name and parameters are things on "our side." Which external system the write ultimately lands in is a different matter: an agent tool's configuration can be retargeted, an external service can be re-registered. The approval record sits quietly in the database with every parameter intact — but the destination has been swapped for something else. Nothing in the record can expose this.

The fix is to bind the target too: record the target at issuance, re-resolve the target at execution, and reject on any mismatch — never silently follow the redirect.

A line worth remembering on its own: "approved" and "approved to write where" are two different things.

This class of attack has a corresponding pattern in security: the confused deputy problem. The deputy (here, the AI system) holds a legitimate authorization but is induced to apply it toward a target that was never intended when the authorization was issued. The attacker doesn't need to forge the authorization itself — they just need to quietly swap the target after issuance but before execution. Since the authorization record doesn't lock in a target, the deputy has no way to tell whether this execution matches the original approval. In the broader context of system security, this also has structural similarities to TOCTOU (time-of-check to time-of-use) race conditions: the check happens at one moment, the use happens at another, and state changes between the two are unconstrained. Writing the target system into the record at issuance and re-comparing at execution is essentially eliminating the mutable variable between "check" and "use."

Binding "How Much to Change": Writable Field Scope

Since exact parameters are already bound, why is this needed?

Because exact parameters can only accept or reject the whole set, while confirmations typically express per-field intent: status can be changed this time, but not owner. Only by explicitly declaring writable fields can you articulate this.

It sits alongside exact parameters, not as a replacement: one answers "are these values correct," the other answers "can this category of field be written at all." The convention is consistent with the rest of the system — undeclared means unconstrained; anything beyond the declared set is rejected outright, not truncated. Truncation reads as "partially changed," when what actually happened was "a write that should have been rejected was quietly narrowed and let through."

Binding "When": Validity Window

Confirmations expiring isn't news. What's easy to miss is: where the expiry information lives.

A mistake the author made: the window only lived on the token. Once the token was consumed, it was gone. Three months later, looking at that row, you can only say "it was approved" — but not what the window was at the time.

And that's precisely when you need it most. Someone asks why a write was permitted at that particular time, you go look at the record, and find that the window depended on the configuration at issuance — which has since changed.

The fix is straightforward: write the window into that row at issuance, then read from that row's value at execution — don't recalculate from current configuration.

This touches on a more general principle of audit design: records should be self-describing — a row should be able to independently answer "what happened at the time" at any future moment, without depending on external, mutable context. Relying on "the configuration at issuance" to reconstruct the window at the time effectively outsources the integrity of the audit record to the configuration management system — and configurations almost inevitably change over time. This aligns with the event sourcing philosophy in database design: events themselves should carry enough information to be replayed or verified at any point, rather than requiring the verifier to reconstruct the environment state from that moment. Writing the window into that row at issuance is the minimal step toward making a confirmation record self-describing.

Binding "Who" and "Which Decision"

The last two: the operator, and the moment the decision was made.

There's also one deliberate design choice: rejections travel the exact same binding path as approvals. If "no" is a separate path with its own switches, the two will gradually drift — a binding added to approvals today gets forgotten on the rejection path tomorrow. Sharing one record, one entry point, makes that drift impossible.

A Check You Can Run Yourself

Don't start by asking "is my confirmation strict enough" — ask a more specific question:

Which fields in your confirmation are computed once at issuance and again at execution?

Any such field can drift. Three tests:

Point the same confirmation at a different target system. Does it succeed?
Change one parameter. Does it succeed?
Three months later, can you state what the window or policy version was at the time?

Any "yes" or "can't say" marks a place that isn't bound.

Why Not Just Issue a Credential for Each Approval?

The author honestly lists two things left undone, and one direction deliberately abandoned.

Field scope can express whether a class of field can be written, but cannot express cross-field rules — for example, "B can only change if A changes." The window column was added later; older records that predate it don't return this field — their windows are unknowable, and the author doesn't fabricate default values for them.

As for "why not sign a credential for each approval" — the author ran the numbers: confirmations are already one-shot, credentials are inherently short-lived and scoped to a single target system, and targets are now bound. Together, these already cover the concerns. Adding another layer buys duplicate complexity, not new guarantees. So this is a trade-off, not an unfilled gap.

The "credential" referenced here corresponds to security mechanisms like capability tokens or macaroons — embedding all authorization constraints into a verifiable, transferable token that allows the holder to complete authentication without querying central state. The advantage of such schemes is decentralized verification; the disadvantage is difficult revocation: once a token is issued, it cannot be recalled within its validity period without an additional revocation list. The author's choice to continue relying on database records rather than tokens means revocation only requires marking that row as invalid — execution-side queries to the database immediately detect this. The trade-off is a database read on every execution, but in exchange you get immediate revocability. This trade-off is especially important in AI autonomous write operation scenarios: when a user discovers an approval was made in error, they should be able to retract it before the operation actually executes, not wait for the token to naturally expire.

Back to the Beginning

Every promise along the entire chain ultimately rests on this one link. Audit records track who approved what; revocation has to restore that approved write. If this link is thin, every link after it quietly covers for it.

The five things worth binding are worth listing again: exact parameters, target system, writable field scope, validity window, operator and decision moment.

This is a set of engineering practices for how human confirmation should work in AI autonomous write operations. The core insight is simple yet profound: a human's "agreement" must be bound into an auditable, non-drifting credential — not a boolean that gets reinterpreted at the moment of execution.