The Approve Button That Wasn't Attached to Anything
An AI approval gate is theater unless the click writes a record, the record binds the exact content, the approval expires, and the send returns the platform's own receipt.
A common safety story follows AI agents into production: a human approves everything before it goes out.
I use that pattern too. AI agents draft public engagement content for my personal brand: comments, replies, and short posts. Nothing ships until I approve it in a private channel. I built it that way on purpose because I do not delegate my name to a language model.
Last week I audited my own approval gate. The button looked perfect. It rendered beautifully under every AI-drafted proposal, green and confident and reassuring.
For some of those cards, it was attached to nothing at all.
The night the button did nothing
The first live send through the chain was supposed to be a formality. The agents had drafted a comment, the approval card was sitting in my channel, and I tapped Approve. Nothing happened. No confirmation, no error, nothing except a tiny warning icon in the chat client, the kind of glyph that is easy to dismiss and impossible to diagnose.
It turned out the button could fail in two completely different ways, and I had both.
The first failure: the card had been posted by the wrong messenger. Two apps post into that channel, and the card came from one that has no ability to hear button taps. The platform routes a tap to whichever app posted the message, so my decision died quietly inside the chat client. No server I control ever saw it.
There was nothing to debug on my side, because on my side nothing had happened. To be clear, that routing behavior is documented and correct; the wiring mistake was mine. But beyond that one cryptic icon, the interface gave no hint about what was wrong or where. The button looked exactly as clickable as a working one.
The second failure was worse. Some cards reached me without a backing record. The approval store, the system of record a tap is supposed to write a decision into, had never been told the proposal existed. So even when my tap did reach my own server, there was nothing to attach the decision to. An approval with no object. That night I created the record by hand so my own click would mean something.
Neither failure threw an error. Both cards were pixel-identical to a working one. That is the detail worth sitting with: when approval is a user-interface element rather than a bound record, the system cannot tell the difference between "a human approved this" and "a button existed."
Green with nothing to catch
Once the wiring was fixed, I ran an adversarial audit before trusting the system with anything more: 88 bounded review passes across six failure-mode lenses, with three independent attempts to refute each candidate finding. Twenty-seven findings survived. Three were blocking.
The finding that reframed everything was not a defect in the send logic. The automated send branch had never actually fired for a real item. Every scheduled run had found an empty queue and done nothing. The one genuine send so far had been my manual test.
The send path was green with nothing to catch.
A healthy system and a system that has never been exercised can produce the same dashboard.
Of the three blocking findings, two are worth telling in full.
First, approvals did not expire. An approval sat in the store as a permanent fact, so a paused sender brought back online a week later would happily fire a week-old yes into a world that had moved on. An approval is a claim about a moment. Mine had no clock on it.
Second, and this is the one that still bothers me: the approval was bound to a label, not to the words. The sender verified a reference that traveled with the proposal, not the content itself. If the text changed after I tapped Approve, through an edit or a regeneration, the system would send the new words under my old yes, mark the job done, and leave no trace that what shipped was not what I saw. My approval covered a pointer, and the pointer's target could drift.
The third blocking finding is additional layered protection that I will not detail publicly while it is in progress. Transparency about the first two is cheap now because they are closed. Discretion about the third is the same discipline pointed the other way.
The row that lies
There was one more lesson hiding in the audit trail, and it is my favorite because it is so easy to fall for.
Early in the build, the store showed rows reading approved and fired. They looked like end-to-end proof: a decision was made, a send went out, the pipeline works. They were nothing of the kind. Those rows were synthetic test entries, and the fired flag they carried was a write my own system had made to itself. The real dispatch leg had never once executed.
"Fired" in your own database is a sentence your system says about itself. Any test path can say it. An internal fired flag does not prove that the outside world accepted anything. External proof begins with the platform's own object identifier, preserved in the audit trail and tied to an artifact that can be inspected.
So we adopted a proof standard with three legs. A decision row created by a real human interaction. A receipt carrying the platform's own identifier for the thing that was created. And the thing itself, visible on the platform. Anything less is your database congratulating itself.
The first send to meet that standard was a comment placed on my own post, chosen deliberately as the lowest-stakes target available. The first fully integrated send to someone else's post came a day later, with no manual bridging anywhere in the path.
What a real approval path has to guarantee
Acting on the audit took eleven separate fixes across four codebases. The agents built every one; I reviewed and approved every one by hand before it landed. From first build to hardened chain took about sixty hours, and the audit landed roughly a day after I had first declared the system finished. It was not finished. Systems rarely are when the person declaring it is also the person who built it.
Here is what the approval path guarantees now, stated as properties rather than implementation. They operate at three layers: the integrity of the decision, the evidence of execution, and the integrity of the operation around both.
The integrity of the decision:
Wired. A tap writes a decision into a system of record. If there is no record, there is no approval, and the send refuses.
Bound. At approval time the system seals a tamper-evident fingerprint of the exact content approved. At send time it recomputes that fingerprint and refuses to ship anything that drifted, even by a character.
Fresh. Approvals expire after 48 hours. A stale yes is treated as a no. The failure direction is always refusal.
The evidence of execution:
Receipted. A send counts as sent only when the platform's own identifier is recorded in the ledger. Internal flags are bookkeeping, not evidence.
The integrity of the operation:
Durable. The audit ledger is write-once and copied off the machine that produces it. History someone can quietly rewrite is not history.
Owned. The send path has named owners, and changes to it automatically request their review. The most safety-critical code should be the hardest to change casually.
Alive. The system that does the sending proves it is alive every day, because a dead sender and a healthy idle one are otherwise identical. Silence should never be allowed to impersonate health.
Through all of this, one fact held: no unapproved content ever went out. Every real send was human-tapped, and the gaps were latent rather than exploited. That is not a reason for comfort. It is the definition of luck, and the entire point of auditing before the incident is to stop renting your safety story from probability.
Five questions for your own approve button
If your team's AI safety story is "a human approves everything," these five questions will tell you whether that story is a system or a feeling.
When someone clicks approve, where exactly is that decision recorded? If the answer is "in the chat thread," you have a vibe, not a record.
What did the approval cover: the exact content that shipped, or a reference to content that could still change after the click?
Can an old approval fire? If nothing expires, every approval you have ever granted is still live ammunition.
What proves a send actually happened: a flag your own system set, or a receipt from the platform it shipped to?
If the system that does the sending died tonight, would tomorrow look any different from a quiet day?
Last edition I argued that instructions are not control flow: what you write in an agent's prompt is a suggestion the model weighs, not a rule the system enforces. This week is the same law, one layer up. A human in the loop is not control flow either, until the loop is a structure: wired, bound, fresh, receipted, durable, owned, alive. The button was the easy part. Making "approved" a fact instead of a feeling took an adversarial audit and eleven reviewed fixes, and the audit only happened because I assumed I was lying to myself.
The gate is only as real as what it is attached to.