All articles

Your AI agent's approval prompt is a permission boundary

Confirm everything and users stop reading. Confirm only the goal and consent becomes dangerously broad. The useful boundary sits at the exact action that changes the world.

Maxence Rabrais — August 29, 2026 — 9 min read

A user tells an AI agent, "Delete the Q3 sandbox." The agent opens settings, finds the workspace, and reaches the delete control. If it asks for confirmation after every click, it is unusable. If it treats the original sentence as unlimited consent, it is reckless. If it asks "Continue?" at the end, the user still cannot tell what will happen. The hard product decision is not whether to keep a human in the loop. It is where that loop begins, what the human is approving, and when that approval stops being valid.

This is why an approval prompt should be treated as part of the permission model, not as polite friction added after the agent is built.

The two bad extremes

The first bad design confirms every state change. Open the billing page? Confirm. Choose the annual tab? Confirm. Fill a company name? Confirm. The product looks cautious, but the repeated prompts train users to approve by reflex. The system has produced consent theater: plenty of clicks, little attention.

The opposite design asks once at the start. "I will clean up the workspace. Shall I proceed?" That sounds efficient until the task expands into archiving records, removing members, and sending a summary email. The user approved a goal, not each consequence. A broad natural-language instruction has become a temporary administrator role.

Both failures come from using conversation as the authorization layer. Conversation is good at establishing intent. It is bad at defining the precise capability being granted.

Microsoft's 2026 taxonomy of agentic failure modes makes the security version of this point explicit. It recommends deterministic human review, separate approval for consequential sub-actions, descriptions derived from underlying tool calls, and approval tiers based on reversibility and blast radius. The application, not the model, has to enforce the boundary.

Classify the consequence, not the button

Teams often begin with a list of dangerous words: delete, send, pay, cancel. That is useful, but button text is not a policy. "Cancel" might close a dialog or terminate a subscription. "Remove" might clear a filter or revoke a person's access. "Continue" might be the final control on a purchase.

The classification needs the action, its target, and its surrounding state. A practical policy can start with five questions:

1. Does this action create an external effect, such as a message, invitation, post, or published change?
2. Does it move money or create a financial commitment?
3. Does it change who can access data or what permissions they have?
4. Does it delete data, close an account, or change a subscription?
5. If it is wrong, can the same user reverse it quickly and completely?

That produces a more useful boundary than "all writes need confirmation."

This is close to the tool-risk model in OpenAI's guide to building agents, which recommends rating tools using write access, reversibility, account permissions, and financial impact. The important move is to make those properties code and policy, not another instruction the model can interpret creatively.

Ask at the point of consequence

Approval should appear as late as possible, but before the external effect.

Consider "Cancel my Growth subscription." The agent can open settings, navigate to billing, and inspect the current plan without interrupting. None of those steps commits the user. The useful review appears when the agent has found the actual Cancel subscription control and knows which subscription it affects.

This timing gives the prompt concrete facts. It can name the action and target instead of paraphrasing the initial request. It also avoids asking the user to approve an operation the agent may not even be able to find.

There is a clean distinction here:

• Clarification happens when the intended action or target is ambiguous. "Remove Alex" needs a question if two members are named Alex.
• Approval happens when the intended action is clear and the application is ready to execute a consequential step. It should be a constrained Accept or Decline decision.

Mixing the two creates maddening conversations. The agent asks "Are you sure?" even though it still does not know which record the user meant. Or it collects approval first, encounters a different confirmation control later, and treats the earlier answer as permission for that new action.

The safer sequence is intent, resolution, review, execution. A later site confirmation is a new executable action and deserves its own decision.

The prompt must describe the executable action

An agent can say, "I am just tidying the workspace," while its next tool call removes a member. Whether that mismatch is malicious, injected, or simply mistaken does not matter. The approval UI cannot trust the agent's narration to describe the authority it is requesting.

Build the review text from the execution object instead. Show the control, target, selected value, destination, and relevant scope that the application has resolved. "Click Delete account for Acme" is useful. "Proceed with cleanup" is not.

