An LLM browser agent is a crawler whose next action is chosen by a model at run time instead of being written down in advance. You give it a goal in prose — find the privacy settings and turn off personalised advertising — and it decides, page by page, what to click. Browser Use, BrowserGym/AgentLab, Skyvern, Stagehand and the Computer-Use APIs are the current instances. The open-source ones still drive Chromium through one of the control channels Crawler already compares, so what is new there is the planner, not the wire — and which channel it is turns out not to be stable, nor always the one the papers say (see the table below). The vendor computer-use APIs are the exception worth noticing: they act on screenshots and coordinates, and the wire underneath is whatever you supply, so a paper naming one has told you even less.

This page exists because a student in 2026 will be asked, in a review or in a group meeting, “why didn't you use an agent for that?” — and because the honest answer is not obvious from the literature, which contains almost none.

Four properties of your instrument change, and each one changes something you have to report. Nothing else on this page follows from anything but these.

The papers below are, essentially, five different ways of finding this out.

The corpus supports a narrow answer, not a general one. Use the question, not the fashion:

• You need behaviour a script cannot produce, and that is the object of study. Song et al. [1Song, Chuxu; Mekala, Dheekshith Dev Manohar; Wang, Hao; Martin, Richard (2026): "Redefining Website Fingerprinting Attacks with Multi-Agent LLMs", in: Proceedings on Privacy Enhancing Technologies, pp. 688-702. (DOI)] needed website-fingerprinting traffic that looked like a person browsing rather than a robot fetching. Their measurement of why is the strongest argument on this page for the technique: nine state-of-the-art WFP models trained only on scripted-crawler traffic score under 10% accuracy on human traffic, while training on the agent-generated traces “boosts accuracy into the 80% range”. Scripted traffic was not a cheap approximation of human traffic; it was a different distribution. Cost: $35 per GB of authentic human browsing (participant compensation and lab infrastructure) against $10 per GB generated by the agents. This is the case where the agent is not a convenience.
• The workflow is per-site bespoke, long, and there are hundreds of them. Sun et al. [2Sun, Chen; Vekaria, Yash; Nithyanand, Rishab (2026): "On the Suitability of LLM-Driven Agents for Dark Pattern Audits", Proceedings on Privacy Enhancing Technologies 2026(4):927-946. (DOI)] audited CCPA right-to-access flows on 456 data broker sites — no two the same, every one a multi-step form. A script here is 456 scripts.
• The agent itself is what you are measuring. Then you are not on this page's first question at all; see Measuring agents is the bigger literature.

Reach for a script instead when:

• the interaction is uniform across the sample — loading a page, accepting a banner, reading cookies. Interaction and Consent cover instruments built exactly for those, and they are deterministic;
• your claim is a prevalence over a fixed denominator. An agent that completes 81% of workflows has silently redefined your denominator, and in the only published account of where those losses go, over half of them are infrastructure and anti-bot failure (see Where the missing sites go) — which is not a random slice of the web;
• you cannot afford to run it three times. See the variance figures below.
• you need to defend the result in five years. The model behind your agent will not exist. See What to Report.

Checked against primary sources on 2026-08-29 (GitHub API for repository state and releases, PyPI for the package, IETF Datatracker for the drafts). Star counts are omitted deliberately; they measure attention, not fitness.

Five things that table is for:

