A manager clicks “Approve.” The AI agent executes the action. Everyone assumes the process was safe. But what if the manager never really understood what they approved?
This is one of those problems that looks solved in a product demo and becomes much more complicated in a real business.
Human approval is often presented as the ultimate safety net for AI agents. If an action is risky, the agent pauses, asks a human, and waits for permission.
Sounds sensible.
But there's a big difference between asking someone to approve an action and giving them enough information to make a meaningful decision.
If an approval screen says “The AI wants to make changes. Approve?”, what exactly is the human approving?
Which record will change? What values will be written? How much money is involved? Can the action be undone? Will the agent perform one operation or several?
Without those details, approval becomes a ritual rather than a security control.
The refund that looked harmless
Imagine a support manager using an AI assistant to handle customer refunds.
The agent investigates a complaint and decides that a refund is appropriate. Before proceeding, it sends the manager a notification:
“Refund requested. Approve?”
The manager is busy. There are dozens of support tickets waiting. The notification looks routine, so the manager clicks approve.
The refund goes through.
Only afterward does the manager discover that the AI selected the wrong order and refunded $450 instead of $45.
The manager technically approved the operation. But did they approve the correct operation?
Not really. They approved a vague description of what the agent intended to do.
A better approval request would include the customer, order number, refund amount, reason, and any relevant policy limits. It would clearly distinguish the exact operation being proposed from a general request to proceed.
That is the foundation of meaningful AI approval workflows.
Approval needs to describe the consequences
Humans are good at making decisions when they have relevant information. We're much less effective when asked to approve something we barely understand.
An approval request should answer a few basic questions.
What will happen? Describe the actual operation in plain language.
What will be affected? Identify the relevant customer, order, invoice, account, or system.
What will change? Show the current value and proposed value when appropriate.
Why is the agent proposing it? Give enough context to understand the decision.
What happens next? Explain whether the action is reversible, permanent, or likely to trigger additional operations.
Consider these two approval messages:
“Approve customer update?”
And:
“Approve changing the delivery address for order #4821 from 14 Lake Road to 82 Park Street? The order has not shipped yet.”
The second message gives the reviewer something concrete to evaluate.
They can spot an incorrect address, question the timing, or recognize that the request is associated with the wrong order.
The first message mostly asks them to trust the AI.
The problem with approval fatigue
There's another reason vague approval requests are dangerous: people get used to them.
Think about the number of notifications an operations manager might receive in a typical day. Purchase requests, expense claims, customer escalations, invoice approvals, and internal messages all compete for attention.
Now add an AI agent that asks for approval every few minutes.
At first, the manager carefully reviews every request. Then the requests become familiar. Most appear harmless. The manager starts approving them quickly.
Eventually, approval becomes a reflex.
This is not necessarily a problem with the person reviewing the request. It's a predictable result of a process that demands too much attention without providing enough useful information.
Good business process automation should reduce unnecessary interruptions, not create an endless stream of meaningless confirmation dialogs.
A better approach is risk-based approval.
Routine, low-impact actions can proceed within clearly defined permissions. Sensitive changes require additional scrutiny. Destructive operations receive the strongest controls.
The goal is not to make humans approve everything. It's to make sure human attention is used where it can genuinely prevent harm.
One approval should authorize one specific action
Here's a technical detail that deserves more attention.
Suppose an agent asks a manager to approve a $75 refund for order #4821.
The manager reviews the details and approves it.
Before execution, the agent changes the refund amount to $750. Perhaps the model reconsidered its decision. Perhaps the system encountered an unexpected result. Whatever the reason, the proposed operation is no longer the one the manager approved.
A secure workflow must reject that substitution.
The approval should be bound to the specific action and its arguments. If the amount, target record, operation, or other material details change, the system should require a new approval.
The same principle applies to multi-step workflows.
Approving an invoice draft should not automatically authorize sending it to the customer if that was not part of the original request. Approving an account update should not grant permission to delete the account.
One approval should authorize one clearly defined action, unless the reviewer has explicitly approved a carefully described sequence of operations.
This is an important principle for secure AI agents: the approval process must be enforced by the application, not merely remembered by the model.
What should an approval screen actually contain?
For a high-impact action, I would expect an approval request to include:
- The requested action: A clear description of what will happen.
- The target: The exact record or resource affected.
- The arguments: Important values, including amounts, identifiers, and proposed changes.
- The reason: A short explanation of why the agent chose this action.
- The risk: Whether the action is reversible or potentially destructive.
- The decision: Explicit approve and reject options, with no ambiguity about what each means.
The system should also record who approved the operation, what they saw, when they approved it, and which exact action was executed.
For particularly sensitive operations, it may need additional checks, such as revalidating the user's permissions immediately before execution.
This creates an auditable link between the human decision and the resulting action.
It also makes investigating mistakes much easier.
Approval through chat needs the same discipline
Many businesses want to approve operations through messaging tools because that's where their teams already work.
A manager might receive a WhatsApp or Telegram message asking them to approve a refund, a stock adjustment, or an order cancellation.
That's convenient. But convenience doesn't remove the need for context.
A chat-based approval should identify the exact operation, show the important details, and make it clear which action the manager is authorizing.
The system must also verify that the person responding is authorized to approve that operation.
A simple reply such as “yes” should not become a reusable authorization token for whatever the agent decides to do next.
For teams using AI agents with existing business systems, the challenge is to make approvals convenient without weakening the rules that govern execution.
How this works with existing systems
You don't need to rebuild an entire business application just to introduce AI-assisted workflows.
You can connect an agent to existing APIs, databases, and internal tools, then define which operations require approval and which permissions apply to each user.
For example, Caterfli focuses on connecting existing systems to AI agents so teams can interact with them through natural language. When designing any such workflow, the key is to ensure that approval happens before the sensitive action and that the approved arguments are the ones ultimately executed.
Start with a few important operations rather than trying to approve everything.
Refunds, record deletion, permission changes, and other high-impact actions are good candidates. For each one, define the information the reviewer needs, the approval conditions, and the checks that must run before execution.
Then test what happens when someone rejects the request, when the underlying record changes, and when the proposed arguments change after approval.
Those cases are just as important as the successful approval.
The real purpose of human approval
Human approval should not exist merely to make an AI system appear safer.
It should give a person a genuine opportunity to understand an action, evaluate its consequences, and decide whether it should happen.
That requires more than a button.
It requires accurate information, clear responsibilities, meaningful permissions, and a system that respects the decision the human actually made.
Personally, I'd rather see an agent pause and explain an uncertain action than send a vague approval notification that everyone learns to ignore.
AI automation should save people time, but it shouldn't turn their judgment into a rubber stamp.
If a person cannot tell exactly what they're approving, the approval isn't a meaningful safety control. It's just another click.
Top comments (0)