Web Agents Should Adopt the Plan-Then-Execute Paradigm

Source: arXiv:2605.14290 · Published 2026-05-14 · By Julien Piet, Annabella Chow, Yiwei Hou, Muxi Lyu, Sylvie Venuto, Jinhao Zhu et al.

TL;DR

This paper critiques the dominant ReAct paradigm for large language model (LLM) based web agents, which interleaves reactive reasoning and acting on live, untrusted web content. The authors argue that ReAct exposes a critical security vulnerability to prompt injection attacks because untrusted runtime web content directly influences the agent's control flow decisions, enabling control-flow hijacking. Instead, they propose a plan-then-execute (PTE) architecture where the agent first synthesizes a static, task-specific program over a trusted, typed website API before execution. Untrusted runtime data can only influence data values, not the program's control flow, providing stronger security guarantees by design.

By analyzing the WebArena benchmark, they show that 100% of tasks are compatible with PTE, with 81.28% solvable by fully programmatic static plans requiring no runtime LLM subroutines, and the rest needing only bounded LLM subroutines that cannot generate new control commands during execution. This demonstrates PTE’s practicality and broad applicability. However, the main bottleneck is that the web currently lacks sufficiently rich, typed APIs exposing site actions and semantics needed for effective planning. The authors present a detailed research agenda to build, standardize, and maintain such interfaces. They also discuss tradeoffs including brittleness to unforeseen runtime conditions and the cost of building APIs. Overall, the paper advocates an infrastructure-first approach to securely scale web agents by separating control-flow generation from untrusted runtime data processing.

Key findings

• ReAct architecture permits attacker-controlled prompt injections to hijack agent control flow because the model chooses actions while observing untrusted web content (Section 3).
• Plan-then-execute (PTE) fixes the control-flow vulnerability by generating a static program before execution, isolating runtime untrusted content to data influence only (Section 4).
• WebArena benchmark analysis: 100% of 860 tasks are compatible with PTE; 81.28% can be solved with purely programmatic static plans requiring no runtime LLM subroutines (Table 1).
• Remaining 18.72% of tasks require runtime LLM subroutines restricted to data processing (e.g., classification) but cannot create new runtime actions, preventing control-flow hijacking (Section 6.2).
• No WebArena tasks require reactive replanning during execution, indicating PTE covers majority of practical web tasks (Section 6.2).
• API discoverability and quality documentation are key for effective planning; naive exposure of large API endpoint sets overwhelms planners (Section 6.3).
• Existing backend REST APIs often incomplete (e.g., only 16 endpoints covering 33% tasks); client SDKs via browser automation are brittle and costly to maintain (Section 6.3).
• PTE reduces token usage, latency, and cost compared to ReAct by enabling one-shot planning and execution (Section 7).

Threat model

Adversaries are untrusted third parties publishing content on websites (commenters, sellers, advertisers) who aim to hijack web agents via prompt injection embedded in observed page content. Their goal is to change the agent's control flow arbitrarily (control-flow hijacking) or to influence outcomes by biasing extracted data (outcome manipulation). Website owners and model providers are assumed trusted and not adversarial. The adversary cannot compromise backend code or the model's architecture itself but exploits untrusted runtime observations.

Methodology — deep read

1. Threat Model & Assumptions: The adversary is a third-party content publisher on websites (e.g., commenters, advertisers) who can inject malicious text into pages that web agents observe during task execution. The attacker cannot compromise the website or model provider but aims to hijack agent control flow (leading to arbitrary actions) or manipulate task outcomes (altering data but not control). Model providers and website owners are trusted. The focus is indirect prompt injection attacks embedded in observed web content acting on the agent’s live decision-making.

2. Data: The analysis centers on WebArena, a public benchmark with 860 tasks over simulated websites spanning shopping (OneStopShop), forums (Reddit), code collaboration (GitLab), CMS, maps, and Wikipedia. Tasks are labeled by compatibility with plan-then-execute, requiring only APIs and possibly runtime LLM subroutines.

3. Architecture / Algorithm: The authors contrast ReAct agents which interleave observations and LLM-driven action decisions with plan-then-execute agents that (a) first generate a deterministic program (plan) over a typed, trusted website API capturing site actions, then (b) execute that program. Runtime untrusted content influences only data parameters or restricted LLM subroutines embedded within the program, never control flow branching or tool invocation.

4. Training & Execution Regime: Not applicable since the contribution is architectural and analytic rather than a trained ML model. Instead, the authors formalize the planner and executor as components interacting via strongly typed APIs, enabling static verification and defending against prompt injection.

5. Evaluation Protocol: The crux is manual categorization of WebArena tasks into 3 categories: safe (pure static plans), safe with influence (static plans plus bounded LLM subroutines for data processing), and replan-needed (requiring runtime replanning). They quantitatively measure what percentage fit each category. They analyze security properties and risks associated with each.

