Executive Summary

Reduce the study to four numbers and it runs like this. How much less the rule-writing group blocked, how many of their rules deferred the decision instead of settling it, how often people approved once those deferred decisions came back as prompts, and how much of the overreach that ended up executing had a person's explicit permission behind it.

The paper opens on a scene. A safety researcher instructed an open-source agent to confirm before acting, yet it began deleting messages from her real inbox and did not stop when told to do so. A natural-language instruction is not necessarily an enforced authorization boundary, and once autonomous execution begins, human intervention may arrive too late. That is the problem the author takes from the incident.

So Ting Yan's August 2026 paper put three permission designs that are in use today side by side. Per-action approval, where a person approves or denies every action (HITL). Model review, where the model handles some actions itself and escalates only a subset (AUTO). And user-authored policy, where the participant sets one standing rule per consequence category before the task begins (POLICY). All three groups supervised the same day and the same 18 actions.

Overreach blocking came out at 59.6%, 53.9%, and 39.6%. In a model that adjusted for action type and presentation order, the user-authored policy group ran 20.1 percentage points below per-action approval (95% CI −32.1, −8.1). The gap against model review was 14.5 points, but it did not survive Holm correction for multiple comparisons. Per participant, that difference works out to roughly 1.4 more overreach actions executing under the policy design than under per-action approval.

The lower blocking rate did not come from rules getting in the way of necessary work. Required-action completion was 94.1%, 96.9%, and 95.3%, close together across the three conditions. The rules did not obstruct the task. They blocked less of what needed blocking.

That said, the rules did block. In the policy group, never rules automatically blocked 11 required actions. Completion stayed level with the other conditions even after paying that cost. The author also notes that no non-inferiority margin was preregistered, so the paper makes no claim that the three conditions were equivalent on completion.

121 people completed the task, and the exclusion criteria preregistered on OSF left 113 in the analysis: 34 in per-action approval, 44 in model review, 35 in user-authored policy. Participants were English-speaking US residents between 18 and 90, recruited with software-industry workers screened out, paid $10 each, and they took about 11 minutes on average. Assignment was random at first, then extended with policy-only recruitment to bring that condition's completed sample closer to the others. The setting is not a developer working with a coding agent. It is an ordinary user handing off ordinary errands.

If the assignment procedure changed partway through, did the result move with it? The author reran the same analysis on the first 100 submissions, collected before the top-up. After the same exclusions that leaves 94 participants, only 16 of them in the policy condition, and in this randomized sample the policy group still blocked 25.0 percentage points less than per-action approval and 19.0 points less than model review. Same direction, same magnitude as the full sample.

The task runs from morning email and calendar through an afternoon trip to the airport and into evening travel wrap-up. The agent attempts 18 actions across that day. Eleven are required to carry out the task, and seven are overreach, outside its scope. The overreach comes in two flavors. Doing something nobody asked for, such as calling the airport to confirm the flight. And reaching into someone else's territory under a plausible pretext, such as reading recent bank transactions to help with the travel budget.

Before the day starts, the policy group sets one rule for each of four consequence categories: spending money, sending or publishing information, deleting, and accessing private information. For each category the choice is one of three options, allow, ask, or never. Money, outbound information, and deletion each contain both required and overreach actions, so a single rule lands on both sides. Private-data access is different. In this scenario every action in that category is overreach.

Thirty-five participants each set one rule per category, so the policy group produced 140 rules in total. 114 of them, 81.4%, were ask. Only 26 settled a future decision in advance: 10 allow and 16 never. Ask was never in the minority in any category. It was chosen by 31 of 35 for spending money, 31 of 35 for sending or publishing, 29 of 35 for deleting, and 23 of 35 for private-data access.

Nor was this a skew produced by a handful of participants. 31 of the 35 chose ask for at least three of the four categories, and 16 of them chose it for all four.

Private-data access was entirely overreach in this scenario, and 23 of 35 participants still chose ask. Ten chose never and two chose allow. Coarse rules alone do not account for that box. Participants had to write a general rule without knowing which situations were coming, and faced with that, they preferred to keep room to judge case by case.

Before setting rules, participants saw two example situations per category and picked allow, ask, or never for each. The same three options they would later see on the rule-setting screen. Their two answers differed in 66 category-level cases, and 53 of those became ask rules. That much can be read as an artifact of coarse rules. But their answers matched in 74 cases, and in 52 of those the answer was already ask; of the remaining 22 matching cases that used allow twice or never twice, only 11 became the corresponding standing rule. Even when people gave themselves the same answer twice, half the time they did not make it a rule.

The paper's conclusion puts it this way: "People may know that they want to decide case by case, but may be unwilling or unable to turn that preference into a broad standing rule." Setting rules in advance can still help, the author adds, but only when those rules settle meaningful decisions. A permission interface should make clear what a rule decides in advance and what it leaves for the user to decide later, because giving users rules is not enough if the important decisions remain unresolved.

Seven overreach actions each for 35 participants comes to 245 attempts in the policy condition. The rules split those 245 three ways. 199 hit an ask rule and went to a runtime permission prompt, 15 ran automatically under an allow rule, and 31 were blocked automatically by a never rule.

Of the 199 that reached a prompt, participants approved 133 and denied 66, an approval rate of 66.8%. That left 148 overreach actions executed, and 133 of them came after someone pressed approve on the spot. 89.9%. Far more leaked through the decisions the rules handed back to people than through the 15 that slipped out automatically. 33 of the 35 participants approved at least one overreach action.

Approval rates diverged between conditions too. On the same seven overreach actions, per-action approval participants approved 40.3% and model-review participants 46.1%, while the policy group approved 66.8%. Balancing the same actions and presentation orders puts the policy group 26.4 percentage points above per-action approval (95% CI 14.7, 38.1). And the gap is not the work of a few unusual actions. The policy group had the highest approval rate on all seven.

