Google launched Computer Use in public preview for Gemini 3.5 Flash on June 24, 2026. The capability lets developers build agents that interpret screenshots and propose interface actions across browser, mobile, and desktop environments.
That is a meaningful shift, but it is not a license to hand an agent the keyboard. Google’s own implementation model makes the boundary clear: the application receives the proposed action, decides whether it is allowed, executes it client-side, captures the new screen state, and repeats the loop. The control plane belongs in the product team’s architecture.
The real release is an action loop
A computer-use agent does not simply return an answer. It can suggest a click, type text, scroll, or otherwise move through an interface. That changes the risk profile from answer quality to execution quality.
For a low-consequence task such as collecting publicly available information, a supervised loop may be enough. For changing customer records, sending communications, purchasing, or touching financial, health, or government data, teams need explicit boundaries before the first pilot.
Three controls to design before a pilot
- Permission boundaries: define the systems, pages, fields, and action types the agent may access. Default to read-only access until a workflow earns broader authority.
- Human approval gates: require a person to approve consequential actions. Google documents safety decisions that can allow, require confirmation, or block actions, but teams still need a clear policy for what requires review.
- Replayable evidence: retain the task request, screenshots or state references, proposed action, safety result, approval, execution outcome, and model version. If an action cannot be reconstructed, it cannot be governed.
Prompt injection becomes an execution problem
When an agent reads a web page or screen, untrusted content can try to redirect it. Gemini includes prompt-injection detection as an opt-in safety mechanism, but detection is only one layer. Treat every page as untrusted input, restrict credentials, isolate sessions, minimize permissions, and stop the task when the environment becomes ambiguous.
In other words, agent safety should not live only in a model setting. It should be expressed in the workflow: where the agent can go, what it can do, when it must pause, and how a human can stop or reverse the result.
Where teams should start
Pick a workflow with a stable interface, clear success criteria, low-cost errors, and a human who already owns the decision. Examples include preparing a draft in a staging environment, collecting data for review, or navigating a known internal tool without making final changes.
Avoid starting with autonomous inbox actions, irreversible record changes, payments, or broad browser access. The fastest path to durable automation is a narrow workflow with strong measurement, not a spectacular demo with vague authority.
The operating question
Computer-use models make it easier to build agents that act. That makes operational design more important, not less. Before enabling a new agent, ask: Can we describe exactly what it may do, what requires approval, and how we will investigate an unexpected action?
If the answer is no, the next work is not prompt engineering. It is workflow design.