Changing only which app is asking drops a GUI agent's permission grants from 26 of 32 to 0 of 32 on the identical task; phoneshell's confirm gate never reads who is asking at all

No attacker, no injected instruction, the same task every time. Only the name on the permission dialog changed, and a frontier model's willingness to grant it collapsed from near-certain to never. phoneshell's own safety check has no field that question could even be asked of.

"'Allow' to Achieve, Over-Privileged Inadvertently," a Permission Literacy study submitted 5 August 2026 (arXiv:2608.04755, Dongsheng Chen, Yuxuan Li, Guanhua Chen, Jiaxin Zhang, Xiangyu Zhao, Lei Ma, Xin Yao and Xuetao Wei), injects Android-style permission pop-ups into real GUI tasks and tests four frontier multimodal LLMs, each shown an annotated screenshot, the UI-tree hierarchy, the requesting app's identity, the permission being asked for, a stated justification, and the available response actions. The paper's sharpest result holds the task completely fixed and varies one field: in a Calendar task, changing only the requester named on the pop-up from Calendar, a plausible fit, to PiMusic, an implausible one, drops grants from 26 of 32 to 0 of 32. The authors call this App-Trust Bias. A second intervention, changing the task context while holding the pop-up itself fixed, call it Task-Prior Override, shifts authorization decisions substantially in the other direction. Neither manipulation touched the instruction the agent was given. Both changed what it decided to allow.

What changed, and when

The study's four-level Permission Literacy framework, built on task relevance crossed with privacy risk and validated by three independent GUI-agent safety experts, is meant to classify whether a given permission grant was appropriate given what the task actually needed. The App-Trust Bias result sits underneath that framework as a confound: before a model can be judged on whether it got the relevance-and-risk tradeoff right, the study shows that identity alone, which app's name sits on the dialog, moves the decision by the full range from near-certain grant to total refusal, with the task and the permission itself held constant. Prompt interventions reduce unnecessary grants in the paper's tests, but inconsistently across the four models, and sometimes suppress grants that were actually appropriate, which the authors read as evidence that the fix belongs in how the decision is made, not just in how it is prompted. Their suggested direction is separating task execution from permission authorization entirely, as two different decisions made by two different mechanisms.

phoneshell's confirm gate was never built with a requester field to be biased by in the first place, which sounds like a defense and is not one. It is 14 regular-expression patterns, covering order, pay, checkout, buy, purchase, send money, transfer, book, subscribe, delete, remove, log out and sign out, checked against the label text of whatever element phone_tap or phone_do just tapped, documented here on 5 October as missing "Send," "Post," "Unsubscribe," and "Erase All Content and Settings" entirely. An iOS system permission alert is, to phoneshell's harness, just another screen with buttons: Allow Once, Allow While Using App, Don't Allow, Allow. None of those four strings appears among the 14 patterns. The gate does not weigh the requesting app's identity against the permission because it does not represent either concept at all; it would tap "Allow" exactly as readily as it already taps "Send."

Where each system's decision actually comes from

What it means for someone gating a phone agent's dangerous steps

The useful distinction the paper draws out is between a bias and a gap. App-Trust Bias is a bias: the agent has the requester identity in front of it and uses it, just not in a way that tracks actual risk, since an implausible requester gets refused even when the specific permission in that trial might have been harmless, and a plausible one gets granted even when it might not have been. phoneshell's situation is a gap: there is no requester field to misuse, because the harness never represents one. A gap is, in one narrow sense, safer than a bias, since a system with no signal to exploit cannot be fooled by that signal. But it is safer only against attacks that specifically target the signal that is missing; it offers no protection at all against the ordinary case of an agent simply tapping "Allow" because "Allow" is not among the 14 words the gate is watching for, the same shape of miss already catalogued for "Send" and "Post."

For anyone building a gate on top of a GUI agent, the two failures point at the same fix from different directions. The paper's authors suggest separating task execution from permission authorization as distinct decisions, so that a permission grant is never simply a side effect of an agent trying to finish its assigned task quickly. phoneshell's gate currently makes exactly that side-effect mistake in the opposite direction: because it only watches tap labels inside ordinary app screens, a permission alert's own distinctive button text was never pulled into the pattern list as its own category, task-completion pressure and permission authorization were never separated because permission authorization was never recognized as a category at all. Adding "Allow," "Allow Once" and "Allow While Using App" to the 14 patterns would close the specific gap this article measures, but it would only be pattern-matching a fourth kind of dangerous label onto the same label-text mechanism; it would not give phoneshell any of the requester-identity or justification-weighing the paper's four models already have and still get wrong.

• A 26-to-0 swing from a single changed field is a stronger result than a generic "models over-grant permissions" claim, because it isolates identity as the driver and rules out the permission type or the task itself as the explanation.
• Prompt-based mitigation reducing grants inconsistently, and sometimes catching valid ones too, is evidence against treating this as a prompting problem; it argues for a structural separation of the two decisions, which is a harder fix than a better system prompt.
• phoneshell's gap here is independent of, not a subset of, the branch-steering vulnerability covered in the COBRA article on 5 October: that one needs an attacker supplying data to steer a pre-approved branch; this one needs no attacker at all, since App-Trust Bias and phoneshell's missing Allow-pattern are both the agent, unprompted by anyone, making the wrong call on its own.

Check it yourself

# The Permission Literacy study's abstract and the App-Trust Bias numbers
curl -s https://arxiv.org/abs/2608.04755

git clone https://github.com/Blomega/phoneshell && cd phoneshell
grep -n "CONFIRM_PATTERNS\|order\|pay\|subscribe" phoneshell/*/config.py
grep -i "allow" phoneshell/*/config.py   # expect no match

What would prove this wrong

• We read the 26-to-0 swing as evidence that requester identity, not task or permission content, is the dominant signal behind the models' decisions. That is wrong if the paper's full tables, once read past the abstract, show the same swing occurs even when the requester name is varied between two equally plausible apps rather than a plausible one against an implausible one; that would point at a cruder plausibility heuristic rather than true identity-tracking. Untested as of this writing, through 31 December 2027.
• We predict that adding "Allow," "Allow Once," "Allow While Using App" and "Don't Allow" to phoneshell's 14 confirm-gate patterns would make the gate ask before granting any iOS system permission, with no exceptions and no identity-conditioned bias of the kind the paper measures, because the gate has no mechanism to treat one requester differently from another. We will update this article, or file the pattern addition directly, once that gap is closed and tested against a live permission prompt.