Gemini Computer Use is GA: injection checks stay opt-in

Google made the Computer Use tool in the Gemini API generally available on Oct. 30, 2026, across both the Interactions API and the GenerateContent API. The tool lets a Gemini model look at a screenshot of a browser, an Android device or a desktop and return the next click, keystroke or scroll for your code to run. If you held a computer-use agent back because it was a preview feature, the decision now is which safety settings to change before it touches real accounts.

The catch is one default. Gemini's built-in safety system flags risky actions on every request, but its check for prompt injection hidden in screenshots is opt-in, and the documentation says "The default is false." An agent that reads web pages, inboxes or tickets should have it turned on before launch.

What changed in Gemini Computer Use?

Computer Use moved from public preview to general availability. The June 24, 2026 preview, launched with Gemini 3.5 Flash, already included the parts that matter here: actions with an intent field, browser, mobile and desktop environments, configurable safety policies and prompt injection detection. The Oct. 30 release note changes the support status and confirms the tool works on both API surfaces.

That second point matters if your Gemini code still uses generateContent. You can add Computer Use there without moving to the Interactions API first.

Google lists four models for the tool:

• gemini-3.8-flash, which Google calls "the recommended model for computer use."
• gemini-4-argon, its most capable model, for complex reasoning.
• gemini-3.5-flash-lite, described as low-latency and cost-effective.
• gemini-3-flash-preview, still a preview model.

For most business tasks, BaristaLabs would start on gemini-3.8-flash and only try Argon if a specific task keeps failing. Google also notes that lower thinking levels "generally achieve a good balance for standard automation tasks."

How does a Gemini computer-use agent work?

Gemini suggests actions, and your application carries them out. Each turn of the loop has four steps.

1. Your app sends the prompt, a screenshot and the computer_use tool settings, including the environment.
2. Gemini returns a function_call for one UI action, with an intent that explains why. Coordinates come back on a 0 to 999 grid that your code scales to the real screen.
3. The response may include a safety_decision. Google's safety system classes each action as allowed, require_confirmation or blocked.
4. Your app runs the action, takes a new screenshot and sends it back in a function_result.

Because your code runs every action, your code also owns the limits. Google's setup guide asks for a sandboxed VM or container, and its reference implementation ships a Docker-based sandbox to start from. The same split between model and executor shows up in Anthropic's browser use tool, and the design lessons carry over.

Which Gemini safety policies should you keep?

Keep all seven on unless you have a narrow, tested reason. Each category decides when the safety system asks for confirmation or blocks an action, and the disabled_safety_policies setting turns one off.

Scroll sideways to see all 3 columns.

Policy	What Google says it covers	BaristaLabs recommendation
FINANCIAL_TRANSACTIONS	Payments, retail checkout, regulated goods	Keep on
SENSITIVE_DATA_MODIFICATION	Health, financial and government records	Keep on
COMMUNICATION_TOOL	Sending emails, chat messages or drafts	Keep on; let a person send
ACCOUNT_CREATION	Registering new accounts on websites	Keep on
DATA_MODIFICATION	File changes, data sharing, storage deletion	Only consider turning off inside a disposable sandbox with nothing to lose
USER_CONSENT_MANAGEMENT	Cookie banners and privacy prompts	Keep on
LEGAL_TERMS_AND_AGREEMENTS	Accepting terms of service or contracts	Keep on

Turning a policy off is a request, not a guarantee. Google says overrides "indicate your preference, but the model may still return a safety_decision with require_confirmation in some cases," so your client must handle confirmations whatever you configure.

How should your code handle require_confirmation?

Show the user the action and its explanation, and wait. If the user confirms, send safety_acknowledgement set to true in the function_result. If not, stop the task. When the decision is blocked, Google says your client "should halt the execution or handle the interruption."

For tasks where a person must step in, such as a second-factor code, Google documents another pattern. You can drop a predefined action with excluded_predefined_functions and register your own function, such as yield_to_user, so the agent hands control back instead of guessing. Agents also get stuck on bot checks, and an earlier post covers why CAPTCHAs still need a fallback path.

Why prompt injection detection matters for business agents

A computer-use agent reads whatever is on the screen, including text an attacker placed there. With enable_prompt_injection_detection set to true, Gemini checks screenshots in the request for hidden instructions, such as "Ignore previous commands," and blocks execution when it finds them. The feature works on Gemini 3.5 Flash-Lite and later.

BaristaLabs interpretation: the cost of turning it on is an occasional blocked step, which your confirmation path already has to handle. The cost of leaving it off is an agent that may follow instructions from a supplier's web page or a customer's email. For any agent that browses outside your own systems, turn it on.

Google's other advice is worth following too. Keep an allowlist of sites the agent may visit, which Google calls "even more secure" than a blocklist. Start each task from a clean state. Log prompts, screenshots, suggested actions, safety responses and the actions your client actually ran. That log is the only record of what the agent did on a screen. The same app-permission thinking applies to Copilot's computer use preview.

Recommended first step

Pick one repetitive browser task that ends before anything is sent or paid, such as collecting order statuses from a supplier portal.

1. Run it in a sandboxed browser on gemini-3.8-flash, with an allowlist of the portal's domain.
2. Set enable_prompt_injection_detection to true and leave all seven safety policies on.
3. Build the require_confirmation and blocked paths before the happy path, and log every turn.
4. Review a week of logs, then decide whether the task earns more access.

If you want help choosing the first task and its limits, see process automation.

Sources and scope

• Gemini API release notes, Computer Use generally available (GA), Oct. 30, 2026, and the June 24, 2026 preview entry.
• Gemini API documentation, Computer use, read Oct. 30, 2026.
• Google, Computer Use reference implementation on GitHub, read Oct. 30, 2026.

This post is based on Google's documentation. BaristaLabs has not tested Computer Use for this post, and the sources do not say how often prompt injection detection catches or misses attacks.