{"slug": "how-to-design-approval-gates-for-ai-agents-before-they-take-real-actions", "title": "How to Design Approval Gates for AI Agents Before They Take Real Actions", "summary": "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.", "body_md": "AI agents are becoming increasingly capable of doing more than generating text.\n\nThey can browse websites.\n\nRead files.\n\nWrite code.\n\nSend messages.\n\nUpdate records.\n\nCreate documents.\n\nUse APIs.\n\nAnd in some systems, they can initiate actions that affect real users or real business data.\n\nThat creates a fundamental engineering question:\n\nWhen should an AI agent be allowed to act automatically, and when should it stop and ask for approval?\n\nThe answer should not be:\n\nAsk for approval before everything.\n\nThat makes automation frustrating.\n\nBut it should not be:\n\nLet the agent do anything once the user clicks Start.\n\nThat creates unnecessary risk.\n\nThe better approach is to design approval gates around the consequences of each action.\n\nStart by Separating Thinking From Acting\n\nAn AI agent may perform several different kinds of work.\n\nSome steps only produce information.\n\nOthers change the outside world.\n\nFor example:\n\nRead a document\n\nSummarize requirements\n\nCompare two options\n\nDraft an email\n\nThese are mostly reversible or read-only.\n\nNow compare them with:\n\nSend the email\n\nDelete a file\n\nPurchase a service\n\nChange database data\n\nDeploy code\n\nModify permissions\n\nThe second group creates real consequences.\n\nA useful design principle is:\n\nLet the agent think freely.\n\nControl when it is allowed to act.\n\nClassify Actions by Risk\n\nDo not treat every tool call equally.\n\nA simple risk model can divide actions into three categories.\n\nLow-risk actions\n\nExamples:\n\nsearching public information\n\nreading documentation\n\nopening a file the user already provided\n\ncalculating values\n\ncreating a draft\n\nThese actions usually do not need repeated approval.\n\nMedium-risk actions\n\nediting a document\n\ncreating a new file\n\nupdating a task\n\nchanging a calendar event\n\npreparing a database update\n\nThese may require approval depending on context.\n\nHigh-risk actions\n\nsending money\n\npublishing content\n\ndeleting data\n\ndeploying production code\n\nchanging user permissions\n\nsending external messages\n\nThese should normally require explicit confirmation.\n\nThe exact categories depend on the product.\n\nWhat matters is defining them intentionally.\n\nApproval Should Be Based on Consequence\n\nA useful question is:\n\nWhat happens if this action is wrong?\n\nSuppose an agent incorrectly summarizes an internal document.\n\nThe consequence may be limited.\n\nNow suppose the same agent sends that incorrect summary to 10,000 customers.\n\nThe underlying text-generation error may be identical.\n\nThe consequence is completely different.\n\nApproval requirements should therefore follow impact, not just model confidence.\n\nMake the Proposed Action Visible\n\nAn approval request should tell the user exactly what will happen.\n\nBad approval:\n\nProceed?\n\nBetter approval:\n\nSend this email?\n\nMuch better approval:\n\nSend the following email to 126 customers in the “Trial Expiring” segment using [support@company.com](mailto:support@company.com).\n\nThe user should be able to understand:\n\nwhat action will happen\n\nwhich data will change\n\nwho will be affected\n\nwhich account will be used\n\nwhether the action can be reversed\n\nApproval without context is not meaningful approval.\n\nShow the Final Payload\n\nWhen possible, show the actual data that will be submitted.\n\nSuppose an agent wants to create a support ticket.\n\nBefore approval, display:\n\nTitle\n\nDescription\n\nPriority\n\nAssigned team\n\nCustomer\n\nAttachments\n\nThis gives the user a chance to catch errors before execution.\n\nThe same principle works for:\n\nemails\n\nAPI requests\n\ndatabase updates\n\ncalendar events\n\nsocial posts\n\ncode changes\n\nThe user should approve the real action, not an abstract description of it.\n\nDo Not Ask for Approval Too Early\n\nImagine this workflow:\n\nUser asks:\n\nResearch three monitoring platforms and recommend one.\n\nThe agent immediately asks:\n\nMay I browse the web?\n\nThen:\n\nMay I open this page?\n\nMay I open another page?\n\nMay I compare pricing?\n\nThis creates approval fatigue.\n\nMost of these steps are read-only.\n\nA better workflow allows the agent to complete the research independently.\n\nApproval should appear only when the agent is about to do something consequential, such as:\n\nstart a paid subscription\n\ncontact a vendor\n\nchange production configuration\n\nThis keeps the experience useful without removing control.\n\nAvoid Approval Fatigue\n\nUsers learn to ignore prompts when they see too many of them.\n\nThis is the same problem seen with cookie banners, operating-system permissions, and security warnings.\n\nIf an AI agent asks:\n\nApprove?\n\nthe user may eventually click Approve without reading.\n\nAt that point, the approval system technically exists but provides little protection.\n\nApproval gates should be rare enough that users recognize them as meaningful.\n\nGroup Related Actions\n\nSuppose an agent needs to update 40 records using the same rule.\n\nAsking for 40 approvals is unreasonable.\n\nInstead, show a batch summary:\n\nThe agent will update 40 customer records.\n\nField changed:\n\naccount_status\n\nCurrent value:\n\ntrial\n\nNew value:\n\nexpired\n\nUsers affected:\n\n40\n\nThen ask for one approval.\n\nBatch approval is useful when:\n\nthe operations are similar\n\nthe scope is visible\n\nthe user can inspect affected items\n\nthe action follows one consistent rule\n\nBut Do Not Hide Mixed Actions Inside a Batch\n\nBatching becomes dangerous when unrelated operations are grouped together.\n\nUpdate 35 customer records\n\nDelete 3 files\n\nSend 12 emails\n\nChange 2 permissions\n\nApprove all?\n\nThat is too broad.\n\nDifferent action types have different consequences.\n\nSeparate approval groups by risk and intent.\n\nUse Threshold-Based Approval\n\nSome actions become risky only above a certain scale.\n\nSend email to one internal teammate\n\nmay not need approval.\n\nSend email to 5,000 customers\n\nprobably should.\n\nYou can create thresholds.\n\nFile deletion\n\n1 temporary file: automatic\n\nMore than 10 files: approval\n\nDatabase update\n\n1 test record: automatic\n\nMore than 100 production records: approval\n\nFinancial action\n\nBelow $5 test transaction: automatic in sandbox\n\nAny real payment: approval\n\nThresholds turn vague safety rules into predictable system behavior.\n\nUse Environment as a Risk Signal\n\nThe same action can have different consequences depending on the environment.\n\nDeleting data in:\n\nlocal development\n\nis very different from deleting data in:\n\nproduction\n\nSimilarly:\n\ndeploy to staging\n\nmay be low risk.\n\ndeploy to production\n\nis higher risk.\n\nApproval logic should understand environments.\n\nA useful rule might be:\n\nDevelopment: automatic\n\nStaging: automatic with logging\n\nProduction: explicit approval\n\nSeparate Preparation From Execution\n\nOne of the strongest agent patterns is:\n\nPrepare automatically.\n\nExecute only after approval.\n\nThe agent can:\n\nanalyze database records\n\ngenerate the SQL update\n\ncalculate affected rows\n\nshow a preview\n\nThen stop.\n\nThe user approves.\n\nOnly then does the system execute the update.\n\nThis keeps most of the automation benefit while preserving human control at the critical moment.\n\nMake Destructive Actions Harder\n\nNot every approval button should look the same.\n\nA low-risk confirmation might use:\n\nApprove\n\nA destructive action could require:\n\nDelete 2,341 records\n\nThis forces the user to understand the specific operation.\n\nFor extremely sensitive actions, you can add stronger confirmation such as:\n\ntyping the resource name\n\nre-authentication\n\ntwo-person approval\n\na short delay before execution\n\nHigh-friction confirmation should be reserved for high-impact actions.\n\nAdd Reversibility When Possible\n\nAn action becomes safer when it can be undone.\n\nInstead of:\n\nDelete file permanently\n\nuse:\n\nMove file to trash\n\nOverwrite database record\n\nStore previous value and update\n\nImmediately publish\n\nSave as scheduled draft\n\nReversibility can reduce the need for aggressive approval while still protecting users from mistakes.\n\nUse Idempotency for Executable Actions\n\nAgents may retry.\n\nNetworks fail.\n\nRequests time out.\n\nThe agent may not know whether an operation succeeded.\n\nImagine a payment request.\n\nThe agent sends it.\n\nThe connection times out.\n\nThe agent retries.\n\nWithout protection, the user could be charged twice.\n\nActions that can be retried should use idempotency where possible.\n\nCreate one unique action ID.\n\nReuse it during retries.\n\nThe receiving service recognizes the duplicate and does not execute the same transaction twice.\n\nThis is especially important for:\n\npayments\n\norders\n\nticket creation\n\nmessages\n\ndatabase writes\n\nexternal API calls\n\nLog Every Approved Action\n\nApproval systems should create an audit trail.\n\nRecord:\n\nwho requested the task\n\nwhat the agent proposed\n\nwho approved it\n\nwhat tool was called\n\nwhat parameters were used\n\nwhen the action happened\n\nwhether it succeeded\n\nwhat changed\n\nThis becomes essential when a user later asks:\n\nWhy did the system do this?\n\nWithout logs, the answer may be impossible to reconstruct.\n\nRecord Rejected Actions Too\n\nRejections are valuable data.\n\nSuppose users repeatedly reject an agent when it tries to:\n\nsend emails too early\n\ndelete files\n\nchoose expensive plans\n\nupdate incorrect fields\n\nThat pattern may indicate a planning problem.\n\nTrack:\n\nproposed action\n\nrejection reason\n\ntask type\n\nagent version\n\nRepeated rejections can become signals for improving:\n\nprompts\n\ntool permissions\n\nplanning logic\n\napproval thresholds\n\nDo Not Rely Only on Model Self-Assessment\n\nYou could ask the model:\n\nIs this action risky?\n\nBut the model should not be the only authority deciding whether it needs approval.\n\nRisk classification should include deterministic application rules.\n\ntool = delete_database_rows\n\nenvironment = production\n\naffected_rows > 0\n\napproval_required = true\n\nThe model may help describe the risk.\n\nThe application should enforce the policy.\n\nCreate Explicit Tool Permissions\n\nAgents should not automatically have access to every available action.\n\nInstead, define permissions by tool.\n\nResearch agent:\n\nAllowed:\n\nweb search\n\nread files\n\ngenerate reports\n\nNot allowed:\n\nsend email\n\nmodify CRM\n\npurchase products\n\nDeployment agent:\n\nread repository\n\nrun tests\n\ndeploy staging\n\nApproval required:\n\ndeploy production\n\nchange billing\n\nThis is easier to reason about than giving every agent universal capabilities.\n\nUse Scoped Credentials\n\nAn agent should receive the minimum access needed for its task.\n\nDo not give:\n\nfull administrator credentials\n\nwhen the task requires:\n\nread-only analytics access\n\nUse:\n\nlimited API keys\n\ntemporary tokens\n\nscoped permissions\n\nservice accounts\n\nenvironment-specific credentials\n\nIf the agent makes a mistake, limited permissions reduce the possible damage.\n\nTime-Limited Permissions Can Help\n\nSome permissions only need to exist during one workflow.\n\nUser approves access to a shared folder for 30 minutes.\n\nAfter the task:\n\npermission expires.\n\nThis reduces the risk of persistent access that nobody remembers later.\n\nApproval Should Be Bound to the Exact Action\n\nImagine the user approves:\n\nSend $50 to Vendor A.\n\nThe agent should not be able to reuse that approval for:\n\nSend $500 to Vendor B.\n\nApproval should be linked to the exact action parameters.\n\nIf important parameters change, approval should become invalid.\n\nrecipient changed\n\namount changed\n\ndatabase changed\n\nfile list changed\n\nmessage changed significantly\n\nThen request approval again.\n\nRevalidate Before Execution\n\nTime can pass between proposal and approval.\n\nThe environment may change.\n\nSuppose the agent proposes:\n\nDelete inactive accounts older than two years.\n\nThe user reviews it 30 minutes later.\n\nBefore execution, the system should confirm that:\n\nthe target records still match the condition\n\npermissions are still valid\n\nthe operation is still allowed\n\nThis prevents stale approvals from producing unexpected actions.\n\nDesign for Partial Failure\n\nSuppose an approved batch contains 100 operations.\n\n60 succeed.\n\n40 fail.\n\nWhat should happen?\n\nPossible strategies include:\n\nstop immediately\n\ncontinue remaining operations\n\nroll back successful changes\n\nretry failures\n\nask for another approval\n\nThe correct answer depends on the task.\n\nBut it should be designed before the agent starts performing important batch operations.\n\nApproval Gates Work Best With Specialized Agents\n\nGeneral-purpose agents can perform increasingly broad tasks, including browser operations, research, code execution, file processing, and application-building workflows.\n\nA 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.\n\nBut broader capability makes permission design even more important.\n\nThe more an agent can do, the more carefully its actions should be scoped.\n\nA Simple Approval Policy\n\nA practical policy might look like this:\n\nRead-only public information\n\nAutomatic\n\nRead internal information\n\nAutomatic if permission already exists\n\nCreate draft content\n\nModify internal reversible data\n\nAutomatic below defined thresholds\n\nSend external communication\n\nApproval required\n\nDelete information\n\nPurchase something\n\nChange permissions\n\nDeploy production code\n\nFinancial transactions\n\nStrong approval required\n\nThis gives both developers and users predictable behavior.\n\nShow Users Why Approval Is Required\n\nA useful approval UI can say:\n\nReason:\n\nThis action sends information outside your organization.\n\nOr:\n\nThis operation will modify 438 production records.\n\nThat teaches users how the system works and makes the approval less arbitrary.\n\nMeasure Approval Quality\n\nOnce the system is running, track metrics such as:\n\napproval rate\n\nrejection rate\n\ntime to approval\n\nactions canceled after preview\n\napproval rate by tool\n\napproval rate by risk level\n\nrepeatedly rejected action types\n\nIf 99.9 percent of one low-risk action is approved immediately, the gate may be unnecessary.\n\nIf users reject 30 percent of another action, the gate is probably valuable.\n\nThe Goal Is Calibrated Autonomy\n\nGood AI agent design is not:\n\nmaximum automation\n\nor:\n\nmaximum human control.\n\nIt is calibrated autonomy.\n\nThe agent should handle routine, low-risk work independently.\n\nHumans should remain involved where mistakes create meaningful consequences.\n\nThat boundary can evolve as the system becomes more reliable.\n\nFinal Thought\n\nThe most important question for AI agents is no longer only:\n\nCan the model complete the task?\n\nIt is increasingly:\n\nWhat should the model be allowed to do without asking?\n\nSeparate thinking from acting.\n\nClassify actions by consequence.\n\nGive agents limited permissions.\n\nShow users exactly what will happen.\n\nRequire approval for high-impact actions.\n\nMake important changes reversible.\n\nLog every execution.\n\nAs AI agents become more capable, good approval design will become one of the main differences between useful automation and dangerous automation.\n\nAI-assisted disclosure: This article was created with AI assistance and reviewed and edited for clarity and accuracy before publication.", "url": "https://wpnews.pro/news/how-to-design-approval-gates-for-ai-agents-before-they-take-real-actions", "canonical_source": "https://dev.to/aiworkflowresearch/how-to-design-approval-gates-for-ai-agents-before-they-take-real-actions-35f2", "published_at": "2026-11-09 06:48:18+00:00", "updated_at": "2026-11-09 06:52:16.393265+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-tools"], "entities": [], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-to-design-approval-gates-for-ai-agents-before-they-take-real-actions", "markdown": "https://wpnews.pro/news/how-to-design-approval-gates-for-ai-agents-before-they-take-real-actions.md", "text": "https://wpnews.pro/news/how-to-design-approval-gates-for-ai-agents-before-they-take-real-actions.txt", "jsonld": "https://wpnews.pro/news/how-to-design-approval-gates-for-ai-agents-before-they-take-real-actions.jsonld"}}