PaperlayerView exact revision on arXiv

Source-linked AI summary

Secure-CUA: Controlling Untrusted Influence in Computer-Use Agents

Sarthak Choudhary, Mihai Christodorescu, Ashish Hooda, Somesh Jha, Tongxin Li, Damien Octeau

arXiv:2610.09469v1cs.CRcs.AI

TL;DR

CUAs must use untrusted interface content for legitimate tasks, but that content can alter intended actions or misdirect their execution. Secure-CUA uses per-action transactions to limit that influence; it achieves 53.55% average task success, compared with 55.12% for Vanilla-CUA and 13.17% for CaMeL-CUA.

  • Problem

    Untrusted interface content can redirect a CUA’s chosen action or its GUI commands, while legitimate tasks may still require information from that content.

    Source: §1 · p. 1

  • Method

    Secure-CUA commits to a per-action transaction before accessing untrusted content, fixing its queries and permitted uses, then grounds the action using a masked observation.

    Source: §1 · p. 2

  • Results

    53.55% average task success for Secure-CUA, compared with 55.12% for Vanilla-CUA and 13.17% for CaMeL-CUA.

    Source: §6.2 · pp. 12–13

  • Takeaways & Limitations

    Under the model’s assumptions, Secure-CUA enforces the security requirements while retaining adaptability to changing interfaces and practical task utility.

    Source: §1 · p. 2, §8 · p. 14

    Secure-CUA relies on manually authored labeling rules, does not guarantee query-response correctness, has substantial latency, and is implemented and evaluated for web applications.

    Source: §7 · p. 14

Abstract

from arXiv · show

Computer-use agents (CUAs) perform tasks across applications (such as desktops, mobile apps, and web browsers) by observing graphical interfaces and issuing commands such as clicks and keystrokes. These interfaces combine trusted controls and content with untrusted content needed for legitimate tasks. An adversary controlling this untrusted content can embed instructions or misleading visual cues to change the agent's intended action or redirect its commands to the wrong interface target. We formalize security requirements for both the agent's decisions and their execution through GUI commands. In an ideal execution model, we show that enforcing both requirements at each step protects execution traces. We instantiate this model in Secure-CUA, our system for secure CUA execution. Its key idea is to commit to an explicit per-action program, called an $\textit{action transaction}$, before accessing untrusted content. Each transaction fixes its queries to untrusted content and the permitted uses of their responses. The system masks untrusted regions and evaluates each transaction to produce the next action, using an isolated query model to answer its queries. It then locates the intended interface target using the masked interface. Under the model's assumptions, Secure-CUA is secure by design, while generating a new transaction at each step helps maintain high task utility by adapting to changing interfaces. We evaluate Secure-CUA under benign conditions on 400 WebArena tasks using three frontier models across $5$ seeds, yielding $6,000$ execution traces. Secure-CUA achieves an average task success rate of $53.55\%$, compared with $55.12\%$ for Vanilla-CUA and $13.17\%$ for CaMeL-CUA.

1. Introduction

CUAs can be redirected by instructions or visual cues in untrusted interface content, even though legitimate tasks may require that content. Secure-CUA formalizes protections for action decisions and GUI execution, then implements them with per-action transactions.

Motivation

  • Untrusted content can change a CUA’s chosen action or redirect its commands to the wrong target, although legitimate tasks may require information from that content.The paper distinguishes changing the semantic action from misgrounding an otherwise correct action.Source: §1 · p. 1

Security principles

  • Generation integrity constrains untrusted influence on semantic actions, while grounding integrity requires GUI commands to execute the chosen action as intended.In an ideal execution model, enforcing both at every step protects the execution trace from unauthorized deviations.Source: §1 · p. 2

Secure-CUA

  • Secure-CUA commits to an explicit action transaction before accessing untrusted content, fixing its queries and permitted uses before producing an action.It masks untrusted content, uses isolated queries, and grounds the resulting action with the masked observation; a new transaction at each step supports adaptation to changing interfaces.Source: §1 · p. 2

Evaluation

  • Secure-CUA achieves 53.55% average task success, compared with 55.12% for Vanilla-CUA and 13.17% for CaMeL-CUA.The evaluation covers 400 WebArena tasks across four applications, three frontier models, and five seeds, producing 6,000 traces.Source: §1 · p. 2

