Human approval that isn't theater

On August 18, 2026, TechTarget published a piece on AI agent security in which Jess Burn, principal analyst at Forrester, asked the question the market had been avoiding: if a person is reviewing hundreds of decisions after the fact, or approving actions they cannot independently validate, or without the expertise to know what they are looking at, is that oversight, or is it just some sort of accountability theater?

In the same piece, Will Pearce of Dreadnode points to the way out: the step defenders need to take is not caring less, it is becoming less policy-driven and more action-driven.

The criticism is fair. It applies to us too, because "you decide, Myrmex executes" is our line. So it deserves an answer, and the answer is not to swear we have human approval. Everyone has that.

What makes an approval empty

An approval is empty when the human cannot evaluate what they are approving. That happens in three ways, and none of them is fixed by adding another checkbox.

It happens through volume: thirty requests an hour are not thirty decisions, they are one repeated signature. It happens through opacity: approving "run remediation on the endpoint" without seeing what will run is authorizing a closed box. And it happens through drift: when the record keeps the intent but not the command, what ran can diverge from what was approved, and nobody can prove the difference afterwards.

The outcome is the same in all three cases. You end up with a record of who clicked, not a record of what happened. That passes a process audit and fails the moment someone has to answer what was actually done to the estate.

The right question has three parts

We replace "is there human approval?" with three questions that can each be verified:

1. What the human sees before deciding.
2. What happens during, once they decide.
3. What is left on record after.

These three are where governance separates from theater, because all three produce evidence.

Before: the plan comes before the action, and approval leaves the chat

In MYRMEX, what goes up for approval is not the request, it is the plan. Before a network change in our own environment, the platform built a numbered plan with the target and the predicted impact of each step, asked whether it could create the change draft, and registered the change with the implementation steps and the rollback steps side by side, before any execution.

The detail that changes the nature of the thing is where the approval happens. It does not happen in the conversation. The change stays in draft and has to be reviewed, approved and put into execution on the change management screen. That matters because the record of the authorization stops being a chat message, which is hard to audit and easy to lose sight of, and becomes a governance object with state, window, affected assets and a way back.

On assets classified as critical, the requirement appears one step earlier. The platform states that the device is configured to ask for confirmation before any query or edit, and asks for explicit authorization even for a read. At first that looks like excessive caution, and it is not: it is the only way an operator finds out that an asset is critical at the moment it matters, rather than in next month's report.

During: verify instead of assume

Execution in MYRMEX follows a rule we call Ground Truth Only: never simulate output, never assume success. The agent executes and reads the real response from the operating system or the vendor's API, and that response is what becomes status.

The consequence shows up when something fails. In a change execution in our own environment, a step stalled because the session with the equipment timed out. The product did not complete the table with what was likely. It wrote that the real-time read commands had not been collected on that attempt, that no table or assumed value would be presented, named the calls that had failed, and offered two ways forward, one of them the rollback already registered in the change.

The same pattern shows up in auditing. When part of the controls in a compliance audit could not be evaluated because an API was not reachable, the result said so in plain text and kept a conservative posture, instead of displaying some value. Declaring what could not be determined is what separates a finding from a generated report. And it is the opposite of the pattern that damages trust in automation most, which is the source failing while the screen shows a number.

An approval is worth nothing if what follows reports success it never verified.

After: the execution chain, not just the outcome

The record that matters is not "action X completed". In the MYRMEX audit trail, each event opens with named fields: date and time, source, type, user, agent, tool, target, command, status, duration, session and invocation, plus the payload of the call. The effective command appears in full, exactly as it ran.

Two of those fields do most of the work.

The first is the separation between user and agent. They are two distinct fields, and the source of the event is recorded separately. Without that, an access review cannot answer the most basic question of the year: of these actions, how many were people? As agents get their own identities and permissions, a record that treats both as "user" loses the ability to answer that exactly when it starts being asked.

The second is the effective command. It is the difference between knowing that someone approved a remediation and knowing what the remediation did. Without it, the record describes a decision. With it, the record reconstructs a fact.

This is also why the record has to be born structured, field by field, rather than turning into running text in a log. A paper accepted at BCCA 2026, an IEEE conference, measured the difference: structured forensic queries reached 1.0 precision on guardrail and delegation lookups, while unstructured text search came in at 0.013 and 0.077. That is two orders of magnitude, and it shows up at the worst possible moment, when someone needs to reconstruct what happened.

What to ask any vendor, including us

If you are evaluating platforms with agents that execute, these five questions separate whoever thought about the problem from whoever added a button:

1. What goes up for approval, the request or the plan?
2. Does the plan have a rollback written before execution, or only after it breaks?
3. Where is the authorization recorded: on a governance screen, or in a chat message?
4. Does whatever executes verify the real result, or assume success?
5. Does the record keep the effective command and separate human action from agent action?

None of them is about autonomy, and that is why they work. Autonomy is a poor ruler: every vendor positions itself wherever the conversation makes convenient. The five above are verifiable in a demo, in fifteen minutes, and require taking nobody's word for anything.

Where we stand

We still say you decide and Myrmex executes. What this post adds is what holds up the first half of that sentence: a decision needs a readable plan before, real verification during, and a reconstructible record after. Without all three, "human control" is a marketing line.

We recently wrote about why we reject the AI SOC and AIOps labels, and the reason is the same one that shows up here: operations happen inside the customer's own technology, and that is where the evidence has to be produced.

Read the ITOps and SecOps post · See the features · See the plans

Sources cited:

Sharon Shea, "AI agent security must move beyond human in the loop, experts say", TechTarget, 08/18/2026.

Bindschaedler, Botha and Siebenbrunner, "Agent Flight Recorder: Tamper-Evident Audit Trails with On-Chain Anchoring for Long-Horizon Tool-Using Agents", arXiv 2609.01931, accepted at BCCA 2026.