6. Reproducibility: WebArena is publicly available. The authors specify assumptions about trusted typed APIs, which currently are not broadly exposed by actual websites—necessitating either website-provided APIs or client SDKs built via headless browsers. Code to generate such SDKs or planners is not detailed, but references exist in prior art (libretto.sh, skyvern.com). Observations about API coverage and brittleness are empirical but based on benchmark analysis.

Concrete End-to-End Example: For the task “Add the best noise cancelling headphones under $200 to my cart,” the PTE agent first generates code using the trusted API exposing product search, filtering by price, selecting based on reviews, and adding the best product to cart. During execution, untrusted web content (e.g., reviews) influences only classification or data extraction subroutines but cannot cause new actions or branch alterations. This eliminates prompt-injection based hijacking of the shop or checkout sequence, unlike a ReAct agent that might click or submit malicious links influenced by adversarial content.

Technical innovations

• Identification of prompt injection vulnerabilities as architectural control-flow hijacking in standard ReAct agents applied to web environments with mixed trusted and untrusted content.
• Proposal and formalization of plan-then-execute architecture that separates planning (control flow generation) and execution (data filling), isolating untrusted runtime data to bounded influence on data values only.
• Demonstration that trusted, strongly typed website APIs enabling static program generation are key enablers for secure planning of web tasks.
• Empirical taxonomy of web agent tasks showing nearly all practical tasks fit the PTE model without requiring reactive replanning.
• Highlighting infrastructure challenge of producing complete, typed, auditable website APIs or SDKs that map website UI actions to semantic operations for effective agent planning.

Datasets

• WebArena — 860 tasks — Public benchmark of multiple simulated websites across shopping, forums, code collaboration, and maps

Baselines vs proposed

• ReAct (standard reactive model): exposed to prompt injection control-flow hijacking, inefficient with repeated re-planning, higher token usage, susceptible to attacker-driven misbehavior.
• Plan-Then-Execute (proposed): 81.28% tasks solvable with static plans, 18.72% require safe LLM subroutines, 0% require runtime replanning; stronger security and 100% coverage of benchmark tasks.

Limitations

• PTE requires trusted, typed, and complete website APIs or SDKs, which are currently mostly unavailable and expensive to build and maintain.
• PTE agents are brittle to runtime unexpected situations (e.g., empty search results) without replanning or interactive clarification, which ReAct handles more gracely.
• Security against outcome manipulation (data-level prompt injection affecting extracted variables or classification) remains a challenge, as this is an integrity problem beyond architectural controls.
• The empirical analysis assumes availability of ideal trusted APIs for all tasks, which may not hold on real-world websites.
• The approach may not fit tasks requiring dynamic discovery or open-ended exploration where control flow depends on runtime data.
• Limited discussion on how to automate SDK/API creation securely without injection risks during preprocessing.

Open questions / follow-ons

• How to design and standardize minimal, typed, and complete APIs that efficiently expose website functionality to support PTE agent planning with minimal developer effort?
• Can automated, secure SDK extraction pipelines be created to generate typed client SDKs from websites without introducing injection risks during preprocessing?
• What mechanisms can complement PTE agents to mitigate outcome manipulation attacks affecting data integrity during execution, e.g., content verification or LLM robustness?
• How can PTE architectures be extended or combined with limited replanning capabilities to handle more dynamic or exploratory web tasks while maintaining security guarantees?

Why it matters for bot defense

For bot-defense and CAPTCHA practitioners, this paper highlights a fundamental architectural vulnerability in current LLM-based web agents to prompt injection attacks that can hijack agent control flows via manipulated page content. It suggests that adopting the plan-then-execute architecture can mitigate these risks by isolating untrusted inputs to data parameters only, blocking attacker influence on control decisions and tool invocations. This separation strengthens the security posture of web agents that perform automated interactions behind the scenes, reducing the attack surface for prompt injections.

However, realizing this architecture requires new infrastructure in the form of robust, typed, trusted programmatic APIs for websites—beyond traditional browser interaction models used today. CAPTCHA and bot-defense teams should understand that defending LLM agents in the wild may necessitate encouraging or enforcing structured API access and auditing rather than reactive, text-driven interaction. Such insights inform defensive design of web automation systems and highlight the limits of tool-use defenses without architectural changes.

Cite

@article{arxiv2605_14290,
  title={ Web Agents Should Adopt the Plan-Then-Execute Paradigm },
  author={ Julien Piet and Annabella Chow and Yiwei Hou and Muxi Lyu and Sylvie Venuto and Jinhao Zhu and Raluca Ada Popa and David Wagner },
  journal={arXiv preprint arXiv:2605.14290},
  year={ 2026 },
  url={https://arxiv.org/abs/2605.14290}
}

Read the full paper

• arXiv:2605.14290 (abstract)
• arXiv:2605.14290 (PDF)