Ask a supplier how they will keep an AI system safe and you will often get the same answer. It will ask you before it does anything.
The system pauses, shows you what it wants to do, and waits for a click. You stay in control. Nothing happens without a human saying yes.
It sounds right. Anthropic measured what actually happens, and the number is uncomfortable.
The 93% problem
From Anthropic’s own engineering write-up on containing Claude across their products:
Our telemetry showed users approved roughly 93% of permission prompts. The more approvals a user sees, the less attention they pay to each.
More than nine times in ten, the prompt is a formality. And the mechanism degrades the more you use it, because attention is finite and every prompt spends some.
This matters more than it first appears. The obvious reading is that users are careless and need training. The better reading is that approval fatigue is a property of the design rather than a failing of the person. Adding more prompts does not add more safety. It adds more prompts, and makes each one weaker.
Anthropic’s response was not to write a guide about reading prompts carefully. They built sandboxing, which cut permission prompts by 84%, and open-sourced the runtime so the boundary can be audited. They moved the safety somewhere the user does not have to be vigilant.
The distinction almost nobody draws
Two things look identical on screen and are not the same at all.
Approval as a business step. “Here is the quote I have drafted for Mrs Patterson. Shall I send it?” The client can answer that. It is their business, their customer and their price. They are the only person who should be deciding it.
Approval as a security control. “This process wants to connect to that system. Allow?” The client cannot meaningfully answer that. Answering it well requires knowing what that system holds, what the process would do with it, and what happens if the request is not what it appears to be.
Anthropic are explicit about where the line falls:
When approving an exception requires expertise the typical user doesn’t have, admins should set a boundary that is absolute and always-on.
Their reasoning is worth following, because it explains why the approval model works at all where it does. Claude Code was built for developers: “The average user is a developer who’s familiar with coding environments: they can read bash, they understand what rm -rf does.” That user can evaluate the prompt. For everyone else, Anthropic reject approval as the primary defence and move to environmental boundaries instead.
Almost every small business is in the second group.
This is also an argument for building the simplest system that solves the problem, because a workflow whose steps are written down has a much smaller surface to contain than an agent choosing its own route.
The case for the other side
Plenty of experienced practitioners recommend baking a human approval step into every AI implementation and treat it as the safety answer. Several of the popular tutorials hand the client per-tool controls: approve, block, or auto-approve. That advice is not foolish and it is worth understanding before dismissing it.
It comes from a real problem. A system acting without oversight can do damage quickly, and an approval step is the fastest thing to build that looks like oversight. It also feels respectful, because it keeps the client in charge of their own business.
We do not follow it, and the reason is not that a model provider published something. It is that the advice carries an assumption it never states: that the person clicking can evaluate what they are approving. Where that assumption holds, approval is a reasonable control. A developer watching a coding tool can read the command and knows what it will do.
Where the assumption fails, the same mechanism produces the appearance of oversight and none of the substance. The telemetry is useful because it tells you which situation you are in, not because it settles the argument by authority.
What “you approve each action” actually does
Here is the part that should change how you read a proposal.
A prompt asking a non-technical owner to authorise something technical does not protect them. It moves the responsibility for the outcome onto the person least equipped to carry it, and it does so in a way that looks like a favour.
If something goes wrong afterwards, the record shows they clicked yes. They did. They also had no basis on which to click no, and the ninety-third prompt of the week did not read any differently from the ninety-second.
That is a liability transfer dressed as a safeguard.
What to ask for instead
The alternative is unglamorous and much stronger. Decide in advance what the system can reach, encode that in the environment, and stop asking.
Anthropic put the principle plainly: design for containment at the environment layer first, then steer behaviour at the model layer. Containment means the system does not have credentials for the thing it should not touch, cannot reach the network it has no business reaching, and operates on a copy where a copy will do.
Then the questions you put to a supplier change shape.
Which systems can this reach, and which can it not? You want a list, not a reassurance. If everything is reachable and the control is a prompt, there is no boundary.
What happens if it tries to do something outside that? The right answer is that it fails, and somebody is told. The wrong answer is that you will be asked.
Which decisions will I be asked to make, and why me? Every prompt should be a business judgement you are qualified to make. If you are being asked to authorise something technical, ask why that decision was not made in advance by whoever built it.
What can I not accidentally do? This is the useful inversion. A good answer describes things that are impossible rather than things that are discouraged.
The version that sells better anyway
There is a commercial argument here, and it runs opposite to instinct.
“You approve each action” sounds like control and reads, on reflection, as risk. The client is being handed a job they did not ask for and cannot do.
“You cannot accidentally authorise something harmful, because the things that would be harmful are not reachable” is a stronger promise, and the person making it is accepting responsibility rather than distributing it.
The second is harder to build. It requires deciding, in advance, what the system is allowed to touch, which requires understanding the business well enough to know. That work is the job. The prompt is what gets offered when the work has not been done.
The honest limit
None of this argues for removing the human. It argues for asking them the right question.
Keep people in the loop wherever the decision belongs to the business. Whether to send the quote, whether the tone is right, whether this customer is a special case: those are exactly the judgements a person should be making, every time, and a system that automates them past the owner is worse rather than better.
The rule is narrow and it holds: never ask someone to authorise something whose consequences they have no way to evaluate. If a decision needs expertise they have no reason to have, it is a boundary somebody sets in advance. It is not a prompt.
Frequently asked questions
Is human-in-the-loop approval bad?
No, when the question belongs to the person answering it. Approving a draft quote or a customer email is a business judgement the owner is qualified to make. The problem is using the same mechanism to ask them to authorise technical actions they cannot evaluate.
What is approval fatigue?
The observed effect that the more permission prompts someone sees, the less attention they give each one. Anthropic’s telemetry found roughly 93% of prompts approved, and noted that attention falls as volume rises. It is a property of the design rather than a training failure.
What should replace approval prompts for security?
Environmental boundaries decided in advance: what the system holds credentials for, what it can reach on the network, and what data it operates on. Anthropic describe this as designing for containment at the environment layer first, then steering behaviour at the model layer.
How do I tell whether a supplier has done this properly?
Ask what the system cannot reach, and what happens when it tries. A supplier with real boundaries can list them. A supplier relying on prompts will describe the approval screen instead.
Does this mean I lose visibility over what the AI does?
The opposite. Boundaries set in advance are written down and auditable. A stream of prompts leaves a record that somebody clicked yes, which tells you little about whether the decision was sound.
Flux Dynamics is a fractional CTO who builds. We decide what a system can reach before it is built, so the client is never asked to authorise something they have no basis to judge. Tell us what you are considering.