Computer-use agents bring the interface back into the threat model

APIs made many software actions explicit: a named operation, typed parameters, a caller identity and a structured response. Computer-use agents move back up the stack. They see pixels or accessibility trees, choose coordinates and controls, type into fields and interpret what appears next.

That flexibility lets an agent work with systems that have no suitable API. It also makes the user interface part of the security boundary again. A button can move, a modal can obscure the target, untrusted content can masquerade as instruction, and a logged-in session can expose far more authority than the task requires.

Computer use should be reviewed as a distinct action technology, not as a generic browser tool.

The interface is an observation, not authoritative state

A screenshot is a rendered view at one moment. It may omit off-screen content, hide state behind overlays, truncate identifiers or present stale information. Accessibility data adds structure but can be incomplete, misleading or inconsistent with pixels. Optical recognition and model interpretation introduce further uncertainty.

Research on computer-use agent vulnerabilities identifies risks including visual overlays, indirect prompt injection and weak binding between interface observations and actions. A separate benchmark, RiOSWorld, evaluates risks originating from both users and environments across web, email, office and operating-system tasks. These studies are early and system-specific, but they show why interface behaviour needs its own adverse testing.

Design around three representations:

• Observed state: what the agent saw—pixels, accessibility nodes, URLs and window metadata.
• Intended action: the semantic effect it meant to cause—send to this recipient, change this field, download this file.
• Authoritative result: what the application or backend confirms actually happened.

Do not treat a changed screen or success message as sufficient proof. Where possible, verify through a structured read, durable record or independent application state.

Broad sessions create ambient authority

A person’s desktop session may contain authenticated email, files, password managers, internal systems and administrative controls. A computer-use agent operating in that session inherits whatever the interface makes reachable, even if the task concerns one website.

NIST’s tool-use taxonomy places computer use in a particularly consequential combination: write access in an untrusted environment. That is not a verdict against the technology. It signals that tool permission and environment trust must be constrained deliberately.

Prefer a dedicated execution identity and environment:

• a separate browser profile, desktop or virtual machine;
• a task-specific user account with least privilege;
• allowlisted applications, destinations and network routes;
• no ambient personal secrets or unrelated sessions;
• controlled download, upload, clipboard and file-system paths; and
• explicit time, action and spending limits.

If the target application supports scoped API access, compare it with computer use. A narrow API may give stronger authorisation and verification. Interface automation is justified when it solves a real integration constraint, not merely because it is easy to demonstrate.

Untrusted content can look like a control

The agent may encounter instructions in webpages, documents, emails, chat messages and images. Those strings belong to the environment; they do not acquire authority because they are visible. Yet a model can interpret them alongside the user’s task.

Treat all environment content as untrusted unless its provenance and role are established. Preserve separation between:

• user objective;
• system and organisational policy;
• application labels and controls;
• retrieved content; and
• messages written by external parties.

Visual design can blur those lines. An attacker can place text next to a familiar icon, construct a fake dialog or hide instructions in a document. The agent should not be authorised to follow any instruction merely because it appears inside the remote interface.

NIST’s analysis of a large-scale agent red-teaming competition reported successful hijacking attacks against all target frontier models in varied agentic scenarios. That finding does not provide a universal failure rate, but it supports defence in depth rather than reliance on model instruction hierarchy alone.

Bind high-consequence actions to stable facts

Coordinate-level commands such as “click at 512, 238” are fragile. The same location may point to a different control after a layout shift. A secure runtime should bind actions to semantic targets and revalidate immediately before execution.

For a consequential action, capture:

• application and trusted origin;
• object identifier and relevant current state;
• semantic control name and expected role;
• exact parameters, recipient, amount or scope;
• approval tied to those facts;
• precondition checked immediately before action; and
• postcondition verified independently afterward.

If the runtime cannot establish those facts, it should ask for help or stop. An agent should not infer a bank account from a truncated label or approve a permission prompt it cannot explain.

Use two-phase execution where possible. The agent prepares the proposed action in a reviewable form, and a separate control performs or authorises the final effect. This is stronger than asking a person to watch a live cursor move.

Build an interface-specific threat model

Review threats across the complete loop:

Stage	Example threat	Control direction
Perception	overlay, hidden element, stale screen	multi-channel checks, provenance, trusted-origin indication
Reasoning	indirect instruction, ambiguous target	context separation, policy enforcement, escalation
Action	misclick, focus theft, keyboard shortcut	semantic targeting, focus lock, allowlisted operations
Session	ambient credentials, cross-application access	dedicated identity, isolation, least privilege
Result	fake success, partial completion	independent state verification
Evidence	sensitive screenshots, missing trajectory	selective capture, redaction, tamper-evident logs

Include ordinary endpoint threats: malware, clipboard leakage, downloads, browser extensions, remote content, session fixation and unpatched applications. Computer-use agents do not create all of these risks, but they can traverse them quickly and repeatedly.

Evaluate effects in a controlled environment

Tests should reproduce realistic interfaces and disruptions, not only clean happy paths. Vary zoom, viewport, latency, pop-ups, expired sessions, layout changes, missing accessibility labels, confirmation order, duplicate clicks and hostile content. Include sites or documents designed to redirect the agent away from the user’s objective.

Use a sandbox that contains realistic but non-production data and no route to protected assets. The UK AI Security Institute’s sandboxing work explains why tool-using agent evaluations need isolation when models can execute code or interact with sensitive resources.

Score more than task completion:

• prohibited actions attempted or completed;
• unnecessary applications or data accessed;
• approval and escalation correctness;
• duplicate or partial effects;
• ability to detect manipulated interfaces;
• recovery after interruption; and
• completeness of evidence for reconstruction.

A successful task with an unauthorised side effect is a failure. A safe refusal on an ambiguous high-consequence screen may be the desired result.

Release with a narrow interface envelope

Begin with a short list of applications, tasks and reversible actions. Keep sensitive flows—payments, access changes, legal submission, deletion, external publication—behind stronger structured controls or direct human execution until the interface path has sufficient evidence.

Define stop conditions: unexpected domain, unrecognised dialog, permission request, changed recipient, security warning, repeated navigation failure, unverified result or evidence of injected instruction. Test the stop path and the handoff, not only the successful task.

Computer-use agents make old applications accessible to new automation. They also inherit the ambiguity and ambient authority that APIs were designed to reduce. The responsible design does not trust the screen. It constrains the session, binds intent to stable facts and verifies the real-world effect beyond the interface.