1. Do not mistake a benchmark for an instrument. WebArena, VisualWebArena, Mind2Web and WebVoyager are how the NLP community evaluates agents. They ship an agent implementation, so you can crawl with one — [7Ramesh, Guruprasad Viswanathan; Nayak, Asmit; Siddique, Basieem; Fawaz, Kassem (2026): "WebSP-Eval: Evaluating Web Agents on Website Security and Privacy Tasks", Proceedings on Privacy Enhancing Technologies 2026(4):666-702. (DOI)] builds on WebVoyager's action space — but you are then building on a 2024 research prototype, and you should say so rather than citing it as a tool.
2. The version gap is already large. The one paper in this corpus that reports a version used browser-use v0.9.5; the current release is v0.13.8. Four minor versions of an agent loop is not a patch level. Neither of the other two Browser Use papers states a version — across the whole family, 1 of 15 agent-tool mentions does. Both release artefacts ([3Jannett, Louis; Mayer, Andreas; Westers, Maximilian; Mladenov, Vladislav; Mainka, Christian; Schwenk, Jörg (2026): "The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web", in: Proceedings of the USENIX Security Symposium. (Link)] on GitHub and Zenodo, [4Jeong, Hyejun; Teymoorianfard, Mohammadreza; Kumar, Abhinav; Houmansadr, Amir; Bagdasarian, Eugene (2026): "Network-Level Prompt and Trait Leakage in Local Research Agents", in: Proceedings of the USENIX Security Symposium. (Link)] on GitHub), so a pin may be recoverable from a lock file by someone who needs it badly enough; it is not in the paper.
3. Two of the five moved off Playwright, and one paper's description of its own stack does not match the package. Stagehand v4 replaced Playwright with chrome-launcher and the Browserbase SDK, and Browser Use has depended on cdp-use rather than Playwright since at least v0.9.5. Both papers that used Browser Use describe their setup as Playwright-driven — [2Sun, Chen; Vekaria, Yash; Nithyanand, Rishab (2026): "On the Suitability of LLM-Driven Agents for Dark Pattern Audits", Proceedings on Privacy Enhancing Technologies 2026(4):927-946. (DOI)] writes “a headless Chrome browser controlled through Playwright”, [3Jannett, Louis; Mayer, Andreas; Westers, Maximilian; Mladenov, Vladislav; Mainka, Christian; Schwenk, Jörg (2026): "The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web", in: Proceedings of the USENIX Security Symposium. (Link)] “using Playwright and the agentic LLM-based Browser Use framework”. They may well have driven Playwright alongside the agent; the point is that “we used framework X” no longer identifies the control channel, which is the one thing Crawler asks you to report. Read the dependency manifest, not the prose.¹⁾
4. Read the registry, not the release page. GitHub's /releases/latest for Stagehand returns 3.7.3, published 2026-08-28; npm's latest dist-tag is 4.0.2, published eight days earlier. 3.7.3 is a v3 maintenance release carrying the v3-latest tag. Take a version from the package registry.
5. MCP is plumbing, not an agent, and so is a vendor toolset. The Model Context Protocol (current protocol version 2026-07-28²⁾) is how a model is handed tools; Playwright MCP makes a browser one of those tools; Anthropic's browser_toolset_20260801 is a tool schema whose calls your own code executes against a browser you host. None of the three decides anything. A paper that says “we used MCP”, or names a vendor toolset, has still not said what drove the browser or what chose the clicks.

The figures below come from a structured extraction over 5,859 full-text papers from CCS, IMC, NDSS, PETS, USENIX Security, TheWebConf and IEEE S&P, 2010–2026. Each query names its own population. The 2025 and 2026 venue-years are provisional — CCS and IMC 2026 have not been held, and IEEE S&P and WWW 2026 abstracts are not in the selection source — which matters more here than on any other page in this wiki, because everything this page counts is inside those two years. Methodology and limitations are at the end of this section.

The same population, for scale:

The contrast that makes “not yet current practice” a measurement rather than an opinion. Same corpus, same years, different role for the same technology:

177 papers (3.0% of 5,859) classify with an LLM; 9 name a browser agent. LLM classification is an established method with a four-year run-up and a page of its own (Website classification); LLM browsing is one year old in this literature and has produced nine papers, six of which are about the agents rather than about the web. Anyone telling you agentic crawling is how the field works now is describing a future, not the record.

This distinction is not in the extraction schema and cannot be derived from it. The nine papers were read by hand and each assignment is recorded with the sentence it rests on (all nine sentences are in the report script and reproduced on llm_agents).

