Baya separates planning from exposure to an untrusted website. The agent first compiles the user request into a Python program against a trusted action API; it does not perform the requested website actions before seeing the site. Runtime content can fill data fields and select already-declared branches, but cannot induce fresh model planning that adds…
Inspect the ClaimsCase · DiggingBeagle record
Baya compiles a web-agent plan before exposing it to live pages
Baya reported 77.8% utility across 581 WebArena Verified tasks and no successful attacks in its tested WASP set. Its control-flow protection depends on a trusted website API and does not make page-supplied values true.
Public disclosure: Nov 4, 2026
Scope
Research reported in a controlled research or disclosure setting. Exact prerequisites, versions and absence of documented exploitation must be preserved.
Assessment profile
Assessment method- Setting
- evaluation
- Exploitation
- demonstrated
- Evidence
- Grade C
- Remediation
- not applicable
- AI role
- AGAINST AI
Basis and provenance
The cited first-party advisory or research establishes the stated mechanism only within its documented conditions. No unrelated production compromise, extended victim scope, financial harm or universal mitigation is inferred.
Assessed Nov 9, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-BAYA-COMPILE-BEFORE-BROWSE · CLM-BAYA-WASP-UTILITY · Securing Web Agents with the Compile-Then-Execute Paradigm
At a glance
Separating the planner from hostile observations can reduce control-flow prompt injection; this is not an assertion that all runtime data and API return values are trustworthy.
Read the implicationsPaper benchmarks and supplied Website API only, not a measured browser deployment; malicious values inside allowed branches remain a distinct threat.
Limits and uncertaintyFull account
Baya separates planning from exposure to an untrusted website. The agent first compiles the user request into a Python program against a trusted action API; it does not perform the requested website actions before seeing the site. Runtime content can fill data fields and select already-declared branches, but cannot induce fresh model planning that adds operations. This distinction is central to the paper's design.
The authors report 77.8% aggregate utility over 581 valid WebArena Verified tasks, compared with 66.7% for API-enabled ReAct and 55.1% for browser-only ReAct. In the tested WASP attack set, success was 0% against Baya, 16.2% against API ReAct and 25.5% against browser ReAct. These are separate utility and security measurements, not proof that every supported task is safe.
What compilation does not establish
A fixed program can still consume a false price, address or document value. Limiting which operations are expressible therefore differs from checking whether their arguments and final effects match the user's authorization. That is an architectural limitation to test, not a demonstrated Baya exploit.
The results depend on the supplied Trusted Website API, task coverage and tested attackers. They do not establish universal browser-workflow coverage, trustworthy API permission declarations or production protection against every form of malicious data.
Mechanism and trust boundary
- 01
Before reading live website data, the planner compiles the trusted user request into a Python program against the Trusted Website API.
- 02
Execution obtains live data and follows predeclared branches; page content does not trigger model replanning that introduces new operations.
- 03
Control-flow constraints restrict the available operations but do not independently establish the truth or authorization of every runtime value.
Claims & evidence
CLM-BAYA-WASP-UTILITYIn the authors' tests Baya scored 0% attack success on WASP versus 16.2% for API ReAct and 25.5% for browser ReAct; utility was 77.8% over 581 valid WebArena Verified tasks.supported
Basis: reported finding
- supportsSecuring Web Agents with the Compile-Then-Execute Paradigmprimary disclosure
arXiv abstract: 581 WebArena tasks, 77.8% utility; WASP attack-success results
CLM-BAYA-COMPILE-BEFORE-BROWSEThe Baya paper describes compiling the user request to a Python plan using a trusted website action API before observing any live website data.supported
Basis: reported finding
- supportsSecuring Web Agents with the Compile-Then-Execute Paradigmprimary disclosure
arXiv abstract: compile-then-execute paradigm and Trusted Website API
CLM-ENR231-BAYA-UTILITY-COMPARATORSBaya reported 77.8% aggregate utility on 581 valid WebArena Verified tasks, against 66.7% for API-enabled ReAct and 55.1% for browser-only ReAct in the authors' evaluation.supported
Basis: reported finding
- supportsSecuring Web Agents with the Compile-Then-Execute Paradigmprimary disclosure
Abstract, WebArena Verified results and ReAct baselines
Implications
Separating the planner from hostile observations can reduce control-flow prompt injection; this is not an assertion that all runtime data and API return values are trustworthy.
Controls and mitigations
- Bind consequential arguments and external-effect authorization to trusted source data, and measure task completion as well as attack prevention.
Unknowns and contradictions
- Paper benchmarks and supplied Website API only, not a measured browser deployment; malicious values inside allowed branches remain a distinct threat.
Sources and citation
Material revision history
- Nov 9, 2026 · Published version · first publication · revision 233