AI agents are becoming increasingly capable of doing more than generating text.
They can browse websites.
Read files.
Write code.
Send messages.
Update records.
Create documents.
Use APIs.
And in some systems, they can initiate actions that affect real users or real business data.
That creates a fundamental engineering question:
When should an AI agent be allowed to act automatically, and when should it stop and ask for approval?
The answer should not be:
Ask for approval before everything.
That makes automation frustrating.
But it should not be:
Let the agent do anything once the user clicks Start.
That creates unnecessary risk.
The better approach is to design approval gates around the consequences of each action.
Start by Separating Thinking From Acting
An AI agent may perform several different kinds of work.
Some steps only produce information.
Others change the outside world.
For example:
Read a document
Summarize requirements
Compare two options
Draft an email
These are mostly reversible or read-only.
Now compare them with:
Send the email
Delete a file
Purchase a service
Change database data
Deploy code
Modify permissions
The second group creates real consequences.
A useful design principle is:
Let the agent think freely.
Control when it is allowed to act.
Classify Actions by Risk
Do not treat every tool call equally.
A simple risk model can divide actions into three categories.
Low-risk actions
Examples:
searching public information
reading documentation
opening a file the user already provided
calculating values
creating a draft
These actions usually do not need repeated approval.
Medium-risk actions
Examples:
editing a document
creating a new file
updating a task
changing a calendar event
preparing a database update
These may require approval depending on context.
High-risk actions
Examples:
sending money
publishing content
deleting data
deploying production code
changing user permissions
sending external messages
These should normally require explicit confirmation.
The exact categories depend on the product.
What matters is defining them intentionally.
Approval Should Be Based on Consequence
A useful question is:
What happens if this action is wrong?
Suppose an agent incorrectly summarizes an internal document.
The consequence may be limited.
Now suppose the same agent sends that incorrect summary to 10,000 customers.
The underlying text-generation error may be identical.
The consequence is completely different.
Approval requirements should therefore follow impact, not just model confidence.
Make the Proposed Action Visible
An approval request should tell the user exactly what will happen.
Bad approval:
Proceed?
Better approval:
Send this email?
Much better approval:
Send the following email to 126 customers in the “Trial Expiring” segment using support@company.com.
The user should be able to understand:
what action will happen
which data will change
who will be affected
which account will be used
whether the action can be reversed
Approval without context is not meaningful approval.
Show the Final Payload
When possible, show the actual data that will be submitted.
Suppose an agent wants to create a support ticket.
Before approval, display:
Title
Description
Priority
Assigned team
Customer
Attachments
This gives the user a chance to catch errors before execution.
The same principle works for:
emails
API requests
database updates
calendar events
social posts
code changes
The user should approve the real action, not an abstract description of it.
Do Not Ask for Approval Too Early
Imagine this workflow:
User asks:
Research three monitoring platforms and recommend one.
The agent immediately asks:
May I browse the web?
Then:
May I open this page?
Then:
May I open another page?
Then:
May I compare pricing?
This creates approval fatigue.
Most of these steps are read-only.
A better workflow allows the agent to complete the research independently.
Approval should appear only when the agent is about to do something consequential, such as:
start a paid subscription
contact a vendor
change production configuration
This keeps the experience useful without removing control.
Avoid Approval Fatigue
Users learn to ignore prompts when they see too many of them.
This is the same problem seen with cookie banners, operating-system permissions, and security warnings.
If an AI agent asks:
Approve?
Approve?
Approve?
Approve?
the user may eventually click Approve without reading.
At that point, the approval system technically exists but provides little protection.
Approval gates should be rare enough that users recognize them as meaningful.
Group Related Actions
Suppose an agent needs to update 40 records using the same rule.
Asking for 40 approvals is unreasonable.
Instead, show a batch summary:
The agent will update 40 customer records.
Field changed:
account_status
Current value:
trial
New value:
expired
Users affected:
40
Then ask for one approval.
Batch approval is useful when:
the operations are similar
the scope is visible
the user can inspect affected items
the action follows one consistent rule
But Do Not Hide Mixed Actions Inside a Batch
Batching becomes dangerous when unrelated operations are grouped together.
For example:
Update 35 customer records
Delete 3 files
Send 12 emails
Change 2 permissions
Approve all?
That is too broad.
Different action types have different consequences.
Separate approval groups by risk and intent.
Use Threshold-Based Approval
Some actions become risky only above a certain scale.
For example:
Send email to one internal teammate
may not need approval.
Send email to 5,000 customers
probably should.
You can create thresholds.
Examples:
File deletion
1 temporary file: automatic
More than 10 files: approval
Database update
1 test record: automatic
More than 100 production records: approval
Financial action
Below $5 test transaction: automatic in sandbox
Any real payment: approval
Thresholds turn vague safety rules into predictable system behavior.
Use Environment as a Risk Signal
The same action can have different consequences depending on the environment.
Deleting data in:
local development
is very different from deleting data in:
production
Similarly:
deploy to staging
may be low risk.
deploy to production
is higher risk.
Approval logic should understand environments.
A useful rule might be:
Development: automatic
Staging: automatic with logging
Production: explicit approval
Separate Preparation From Execution
One of the strongest agent patterns is:
Prepare automatically.
Execute only after approval.
For example:
The agent can:
analyze database records
generate the SQL update
calculate affected rows
show a preview
Then stop.
The user approves.
Only then does the system execute the update.
This keeps most of the automation benefit while preserving human control at the critical moment.
Make Destructive Actions Harder
Not every approval button should look the same.
A low-risk confirmation might use:
Approve
A destructive action could require:
Delete 2,341 records
This forces the user to understand the specific operation.
For extremely sensitive actions, you can add stronger confirmation such as:
typing the resource name
re-authentication
two-person approval
a short delay before execution
High-friction confirmation should be reserved for high-impact actions.
Add Reversibility When Possible
An action becomes safer when it can be undone.
Instead of:
Delete file permanently
use:
Move file to trash
Instead of:
Overwrite database record
use:
Store previous value and update
Instead of:
Immediately publish
use:
Save as scheduled draft
Reversibility can reduce the need for aggressive approval while still protecting users from mistakes.
Use Idempotency for Executable Actions
Agents may retry.
Networks fail.
Requests time out.
The agent may not know whether an operation succeeded.
Imagine a payment request.
The agent sends it.
The connection times out.
The agent retries.
Without protection, the user could be charged twice.
Actions that can be retried should use idempotency where possible.
For example:
Create one unique action ID.
Reuse it during retries.
The receiving service recognizes the duplicate and does not execute the same transaction twice.
This is especially important for:
payments
orders
ticket creation
messages
database writes
external API calls
Log Every Approved Action
Approval systems should create an audit trail.
Record:
who requested the task
what the agent proposed
who approved it
what tool was called
what parameters were used
when the action happened
whether it succeeded
what changed
This becomes essential when a user later asks:
Why did the system do this?
Without logs, the answer may be impossible to reconstruct.
Record Rejected Actions Too
Rejections are valuable data.
Suppose users repeatedly reject an agent when it tries to:
send emails too early
delete files
choose expensive plans
update incorrect fields
That pattern may indicate a planning problem.
Track:
proposed action
rejection reason
task type
agent version
Repeated rejections can become signals for improving:
prompts
tool permissions
planning logic
approval thresholds
Do Not Rely Only on Model Self-Assessment
You could ask the model:
Is this action risky?
But the model should not be the only authority deciding whether it needs approval.
Risk classification should include deterministic application rules.
For example:
tool = delete_database_rows
environment = production
affected_rows > 0
Then:
approval_required = true
The model may help describe the risk.
The application should enforce the policy.
Create Explicit Tool Permissions
Agents should not automatically have access to every available action.
Instead, define permissions by tool.
For example:
Research agent:
Allowed:
web search
read files
generate reports
Not allowed:
send email
modify CRM
purchase products
Deployment agent:
Allowed:
read repository
run tests
deploy staging
Approval required:
deploy production
Not allowed:
change billing
This is easier to reason about than giving every agent universal capabilities.
Use Scoped Credentials
An agent should receive the minimum access needed for its task.
Do not give:
full administrator credentials
when the task requires:
read-only analytics access
Use:
limited API keys
temporary tokens
scoped permissions
service accounts
environment-specific credentials
If the agent makes a mistake, limited permissions reduce the possible damage.
Time-Limited Permissions Can Help
Some permissions only need to exist during one workflow.
For example:
User approves access to a shared folder for 30 minutes.
After the task:
permission expires.
This reduces the risk of persistent access that nobody remembers later.
Approval Should Be Bound to the Exact Action
Imagine the user approves:
Send $50 to Vendor A.
The agent should not be able to reuse that approval for:
Send $500 to Vendor B.
Approval should be linked to the exact action parameters.
If important parameters change, approval should become invalid.
For example:
recipient changed
amount changed
database changed
file list changed
message changed significantly
Then request approval again.
Revalidate Before Execution
Time can pass between proposal and approval.
The environment may change.
Suppose the agent proposes:
Delete inactive accounts older than two years.
The user reviews it 30 minutes later.
Before execution, the system should confirm that:
the target records still match the condition
permissions are still valid
the operation is still allowed
This prevents stale approvals from producing unexpected actions.
Design for Partial Failure
Suppose an approved batch contains 100 operations.
60 succeed.
40 fail.
What should happen?
Possible strategies include:
stop immediately
continue remaining operations
roll back successful changes
retry failures
ask for another approval
The correct answer depends on the task.
But it should be designed before the agent starts performing important batch operations.
Approval Gates Work Best With Specialized Agents
General-purpose agents can perform increasingly broad tasks, including browser operations, research, code execution, file processing, and application-building workflows.
A general-purpose AI agent can be useful for understanding how multi-step autonomous workflows are evolving and why action boundaries become important as agents gain more tools.
But broader capability makes permission design even more important.
The more an agent can do, the more carefully its actions should be scoped.
A Simple Approval Policy
A practical policy might look like this:
Read-only public information
Automatic
Read internal information
Automatic if permission already exists
Create draft content
Automatic
Modify internal reversible data
Automatic below defined thresholds
Send external communication
Approval required
Delete information
Approval required
Purchase something
Approval required
Change permissions
Approval required
Deploy production code
Approval required
Financial transactions
Strong approval required
This gives both developers and users predictable behavior.
Show Users Why Approval Is Required
A useful approval UI can say:
Approval required
Reason:
This action sends information outside your organization.
Or:
Approval required
Reason:
This operation will modify 438 production records.
That teaches users how the system works and makes the approval less arbitrary.
Measure Approval Quality
Once the system is running, track metrics such as:
approval rate
rejection rate
time to approval
actions canceled after preview
approval rate by tool
approval rate by risk level
repeatedly rejected action types
If 99.9 percent of one low-risk action is approved immediately, the gate may be unnecessary.
If users reject 30 percent of another action, the gate is probably valuable.
The Goal Is Calibrated Autonomy
Good AI agent design is not:
maximum automation
or:
maximum human control.
It is calibrated autonomy.
The agent should handle routine, low-risk work independently.
Humans should remain involved where mistakes create meaningful consequences.
That boundary can evolve as the system becomes more reliable.
Final Thought
The most important question for AI agents is no longer only:
Can the model complete the task?
It is increasingly:
What should the model be allowed to do without asking?
Separate thinking from acting.
Classify actions by consequence.
Give agents limited permissions.
Show users exactly what will happen.
Require approval for high-impact actions.
Make important changes reversible.
Log every execution.
As AI agents become more capable, good approval design will become one of the main differences between useful automation and dangerous automation.
AI-assisted disclosure: This article was created with AI assistance and reviewed and edited for clarity and accuracy before publication.
Top comments (0)