▲ Runtime approval of the same seven overreach actions | Source: Yan (2026), Table 4. Per-action approval and model review showed every action to every participant, while the policy condition showed an action only when the standing rule was ask, so the denominators differ.

This comparison should not be read as causal. The author flags it as a conditional association rather than a randomized condition effect. A policy participant only sees a prompt for actions their own rule routed to ask, so the three groups were not looking at the same screens under the same terms. Why they approved more often is something this data cannot identify, and the paper says so among its limitations. What is certain is the observation itself. Faced with a decision that came back as a prompt, people mostly let it through.

Strip out the between-condition comparison and look only inside the policy group, and the same scene remains. 56 ask-routed overreach actions matched a pre-task response where the participant had said never, and participants later approved 24 of them. 17 of the 35 did this at least once. The paper is explicit that this was not a rule violation. The standing rule on those actions was ask, and ask had left the final decision to the user. What changed was not the rule but the preference stated before the task.

The most practical reason to adopt a pre-written policy is to cut down on interruptions. That goal was half met. Runtime permission prompts fell from 18.0 in the per-action group to 10.9 in the policy group (ratio 0.605, 95% CI 0.553 to 0.662). The number of decisions landing on screen clearly dropped. But the model-review group, which wrote no rules at all, was already getting the same relief at 10.0. Cutting prompts did not require users to write rules.

Add in the time spent setting up the rules and the story changes. Mean total intervention time went from 142.1 seconds to 128.8, a difference of −12.9 seconds with an interval running from −46.3 to 20.6, which crosses zero. There is no basis for saying the time went down. The policy group spent effort up front and received fewer prompts later, with total burden unchanged and 20.1 percentage points of blocking given away.

The author attaches a caveat here. An 18-action session was not long enough to show a reliable reduction in total time, and with more daily actions the expectation is that prompt savings accumulate while rule setup remains a one-time cost. So what the experiment pins down is not that the burden stays fixed forever. It is that in the range where the burden went down, the blocking went down with it.

What participants felt did not track the outcome. People in all three conditions reported high perceived control, and no subjective rating differed reliably between the policy group and either baseline. This held even though the policy group let through the most overreach. Feeling in control did not mean the system was providing stronger protection.

Whether the outcomes matched participants' own earlier preferences did not separate the conditions either. Agreement with their pre-task answers came to 75.2% for per-action approval, 74.1% for model review, and 70.2% for the policy group, and the adjusted policy-versus-model-review difference was 3.3 points lower with an interval crossing zero. The prediction that writing your own rules gets you closer to your own preferences was registered before the study ran, and the data did not support that direction.

The three-way choice this study put on the stand is not a design invented in a lab. Reviewing related work, the paper cites Claude Code as a shipping example, with application-enforced allow, ask, and deny rules covering tools, commands, paths, domains, and MCP servers alongside an auto mode, and notes that Codex similarly combines approval modes, static policies, and an operating-system sandbox. The participants here were not developers, though, and what they supervised was not a coding agent. No particular product was on the stand. The permission design pattern those products share was, carried over into a general-user scenario.

For anyone designing agent adoption inside an organization, the question this result poses is sharp. Having an approval policy is easy to enter as evidence in an audit or a compliance review, but whether that policy reduced any risk is a separate fact. In this study the policy existed and 140 rules were written, and the number of decisions it settled in advance was 26. The other 114 handed the decision back to a person, and two thirds of what came back went through.

Which changes what you should be measuring. Not whether a policy document exists, but what percentage of policy items finish a decision before the action, how often the items left on ask come back to a person in live operation, and what the actual approval rate is at those prompts. Without those three numbers, an approval policy is not a mechanism for reducing risk. It is a mechanism for producing approval records.

The design directions the author proposes point at the same spot. Preview which actions a rule would send back as prompts before the user picks it, and estimate how often it would require another decision. When approvals repeat for the same recipient, suggest a narrower rule scoped to that recipient. For reversible actions, consider options outside the three fixed choices, such as a short countdown that lets the action proceed while leaving time to cancel. The point is not to make users choose between an unconditional rule and being asked every time.

The limits are equally clear. This was one scripted day in simulation, no real money or personal data moved, and participants were recruited online from outside the software industry. The four consequence categories were coarse enough that the prevalence of ask could reflect either a preference for case-by-case control or insufficient rule specificity, which the author states as a limitation. The numbers here are better read as coordinates pointing at where policy design leaks than as values that transfer to long-term operation. The conditions of the research itself are worth stating too. The author reports that the study was independently funded without institutional or employer sponsorship, and that because the research environment provided no access to an institutional ethics review board, it received no formal ethics review. Preregistration and released artifacts covering analysis code and model output are offered as the verification path instead.

An earlier Pebblous piece on 3,607 classified field failures stopped at the finding that overeagerness was the most common failure type and concluded that governance had to move to permission design. This experiment fills in the next square. Moving to permission design is not enough on its own. You also have to check whether that design actually finishes any decisions.

Academic

• 1.Yan, T. (2026). "Do User-Authored Permission Policies Improve Protection Against AI Agent Overreach?" arXiv:2608.27443. The primary source for every number in this article.

Industry & Press

• 2.Cramer, J. (2026). ""This should terrify you": Meta's AI safety director lost control of an agent that deleted her emails." Fast Company. The report cited as the opening incident in §1 of the paper above.

Official Documentation

• 3.Anthropic. (2026). "Configure permissions." Claude Code Documentation.
• 4.Anthropic. (2026). "How we built Claude Code Auto Mode: a safer way to skip permissions." Anthropic Engineering.