Only three of the nine used an agent purely as an instrument. If you are about to write “prior work uses LLM agents for web measurement”, check which of the two you mean; the citation you reach for is probably a paper measuring the agent.

• How they were produced. One structured record per paper was extracted from full text, each tuple carrying a verbatim evidence quote and its section. The script that produces every number in this section, with its denominators, is report_llm_agents.mjs; the folding rule is a new family in tool_fold.mjs. Every query, the script's unedited output, the full-text probe and the residue are on llm_agents; corpus-level caveats are on Corpus.
• The fold is new and it is an explicit list, not a pattern. “LLM browser agents” is an ordered regex family tested before Playwright and Puppeteer, because several of these agents sit on those libraries — Skyvern requires playwright>=1.46.0, BrowserGym pins playwright==1.44 — and a name matched in the wrong order would be counted as the library rather than as the agent. Two names were excluded on purpose: MCP Server Crawler [9Zhao, Shuli; Hou, Qinsheng; Zhan, Zihan; Wang, Yanhao; Xie, Yuchong; Guo, Yu; Chen, Libo; Li, Shenghong; Xue, Zhi (2026): "Parasites in the Toolchain: A Large-Scale Analysis of Attacks on the MCP Ecosystem", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)], an ordinary crawler over MCP directories, which stays in the report's printed residue; and WebAgentDriver, the Appium XCUITest driver on jailbroken iOS, which sits in a mobile category outside that residue table and is written into the fold file as a comment instead. Crawl4AI and Firecrawl are excluded too — they are conventional crawlers that emit Markdown for a model to read afterwards, and nothing in them decides the next action.
• A full-text probe was run separately, over all 5,869 rendered paper.cols.txt files⁵⁾ for 22 named agent frameworks. It is the reason the counts above are not larger: the extraction sees a framework only when it lands in tools[], and the probe confirms that everywhere else these names appear they are related work. The probe also shows why a naive one is worthless here — the de-hyphenation that repairs PDF line breaks turns “browser-based” into “browserbased”, so a plain /browserbase/i probe reports 45 papers going back to 2010, none of them about Browserbase. Both the wide and tight forms, and everything the tightening discarded, are printed on the provenance page.
• Counts are of papers, never tuples, and shares are of the population named in the heading.
• Everything here rests on the provisional years. Nine papers is a small number and 2026 is an incomplete year. Treat the direction as real and every rate as provisional; the honest claim is “this had not happened yet by 2026”, not “this will not happen”.
• Quotes were checked. All 15 evidence quotes behind the family were matched against the paper full text: 3 exact, 3 partial after normalising whitespace and hyphenation, 9 below threshold — and all nine were then read by hand and all nine are present in the source, failing only because the extraction dropped bracketed citation markers or because two-column reading order interleaved the sentence. The adjudication is on the provenance page.
• Venue coverage. Seven venues. Agent research overwhelmingly publishes at NeurIPS, ICML, ICLR, ACL and CHI, none of which are in this corpus. A count of nine is a statement about security, privacy and measurement venues, not about the world. The frameworks in the table above are real and widely used outside it.

Sun et al. [2Sun, Chen; Vekaria, Yash; Nithyanand, Rishab (2026): "On the Suitability of LLM-Driven Agents for Dark Pattern Audits", Proceedings on Privacy Enhancing Technologies 2026(4):927-946. (DOI)] ran a browser-use agent (v0.9.5, GPT-5, headless Chrome on one California-hosted server, “controlled through Playwright” in their own description — see the caveat above) over 456 data broker sites. The framework's internal is_successful flag reported completion rates of 95% and 89% in two phases. After the authors applied their own verification — a six-category failure taxonomy the agent had to fill in, with runs reporting a failure treated as unsuccessful “even if the internal is_successful flag indicates completion” — the real figure was 81% of workflows, reported as 87% and 79% in the two phases the paper breaks out.⁶⁾

