How to Design Approval Gates for AI Agents Before They Take Real Actions

A developer outlined a design approach for placing approval gates in AI agent systems, arguing that agents should be allowed to think and perform read-only work freely while actions with real-world consequences—sending money, publishing content, deleting data, deploying production code, or changing permissions—require explicit confirmation. The approach classifies tool calls into low-, medium-, and high-risk tiers, bases approval on the impact of a wrong action rather than model confidence, and requires showing the final payload and affected users before execution to avoid approval fatigue.

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 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 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 mailto: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? May I open another page? 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? 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. 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. Send email to one internal teammate may not need approval. Send email to 5,000 customers probably should. You can create thresholds. 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. 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 Overwrite database record Store previous value and update Immediately publish 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. 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. tool = delete database rows environment = production affected rows 0 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. Research agent: Allowed: web search read files generate reports Not allowed: send email modify CRM purchase products Deployment agent: read repository run tests deploy staging Approval required: deploy production 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. 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. 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 Modify internal reversible data Automatic below defined thresholds Send external communication Approval required Delete information Purchase something Change permissions Deploy production code 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: Reason: This action sends information outside your organization. Or: 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.