2. Related Work

Prior CUA-security work addresses attacks through information-flow architectures, robustness or detection methods, and policies at different interface layers. Secure-CUA combines per-action transactions with protected visual grounding to constrain untrusted influence while supporting adaptive GUI interaction.

Attacks on CUAs

  • CUA attack studies show that malicious web content, pop-ups, images, pixel perturbations, and context manipulation can redirect agent behavior [Liao et al., 2025; Zhang et al., 2025; Wu et al., 2025; Wang et al., 2025; Patlan et al., 2025].VPI-Bench, WASP, and RedTeamCUA benchmark visual prompt injection and attacks in web or hybrid web-OS environments [Cao et al., 2026; Evtimov et al., 2026; Liao et al., 2026].Source: §2 · p. 3

Other approaches

Secure information-flow architectures for CUAs

  • Plan-then-execute systems separate trusted planning from untrusted processing, while CaMeL-CUA uses whole-task programs and quarantined perception [Debenedetti et al., 2025; Beurer-Kellner et al., 2025; Foerster et al., 2026].Other architectures use guardrails, APIs, protected variable passing, or type-directed privilege separation; Secure-CUA instead fixes per-action queries and their permitted uses before retrieval, alongside protected visual grounding.Source: §2 · p. 3

3. Problem Formulation

The formulation models a CUA as choosing semantic actions and grounding them into executable GUI commands while untrusted interface content may affect either stage. Its security principles isolate observations and restrict how untrusted information may influence actions and their execution.

3. Problem Formulation

  • The running example asks the CUA to copy a review into Description, where an embedded instruction may redirect the action to Title or a misleading ad may redirect the click.These illustrate distinct risks: changing the chosen field and grounding the correct field to the wrong coordinates.Source: §3 · pp. 3–4

3.1. CUA Execution

  • A CUA interaction has two stages: action generation chooses a semantic action, and visual grounding translates it into executable GUI commands.A single vision-language model may perform both stages in one call.Source: §3.1 · p. 4

3.2. Threat Model

  • The threat model partitions observations into trusted and untrusted components, assumes attacker-controlled content is classified as untrusted, and trusts runtime mediation and the application’s trusted interface.The adversary may control untrusted text, images, layout, and interactive elements, but cannot modify trusted controls or bypass runtime mediation.Source: §3.2 · pp. 5–6

3.3. Security Principles

  • Observation isolation routes trusted and untrusted content through separate paths, keeping raw untrusted content out of action-generation and grounding contexts.Untrusted content is not simply discarded because tasks may require its information, such as the review text.Source: §3.3 · p. 6
  • Bounded endorsement specifies what information may be taken from untrusted content and how it may be used, with the specification fixed before values are obtained.In the example, the review may supply the typing argument but cannot change the operation or destination.Source: §3.3 · pp. 6–7
  • Generation integrity limits untrusted influence on semantic actions to the task’s bounded-endorsement specification.That specification fixes what information may be endorsed and how it can affect control flow or supply data arguments.Source: §3.3 · p. 6
  • Grounding integrity requires GUI commands to preserve the chosen operation and target regardless of untrusted observations.Typing into Title instead of Description violates this requirement even if the semantic action remains unchanged.Source: §3.3 · p. 7
  • Under trusted runtime mediation, the execution invariant requires both generation integrity and grounding integrity at every step.Untrusted content may influence realized operations, targets, and data arguments only as permitted by bounded endorsement.Source: §3.3 · p. 7

4. Ideal Secure CUA Execution

The ideal execution model links secure action generation and visual grounding through trusted runtime mediation. Its guarantees establish trace integrity, while existing instantiations can leave either grounding or downstream action influence insufficiently constrained.

4.1. Abstract Execution Model

  • The model represents the agent as a semantic controller generating actions from its state and a transducer grounding those actions into GUI commands for the environment.The controller is secure when generation integrity holds at every reachable state; the transducer is secure when grounding integrity holds at every reachable environment state.Source: §4 · p. 7, §4.1 · p. 7