Jannett et al. [3Jannett, Louis; Mayer, Andreas; Westers, Maximilian; Mladenov, Vladislav; Mainka, Christian; Schwenk, Jörg (2026): "The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web", in: Proceedings of the USENIX Security Symposium. (Link)] report the other end of the range. Wanting full automation of passkey registration, authentication and deletion, they built a prototype on Playwright and Browser Use and tried it on five randomly selected passkey-enabled sites: it succeeded on one of the five. They fell back to a semi-automated design. The obstacles they list — customised UIs, confirmation prompts, password re-entry, 2FA by email/SMS/OTP, CAPTCHAs, rate limiting — are not exotic; they are what any authenticated-area measurement meets (Registration).

The 19% Sun et al. could not complete is the most transferable thing in the paper: it is the only published account of where an agent crawl's coverage goes. Their six-category breakdown of the incomplete workflows:

Read the last row first. Only 5.1% of the losses are the model's own reasoning going wrong; just over half — 52.5% — is infrastructure and anti-bot. The authors draw the conclusion that matters for anyone budgeting a sample: “even a perfectly calibrated dark pattern classifier would remain unable to evaluate these workflows without modifications to the underlying system infrastructure and agent-website interaction mechanics.” A better model will not recover them. A different vantage point, a session-recovery mechanism, or an evasion decision might — and the last of those is where this stops being an engineering question (Being Detected, and the Ethics of Not Being).

This is one taxonomy, from one paper, over one task family (CCPA request portals), on a single run. It is the only one published, so it is the best available guess at where your coverage will go — not a law.

Sun et al. report ≈$0.52 and ≈287k tokens per data broker in their best-performing configuration. Over 456 sites that is roughly $240 for one pass; over a Tranco top-10k sample it would be around $5,200 per pass, and the variance figures below say you need more than one pass.

Steiner et al. [5Steiner, Aaron; Peeters, Ralph; Bizer, Christian (2026): "MCP vs RAG vs NLWeb vs HTML: A Comparison of the Effectiveness and Efficiency of Different Agent Interfaces to the Web", in: Proceedings of the ACM Web Conference. (DOI)] put the same cost in a different unit by comparing four ways of giving an agent access to the same four shops. Driving the HTML — the thing an agent-crawler does — was the worst of the four on every axis: F1 0.67 against 0.75–0.77 for the MCP, NLWeb and RAG interfaces; ≈241k tokens per task against 47k–140k; 291 seconds per task against 50–62. Read as measurement advice: if the site offers you an interface that is not the rendered page, the agent is cheaper and better through it — and if your research question is the rendered page, you are paying five times over for the privilege. (Their testbed is four simulated shops, not the live web; treat the ratios, not the absolutes.)

Ramesh et al. [7Ramesh, Guruprasad Viswanathan; Nayak, Asmit; Siddique, Basieem; Fawaz, Kassem (2026): "WebSP-Eval: Evaluating Web Agents on Website Security and Privacy Tasks", Proceedings on Privacy Enhancing Technologies 2026(4):666-702. (DOI)] ran eight agent instantiations over 200 task instances across 28 websites, then re-ran a hard subset three times. The strongest model, Gemini-3.1-Pro, solved 90% of that subset at least once in three trials (pass@3) and 51% in all three (pass³). The weakest, Gemma-3-27B, scored 0.27 and 0.02.

Ramesh et al. also report the ordinary sensitivities, and the largest of them is the model. Over the same 200 instances without navigation hints, Gemini-3-Pro succeeded on 165 and the open-weight Gemma-3-27b on 40 — a spread of 62.5 percentage points between two agents that are otherwise the same harness. Removing the navigation hint from the prompt costs Gemini-3-Pro 4 instances (169 → 165, 84.5% → 82.5%) and Gemini-2.5-Flash 21 (127 → 106, “a relative difference of 16.5%”).⁷⁾ In their benchmark, which model you picked moved the headline number further than any methodological decision on this page. Whether that holds on a live-web prevalence measurement is untested.

