The residual finding in our injection work was uncomfortable. After three layers of defence, the attacks that still succeeded were not asking the agent to do anything unauthorised. They were asking it to do something the user had approved, with parameters the user never saw. A confirmation dialog that says “the agent wants to navigate — allow?” answers the wrong question.
That is a human-factors problem, not a cryptographic one, and we did not have the expertise to guess at it. So we ran a study: 340 participants, five dialog designs, between-subjects, with benign and adversarial requests interleaved in a realistic task flow rather than presented as a security test.
Five designs
- A — Action only. “The agent wants to open a web page. Allow?” No destination shown. This is the design our alpha shipped with, which is why we tested it.
- B — Action plus domain. Adds the destination hostname.
- C — Full URL. Shows the complete destination including path and query.
- D — Full URL with provenance. As C, but the portion of the URL derived from page content rather than from the user is visually marked.
- E — Full URL, provenance, and a plain-language summary of what would be sent.
Design A approved 81% of adversarial requests, which is roughly what DBR-2026-03 predicted from the attack side. Showing the hostname (B) helped less than we expected — attackers control the hostname, and a plausible one defeats it. The full URL (C) dropped approval to 44%. Marking which part of the URL came from page content (D) dropped it to 26%, and adding a plain-language summary (E) reached 22%.
Benign approval stayed above 91% for every design, so none of these is simply training people to refuse. That was the outcome we were most worried about: a dialog that stops attacks by making the agent useless has not solved anything, it has just moved the failure.
The uncomfortable result
We asked participants, immediately after each decision, to describe in their own words what they had just approved. Two raters scored the answers for accuracy. We expected comprehension and correct refusal to track each other closely. They do not.
The correlation is r = 0.31. A substantial number of participants correctly described a request as sending their previous page's contents to an unfamiliar address — and approved it anyway. When we asked why in the debrief, the most common answer was some version of “I assumed it needed to do that.” People extend enormous benefit of the doubt to software they have chosen to trust, and an agent they installed deliberately is exactly that kind of software.
Comprehension is not consent. A user who understands what they are approving and approves it anyway is not protected by a clearer dialog — they are protected by the agent not being able to ask.
This pushed us back toward capability limits rather than better prompts. The dialog improvements are real and we shipped them, but the more durable fix is that the agent's egress is restricted to origins already in the user's session, so the dangerous request cannot be constructed in the first place. A confirmation is a last line, not a first one.
The cost of asking well
| Design | Adversarial approval | Benign approval | Median decision time | Reported friction |
|---|---|---|---|---|
| A — Action only | 81% | 97% | 1.2 s | 1.4 / 5 |
| B — Action + domain | 68% | 96% | 1.6 s | 1.6 / 5 |
| C — Full URL | 44% | 94% | 2.4 s | 2.3 / 5 |
| D — URL + provenance | 26% | 93% | 2.9 s | 2.5 / 5 |
| E — + plain summary | 22% | 91% | 3.1 s | 2.7 / 5 |
Design E costs 1.9 seconds per decision over the baseline and rates 2.7 out of 5 on self-reported annoyance. In a flow where the agent asks two or three times per task that is tolerable. In a flow where it asks fifteen times it is not, and we have seen internally that people begin approving reflexively somewhere around the eighth prompt in a session. Reducing the number of confirmations matters at least as much as improving each one.
By the tenth confirmation in a single session, approval rates on adversarial requests under design E had climbed from 22% to 39%. The dialog had not changed. The person had. Any design evaluated on a single decision will overstate how well it works in a real session, which is a criticism that applies to most published work in this area including our own first attempt.
Method
Limitations
Participants were in a study, using an unfamiliar tool, on data that was not theirs. Every one of those factors probably makes them more cautious than a real user with real stakes and real habituation, which means our approval rates are likely optimistic across all five conditions. The panel skews younger and more technical than a general population. Six adversarial items in a session is a far higher density than reality, which may have made participants suspicious in a way that also flatters the results. And a single session cannot measure habituation over months, which is the timescale that actually matters.
Study materials, dialog designs, and the anonymised response set are available for replication. If you run this with a less technical population we would very much like to see the numbers: research@dartbrowser.com.
Related work
The security-warning literature is long and consistent: users click through warnings they do not understand, and often through ones they do [2, 3]. Egelman et al. [1] established the basic result for phishing warnings and Akhawe and Felt [4] measured click-through at browser scale. Our contribution is to a setting those studies did not anticipate, where the dangerous element is not the action but a parameter of an action the user genuinely wants. We also replicate, in a new context, the habituation effect documented by Vance et al. [5], and find it sets in faster than we expected.
Artefacts
Everything below is published or available on request. A number nobody can reproduce is an advertisement, not a result.
References
- Egelman, S., Cranor, L. F., & Hong, J. (2008). You’ve Been Warned: An Empirical Study of the Effectiveness of Web Browser Phishing Warnings. ACM CHI.
- Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., & Cranor, L. F. (2009). Crying Wolf: An Empirical Study of SSL Warning Effectiveness. USENIX Security.
- Felt, A. P., Ainslie, A., Reeder, R. W., et al. (2015). Improving SSL Warnings: Comprehension and Adherence. ACM CHI.
- Akhawe, D., & Felt, A. P. (2013). Alice in Warningland: A Large-Scale Field Study of Browser Security Warning Effectiveness. USENIX Security.
- Vance, A., Kirwan, B., Bjornn, D., Jenkins, J., & Anderson, B. (2017). What Do We Really Know About How Habituation to Warnings Occurs Over Time? ACM CHI.
- Bhardwaj, M. (2026). Measuring prompt injection resistance in agentic browsers. Dart Browser Research, DBR-2026-03.
Bhardwaj, M. (2026). The confirmation boundary: what users actually approve when an agent asks. Dart Browser Research, DBR-2026-06.
