Source-linked AI summary
Securing Computer-Use Agents Against Branch Steering Attacks
Giulio Zingrillo, Hanna Foerster, Ilia Shumailov, Yiren Zhao, Robert Mullins
TL;DR
CUAs are vulnerable to indirect prompt injection across rendered web content and MCP tools, and dynamic interfaces allow untrusted data to steer authorized branches. This paper introduces STEER-Bench and COBRA, which combines trusted plans with ahead-of-time branch constraints. COBRA reports 0% ASR on in-scope attacks across four benchmarks while retaining benign completion and utility.
Problem
Dynamic CUA plans must branch on runtime states, allowing untrusted content to steer an authorized path without injecting new instructions.
Source: §1 · p. 1Method
COBRA commits to a trusted branching plan with ahead-of-time capability constraints and enforces them at HTTP and MCP boundaries.
Source: §1 · p. 2Results
0% ASR on 1,259 in-scope attacks across four benchmarks, with 100% benign completion and 79% completion under active attack; STEER-Bench clean-task utility is 97%.
Source: §1 · p. 2Takeaways & Limitations
COBRA extends Dual-LLM protection to constrain branch decisions and action parameters, while results identify semantic effects, unsupported channels, and approved-description availability as open challenges.
Source: §7 · p. 9COBRA cannot deterministically constrain some security-critical values visible only in the GUI, such as a displayed price absent from the HTTP or MCP request.
Source: §6 · p. 8
Abstract
from arXiv · showhide
Modern Computer Use Agents (CUAs) directly interact with graphical user interfaces and execute third-party web tools, exposing them to indirect prompt injection across every rendered page and tool response. While the Dual-LLM pattern is the primary system-level architecture offering formal security guarantees - using an isolated Planner LLM (P-LLM) to fix execution paths before processing untrusted inputs via a Quarantined LLM (Q-LLM) - these guarantees break down in graphical environments. Because CUA interaction is inherently dynamic, plans cannot remain data-independent; they must branch based on anticipated runtime web content - covering all possible cases the agent may encounter. This exposes agents to branch steering attacks, where an adversary crafts untrusted data to coerce a CUA down a hazardous, pre-approved branch without injecting explicit instructions. We systematically study branch steering attacks and introduce STEER-Bench (101 tasks across 9 domains), showing high attack success against both standard (94.4%) and vanilla Dual-LLM (89.5%) CUAs. We then propose COBRA, an architecture that pairs trusted branching plans with ahead-of-time capability constraints, strictly bounding the parameters and destinations each branch may execute. On STEER-Bench, COBRA reduces attack success to 0% while retaining 97% benign utility.
1 Introduction
CUAs face indirect prompt injection through both rendered content and MCP tools, while dynamic interfaces make precommitted plans vulnerable to branch steering. The paper introduces STEER-Bench and COBRA, which pairs branching plans with ahead-of-time capability constraints.
1 Introduction
- CUAs face indirect prompt injection through rendered web content and MCP tools, whose attacks can compose across GUI actions and tool calls.Poisoned tool descriptions may reach the agent during initialization, before website visits.Source: §1 · p. 1
- Dynamic web interfaces require plans to branch on anticipated runtime states, allowing adversaries to steer agents toward hazardous pre-approved paths without injecting new instructions.This branch steering exploits a gap in Dual-LLM control-flow integrity.Source: §1 · p. 2
- COBRA constrains each branch’s capabilities ahead of time and validates runtime choices and action parameters before HTTP or MCP operations proceed.A planner commits the program; a quarantined vision-language model supplies perception, while the Branch Resolution Hub and proxies enforce constraints.Source: §1 · p. 2
- Branch steering succeeds at 94.4% ASR against standard CUAs and 89.5% against vanilla Dual-LLM systems on STEER-Bench’s 101 tasks across 9 domains.The benchmark systematically evaluates branch steering attacks.Source: §1 · p. 2
- COBRA achieves 0% ASR on 1,259 in-scope attacks across four benchmarks while maintaining 100% benign completion and 79% completion under active attack.On STEER-Bench, it also preserves 97% of clean-task utility.Source: §1 · p. 2
2 Related Work
Prior work includes probabilistic injection detection, structural defenses, MCP-specific protections, and benchmarks for web, OS, and tool-use attacks. COBRA’s design addresses tasks that combine GUI-mediated web interaction with MCP calls.
2 Related Work
- Detection-based defenses depend on recognizing attacks, while rerun-based MELON is difficult to apply to live CUAs because clicks reveal little about task intent and desktops are hard to reproduce.Prior attacks include malicious pop-ups, image patches, and visible or hidden visual injections.Source: §2 · p. 2
- Structural defenses enforce predefined properties independently of untrusted content; COBRA’s Figure 1 assigns planning and CFI to the P-LLM/Q-VLM separation and runtime-value checks and DFI enforcement to the BRH and proxies.Prior systems address executable plans, provenance, or isolation, while Progent covers structured tool calls but not GUI interaction or raw HTTP requests.Source: §2 · p. 2, Figure 1 · p. 3
- MCP security work studies tool poisoning and post-approval manipulation, while COBRA targets tasks that combine MCP calls with web interaction.ETDI authenticates tool definitions and binds them to authorization decisions.Source: §2 · p. 3
- Existing benchmarks cover web injections, OS-level attacks, MCP interfaces, or text-based tool agents, but do not exercise all of COBRA’s GUI-mediated HTTP enforcement setting.InjecAgent and ASB study text-based agents rather than live CUAs.Source: §2 · p. 3
- STEER-Bench groups attacks by violated property and tests each suite with its corresponding defense component enabled and disabled, unlike whole-system-only success reporting.This enables component-level analysis of which protections stop attacks.Source: §2 · p. 3
3 Threat Model
The threat model distinguishes control-flow violations from data-flow branch steering and assumes adversaries can manipulate content returned by third-party services. COBRA enforces at HTTP and MCP boundaries, with HTTP checks varying by available site metadata.
3 Threat Model
- Control-flow integrity requires runtime actions to belong to the pre-authorized plan, while data-flow integrity bars untrusted runtime data from choosing branches or setting security-critical action parameters.Branch steering violates DFI by steering an authorized plan without adding instructions, unlike prompt injection that introduces unspecified actions.Source: §3 · pp. 3–4
- The attacker may control rendered web content and, on unapproved or compromised servers, MCP descriptions and outputs, but cannot inspect or alter the committed plan or protected interpreter state.The assumed attacker knows COBRA’s architecture and enforcement mechanisms.Source: §3 · p. 4
- The threat model includes both CFI violations, which induce actions absent from the plan, and DFI violations, which steer authorized branches or bind action parameters.Examples of CFI violations include unauthorized tool calls, malicious-domain navigation, and arbitrary system commands.Source: §3 · p. 4
- COBRA polices outgoing HTTP requests and MCP invocations; without a sitemap, HTTP enforcement restricts operations to an authorized-domain allowlist.With an approved sitemap, the proxy checks request methods, parametrized routes, and payload fields against branch constraints.Source: §3 · p. 4
- User-approved site sitemaps and MCP tool definitions are pinned with SHA-256 hashes, and subsequent upstream changes invalidate the hash and halt execution before dispatch.The stated examples include tool poisoning and rug-pull attacks.Source: §3 · p. 4
4 Architecture
COBRA commits to a plan before untrusted interaction, then resolves branches and parameters against planned constraints. HTTP and MCP proxies enforce those constraints at operation boundaries; fused planning adds alternatives to address unanticipated interface states.
4 Architecture
- The interpreter runs the committed plan, the BRH resolves branch decisions and parameters, and HTTP/MCP proxies check outgoing operations against the resolved constraints.Enforcement targets network and tool calls because a GUI click alone does not identify the operation it causes.Source: §4 · p. 4
- Approved sitemaps describe site operations, endpoints, methods, URL templates, and request fields; MCP tools and structured arguments provide the corresponding vocabulary for tool calls.COBRA binds user approvals to artifact hashes, and changed descriptions require renewed approval.Source: §4 · p. 4
- Before observing untrusted content, the P-LLM generates a program from the trusted request and approved descriptions, then annotates branches with permitted destinations, tools, and parameter constraints.If a security-critical value lacks an authorized source, COBRA asks the user for it during plan construction.Source: §4 · p. 5
- The BRH accepts attacker-supplied branch choices or parameter values only when they satisfy constraints fixed by the plan.Constraints accumulate through nested branches and refresh at each transition, so earlier-branch permissions do not persist.Source: §4 · p. 5
- HTTP and MCP proxies check outgoing operations against BRH constraints; sitemap-backed HTTP checks match declared operations and fields, while MCP checks approved tool definitions and servers.GUI effects that do not traverse HTTP fall outside the stated enforcement boundary.Source: §4 · p. 5
- Without an approved sitemap, COBRA’s HTTP proxy admits only hosts authorized by the plan; with one, it checks destinations and field values against declared operations.Approved sitemaps enable more granular operation-level constraints.Source: §4 · pp. 4–5
- Fused planning merges five parallel plans from the same trusted input into one branching program, retaining distinct alternatives for execution by the standard COBRA components.Five candidates are reported as a favorable empirical trade-off between utility and token consumption.Source: §4 · p. 5
5 Evaluation
COBRA blocks branch-steering attacks on STEER-Bench while retaining benign utility, and external benchmarks show protection across scoped HTTP and MCP threats. On OSWorld-MCP, its completion varies by planner configuration, and fused planning recovers some tasks on the first attempt.
5 Evaluation
- STEER-Bench tests nine targeted components across 101 tasks, 199 attack cells, and 138 benign cells spanning GUI and MCP interactions.Attack success is scored when the targeted harmful action violates active constraints, not when an attacker completes a broader multi-step objective.Source: §5 · pp. 5–6
- 0% ASR with complete COBRA contrasts with 94.4% for ReAct and 89.5% for vanilla Dual-LLM, while COBRA retains 97% benign utility.Disabling targeted protections raises ASR to 55–100%, with a cell-weighted average of 87.6%.Source: Table 1 · p. 6, §5 · p. 6
5.1 External Validation
- On OS-Harm, plan–execution separation blocks all 51 prompt-injection attacks; the HTTP proxy blocks all 21 unauthorized HTTP requests while permitting legitimate operations.The other 30 cases use channels the HTTP proxy does not inspect and remain blocked by the dual-LLM plan–execution boundary.Source: §5.1 · p. 6
- With approved sitemaps, COBRA reduces WASP request-level ASR from 14/19 (73.7%) to 0/19 while preserving 100% benign completion.Without sitemaps, host-level enforcement blocks five cross-domain attacks, but all 14 same-host unauthorized-operation attacks succeed.Source: §5.1 · pp. 6–7
- COBRA blocks all 1,210 MCPTox attacks that change the selected tool or arguments, but cannot distinguish 13 cases with identical calls and different hidden server effects.Utility under attack is 79%, compared with 100% without enforcement; the loss primarily reflects plan-generation failures rather than legitimate calls blocked by the proxy.Source: §5.1 · p. 7
5.2 Utility and Cost
- With gpt-5 planning and UI-TARS-1.5-7B interaction, COBRA completes 133/361 OSWorld-MCP tasks (36.8%), versus 85/361 (23.5%) for UI-TARS ReAct.Sonnet-5 in both COBRA roles yields 38.8% completion versus 36.8% for gpt-5 plus UI-TARS, at $0.627 versus $0.332 per task.Source: §5.2 · p. 7
- On 86 matched OSWorld tasks, COBRA completes 36/86 (41.9%) versus 22/86 (25.6%) for the earlier Dual-LLM system, a 16.3-percentage-point difference.MCP calls occur in 336/722 task–configuration evaluations (46.5%) across the two analyzed configurations.Source: §5.2 · p. 7
- Fused planning moves 27 of 55 tasks (49.1%) that standard planning completed on attempts 2–5 to completion on the first attempt.It merges five candidate plans into one branching program without exposing the planner to runtime observations.Source: §5.2 · p. 7
6 Discussion
COBRA pairs committed branching plans with constraints on the permissions available along each route. The discussion identifies boundaries involving observable operations, blind planning, and the availability of approved service descriptions.
Why constrain both control flow and data flow?
- CFI keeps execution within the committed plan, while DFI constrains permissions for the selected route, including how permissions appear, combine, and expire across branches.Without anticipated execution flow, request-level defenses can leave permissions available when an agent changes course.Source: §6 · pp. 7–8
How far can structural enforcement extend?
- COBRA checks observable HTTP and MCP operations, but cannot deterministically constrain GUI-only values, free-form meaning, hidden server effects, or unsupported channels such as SMTP and filesystem actions.These applications lack a common interface exposing action semantics and values for enforcement.Source: §6 · p. 8
How can blind planning recover from unexpected states without weakening the trust boundary?
- Blind planning can miss interface states: fused planning recovers some later successes on the first attempt but cannot yet replace repeated independent attempts.The discussion identifies training the planner on task trajectories and execution feedback as a possible direction.Source: §6 · p. 8
Will websites make their operations available to agents in a form that can be secured?
- Without authoritative site descriptions, COBRA must rely on coarser host restrictions or reviewed approximations; candidate sitemaps cover every needed operation for 18/25 website-facing tasks (72%).Candidate sitemaps require review and updates as sites change, and whether site owners will publish authoritative descriptions remains uncertain.Source: §6 · pp. 8–9
7 Conclusion
COBRA constrains branch decisions and action parameters before execution, then enforces those constraints at HTTP and MCP boundaries. Its appendix describes how a committed plan becomes branch-specific checks.
7 Conclusion
- COBRA extends Dual-LLM protection beyond control-flow integrity by constraining branch decisions and action parameters at HTTP and MCP boundaries.The conclusion identifies semantic effects, unsupported channels, and the availability of approved service descriptions as open challenges.Source: §7 · p. 9
A From a Plan to Enforceable Constraints
- Deterministic parsing records each plan branch, its alternatives, its condition variable, and destinations named in the plan, fixing available actions before execution.For a price-threshold condition, parsing records the plan variable that supplies the price.Source: A From a Plan to Enforceable Constraints · p. 11
- The P-LLM annotates the fixed plan with branch- and action-specific permissions and value constraints using the trusted request, plan, and approved descriptions.It receives no observations from the current execution.Source: A From a Plan to Enforceable Constraints · p. 11
- Each perception step declares an expected output type; the Q-VLM must return a value in that format or report it is not visible, and invalid or unavailable values raise errors.The interpreter binds validated values to plan variables and evaluates committed branch conditions deterministically.Source: A From a Plan to Enforceable Constraints · p. 11
- After branch selection, the BRH substitutes validated variables into that branch’s constraints and combines inherited constraints; missing values or type mismatches fail checks.Leaving a branch restores the parent state so its permissions do not persist.Source: A From a Plan to Enforceable Constraints · p. 11
- Before execution, the BRH checks action parameters and HTTP/MCP proxies check outgoing calls against resolved constraints; unknown predicates or wrong types cause rejection.A request carrying $80 is blocked when the branch permits $40 in the specified price field.Source: A From a Plan to Enforceable Constraints · p. 11
- If a security-critical value is neither supplied by the trusted request nor obtainable from an authorized source, COBRA asks the user before committing the plan.During execution, untrusted content cannot trigger further clarification requests.Source: A From a Plan to Enforceable Constraints · p. 11
B Designing STEER-Bench’s Suites
STEER-Bench uses targeted ablations to assess component contributions and includes multiple interface layouts to reduce dependence on a single template.
B Designing STEER-Bench’s Suites
- Each attack cell is run with full COBRA and with its targeted component disabled, holding other components fixed to assess that component’s contribution.A higher ASR after disabling a component is evidence it contributed to blocking; unchanged ASR cannot isolate its effect because another defense or model refusal may still block the attack.Source: B Designing STEER-Bench’s Suites · p. 11
- Under ablation, S1, S2, S4, and S8 reach 100% ASR, fully isolating their target components; remaining suites reach 55–80% because another applicable check still blocks some cells.Source: B Designing STEER-Bench’s Suites · pp. 11–12
- Four page layouts vary the placement and presentation of relevant values while preserving the security property under test.Figure 2 shows interfaces from four STEER-Bench tasks.Source: B Designing STEER-Bench’s Suites · p. 12, Figure 2 · p. 12
C Fused Planning
Fused planning merges multiple trusted-request plans into one committed branching program, preserving alternative routes without exposing the planner to runtime observations. On OSWorld-MCP, it recovers some tasks on the first attempt that standard planning completes only after retries.
C Fused Planning
- Five plans from the same trusted request and approved descriptions are merged into one branching program with alternative routes and fallbacks.The candidate strategies vary how they use MCP, GUI interaction, feasibility checks, and progress verification.Source: C Fused Planning · p. 12
- Neither candidate generation nor merging uses runtime observations; the committed program passes through the standard constraint and enforcement pipeline.The Q-VLM can provide observations but cannot add actions or routes, and constraints refresh when execution switches routes.Source: C Fused Planning · p. 12
- First-attempt completion rises from 78 to 105 of 361 tasks with fusion, recovering 27 of 55 tasks standard planning solved only on later attempts.Fusion preserves all 78 standard first-attempt successes.Source: C Fused Planning · p. 12, Table 3 · p. 13
D MESA: Generating Candidate Site Descriptions
This section describes how MESA generates candidate site descriptions, how approved sitemaps enable endpoint-level HTTP enforcement, and how COBRA combines GUI and MCP routes. Evaluations report sitemap coverage and enforcement outcomes, while observed MCP use is associated with mixed task-success differences.
D MESA: Generating Candidate Site Descriptions
- MESA crawls site evidence, proposes common agent operations, and materializes reviewed operations as HTTP sitemaps and corresponding MCP tools.Site owners may edit, remove, or add candidates before publication, and COBRA users separately approve published artifacts; MESA does not certify its output.Source: D MESA: Generating Candidate Site… · p. 13
- On 26 Reddit tasks, MESA provides complete artifact coverage without human revision for 18 (69.2%), partial coverage for three (11.5%), and at least partial coverage for 21 (80.8%).Five tasks (19.2%) lack sufficient coverage.Source: D MESA: Generating Candidate Site… · pp. 13–14
- For 18 of 25 website-facing Chrome tasks (72%), generated sitemaps contain all required operations; the other seven require missing operations.The 25 tasks exclude 21 browser-settings tasks that do not interact with an external website.Source: D MESA: Generating Candidate Site… · p. 14
E Sitemap-Conditioned HTTP Guarantees
- Without an approved sitemap, COBRA retains host-level enforcement but cannot generally distinguish operations on the same authorized host; an approved sitemap defines the closed HTTP action space.The proxy rejects requests whose method or endpoint is not selected by the plan.Source: E Sitemap-Conditioned HTTP Guarantees · p. 14
- With an approved sitemap, endpoint constraints block 14 additional WASP attacks, bringing the total to 19 of 21; without one, host-level enforcement blocks five cross-domain attacks.The remaining two attacks produce an authorized request but differ in a semantic property of free-form text that deterministic request constraints cannot express.Source: E Sitemap-Conditioned HTTP Guarantees · p. 14
F Arbitrating GUI and MCP Interaction
- COBRA plans permitted GUI and MCP paths without a learned channel arbiter; MCP errors can trigger planned GUI fallback, while GUI observations can verify successful MCP operations.The MCP proxy checks tools, servers, and arguments against active branch constraints, so switching modality does not bypass enforcement.Source: F Arbitrating GUI and MCP Interaction · pp. 14–15
- Tasks with observed MCP use succeed at 37.2%, versus 34.2% without observed use, but the direction varies by model and the results are associational.In the Sonnet configuration, success is 42.1% versus 33.8%; among solved tasks, MCP use coincides with fewer mean attempts, 1.98 versus 2.31.Source: F Arbitrating GUI and MCP Interaction · p. 15, Table 4 · p. 15
G Cost and Utility Across Model Roles
The section examines model-use costs and the effect of assigning different models to planning and interaction. Its results describe annotation overhead, higher fused-planning cost, and a small pilot in which local interaction models were less effective as blind planners than gpt-5.
G Cost and Utility Across Model Roles
- In the asymmetric gpt-5+UI-TARS configuration, the locally served Q-VLM uses 78% of overall tokens, while planning and annotation account for all measured cost.Planning and annotation account for 42% of measured tokens with Sonnet-5 and 64% with kimi-k2.5 in dual-role configurations.Source: G Cost and Utility Across Model Roles · p. 15
- Annotation adds 9% to tokens used for planning and interaction without annotation in the gpt-5+UI-TARS sample, with overhead ranging from 7% to 14% across sampled applications.Measured overhead is 18.7% for dual-role Sonnet-5 and 15.0% for dual-role kimi-k2.5.Source: G Cost and Utility Across Model Roles · p. 15
- On OSWorld-MCP, fused planning uses approximately 150,000 P-LLM tokens and costs $0.59 per task, versus 73,000 P-LLM tokens and $0.33 per task for standard planning.Fusion spends more before execution but avoids the retry loop in this measurement.Source: G Cost and Utility Across Model Roles · p. 15
- On a fixed 20-task OSWorld-MCP pilot, locally served GUI models were less effective as blind planners than reactive agents, while gpt-5 produced longer, more reliable plans and completed more tasks.The pilot is too small to establish a general ranking of planner models.Source: Table 6 · p. 16, G Cost and Utility Across Model Roles · p. 16
- Adding gpt-5 planning improves aggregate OpenCUA completion for both interaction-model sizes, with a larger and more consistent domain-level gain for OpenCUA-7B.The caption reports aggregate improvement for both sizes and greater consistency across domains for OpenCUA-7B.Source: Table 7 · p. 16
H OpenCUA Utility Results
Adding a gpt-5 planner improves aggregate completion for both OpenCUA interaction models, but the size and consistency of the gain depend on the interaction model. The larger model has mixed domain-level results, including losses in three domains.
H OpenCUA Utility Results
- COBRA raises OpenCUA-7B completion by 8.6 percentage points and OpenCUA-32B completion by 2.5 points; domain results match or improve for 7B but are mixed for 32B.With OpenCUA-32B, COBRA improves Writer, Impress, Multi-apps, VLC, and VS Code, but loses completion on Chrome, Calc, and Thunderbird.Source: H OpenCUA Utility Results · p. 16