Sun et al.'s ablation over four prompt configurations, on the same agent, same model, same sites:

Two readings, both about measurement rather than about prompting. First, the swing from worst to best configuration is 23 points of accuracy on identical data — larger than most effects a web-measurement paper reports, which means an unreported prompt is an unreported instrument. Second, adding a “you are a regulatory auditor” role made it worse: −7.1 points of accuracy and −11.1 of precision against plain zero-shot, because it raised sensitivity and false positives together. The authors flag this as “counter to the common expectation that role framing improves overall task performance”. Publish the prompt, and treat prompt-engineering folklore as a hypothesis about your instrument, not a setting.

For context on the ceiling: their two human annotators building the ground truth reached Cohen's κ = 51.9% on binary present/absent labels before adjudication. Dark-pattern labelling is hard for people too (Interrater agreement).

The three both papers, the two subject papers and the one baseline use all point the instrument at least partly the other way, and this is where the corpus is actually growing. Four of them are worth knowing exist, because they are the reviewer's frame of reference:

• Ersoy et al. [6Ersoy, Devin; Lee, Brandon; Shreekumar, Ananth; Arunasalam, Arjun; Ibrahim, Muhammad; Bianchi, Antonio; Celik, Z. Berkay (2026): "Investigating the Impact of Dark Patterns on LLM-Based Web Agents", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)] built LiteAgent, a harness that runs any of six commercial and academic agents against TrickyArena, four React sites with selectively enabled dark patterns. With a single dark pattern present, agents fell for it 41% of the time on average, higher-performing agents more than weaker ones; prompting them to avoid a specific pattern with step-by-step instructions — the most effective countermeasure they found — cut susceptibility by only about 32%; and turning on vision capabilities lowered task success while raising susceptibility for a majority of agents.
• Ramesh et al. [7Ramesh, Guruprasad Viswanathan; Nayak, Asmit; Siddique, Basieem; Fawaz, Kassem (2026): "WebSP-Eval: Evaluating Web Agents on Website Security and Privacy Tasks", Proceedings on Privacy Enhancing Technologies 2026(4):666-702. (DOI)] ask whether agents can do the security and privacy tasks a user would delegate — managing cookie preferences, revoking sessions — and find performance collapses on stateful widgets (toggles, radio buttons) that require reading the current state before acting.
• Jeong et al. [4Jeong, Hyejun; Teymoorianfard, Mohammadreza; Kumar, Abhinav; Houmansadr, Amir; Bagdasarian, Eugene (2026): "Network-Level Prompt and Trait Leakage in Local Research Agents", in: Proceedings of the USENIX Security Symposium. (Link)] show a passive network observer can recover an agent's prompt and infer user traits from the domain-and-timing trace alone, across GPT Researcher, AutoGen and Browser-Use.
• Steiner et al. [5Steiner, Aaron; Peeters, Ralph; Bizer, Christian (2026): "MCP vs RAG vs NLWeb vs HTML: A Comparison of the Effectiveness and Efficiency of Different Agent Interfaces to the Web", in: Proceedings of the ACM Web Conference. (DOI)] is the interface comparison above, and reads as an argument that the web will grow agent-specific interfaces rather than being browsed as-is.
• The remaining two are further from web measurement but complete the count: Chang et al. [10Chang, Hongyan; Bao, Ergute; Luo, Xinjian; Yu, Ting (2026): "Overcoming the Retrieval Barrier: Indirect Prompt Injection in the Wild for LLM Systems", in: Proceedings of the USENIX Security Symposium. (Link)] on indirect prompt injection reaching a multi-agent system through retrieved web content, and Teoh et al. [8Teoh, Xiwen; Lin, Yun; Li, Siqi; Liu, Ruofan; Sollomoni, Avi; Harel, Yaniv; Dong, Jin Song (2025): "Are CAPTCHAs Still Bot-hard? Generalized Visual CAPTCHA Solving with Agentic Vision Language Model", in: Proceedings of the USENIX Security Symposium. (Link)], whose agentic CAPTCHA solver treats an off-the-shelf web agent as the baseline to beat.