4. Ideal Secure CUA Execution

  • A trusted runtime couples controller and environment transitions, mediating commands, updating history, and supplying the next observation.This abstraction is used to establish security guarantees for execution traces.Source: §4 · p. 7, §4.1 · p. 8

4.2. Security of Execution Traces

  • Under trusted runtime mediation, secure action generation and grounding preserve execution integrity at every step, including against admissible adaptive adversaries.The proof proceeds by induction over the execution trace, maintaining the invariant at each environment transition.Source: §4.2 · p. 8
  • If an adversary can control the outcome of any step in polynomial time, it can construct any finite feasible attack trace in polynomial time under the stated assumption.The construction induces each desired outcome sequentially, including the successor states needed for the next step.Source: §4.2 · p. 8

4.3. Security Gaps in Existing Instantiations

  • A fixed trusted program does not protect GUI target grounding when a VLM processes adversarial observations, so a secure semantic controller alone does not ensure execution integrity.The section describes an attack that redirects a VLM-backed find operation to another post’s downvote control while preserving the semantic action and program branch.Source: §4.3 · pp. 8–9
  • Observation filtering and target permissions do not by themselves establish generation integrity when isolated-query results can influence later actions without enforced use constraints.The section identifies this gap in transducer-focused approaches and motivates combining observation isolation with bounded endorsement.Source: §4.3 · p. 9

5. Secure-CUA Design and Execution

Secure-CUA separates trusted context from untrusted interface content and commits to an action transaction before querying that content. Isolated queries, masked-interface grounding, and runtime checks govern how returned values enter GUI commands.

5. Secure-CUA Design and Execution

  • Secure-CUA separates trusted and untrusted observations, generates a per-action transaction from trusted context, and grounds the resulting action using trusted observations.Its five components are an actuator, Python interpreter, isolated query model, grounding model, and trusted runtime.Source: §5 · p. 9
  • The runtime masks untrusted regions, while each transaction specifies in advance what to retrieve, expected response types, and how responses may affect control flow or action arguments.The actuator commits this specification before accessing untrusted content; the interpreter enforces permitted uses and the isolated query interface validates response types.Source: §5 · p. 10
  • The runtime validates each transaction before evaluation, checks target permission and suitability, and rejects failed steps without executing GUI commands.Rejected steps record sanitized feedback in history.Source: §5 · pp. 10–11
  • Transactions use typed queries to obtain untrusted information, and free-form string results remain opaque symbolic references that may enter designated data arguments.The runtime resolves references only for text insertion or final answers, after any required grounding.Source: §5 · p. 11
  • The grounding model locates targets from the operation and target description without endorsed argument values; the runtime validates targets and inserts those values only into designated data arguments.The runtime then constructs and executes GUI commands, keeping inserted untrusted values masked in later observations.Source: §5 · p. 11
  • Under the stated assumptions, separating raw untrusted content from the actuator and grounding model while enforcing committed query uses provides execution integrity by construction.The isolated query interface confines access to untrusted content, and the per-action program specifies how retrieved information may be used.Source: §5 · p. 11

6. Evaluation

The evaluation tests whether Secure-CUA preserves legitimate task performance under benign conditions while measuring untrusted-information access and execution overhead. Across WebArena tasks, it achieves success rates close to Vanilla-CUA and substantially above CaMeL-CUA.

6. Evaluation

  • The evaluation tests benign task completion because Secure-CUA's protections are intended to block unauthorized influence under the stated assumptions.It asks about task success, untrusted-content queries, and execution overhead.Source: §6 · p. 11

6.1. Experimental Setup

  • The study covers 400 WebArena tasks across Postmill, Shopping, Shopping Admin, and GitLab, run five times with three frontier models.Secure-CUA uses manually authored DOM-labeling rules and assumes adversary-controlled content is labeled untrusted.Source: §6.1 · p. 12
  • Task success is the percentage of runs passing WebArena evaluators; the evaluation also measures query frequency, return types, execution time, and token usage.The task evaluators check string matching, URL matching, and application state.Source: §6.1 · p. 12