The Microsoft taxonomy calls the weak version description laundering: the agent presents a harmless summary that hides a more consequential underlying action. The proposed defense is straightforward. Generate the approval description from the actual tool call or page control, not from free-form model text.

This matters even when nobody is attacking the system. Models compress. They omit qualifiers. They refer to the wrong object with "it." The execution layer already has the exact arguments, so the review should use them.

Consent should be one-shot and state-bound

The most overlooked question comes after the user clicks Accept: what exactly did that click authorize?

Suppose the review displayed "Delete Q3 sandbox." While the card was open, the page re-rendered and the underlying element now points to the production workspace. Or the route changed. Or a form's recipient changed. If approval is represented as a boolean called approved, the agent may execute against a state the user never saw.

Approval should instead bind to a fingerprint of the pending action. That can include the element identity, action type, target label, destination, form state, container, origin, and route. Immediately before execution, the application compares the current action with the reviewed one.

If anything security-relevant changed, execution stops. The old approval is spent anyway, so it cannot be replayed after the page changes back. If execution succeeds, it is also spent. One review, one attempt, one unchanged target.

This is not excessive ceremony. It is the same principle used in signed requests and single-use tokens: authority should be narrow, attributable, and short-lived. Microsoft's application-layer guidance argues that human review should prevent agents from self-authorizing consequential actions, with triggers enforced by code and intervention possible during execution. State-bound consent is how that principle survives a dynamic interface.

Approval is one layer, not the safety system

Even a well-designed prompt cannot carry the whole safety model. A user can approve a bad action because the target is confusing. A prompt injection can distort the path that led to the review. A compromised page can present misleading context. Some tasks should remain outside the agent's authority regardless of consent.

OpenAI's ChatGPT agent system card presents confirmations alongside model training, automated monitors, restricted capabilities, and active supervision in sensitive contexts. That layered structure is the right mental model. Approval limits the damage from a mistake. It does not prove the preceding reasoning was sound.

The rest of the system still needs:

• least-privilege access to tools and data;
• deterministic blocks on forbidden targets and sensitive inputs;
• a stop control during a multi-step task;
• a fresh read of the interface after each action;
• a final audit of the requested outcome before claiming success;
• logs that connect the user's request, review, execution, and result.

The final audit is especially important. Acceptance means "you may try this exact action." It does not mean the click worked, the right state changed, or the task is complete.

What we chose for Barkan

In Barkan's Do Mode, routine navigation and reversible interface work can proceed without a confirmation parade. The widget pauses locally before actions classified as data deletion, account or subscription changes, money movement, external communication, or access changes. The review is triggered in the execution path, not left to the model's discretion.

An accepted review is bound to the current action target and page state, then consumed on the first execution attempt. If the target mutates, the approval cannot be reused. If the website opens its own final confirmation, that control is reviewed as a separate action. After actions run, Barkan reads a fresh rendered view and uses a separate final audit turn before it reports completion.

These choices add friction exactly where we want it. The goal is not maximum autonomy or maximum caution. It is maximum useful work under a permission boundary a user can understand.

Measure the boundary, not just acceptance

Approval rate alone is a poor success metric. A 99 percent acceptance rate could mean the agent is always right. It could also mean the prompts are so frequent and vague that users no longer read them.

Track the system as a control:

• Review coverage: consequential actions that were interrupted before execution.
• False interruption rate: harmless actions that triggered a review.
• Decision rate by category: accepts and declines for deletion, money, communication, access, and account changes.
• Stale consent rejections: attempts blocked because the target or state changed during review.
• Verified completion: approved actions whose intended end state was confirmed afterward.
• Stop and correction behavior: tasks users interrupted or redirected before a consequential step.

Then inspect examples from both tails: consequential actions that escaped review and benign actions that annoyed users. The policy improves by shrinking both groups, not by driving every task toward more approval.

The approval prompt is the moment an AI product turns a prediction into authority. Treat it with the rigor of a permission grant. Let the agent move quickly through reversible work, stop on the exact consequential action, show what will really execute, and make every yes expire after one attempt.