For the mirror image — an LLM planning a crawl you wrote yourself, rather than an off-the-shelf agent — see Stafeev et al.'s YuraScanner [11Stafeev, Aleksei; Recktenwald, Tim; De Stefano, Gianluca; Khodayari, Soheil; Pellegrino, Giancarlo (2025): "YuraScanner: Leveraging LLMs for Task-driven Web App Scanning", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] (NDSS 2025), which drives Puppeteer with GPT-4 to execute task workflows in web applications. It folds nowhere near the frameworks above, because it is one of the “bespoke crawler with its own name” papers that Crawler counts 181 of. That is currently the more common shape.

An agent-driven browser is a third detection category, after “is this a human” and “is this an AI crawler”. Crawler Detection covers the first two and the 2025–2026 turn in bot management; only what is specific to agents belongs here.

• Your search engine will notice first. Jeong et al. [4Jeong, Hyejun; Teymoorianfard, Mohammadreza; Kumar, Abhinav; Houmansadr, Amir; Bagdasarian, Eugene (2026): "Network-Level Prompt and Trait Leakage in Local Research Agents", in: Proceedings of the USENIX Security Symposium. (Link)] record that of Browser-Use, “By default, it issues Google queries via search_web, which frequently triggers reCAPTCHA; we therefore configure it to use Bing with automatic fallback.” An agent that navigates by searching hits the most aggressively bot-managed surface on the web before it reaches your sample.
• Blocking shows up as a failure category, not as an error. Sun et al.'s taxonomy has the agent classify its own blocks, with security_barrier defined as “website actively blocks automation (CAPTCHA, Cloudflare)” — distinct from automation_instability, interaction_failure and navigation_failure. Whatever you build, separate “the site refused” from “the agent gave up”, or your coverage loss is uninterpretable.
• The field has not agreed on evasion, and the disagreement is inside one year. Three 2026 papers, three positions. Sun et al.: “We deliberately avoided evasive crawling techniques (e.g., disguised user agents or proxy rotation)” and treated CAPTCHA-blocked workflows as execution failures. Jannett et al.: “we did not use automatic CAPTCHA solvers, since this would bypass protections designed to prevent automation.” Ramesh et al. [7Ramesh, Guruprasad Viswanathan; Nayak, Asmit; Siddique, Basieem; Fawaz, Kassem (2026): "WebSP-Eval: Evaluating Web Agents on Website Security and Privacy Tasks", Proceedings on Privacy Enhancing Technologies 2026(4):666-702. (DOI)]: “we use the undetected chromedriver and automatic captcha solvers in the setup to help avoid bot detection when interacting with websites.” Whichever you choose, choose it explicitly and defend it in the paper — see Ethics. Note that the third is an agent-benchmarking study on 28 sites the authors hold accounts on, which is not the same ethical situation as an unannounced crawl of 456 strangers.
• Your model vendor sees every page you crawl. An API-backed agent ships the page — its text, often its screenshots — to a third party under that vendor's terms, for every site in your sample. That is a data-handling question a scripted crawl does not raise, and it is separate from detection: it applies to authenticated pages, to participant-facing content, and to any site whose own terms you are relying on. Sun et al. ran GPT-5 over 456 data brokers; Ramesh et al. ran eight models over accounts they held themselves. Say which vendor saw your crawl, and settle it against your ethics approval (Ethics) before the crawl, not after.
• Declaring yourself may become possible. The IETF Web Bot Auth working group is chartered and active, and the current protocol draft — draft-meunier-webbotauth-httpsig-protocol-02, HTTP Message Signatures for automated traffic — was revised on 2026-08-19 and is Active; it replaces the earlier individual draft-meunier-web-bot-auth-architecture.⁸⁾ Nothing to cite yet, and nothing that helps you today, but “sign your crawler and be let in” is the one development that would change the ethics calculus above rather than restating it.