6.2. Results and Discussion

  • 53.55% mean TSR versus 55.12% for Vanilla-CUA and 13.17% for CaMeL-CUA; Secure-CUA also gains 20.4 points on Shopping Admin and 6.2 points on GitLab with Gemini 3.8 Flash.Secure-CUA's reductions reach 13.4 percentage points in some Claude Opus 5 settings.Source: §6.2 · pp. 12–13, Figure 3 · p. 13
  • Across 6,000 runs, 19.6% of transactions issue untrusted-content queries, averaging 11.0 queries per task; 52.4% of calls return structured values and 47.6% free-form strings.Structured queries dominate Shopping, while strings dominate Postmill and Shopping Admin.Source: §6.2 · p. 13
  • Secure-CUA averages 4.14 × 10^5 tokens and 426.3 seconds per task, versus 1.82 × 10^5 tokens and 408 seconds for CaMeL-CUA; its runtime is approximately 3× Vanilla-CUA's.Token use remains close to Vanilla-CUA for Opus and Gemini but rises from 2.75 × 10^5 to 4.10 × 10^5 for GPT.Source: §6.2 · p. 13

7. Limitations & Future Work

Secure-CUA's deployment and evidence are bounded by manual labeling, imperfect query-response correctness, substantial latency, and a web-focused implementation and evaluation. The authors identify automation, query robustness, latency reduction, and evaluation beyond web applications as future work.

Limitations

  • Secure-CUA relies on manually authored labeling rules, and bounded endorsement does not guarantee that query responses are correct.The implementation and evaluation focus on web applications, and execution latency remains substantial.Source: §7 · p. 14

Future work

  • Automatic labeling, more robust isolated query models, parallel or batched queries, and desktop/mobile evaluations are proposed future work.The authors suggest labeling automation could ease deployment in new applications and query scheduling could reduce latency while preserving isolation.Source: §7 · p. 14
  • The same trusted/untrusted observation problem also arises in robotics, but adapting the approach requires identifying sensory trust boundaries and preserving intended actions during translation to physical commands.Source: §7 · p. 14

8. Conclusion

The paper formalizes generation and grounding integrity and establishes guarantees for complete execution traces under stated assumptions. Secure-CUA implements these requirements with per-action transactions and achieves WebArena task performance close to Vanilla-CUA and substantially above CaMeL-CUA.

8. Conclusion

  • The formalized security requirements have guarantees for complete execution traces under the stated assumptions.Source: §8 · p. 14
  • Secure-CUA combines observation isolation, bounded endorsement, and explicit per-action transactions to control untrusted influence while adapting to changing interfaces.Source: §8 · p. 14
  • Across 6,000 WebArena runs, Secure-CUA preserves performance close to Vanilla-CUA and substantially outperforms CaMeL-CUA.Source: §8 · p. 14

A. Formal Execution Model and Security Guarantees

The execution model composes semantic action generation, GUI-command grounding, and trusted runtime mediation; under component-security assumptions, every finite trace preserves generation and grounding integrity. An attack procedure that can induce desired outcomes through admissible corruptions can also reproduce feasible traces with a stated computation bound.

A.1. Formal Execution Model

  • The model links controller and environment transitions through a transducer that maps semantic actions to GUI commands, which the trusted runtime executes.The runtime supplies the next observation and updated history to the controller.Source: §A.1 · pp. 18–19, Figure 4 · p. 18
  • A semantic controller generates actions from its state, while a transducer maps each action and environment observation to GUI commands or rejection.The controller state captures context, memory, and task progress.Source: §A.1 · p. 18
  • The model defines controller security by generation integrity at reachable interactions and transducer security by grounding integrity or rejection before execution.Both definitions apply to every admissible untrusted observation.Source: §A.1 · p. 19

A.2. Execution Traces and Adversarial Observations

  • Execution traces allow admissible corruption of untrusted content between steps, and the permitted traces satisfy both integrity requirements at every step.The adversary may choose content based on preceding interactions.Source: §A.2 · p. 19

A.3. Execution Integrity

  • Every finite execution trace satisfies generation and grounding integrity if the semantic controller, transducer, and trusted runtime meet the theorem’s assumptions.The guarantee covers admissible adaptive adversaries.Source: §A.3 · p. 20

