Computer Use and the Evaporating Air Gap

Computer Use is the shorthand for the capability now shipping across frontier labs where a model takes screenshots of a real desktop, reads the screen, and drives the mouse and keyboard directly. Anthropic published it first, the rest of the field has matched or extended it, and enterprises are piloting it for support-ticket triage, form-filling workflows, legacy-system integrations, and almost anything where "the data is in a UI and there is no API." The productivity story is straightforward. The security story is not.

The part that is not yet being said out loud in most threat models is that Computer Use quietly voids a lot of the air-gap assumptions that regulated teams have been relying on for two decades.

What air gaps used to protect against

The classic air gap was a network-layer control. A workstation, VM, or administrative jump host had no route out to the public internet. Outbound connections were blocked at the firewall, DNS was internal-only, and any exfiltration attempt required either a physical path — USB, screen photo, printed paper — or a second machine. The control was strong because it was physical in character, even when implemented in software. You could not get data out over a network that did not exist.

Hybrid air gaps — the more common architecture in regulated environments today — are a variation. A restricted network where only approved destinations are reachable, a proxy logs every request, the workstation has no arbitrary internet. The exfiltration surface is narrow and heavily monitored. An adversary with code execution on the workstation is contained because the workstation cannot talk to anywhere interesting.

None of this protects you against a model that can type.

The failure mode

A Computer Use agent running on a restricted workstation is typing into the same browser, clicking the same buttons, and reading the same screens as the human operator it replaces. From a network-layer perspective, its traffic is indistinguishable from the operator's traffic, because it is the operator's traffic. The browser is an allowed destination. The CRM is an allowed destination. The internal ticketing system is an allowed destination. Every action the agent takes is within the approved surface.

What the agent does inside the approved surface is where the exfiltration lives. A model browsing from an air-gapped workstation can paste sensitive data into the search box of an internal tool that logs queries to a third-party analytics service. It can draft an email that happens to include customer records in the signature. It can fill a form on an approved vendor site whose "notes" field is unmonitored. The network control has no view into any of this, because the network control has been telling the truth: no unauthorized destinations were contacted. The unauthorized disclosures all occurred inside authorized ones.

The deeper problem is that the model's actions are fast enough and shaped enough like normal operator behavior that the behavioral analytics on the UI layer are not going to flag them. A human pasting a customer record into a search box at 2 a.m. is an incident. A model pasting the same record into the same box during normal business hours, driving a workflow the operator approved at the start of the session, is traffic.

Why human-in-the-loop is weaker than it sounds

The standard mitigation proposed for Computer Use is human-in-the-loop: require operator confirmation before any sensitive action. This works as theater and fails in practice for the same reason that every other high-volume confirmation control fails. The operator approves hundreds of actions per session. The approvals become reflexive. Any action the model has framed reasonably will be approved.

Human-in-the-loop is effective when the ratio of decisions to confirmations is low. When it is high, and Computer Use workflows by their nature produce high ratios, the human becomes a rubber stamp. This is well understood in the industrial-control literature. It is apparently being relearned in the AI-operations space.

What an actual control looks like

Regulated environments that are approving Computer Use for production need to stop treating it as a network-layer problem and start treating it as a UI-layer problem. The controls that work are the ones that assume the network perimeter has already been bypassed because a model with keyboard access is on the inside.

Three things matter.

First, the desktop the model runs on must be a dedicated environment, not a shared operator workstation. A model-driven session should not have access to the operator's saved credentials, browser history, or file system. This sounds obvious and is almost never implemented that way in early pilots, because the pilots start by handing the model the operator's laptop.

Second, UI-layer telemetry is the new audit surface. Screenshot logging, keystroke logging, and action-attribution at the application level become the record of what the model did. This is what used to be called surveillance and is now, under a different name, the minimum viable compliance control for this class of agent. Teams should expect assessors to ask for it.

Third, the scope of the model's session must be explicit and narrow. A Computer Use agent triaging tickets in a CRM should not have the authority to open the company email client. This is a session-scoping control, enforced at the desktop-environment level, not at the model level. Do not rely on the model to respect scope. Assume the model will do whatever its available UI allows.

Computer Use is a legitimately useful capability. It is also the first mass-deployed class of agent whose risk model is not expressible in the language of firewalls and proxies. The teams that recognize this early will have controls in place before the first incident. The teams that treat it as "just another browser" will be the source of the first incident.