An agent crawl is reproducible only if a reader can rebuild the instrument, and the instrument is now five things instead of one. Of the 15 agent-tool mentions in this corpus, one states a framework version. Do better than the state of the art here; it is cheap.

1. The framework and its exact version. browser-use 0.13.8, not “an LLM agent”. The one paper that did this is the one whose result can still be interpreted.
2. The model, its exact identifier, and its date. gpt-5-2026-xx-xx, not “GPT-5”. Model identifiers are retired; Ramesh et al. had to swap Gemini-3-Pro for Gemini-3.1-Pro mid-study because the first “was discontinued”. If the model is gone, an unversioned reference is unreproducible in the strongest sense.
3. The prompt, in full, in an appendix or artefact. It moved accuracy by 23 points in the only paper that measured it. A prompt is method, not configuration.
4. Temperature, sampling settings and how many times you ran it. If you ran it once, say so — Sun et al. do, and their paper is better for it.
5. Two completion numbers: what the framework reported, and what you verified independently. With the verification procedure. This is the single most consequential line on the page.
6. A failure taxonomy over the sites you did not complete, separating site refusal from agent failure. Otherwise your non-response is uninterpretable and probably not missing at random.
7. Cost per site, in currency and tokens. It is the sample-size constraint, it is comparable across papers, and one paper reporting it ($0.52 / 287k tokens) is not enough for anyone to plan against.
8. Everything a scripted crawl already owes you: browser and version, vantage point (Crawling location), statefulness (Stateful Stateless), dates, and the artefact (Artifacts).

1. [2Sun, Chen; Vekaria, Yash; Nithyanand, Rishab (2026): "On the Suitability of LLM-Driven Agents for Dark Pattern Audits", Proceedings on Privacy Enhancing Technologies 2026(4):927-946. (DOI)] — read this one first even if you never use an agent. It is the only paper in the corpus whose research question is whether the instrument works, and its completion, cost, prompt-ablation and failure-taxonomy figures are the numbers every other page here would want.
2. [1Song, Chuxu; Mekala, Dheekshith Dev Manohar; Wang, Hao; Martin, Richard (2026): "Redefining Website Fingerprinting Attacks with Multi-Agent LLMs", in: Proceedings on Privacy Enhancing Technologies, pp. 688-702. (DOI)] — the strongest case for: a measurement that scripted crawling could not have produced, with the cost comparison.
3. [3Jannett, Louis; Mayer, Andreas; Westers, Maximilian; Mladenov, Vladislav; Mainka, Christian; Schwenk, Jörg (2026): "The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web", in: Proceedings of the USENIX Security Symposium. (Link)] — one paragraph, one of five sites, and an honest retreat to semi-automation. The counterweight.
4. [6Ersoy, Devin; Lee, Brandon; Shreekumar, Ananth; Arunasalam, Arjun; Ibrahim, Muhammad; Bianchi, Antonio; Celik, Z. Berkay (2026): "Investigating the Impact of Dark Patterns on LLM-Based Web Agents", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)] — if agents browse for users, dark patterns are aimed at agents. LiteAgent and TrickyArena are released.
5. [5Steiner, Aaron; Peeters, Ralph; Bizer, Christian (2026): "MCP vs RAG vs NLWeb vs HTML: A Comparison of the Effectiveness and Efficiency of Different Agent Interfaces to the Web", in: Proceedings of the ACM Web Conference. (DOI)] — what driving the HTML costs relative to the alternatives.
6. [11Stafeev, Aleksei; Recktenwald, Tim; De Stefano, Gianluca; Khodayari, Soheil; Pellegrino, Giancarlo (2025): "YuraScanner: Leveraging LLMs for Task-driven Web App Scanning", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] — the more common shape: your own crawler, with an LLM choosing the workflow.