A.4. Attack Trace Construction

  • If an attack procedure can induce each desired step outcome through admissible corruption in at most p(n) time, it can reproduce an m-step feasible trace in O(m p(n)) computation time.When p is polynomial, the bound is polynomial in the trace description length.Source: §A.4 · pp. 20–21

B. Analysis of Existing Instantiations

Existing semantic-controller approaches constrain action generation through programs, information-flow controls, or runtime policies. Such constraints do not necessarily govern how untrusted information selects among permitted actions, and direct GUI interaction adds a separate target-mapping obligation.

B.1. Semantic Controller Instantiations

  • Generated programs and runtime policies constrain action generation in different ways, but permissions over multiple actions do not specify how untrusted information may choose among them.Generation integrity additionally requires actions to follow the bounded-endorsement specification.Source: §B.1 · pp. 21–22
  • Unlike tool-calling APIs with trusted operation mappings, direct GUI execution relies on a transducer to map semantic target descriptions to interface elements.A program may preserve its operations and branch while GUI commands reach another object.Source: §B.1 · p. 22
  • Plan-Then-Execute for web agents places named-operation mappings inside trusted APIs or site-specific SDKs, whereas direct GUI interaction must establish that mapping through its transducer.The appendix frames the following attack as an example of leaving this obligation unenforced.Source: §B.1 · p. 22

B.2. Grounding Attack on CaMeL-CUA

A CaMeL-CUA grounding attack redirects an intended upvote to another post’s downvote without changing the semantic action or program branch. The appendix connects this failure to reference corruption, contrasts transducer defenses, and details Secure-CUA’s execution procedure.

B.2. Grounding Attack on CaMeL-CUA

  • In 4 of 5 runs, adversarial content redirected CaMeL-CUA to downvote another post while preserving the intended upvote action and program branch.The attack uses the coordinates returned by find for the unchanged click call.Source: Figure 5 · p. 23, §B.2 · p. 24

B.3. Connection to Function-Pointer Corruption

  • Corrupted GUI coordinates resemble a corrupted function pointer: both can redirect execution while leaving the instruction that uses the reference unchanged.The mechanisms differ: the CUA attack influences the VLM through untrusted observations rather than modifying program memory.Source: §B.3 · p. 24

B.4. Transducer Instantiations

  • Target permissions and isolated queries do not alone ensure integrity: untrusted content can still influence action selection or downstream control flow.Execution integrity requires both a faithful transducer and an action satisfying the semantic-controller contract.Source: §B.4 · pp. 24–25

C. Secure-CUA Implementation Details

  • The implementation appendix covers Secure-CUA’s execution procedure, security guarantees, observation masking, query isolation, transaction language, and grounding enforcement.The runtime procedure is summarized in Algorithm 1.Source: C. Secure-CUA Implementation Details · p. 25, §C.1 · p. 25

C.1. Detailed Execution Procedure

  • Each turn fixes the masked observation and manifest before transaction generation, then validates and evaluates the program before grounding and dispatch.Pending storage writes commit only after dispatch succeeds; pre-interaction failures reject the transaction without executing GUI commands.Source: §C.1 · p. 25
  • After a browser operation has been attempted, a failure may leave application effects the runtime cannot confirm or reverse, and browser effects are not rolled back.Uncommitted storage writes are discarded, while already committed writes remain in persistent storage.Source: §C.1 · pp. 25–26

C.2. Security Guarantees

Secure-CUA’s security guarantees combine fixed action transactions and runtime enforcement to limit untrusted content’s influence on semantic actions and preserve grounded targets during GUI execution. Its component prompts separate querying untrusted content from grounding a chosen action, constraining model inputs and requiring reliable target identification without guessing hidden content.

C.2. Security Guarantees

  • Under observation isolation and correct R and I, untrusted content influences semantic actions only through each transaction’s explicit control flow, establishing generation integrity.The actuator and interpreter realize a secure semantic controller.Source: §C.2 · p. 26
  • With observation isolation, accurate grounding, and correct R and I, runtime mediation preserves each intended target through command execution, establishing grounding integrity and satisfying Theorem 4.1’s conditions.Source: §C.2 · p. 26

