Search COMPUTER USE

Search the evidence-backed index by name, vendor, or use case.

COMPUTER USE / GUIDE

Computer-use security: design the boundary

A practical review framework for accounts, interface content, execution permissions, and consequence checks.

Begin with the reachable authority

Our editorial security review starts with the execution account and environment. List the records it can read, actions it can perform, files it can access, and external destinations it can reach. Then compare that authority with the task. A prompt restricting an agent to one report is insufficient if the same session can also change billing details.

OpenAI and Anthropic both recommend isolating computer-use environments and limiting privileges. Treat these as baseline design considerations, not a certification of any deployment. The browser, model service, logs, artifact store, and operator console all belong in the data-flow review.

Separate instructions from observed content

A page can contain ordinary data, user-authored messages, and malicious instructions in the same view. The agent needs to read that view to work, but its content must not grant new authority. An instruction embedded in a document to upload another file is not equivalent to a task instruction from the account owner.

Review how proposed actions reach the executor. Domain restrictions, permitted action types, record scopes, and approval checks should be enforced by application code where possible. Detection can help identify suspicious content; it is not a reason to remove execution restrictions.

Make consequential changes reviewable

A useful approval panel shows the actual target, operation, fields, amount if relevant, destination, and supporting artifact. Approving an abstract goal at the beginning of a long run may be insufficient when the concrete result was unknown. Bind approval to the prepared action and invalidate it if the target or payload changes.

Read-only access also deserves boundaries. Copying a private record into a model input, uploading a document, or taking a screenshot can transmit data. The review must cover the collection and observation path, not only the final Submit button. Use synthetic data while proving these controls.

Define evidence for operations

Keep enough trace information to explain what happened: task identifier, account scope, action sequence, approval event, result artifact, and failure reason. Set retention deliberately and remove unnecessary sensitive fields. A detailed trace that becomes a second uncontrolled data store is a new problem.

Before unattended operation, exercise cancellation, session expiry, ambiguous identity, duplicate submission, hostile page instructions, and lost confirmation responses. Decide who receives exceptions and how the run is resumed. This guide describes a review approach; it does not establish regulatory compliance, eliminate prompt injection, or certify any vendor configuration.

RESEARCH NOTES

Sources & verification

Reviewed Sep 27, 2026. Architecture recommendations are editorial analysis; linked vendor documentation supports the underlying capability and safety facts.

  1. developers.openai.com/api/docs/guides/tools-computer-use
  2. platform.claude.com/docs/en/agents-and-tools/tool-use/computer-use-tool
  3. cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html
How we verify evidence →

Put the guidance to work