Technical Summary: Web Agents Should Adopt the Plan-Then-Execute Paradigm

Problem Statement

The paper argues that the current default architecture for Large Language Model (LLM) web agents, ReAct (Reasoning-and-Acting), is fundamentally insecure and inefficient for web environments.

The Core Vulnerability:
In a ReAct loop, the agent observes the environment (the webpage), queries the LLM for the next action, and executes it. Web content is inherently a mixture of trusted interface elements and untrusted data from third parties (e.g., user reviews, ads, forum posts, sponsored content). Because the ReAct loop interleaves observation and action selection, untrusted content is presented to the model precisely when it decides the next control flow step. This creates a direct path for indirect prompt injection attacks, where an attacker can manipulate the agent's control flow (e.g., hijacking the agent to perform unauthorized actions like data exfiltration or financial transfers) rather than merely influencing data values.

Secondary Issues:

• Inefficiency: ReAct agents are "near-sighted," replanning at every step based on the current state. This leads to high token usage, latency, and cost, as the agent repeatedly rediscover workflows that are often static and repeatable.
• Reproducibility: The dynamic nature of ReAct makes debugging and verifying agent behavior difficult, as the control flow is determined by runtime observations rather than a fixed plan.

Methodology: Plan-Then-Execute (PTE)

The authors propose Plan-Then-Execute (PTE) as a secure alternative architecture. In PTE, the agent commits to a task-specific program before observing runtime web content.

Key Architectural Components:

1. Trusted API Interface: Instead of interacting with raw DOM elements or screenshots, the agent interacts with a trusted API (either provided by the website or constructed as a client-side SDK). This API exposes typed functions (e.g., search(query), add_to_cart(sku)) with known input/output schemas.
2. Planning Phase: The LLM planner generates a deterministic program (the plan) based on the user's goal and the trusted API definitions. Crucially, the planner does not receive runtime web content. The control flow graph is fixed at this stage.
3. Execution Phase: An executor runs the pre-committed program. Runtime web content is only used to fill parameters, determine branch outcomes, or influence data values within the predefined execution graph.
4. LLM Subroutines: To maintain utility, the framework allows the use of LLM subroutines for local data processing (e.g., extraction, classification, summarization) within the fixed plan. However, these subroutines are strictly constrained: they cannot generate new code, select new tools, or alter the control flow. Their outputs are typed and treated as data, not instructions.

Security Guarantee:
PTE enforces a strict separation between control flow (determined during planning) and data flow (determined during execution). Untrusted web content can influence values (e.g., which product is selected based on a review) but cannot redefine the task or cause the model to synthesize new actions at runtime. This prevents control-flow hijacking.

Key Contributions

1. Architectural Critique of ReAct: The paper identifies that ReAct's interleaving of observation and action selection is an architectural flaw for web agents, making them inherently vulnerable to prompt injection.
2. Proposal of PTE for Web Agents: The authors introduce a paradigm shift where agents write programs over typed website APIs before execution, isolating planning from untrusted content.
3. Task Taxonomy and Empirical Analysis:
   • The authors categorize web tasks into three types: Safe (static code), Safe with Influence (requires LLM subroutines for data processing), and Replan-Needed (requires dynamic data-driven planning).
   • They analyze the WebArena benchmark (860 tasks across 6 simulated websites).
   • Result: 100% of WebArena tasks are compatible with PTE. Specifically, 81.28% can be completed with purely programmatic plans (no runtime LLM subroutines), and the remaining 18.72% require LLM subroutines for data processing but remain safe from control-flow hijacking. None of the tasks required dynamic replanning.
4. Identification of Infrastructure Gaps: The paper highlights that the primary barrier to PTE adoption is not modeling capability but infrastructure. Current web interfaces (clicks, scrolls) are not semantically typed. The authors argue for the development of:
   • Typed, complete, and auditable website APIs (or client-side SDKs).
   • API discovery mechanisms to help planners find relevant endpoints.
   • Robust error handling strategies for static plans (e.g., explicit retry logic).

Results and Findings

• Security: PTE eliminates the third category of threat in their model (control-flow hijacking) by design. While "Safe with Influence" tasks remain vulnerable to outcome manipulation (e.g., an adversarial review changing a product selection), the damage is bounded; the attacker cannot redirect the agent to perform unrelated, destructive actions.
• Applicability: The analysis of WebArena demonstrates that the vast majority of common web tasks (shopping, forum posting, issue tracking) have static control flows that can be determined from the user prompt alone, making them ideal candidates for PTE.
• Efficiency: By planning once and executing a fixed program, PTE reduces token consumption and latency compared to the iterative ReAct loop. It also enables caching of plans for common queries.

Significance and Claims

The paper claims that web tasks do not need reactivity by default; they need typed, complete, auditable website APIs.

• Shift in Responsibility: The authors argue that the security problem is not a "modeling problem" (i.e., training models to be more robust) but an "infrastructure problem." The current web lacks the interfaces necessary for secure agent execution.
• Research Agenda: The paper outlines a research agenda focused on building the necessary infrastructure:
  1. Interfaces: Standardizing agent-friendly web APIs and automating the generation of client-side SDKs.
  2. Planner Design: Creating agents that generate expressive, task-specific programs using these trusted APIs.
  3. Verification: Statically checking generated programs against security policies and constraining LLM subroutines via type verification.
  4. Evaluation: Developing benchmarks that jointly measure security, utility, and efficiency.

The authors conclude that while ReAct may still be superior for highly dynamic websites, exploration-heavy tasks, or workflows spanning unpreprocessed sites, Plan-Then-Execute should be the default architecture for web agents to ensure security and efficiency.