• Crawler — the control channel underneath every agent here, and the framework table this page adds a row to.
• Crawler Detection — bot management, and the 2025–2026 AI-crawler turn.
• Interaction — what to do on the page, deterministically.
• Website classification — LLMs in the role they actually established themselves in.
• Automated measurements — whether to crawl at all.
• Ethics — where the evasion decision belongs.
• Interrater agreement — for the human ground truth an agent has to be measured against.
• llm_agents — every query, the report script's output, the fold residue and the quote adjudication behind this page.

[1]

Song, Chuxu; Mekala, Dheekshith Dev Manohar; Wang, Hao; Martin, Richard (2026): "Redefining Website Fingerprinting Attacks with Multi-Agent LLMs", in: Proceedings on Privacy Enhancing Technologies, pp. 688-702. (DOI)

[2]

Sun, Chen; Vekaria, Yash; Nithyanand, Rishab (2026): "On the Suitability of LLM-Driven Agents for Dark Pattern Audits", Proceedings on Privacy Enhancing Technologies 2026(4):927-946. (DOI)

[3]

Jannett, Louis; Mayer, Andreas; Westers, Maximilian; Mladenov, Vladislav; Mainka, Christian; Schwenk, Jörg (2026): "The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web", in: Proceedings of the USENIX Security Symposium. (Link)

[4]

Jeong, Hyejun; Teymoorianfard, Mohammadreza; Kumar, Abhinav; Houmansadr, Amir; Bagdasarian, Eugene (2026): "Network-Level Prompt and Trait Leakage in Local Research Agents", in: Proceedings of the USENIX Security Symposium. (Link)

[5]

Steiner, Aaron; Peeters, Ralph; Bizer, Christian (2026): "MCP vs RAG vs NLWeb vs HTML: A Comparison of the Effectiveness and Efficiency of Different Agent Interfaces to the Web", in: Proceedings of the ACM Web Conference. (DOI)

[6]

Ersoy, Devin; Lee, Brandon; Shreekumar, Ananth; Arunasalam, Arjun; Ibrahim, Muhammad; Bianchi, Antonio; Celik, Z. Berkay (2026): "Investigating the Impact of Dark Patterns on LLM-Based Web Agents", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[7]

Ramesh, Guruprasad Viswanathan; Nayak, Asmit; Siddique, Basieem; Fawaz, Kassem (2026): "WebSP-Eval: Evaluating Web Agents on Website Security and Privacy Tasks", Proceedings on Privacy Enhancing Technologies 2026(4):666-702. (DOI)

[8]

Teoh, Xiwen; Lin, Yun; Li, Siqi; Liu, Ruofan; Sollomoni, Avi; Harel, Yaniv; Dong, Jin Song (2025): "Are CAPTCHAs Still Bot-hard? Generalized Visual CAPTCHA Solving with Agentic Vision Language Model", in: Proceedings of the USENIX Security Symposium. (Link)

[9]

Zhao, Shuli; Hou, Qinsheng; Zhan, Zihan; Wang, Yanhao; Xie, Yuchong; Guo, Yu; Chen, Libo; Li, Shenghong; Xue, Zhi (2026): "Parasites in the Toolchain: A Large-Scale Analysis of Attacks on the MCP Ecosystem", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[10]

Chang, Hongyan; Bao, Ergute; Luo, Xinjian; Yu, Ting (2026): "Overcoming the Retrieval Barrier: Indirect Prompt Injection in the Wild for LLM Systems", in: Proceedings of the USENIX Security Symposium. (Link)

[11]

Stafeev, Aleksei; Recktenwald, Tim; De Stefano, Gianluca; Khodayari, Soheil; Pellegrino, Giancarlo (2025): "YuraScanner: Leveraging LLMs for Task-driven Web App Scanning", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[12]

Zeber, David; Bird, Sarah; Oliveira, Camila; Rudametkin, Walter; Segall, Ilana; Wolls´en, Fredrik; Lopatka, Martin (2020): "The Representativeness of Automated Web Crawls as a Surrogate for Human Browsing", in: Proceedings of The Web Conference 2020, pp. 167–178. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)