In a post published by Zapier, the company describes the development process and experiments behind the permissions and approval mechanism in Sidekick, its AI-powered workspace. The company highlights the central challenge facing AI products that perform actions rather than merely generate text: whether an agent should ask permission before every action, or act and report only after the fact. According to Zapier, both extreme approaches fail in a practical workspace, and the company details a series of iterations, mistakes, and engineering solutions tested during the system's development.
Why Neither Extreme of Asking Permission Works in a Workspace
According to Zapier's description, when an AI assistant asks permission for every minor action, users experience rapid fatigue. The company illustrates a scenario where the agent asks permission to read a file, then to read another file, and later to perform a web search. By the tenth request, the user stops reviewing the details of the request and approves it automatically. As a result, the eleventh request, which may involve sending an email to a customer, is approved with the same reflexive motion without being reviewed.
The opposite extreme, in which the agent asks for no permission at all, poses a quiet but substantial risk. An assistant operating without requesting approvals can run for weeks without incident, but the moment it deletes the wrong folder, the user's trust in the system is immediately damaged. Therefore, the core question identified at Zapier is not whether to pause every action, but which decisions belong to the user and which belong to the AI, with the frequency of interruptions to the user following from that answer.
Iteration One: Granular Approval per Tool and Initial Technical Challenges
The initial version of Sidekick divided the agent's tools into two main groups. Read actions ran autonomously without interruption, whereas any action that modified information—such as writing a file, editing a document, or moving or deleting items—paused the process and presented the user with a card offering three choices: Block, Once, or Always.
This initial implementation triggered a series of issues:
- The approval request existed only within the open browser window; closing the tab caused the request to disappear.
- It was impossible to respond to the request from other locations, such as within Slack.
- Choosing the Always option was forgotten the moment the user refreshed the browser page.
- When an action failed, Sidekick could ask for approval again and again for the same action.
- Approval requests were sometimes hidden inside collapsed sections of the conversation and remained out of sight.
- The system displayed approval requests even for harmless steps such as reading a file, causing critical questions to be swallowed among routine ones.
To resolve some of these issues, Zapier saved approvals on its servers, allowing requests to be answered from wherever Sidekick was used. In addition, button copy was modified to clarify exactly what was being approved, for example: "Allow editing files for this chat."
Iteration Two: Shifting Rules from the Tool to the Protected Resource
A few months later, developers identified a deeper problem: Sidekick was running two separate systems for making approval decisions. One system covered built-in capabilities, such as editing a file, while the second system covered small programs Sidekick writes and runs to interact with external applications like Slack. The two systems had been built at different times, did not share common rules, and sometimes provided conflicting answers for the same type of action.
Furthermore, rules were attached to the tool itself (such as "may the write tool be used"), whereas the user is concerned with the resource at risk—such as their Slack account, a specific folder, or an important document. A rule configured on a tool could not specify "never touch this document" or "send messages only to me and not to my coworkers."
Consequently, the system was rebuilt around the protected resource: rules were attached to the file, the connected application, the website, or the automation itself. The rules were structured as a deterministic and consistent system:
- If any rule specifies "never," that instruction prevails.
- If there is no blocking rule and a rule specifies "ask first," the system asks the user.
- Only if no rule blocks the action does Sidekick proceed without asking.
The card was simplified to three options: Cancel, Allow, or Allow and configure rule. Additionally, the agent was granted the capability to read and edit its own rules to explain why a particular action was blocked, and a guardrail was introduced that prevents the agent from proposing a blanket "allow all code execution" rule.
Iteration Three: Making Approval Requests Clear and Legible
According to Zapier, an approval request devoid of specifics is worse than having no prompt at all. Initially, the permission modification card presented the proposed rule as a raw JSON code block. The company replaced it with readable lines displaying a badge (Allow, Ask first, or Deny), the permission scope, an "Only when" condition line, and account names instead of technical connection IDs.
Another issue involved the "Allow and configure" button. Originally, the button merely left a note for the agent, which often forgot it, resulting in users being asked the exact same question again. The chosen fix opens a side chat that handles permission configuration without blocking the primary conversation, leaving a single line in the transcript once the process concludes. In addition, a suggested permissions mechanism was tested that evaluates past decisions and proposes standing rules that can be toggled on and off. Another experiment, in which the agent rewrote code and retried actions, was put on hold, but the underlying concept of spending the AI's compute effort before demanding human attention was preserved.
Moving Review and Approval Mechanisms Outside the Chat Stream
Zapier notes that a chat interface is ill-suited for carefully reviewing proposed actions, as details can become buried within text bubbles. Consequently, the team decided to stop displaying approval requests, questions, and action plans as in-chat messages. These elements were relocated to a panel pinned to the text input box, ensuring they are not buried beneath messages and enabling workflow interaction even while editing a document without a side conversation.
The company elected to keep the panel out of the user's way during active work and open it only when an action requires review, rather than demanding upfront permission configuration prior to starting a task. To address requests that users missed after navigating away from the screen where a task was executing, an inbox was added to review approvals from anywhere across Sidekick.
The Shift to Plain-Language Rules: Auto Mode versus YOLO Mode
An engineer on the team proposed an "Auto mode" prototype in which an AI reviewer reads rules written in plain human language and decides on the user's behalf. The team split between those who insisted on maintaining precise predictability and those who argued that non-technical users cannot be expected to draft exact rules.
The launched design combined both perspectives: user-defined rules remained the firm floor checked first, and the AI reviewer intervenes only when rules do not cover a specific situation. The system offered two modes:
- Auto mode: An AI reviewer evaluates every uncovered action against baseline safety guidelines and user rules, asking the user whenever it is uncertain.
- YOLO mode (short for "dangerously skip permissions"): The system permits the execution of any action not covered by rules, without additional AI review. Even in this mode, "never" and "ask first" rules remained in force, and approval was strictly required prior to altering permissions.
Practical Experience with the Modes and the Direction of the Next Mode
Following the rollout of the modes to pilot users, a user reported that YOLO mode was asking for permission. It turned out the agent was attempting to edit its own permissions—a specific case that YOLO deliberately refuses to bypass. The mode's name had promised a behavior the system refused to supply.
Additionally, the greatest hurdle was drafting instructions for instances where no rule applies and the AI reviewer must exercise judgment. The initial prompt instructed caution regarding any action reaching beyond the user's own data. As a consequence, the agent halted to request approval before a simple search within the user's own files, having interpreted the term "search" as an outward-facing action. The issue was resolved by explicitly clarifying that reading the user's own data is permitted.
In mid-October, Zapier notified YOLO test users that the mode was being discontinued, as skipping all approvals proved to be an incorrect design. The company is developing a new mode in which a single set of rules remains permanently valid, and toggling modes alters only how uncovered cases are handled. In those instances, judgment relies on how easily an action can be undone and its surrounding context. Outward-facing actions (such as sending a message) require approval first, while agreeing to legal terms and executing payments are never permitted.
How to Evaluate Approval Interfaces in AI Products
According to Zapier, the mere fact that a product requests permission does not in itself indicate the quality of the mechanism. The primary test is whether the user understands what they are consenting to at the moment of the request, and whether they can define rules in their own words and identify which rule was triggered. The company concludes that a product can request approval multiple times a day and still earn trust, provided each question clearly demonstrates to the user what is about to happen.