AI agents are increasingly capable of doing more than generating text.
An agent can call APIs, update records, send messages, process transactions, create support tickets, modify files, and interact with business systems.
That capability creates an important architectural question:
Which actions should an AI agent execute autonomously, and which actions should require human approval?
Giving every tool unrestricted autonomous access creates unnecessary risk.
Requiring approval for every tool creates unnecessary friction.
A better design is to introduce approval gates around actions where mistakes, misuse, or unexpected model behavior could have meaningful consequences.
Microsoft's current Agent Framework guidance supports human-in-the-loop approval for sensitive function tools. When an approval-required tool is invoked, the agent run pauses and the application receives an approval request instead of immediately executing the operation.
This article explains how to design approval gates that are practical, auditable, and suitable for production agent architectures.
What Is an Approval Gate?
An approval gate is a control point between an agent's decision to execute an action and the actual execution of that action.
Without an approval gate:
User
|
v
AI Agent
|
v
Tool
|
v
Action Executed
With an approval gate:
User
|
v
AI Agent
|
v
Tool Request
|
v
Risk Check
|
v
Human Approval
|
+---- Reject
|
+---- Approve
|
v
Tool Executes
The important distinction is that the model can request an action without automatically receiving permission to perform it.
Why Approval Gates Matter
An AI model does not have the same authority as a human decision-maker.
Even when the model correctly understands a request, several things can go wrong:
The wrong tool can be selected.
Arguments can be incorrect.
Context can be incomplete.
External data can contain malicious instructions.
A downstream system can behave unexpectedly.
The requested operation may be difficult to reverse.
Microsoft's current safety guidance recommends approval for high-risk tools and identifies side effects, sensitive data, reversibility, and scope of impact as important factors when deciding which tools need approval.
An approval gate adds a deterministic control outside the model.
Which Actions Should Require Approval?
Not every tool needs human approval.
A useful starting point is to evaluate four dimensions.
Side Effects
Does the operation change something?
Examples:
Read customer
-> Low side effect
Update customer
-> Higher side effect
Delete customer
-> High side effect
Data Sensitivity
Does the operation access or modify sensitive information?
Examples include:
Financial information
Personal information
Credentials
Confidential business records
Reversibility
Can the operation easily be undone?
For example:
Read record
-> Reversible / no mutation
Update record
-> Potentially reversible
Delete record
-> Potentially difficult to reverse
Scope of Impact
How many resources or people can the action affect?
Compare:
Update one customer
with:
Update every customer
The second operation deserves stronger controls.
A Practical Risk Classification
You can classify tools into four levels.
| Risk | Example | Approval |
|---|---|---|
| Low | Search documentation | Usually not required |
| Medium | Read internal records | Policy dependent |
| High | Update business data | Often required |
| Critical | Delete records or transfer money | Required |
This is not a universal classification.
Each organization should define its own thresholds based on business impact, compliance requirements, and threat model.
Do Not Let the Model Decide Its Own Approval Requirement
A common architectural mistake is:
Agent
|
v
"Should I ask for approval?"
|
v
Model decides
This is not a reliable security boundary.
Instead:
Agent
|
v
Tool Call
|
v
Deterministic Policy
|
+---- Approval required
|
+---- Approval not required
The policy should be enforced by application code or infrastructure.
The model can request a tool.
It should not be able to bypass the policy that protects the tool.
Approval Should Happen Before Execution
The safest sequence is:
1. Agent proposes tool call
2. Application validates arguments
3. Policy evaluates risk
4. Approval request is generated
5. Human approves or rejects
6. Server validates again
7. Tool executes
8. Result is recorded
The tool must not execute before step 5 when approval is required.
This sounds obvious, but it is important when designing asynchronous agent workflows.
Use Approval-Required Tools
Microsoft Agent Framework provides an approval mechanism for tools.
The framework can return an approval request to the application instead of immediately executing the function. The application then sends the user's approval decision back before execution continues.
Conceptually:
Agent Run
|
v
Function Call
|
v
ApprovalRequired
|
v
Application
|
v
User
After approval:
User
|
v
Approve
|
v
Application
|
v
Agent Workflow
|
v
Tool Execution
C# Approval Example
Microsoft's current Agent Framework uses ApprovalRequiredAIFunction to mark a function as requiring approval.
A simplified example is:
var refundTool =
new ApprovalRequiredAIFunction(
AIFunctionFactory.Create(
ProcessRefund));
The agent can then be configured with the approval-required tool:
ChatClientAgent agent =
new(
chatClient,
instructions:
"You process customer refund requests.",
tools:
[
refundTool
]);
The exact constructor and client configuration depend on the Agent Framework version and model provider being used.
The important architectural behavior is:
Agent
|
v
ProcessRefund
|
v
Approval Required
rather than:
Agent
|
v
ProcessRefund
|
v
Immediate Execution
Detect the Approval Request
When the agent pauses for approval, the application needs to inspect the returned content.
Microsoft's current C# guidance uses FunctionApprovalRequestContent to identify an approval request.
A simplified pattern is:
var response =
await agent.RunAsync(
userMessage,
session);
foreach (var content in response.Content)
{
if (content is FunctionApprovalRequestContent approval)
{
// Present approval UI.
}
}
The application can then present the proposed operation to the user.
Show the User What Will Happen
Do not display:
Approve this action?
That provides too little information.
Instead, show meaningful context:
Action: Process refund
Customer: Alice
Order: ORD-1001
Amount: ₹4,500
Reason: Duplicate payment
Requested by: Support Agent
[Approve] [Reject]
The reviewer should be able to understand the consequence without inspecting application logs.
Microsoft's responsible-AI guidance recommends giving reviewers enough context to make decisions while keeping human review meaningful rather than turning it into a bottleneck.
Never Hide Important Arguments
Suppose the tool is:
ProcessRefund(
orderId,
amount,
reason);
The approval request should identify:
Order
Amount
Reason
Do not show:
ProcessRefund(...)
and expect the user to trust the model.
The approval UI is part of the security boundary.
Validate Arguments Before Approval
The approval request should be generated from validated arguments.
For example:
if (amount <= 0)
{
throw new ArgumentOutOfRangeException(
nameof(amount));
}
if (amount > maximumRefundAmount)
{
throw new InvalidOperationException(
"Refund exceeds the permitted amount.");
}
This prevents obviously invalid requests from reaching the reviewer.
However, validation does not replace authorization.
You still need to determine whether the caller is permitted to perform the operation.
Validate Again After Approval
Approval should not be treated as permanent authorization.
Consider:
10:00
Agent requests refund
|
v
Human approves
10:05
Tool executes
What if the order changed during those five minutes?
The server should revalidate important conditions immediately before execution.
For example:
var order =
await repository.GetOrderAsync(
orderId,
cancellationToken);
if (order is null)
{
throw new InvalidOperationException(
"Order no longer exists.");
}
if (order.Status != OrderStatus.Refundable)
{
throw new InvalidOperationException(
"Order is no longer refundable.");
}
This is a form of time-of-check/time-of-use protection.
Avoid Stale Approval Requests
An approval should be associated with the exact proposed operation.
A useful approval record can contain:
Approval ID
Agent ID
User ID
Tool
Arguments
Policy Version
Timestamp
Expiration
Decision
Decision Maker
For sensitive actions, consider generating an operation identifier:
Approval ID:
APR-8F42...
Operation:
Refund ORD-1001
Amount:
₹4,500
When the tool executes, the server can verify that the approval corresponds to the requested operation.
Bind Approval to the Tool Call
Do not allow this sequence:
Approval
for:
Delete Customer A
to authorize:
Delete Customer B
The approval must be bound to the specific operation.
Conceptually:
Approval
|
+-- Tool Name
+-- Resource
+-- Arguments
+-- Identity
+-- Expiration
Before execution:
Requested Operation
|
v
Compare With Approval
|
+----+----+
| |
Match Mismatch
| |
v v
Execute Reject
Use Policy-Based Approval
Hard-coding every tool into application logic can become difficult to maintain.
Instead, define policies.
For example:
{
"tools": {
"search_customer": {
"approval": "never"
},
"update_customer": {
"approval": "conditional"
},
"delete_customer": {
"approval": "always"
}
}
}
The exact configuration format can vary.
The important concept is separating:
Tool Implementation
from:
Approval Policy
This allows security teams to change approval requirements without rewriting business logic.
Conditional Approval
Some tools should require approval only under certain conditions.
For example:
Refund <= ₹1,000
|
v
Automatic
Refund > ₹1,000
|
v
Human Approval
Another example:
Update customer
|
+-- Own account -> Automatic
|
+-- Another customer -> Approval
Conditional approval can reduce unnecessary interruptions while maintaining stronger controls around higher-risk operations.
Approval Based on Amount
Financial operations are a common example.
bool RequiresApproval(decimal amount)
{
return amount >
policy.MaximumAutomaticAmount;
}
Then:
₹500
|
v
Automatic
₹5,000
|
v
Approval
₹500,000
|
v
Approval + Elevated Review
The thresholds must come from business policy.
Do not hard-code arbitrary financial limits into an article's example and present them as production guidance.
Approval Based on Environment
Production operations should generally have stricter controls than development operations.
For example:
Development
|
v
Automatic
Staging
|
v
Conditional
Production
|
v
Human Approval
An agent that can restart a development service may not need the same approval workflow as an agent that can restart a production service.
Approval Based on User Role
Approval policies can also consider the authenticated user's role.
For example:
Support Agent
|
v
Refund <= Policy Limit
Finance Manager
|
v
Higher Refund Limit
But do not assume that a user's role alone should bypass all safeguards.
The operation still needs authorization and policy evaluation.
Separate Requester and Approver
For higher-risk operations, consider separation of duties.
For example:
Agent requests action
|
v
Employee A initiates
|
v
Employee B approves
|
v
Action executes
This can reduce the risk of one identity controlling the entire workflow.
Whether this is required depends on organizational policy and regulatory requirements.
Approval Expiration
Approvals should not necessarily remain valid forever.
For example:
Approval created
|
v
Valid
|
v
Expiration
|
v
Must request again
The expiration duration should reflect the risk and operational workflow.
A refund approval may remain useful for a short period.
A production configuration approval may need to be tied to a deployment or change request instead.
Handle Rejection Explicitly
A rejection is not an error.
It is a valid workflow outcome.
For example:
if (!approved)
{
return new ToolDecision
{
Status = "Rejected",
Message =
"The requested refund was not approved."
};
}
The agent should receive a clear result indicating that execution did not occur.
Do not allow the agent to interpret rejection as:
"Try the same operation again."
unless the workflow explicitly allows it.
Prevent Approval Loops
A poorly designed agent can repeatedly request the same rejected action.
For example:
Agent
|
v
Refund
|
v
Rejected
|
v
Agent
|
v
Refund
|
v
Rejected
|
v
...
Introduce limits.
For example:
Maximum approval attempts
Maximum retries
Workflow termination condition
The exact limits should be defined by the application.
Approval and Retries
Be careful when combining approval with automatic retries.
Suppose:
Tool Call
|
v
Approval
|
v
Approved
|
v
Network Error
Should the application automatically retry?
For an idempotent read operation, perhaps.
For a financial or irreversible operation, automatic retries can be dangerous.
Use idempotency keys where the underlying operation supports them.
For example:
Operation ID:
REFUND-ORD-1001-001
The downstream service can use the identifier to prevent duplicate execution.
Approval and Idempotency
For high-risk operations:
Agent
|
v
Approval
|
v
Operation ID
|
v
Execute
The server should ensure that the same approved operation cannot accidentally execute twice.
Conceptually:
if (await store.WasExecutedAsync(
operationId,
cancellationToken))
{
return existingResult;
}
Then execute the operation and record the result atomically where the underlying architecture allows.
The exact implementation depends on the database and transaction model.
Approval Should Survive Process Restarts
A production approval workflow may not finish within one HTTP request.
For example:
Agent
|
v
Approval Requested
|
v
Application Paused
|
v
User Responds Later
|
v
Application Resumes
If the process restarts between these steps, the approval state must not disappear.
Microsoft Agent Framework workflows support request/response handling and checkpointing, allowing pending requests to be preserved and re-emitted when a workflow is restored.
This is important for long-running workflows.
Asynchronous Approval Architecture
A production architecture can look like:
+----------------+
| AI Agent |
+-------+--------+
|
v
+---------------+
| Policy Engine |
+-------+-------+
|
Approval Needed
|
v
+---------------+
| Approval Store|
+-------+-------+
|
v
+---------------+
| Human Review |
+-------+-------+
|
Approve/Reject
|
v
+---------------+
| Agent Workflow|
+-------+-------+
|
v
+---------------+
| Tool Executor |
+---------------+
The approval store can contain the state required to resume the operation.
Keep Approval Separate From Tool Execution
A useful architectural boundary is:
Approval Service
|
v
Authorization Decision
|
v
Tool Execution Service
This makes the system easier to audit.
The tool executor should never assume:
"Someone must have approved this."
It should verify the authorization context supplied by the application.
Approval Is Not Authorization
These concepts are related but different.
Authentication
Who is requesting the operation?
Authorization
Is this identity allowed to perform the operation?
Approval
Has the required human reviewer explicitly approved this particular operation?
A secure flow may require all three:
Identity
+
Authorization
+
Approval
|
v
Execution
Removing one can weaken the security model.
Add Audit Logging
For every approval-controlled action, record:
Approval ID
Timestamp
Requester
Approver
Agent
Tool
Resource
Arguments classification
Policy evaluated
Decision
Execution result
For sensitive data, do not blindly log the complete arguments.
Instead, classify or redact them.
For example:
{
"approvalId": "APR-1001",
"tool": "process_refund",
"orderId": "ORD-1001",
"amount": "[REDACTED]",
"approver": "user-123",
"decision": "approved"
}
The actual logging strategy should follow the organization's data-classification requirements.
Provide a Clear Approval UI
A reviewer should see:
Requested Action
Who requested it
Why it is needed
What resource is affected
What will change
Potential impact
Relevant policy
Expiration
Approve
Reject
Avoid interfaces that encourage users to click:
Approve
Approve
Approve
without understanding the operation.
That turns human approval into a meaningless checkbox.
Do Not Overuse Approval
If every tool requires approval:
Search customer
|
v
Approve
Read order
|
v
Approve
Calculate total
|
v
Approve
the user experience becomes unusable.
Microsoft's guidance supports selective approval for sensitive operations rather than requiring every function to be gated.
A better model is:
Low-risk
|
v
Automatic
Medium-risk
|
v
Policy-based
High-risk
|
v
Human Approval
Design for Safe Rejection
When the user rejects an operation, the agent should not attempt to circumvent the decision.
For example:
User:
Do not send the email.
Agent:
Understood. The email was not sent.
Not:
User:
Reject.
Agent:
I will try another email tool.
The application should enforce the rejection for the specific operation and prevent tool substitution from bypassing policy.
Protect Against Tool Substitution
Consider:
Tool A:
send_email
requires approval.
The agent then discovers:
Tool B:
http_request
and attempts to call the email provider directly.
This is a policy bypass.
Approval policies should therefore consider capabilities, not only tool names.
For example:
Capability:
Send external email
could apply to multiple tools that can produce the same side effect.
This is a stronger model than maintaining a simple list of approved function names.
Use Capability-Based Policies
A capability-oriented policy can look like:
read_customer
-> customer.read
update_customer
-> customer.write
send_email
-> communication.external
delete_customer
-> customer.delete
Then approval rules can operate on capabilities:
customer.read
-> automatic
customer.write
-> conditional
customer.delete
-> approval
communication.external
-> approval
This becomes particularly valuable as the number of tools increases.
Approval in Multi-Agent Systems
Multi-agent workflows introduce another challenge.
For example:
Triage Agent
|
v
Billing Agent
|
v
Refund Tool
The approval policy should remain effective regardless of which agent invokes the tool.
Microsoft's Agent Framework supports approval-required tools in handoff workflows and pauses the workflow when a sensitive tool is requested.
The security boundary should therefore be associated with the tool or capability, not merely with the first agent in the workflow.
Approval in MCP Workflows
The same concept applies when the agent uses MCP tools.
Conceptually:
Agent
|
v
MCP Client
|
v
Policy
|
v
Approval
|
v
MCP Tool
The important requirement is that the approval gate must execute before the side effect.
Do not rely on the MCP server's tool description to determine whether an operation is safe.
Common Mistakes
Approving the Tool Instead of the Operation
Approving refund once should not necessarily authorize every future refund.
Showing Too Little Context
The reviewer needs to understand the consequence.
Approving Before Validation
Invalid or unauthorized operations should not reach approval.
Failing to Revalidate After Approval
The resource may change while the user is reviewing it.
Storing Approval Only in Memory
Process restarts can lose pending requests.
Allowing Automatic Retry of Irreversible Actions
Retries can produce duplicate side effects.
Letting the Model Bypass Rejection
A rejected action must remain rejected.
Requiring Approval for Everything
This creates unnecessary user friction.
Logging Sensitive Approval Data
Audit trails must not become a source of data leakage.
Troubleshooting
The Agent Executes Before Approval
Check whether the tool is actually wrapped or configured as approval-required.
Also verify that no alternate tool can perform the same side effect.
Approval Requests Disappear After Restart
Persist pending workflow state rather than keeping it only in process memory.
Microsoft's workflow checkpointing mechanism can preserve pending requests across process restarts.
Users Approve the Wrong Operation
Improve the approval UI.
Display:
Tool
Resource
Arguments
Expected effect
Requester
Reason
and use a unique operation identifier.
The Same Operation Executes Twice
Introduce idempotency at the business-operation level.
Approval alone does not prevent duplicate execution.
Users Are Constantly Asked for Approval
Review the risk policy.
Move genuinely low-risk read operations out of the approval path and use conditional approval for actions where risk depends on context.
Best Practices
Use approval gates for consequential actions.
Classify tools by side effect, sensitivity, reversibility, and impact.
Enforce approval outside the model.
Validate tool arguments before approval.
Revalidate critical conditions immediately before execution.
Bind approval to the exact operation.
Use expiration for stale approvals where appropriate.
Persist approval state for long-running workflows.
Use idempotency for sensitive operations.
Log requester, approver, operation, decision, and outcome.
Do not log secrets or unnecessary sensitive data.
Give reviewers enough context to make an informed decision.
Use conditional approval where risk varies by context.
Prevent rejected operations from being retried through alternate tools.
Apply policies consistently across multi-agent workflows.
Treat approval as one layer of security, not a replacement for authorization.
Frequently Asked Questions
Which AI agent actions should require human approval?
Actions that modify data, send external communications, move money, access sensitive information, delete resources, change production systems, or have difficult-to-reverse consequences are strong candidates.
Microsoft's current guidance specifically highlights side effects, sensitive data, reversibility, and scope of impact when deciding which tools should require approval.
Should every AI tool require approval?
No.
Low-risk read-only operations can often execute automatically when properly authorized. Approval should be targeted at actions where human judgment meaningfully reduces risk.
Is human approval the same as authorization?
No.
Authorization determines whether an identity is permitted to perform an operation.
Approval determines whether the required human decision has been made for a particular operation.
A production system may require both.
Can approval be conditional?
Yes.
For example, a low-value operation could execute automatically while a higher-value or higher-impact operation requires approval.
What happens if the application restarts while waiting for approval?
A production workflow should persist the pending approval state.
Microsoft Agent Framework supports checkpointing for workflows so pending requests can be restored and emitted again after a workflow resumes.
Can an AI agent bypass a rejected approval?
It should not be able to.
The application should enforce the policy independently of the model and prevent equivalent tools from being used to circumvent the rejected operation.
Should approval requests expire?
For many sensitive workflows, expiration is useful because the underlying state may change after the request is created.
The appropriate expiration period depends on the operation.
How should approval work in multi-agent systems?
Apply the approval requirement at the tool or capability boundary rather than trusting a particular agent to enforce it.
This ensures that a sensitive operation remains protected regardless of which agent requests it.
Conclusion
Human approval is one of the most practical controls for reducing the risk of autonomous agent actions.
The goal is not to put a human in front of every tool call.
The goal is to create a deterministic boundary around operations where autonomous execution has meaningful consequences.
A strong design looks like:
Agent
|
v
Tool Request
|
v
Input Validation
|
v
Authorization
|
v
Risk Policy
|
+---- Low Risk --------> Execute
|
+---- High Risk
|
v
Human Approval
|
+---+---+
| |
Reject Approve
| |
v v
Stop Revalidate
|
v
Execute
|
v
Audit
The most important principle is:
The model should be allowed to request an action, but the application should decide whether that action is permitted to execute.
Approval gates work best when they are combined with least privilege, deterministic authorization, argument validation, audit logging, idempotency, and safe shutdown mechanisms.
For low-risk operations, autonomy can provide a fast user experience.
For high-impact operations, a carefully designed approval gate provides something an AI model cannot provide on its own: explicit human accountability at the point where the system is about to cause a consequential change.
Join the conversation! Your thoughts help the community grow.