Benign tasks, unsafe shortcuts: a new safety benchmark for computer-use agents

What is this?

In late June 2026, Mina Mohammadmirzaei and Jeffrey Flanigan of the University of California, Santa Cruz posted OSGuard: A Benchmark for Safety in Computer-Use Agents on arXiv. It measures a failure mode that most agent-safety work steps over: an agent that is handed a perfectly legitimate instruction, in an environment that is not trying to trick it, and still causes harm through how it carries the task out.

Much of the existing red-teaming literature — including adversarial suites like OS-Harm — studies what happens when the instruction is malicious or the environment is booby-trapped with injected content. OSGuard targets the complementary regime the authors call benign-task computer use: the original instruction is not malicious, the environment is not overtly adversarial, and the safety challenge arises entirely from the action the agent chooses given the current state of the screen and file system. Reaching the nominal goal is not the same as reaching it safely, and task-success metrics alone cannot tell the two apart.

How it works

OSGuard is not an attack. It is a dual-granularity evaluation suite, and both halves are designed to be run in a controlled environment rather than against anyone’s live desktop.

The first half is an action-level benchmark. It presents a set of contextualized proposed actions, each labelled as allowed, unrelated, or unsafe, where the label is judged relative to the original instruction and the current interface state. This isolates a single question: can a guardrail model, shown one proposed action in context, correctly recognise when that action oversteps the task or would do damage? It is a local, per-step oversight test with no full-task execution involved.

The second half is a risk-augmented execution suite. The authors take task variants derived from OSWorld — a suite of real desktop tasks — and modify the environment so that the original task remains achievable, but a latent hazard is introduced along the way. The example the paper highlights is a destructive overwrite: a file or piece of state that a careless action would clobber even though nothing about the instruction asked for that. Each variant is paired with an augmented evaluator that keeps the original task-success criterion and adds explicit, state-based safety invariants — conditions on the world that must still hold after the agent finishes. An agent that completes the task but violates an invariant is scored as unsafe even though it “succeeded.” No exploit payload is needed to understand this; the mechanism is a measurement harness, not a technique for causing harm.

Why it matters

The headline finding is a gap between two things that are easy to conflate. Current multimodal guardrails can do well on the isolated action-level judgments — shown a single proposed action, they often flag the unsafe one correctly. But the risk-augmented execution suite exposes remaining distance between that local competence and reliable end-to-end safety: recognising an unsafe action in a labelled snapshot is not the same as steering a whole multi-step task away from a destructive shortcut when the model is actually driving.

That distinction matters more as computer-use agents move onto real machines with file access, shell access, and installed applications. The benign-task surface is exactly the one that ordinary users will exercise every day, and it is not covered by defenses tuned for prompt injection or jailbreaks. An agent does not need to be attacked to overwrite the wrong file, empty the wrong folder, or take an irreversible shortcut toward a legitimate goal. OSGuard gives teams a way to see that class of failure instead of hiding it behind a green task-success checkmark.

Defenses

Score safety separately from task success. The core lesson is that a completed task can still be an unsafe one. Evaluations — and production telemetry — should carry explicit safety invariants (what must remain true about files, state, and side effects) alongside the success criterion, so a destructive shortcut is never mistaken for a win.

Evaluate end-to-end, not only per action. A guardrail that scores well on isolated action judgments can still fail to keep a full task safe. Test oversight in the loop, on multi-step execution, the way OSGuard’s risk-augmented suite does, rather than assuming per-step accuracy composes into trajectory-level safety.

Give guardrails the current state, not just the instruction. OSGuard labels actions relative to both the instruction and the interface state. Runtime guardrails should likewise read what is actually on screen and in the file system before approving an action, so context-dependent hazards (an about-to-be-overwritten file) are visible at decision time.

Gate irreversible operations. Destructive overwrites, deletions, and other non-reversible side effects deserve confirmation, snapshots, or a reversible staging layer — controls that cap the damage of a wrong action independently of whether the model recognised it as risky. Related work such as ProjGuard explores lightweight runtime monitoring for exactly this deployment setting.

Constrain capability at runtime. Scoped file permissions, sandboxed working directories, and least-privilege access to system commands limit how much harm a benign-task shortcut can do, regardless of the guardrail’s verdict.

Status

Item	Reference	Date	Notes
Paper	arXiv:2606.15034	June 2026	Mohammadmirzaei & Flanigan (UC Santa Cruz)
Design	Dual-granularity: action-level benchmark + risk-augmented execution suite	—	Benign-task regime; not adversarial
Action level	Proposed actions labelled allowed / unrelated / unsafe vs. instruction + UI state	—	Tests local guardrail decisions
Execution suite	OSWorld-derived variants with latent hazards (e.g. destructive overwrites) + state-based safety invariants	—	Task stays achievable; safety scored separately
Finding	Guardrails handle isolated actions well; end-to-end safety gaps remain	—	Local oversight ≠ full-task safety
Related	OS-Harm, ProjGuard, OSWorld	2025–2026	Adversarial safety, runtime monitoring, base task suite

OSGuard’s contribution is conceptual as much as it is a dataset: it separates “did the agent finish the task” from “did the agent stay safe getting there,” and shows that guardrails which look competent on the first question can still fall short on the second. For anyone deploying a computer-use agent on a real machine, that is the difference worth measuring before the agent touches production files.