C.3. Observation Masking and Query Isolation

  • Untrusted regions are masked in screenshots and accessibility views, then revealed selectively to isolated, single-turn query calls whose typed responses are validated and withheld from the actuator and grounder.The query model receives no separate task instruction, interaction history, or previous query context.Source: §C.3 · p. 27

C.4. Transaction Language and Persistent Storage

  • Transactions use a restricted language and fix query specifications and action control arguments before retrieval, producing exactly one semantic action or rejecting the transaction.Retrieved values cannot rewrite query questions or response specifications.Source: §C.4 · p. 28
  • Free-form strings remain opaque references, usable only in permitted comparisons or designated data fields; explicitly remembered values persist after successful dispatch while raw results remain hidden from the actuator.Persistent writes are published atomically, and uncommitted writes are discarded.Source: §C.4 · pp. 28–29

C.5. Grounding and Runtime Enforcement

  • The runtime validates targets, anchors, and observation stability, then binds opaque values only to designated data arguments and repeats checks before interaction.Changes detected in the page or queried content cause rejection.Source: §C.5 · p. 30

C.6. Component Prompts

  • Component prompts direct the actuator to inspect trusted masked views, query untrusted content only through the transaction, and emit exactly the next action while respecting opaque-string and mask-anchor constraints.The prompt treats retrieved strings as opaque handles and disallows their use as action targets or other grounder-visible free text.Source: §C.6 · pp. 31–32
  • After interpretation chooses an action, the grounder receives that semantic action and masked trusted-view materials, but no task, transaction source, query, query result, memory value, or reasoning.For the Sonnet backend, the runtime also withholds Type.value and Press.key.Source: §C.6 · pp. 33, 36
  • The isolated query model answers only the committed question using a selected region and optional accessibility snippet, without task instructions, interaction history, or protected-storage contents.Text answers must be transcribed verbatim; the model can return an unknown outcome when it cannot answer.Source: §C.6 · p. 35
  • The grounder maps the trusted semantic browser action, already chosen by a protected transaction, to screen coordinates, locating exactly its specified control without changing its operation, target, or effect, and returning not-found if it cannot reliably identify one.Source: §C.6 · p. 36

D.1. WebArena Tasks and Evaluation

The evaluation uses WebArena tasks across four applications, with success determined by benchmark evaluators. Runs repeat tasks under controlled resets and agent-specific interaction budgets.

D.1. WebArena Tasks and Evaluation

  • WebArena covers forum, storefront, store-administration, and repository-management tasks, evaluated with the original instructions and evaluators.A task succeeds only when all required answer, URL, and application-state checks pass.Source: §D.1 · p. 37
  • 400 single-site tasks are selected from WebArena, with 100 per application and a fixed task set across agents, model configurations, and repetitions.The selection ensures at least 30 string_match tasks per application; remaining positions are filled randomly.Source: §D.1 · p. 37

D.2. Execution Protocol

  • Each task is repeated five times from a reset application state and fresh browser profile, with a 40-minute limit and agent-specific interaction budgets.Secure-CUA uses up to 50 transaction attempts; Vanilla-CUA up to 50 browser-action turns; CaMeL-CUA runs one whole-task program under limits of 50 GUI actions and 100 quarantined queries.Source: §D.2 · p. 37

D.3. Access to Untrusted Information

Across 6,000 Secure-CUA runs, the section measures how often transactions query untrusted information, query volume, and the types of returned values.

D.3. Access to Untrusted Information

  • Query frequency includes rejected and partially executed transactions, while mean queries per task counts all issued query attempts across runs.The measures include unsuccessful attempts and calls from transactions later rejected.Source: §D.3 · p. 37
  • Structured queries request Boolean, integer, floating-point, or enumeration values; string queries request free-form text, with percentages computed over all calls.Overall results pool the underlying counts across applications for each model rather than averaging application-level percentages.Source: §D.3 · pp. 37–38
  • Across these runs, 19.6% of transactions issue queries, averaging 11.0 queries per task; among 66,175 query calls, 52.4% request structured values and 47.6% request strings.Source: §D.3 · p. 38

Related papers

Loading 2610.09469v1…