3.5 Computer Use / desktop control risks
Screen-and-click control can see and act across desktop apps, creating risks that differ from sandboxed code execution.
Last reviewed: August 18, 2026
Computer Use / desktop control risks: what security teams need to know
Computer Use and desktop-control modes operate through screenshots, clicks, typing, and application context. They can cross from one app into another without the neat boundaries that API tools usually provide.
The main control question is whether the organization can see and restrict what the agent can observe or do on the endpoint. Browser and network controls alone usually miss part of this surface.
Common computer use / desktop control risks security failures
The agent can see secrets or personal data on screen.
A desktop app runs outside browser inspection.
Personal AI accounts are used on managed devices.
Screen-based prompt injection appears inside a document, page, or app.
Endpoint logs do not identify which actions were agent-driven.
Computer Use / desktop control risks security controls checklist
Restrict desktop-control features to reviewed groups and devices.
Keep password managers, secret stores, HR, finance, and identity admin apps out of agent workflows.
Use endpoint controls to detect desktop app usage and personal-account sign-in.
Require approval before cross-app actions and external writes.
Log app, window class, user, session, approval, and outcome where possible.
Anthropic
Overview
On the desktop, the Anthropic surfaces are Claude Desktop, Cowork, Claude Code, extensions, browser use, and computer use. Desktop extensions are MCP Bundles (.mcpb): archives containing a local MCP server and a manifest describing its capabilities. Computer use is different: Claude takes screenshots and clicks or types directly in approved applications, with no sandbox between Claude and those apps.
Remote Cowork sessions on web or mobile can reach local files, browser state, or computer use only through the Claude Desktop app while the device is online. Computer use is currently a Pro and Max research preview, not a Team or Enterprise capability, so do not describe it as an enterprise control surface until that availability changes.
Anthropic documentation
Applicable Harmonic guides for Anthropic
OpenAI
Overview
Keep hosted and local OpenAI control separate, because their evidence differs. ChatGPT agent mode is a hosted virtual computer, so its actions do not appear in endpoint telemetry. Local Computer Use runs in ChatGPT Desktop (Work / Codex) on macOS and Windows in both Work and Codex. It can see and operate graphical applications outside the project workspace, so operating-system permissions and the app's allowed-application list become part of the control plane.
ChatGPT Desktop (Work / Codex) combines Chat, Work, and Codex in one installation. Review which executable is deployed, whether Computer Use is installed and enabled, which apps are approved, and which mode initiated the action.
OpenAI documentation
Applicable Harmonic guides for OpenAI
Frequently asked questions about computer use / desktop control risks
What is Computer Use in AI tools?
It is a family of capabilities where the agent observes a screen and acts through clicks, typing, and screenshots rather than structured API calls. It comes in two shapes: hosted virtual computers, such as ChatGPT agent mode, where the desktop belongs to the vendor, and local desktop control, where the agent acts on the user's own machine. The two need different controls and produce different evidence.
Why is desktop control different from API tools?
A screenshot captures whatever is visible, including notifications, password managers, other apps, and personal data, not just what was intentionally shared, and clicks can cross app boundaries that API scopes would have enforced. Screen content is also an injection surface: instructions rendered in a document or page can steer the agent. The tidy per-tool permission model largely disappears.
Should desktop control be allowed on managed devices?
Only for reviewed use cases, restricted user groups, and devices where endpoint telemetry can attribute agent actions. Use platform gates where they exist, such as role-based access for agent capabilities and enterprise controls for desktop extensions, rather than relying on user discipline. Handle personal AI accounts on managed devices first, since they bypass every workspace control.
What apps should be off limits?
Start with password managers, identity admin consoles, finance, HR, healthcare, legal, source-control administration, and production cloud consoles. The pattern: apps where one click is irreversible or one visible screen is a reportable exposure. Keep those apps closed during agent sessions rather than trusting the agent to ignore them.
How can teams monitor desktop-control risk?
Combine endpoint telemetry for which apps ran and which windows were active, AI-platform logs where they exist, app inventory for desktop extensions and local servers, and user reporting. Know the gaps in advance: hosted virtual computers leave no endpoint trace, and local extension activity may not appear in vendor compliance feeds. Section 6.6 maps evidence by surface.
Applicable regulations and frameworks
G.1 Map your controls to NIST AI RMF and CSF 2.0
This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes.
G.3 DORA and AI resilience in financial services
Conditional: for a DORA-regulated workflow, this supports ICT containment, resilience, continuity, and recovery.
G.6 Write an AI Acceptable Use Policy that holds up
This article supplies a technical or process control used to enforce the acceptable-use policy.
G.7 Ownership and RACI for AI security
This control depends on the ownership and evidence responsibilities defined in the RACI.
G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.
Related handbook guidance
Was this helpful?