OpenAI added computer use to its Agents API at DevDay on 29 September. The agent drives a browser in an OpenAI-hosted environment, and your application approves each new website origin before the agent can open it.

That approval gates where the agent goes, not what it does once it gets there. OpenAI's own guide says so, and tells you to restrict the browser to resources that can't make purchases or destructive changes if you need a confirmation step.

The real controls are the accounts you let it sign into, the network policy you set, and the choice to run your own browser runtime for anything consequential. A confirmation function tool only works if the agent decides to call it.

What shipped

The Agents API went into public beta on 10 September with durable sessions, hosted or custom sandboxes, and MCP support. The DevDay changelog entry adds computer use: agents can "complete tasks in an OpenAI-hosted browser, with website access approvals and sign-in handled by your application."

The flow is event-driven. You create a session with the computer_use tool and an openai_hosted environment, send a task, and listen on the event stream. When the agent wants a site it hasn't visited yet, the session moves to requires_action and hands you a computer_use_approval_request of type browser_origin_access, with the origin and an optional reason. You answer approve, deny, or cancel.

Sign-in works the same way. The agent raises a browser_authentication request with a list of fields, your UI renders them, and the user types the values. Email, password, and verification codes are supported. Passkeys and QR-code sign-in are not, and only the main agent can ask for credentials, subagents can't.

The part that is done well

The credential handling is the careful piece. The guide states that submitted sign-in values "stay outside the agent's model input and are omitted from authentication response items in session history."

That matters. The model never sees the password, so a prompt injection on some page can't talk it into pasting your password somewhere else. It's the same pattern Google used for Gemini's managed agents earlier this month, where a proxy injects the secret and the agent only holds a placeholder.

The origin approval is also stricter than I expected. It applies to public websites too, and turning on network access doesn't count as approval. An agent that wanders from your supplier portal to a lookalike domain has to stop and ask.

Where the line actually sits

Every team building on this should copy one sentence into their design doc. Under a heading that reads "Origin approval does not enforce confirmation before individual actions," OpenAI writes: "If your application must guarantee confirmation before purchases, destructive changes, or other consequential actions, restrict the hosted browser to resources that cannot perform them, or use a browser runtime you control."

The next line is the one people will skip: "Asking for confirmation through a function tool relies on the agent calling that function."

Read those together and the model is clear. Once a user approves billing.example.com and signs in, the agent can click anything on that origin. Approve, delete, submit, pay. The platform has no hook between the agent deciding to click and the click landing.

Most teams will build the obvious thing first. They'll add a confirm_action function tool, write "always call confirm_action before submitting a payment" in the instructions, and consider it handled. It works in the demo. It works in most runs. It is an instruction, not a control, and the guide is telling you as much.

Two layers, neither of them about actions

There are two gates in this setup, and it helps to keep them apart.

The network policy is an environment setting. It controls outbound access for the browser and for any code running in the sandbox. The guide tells you to allow the destination site plus whatever domains it needs for page resources and redirects.

Origin approval sits on top of that. It's a per-origin user decision, and it doesn't override the network policy. A site blocked by the network policy stays blocked even if the user approves it.

Both layers answer the question "can the agent reach this host." Neither answers "should the agent press this button." For a research task that reads public pages, that's enough. For a task that logs into a vendor portal with a real account, it isn't.

What I'd do before putting this in front of users

Scope the account, not the browser. The cleanest version of OpenAI's advice is to sign the agent into accounts that can't do damage. A read-only user on the ERP. A procurement login without approval rights. A card with a hard limit of zero. If the account can't pay, the agent can't pay, whatever it clicks.

Split read tasks from write tasks. Run lookups and report-pulling in the hosted browser, where the risk is reading something it shouldn't. Move anything that submits, pays, or deletes into a runtime you control, where you can intercept the action before it executes. OpenAI offers that path explicitly.

Make the network policy tight on purpose. Allow the three domains the task needs and their resource hosts, not a wildcard. Origin approval will catch the rest, but a user who has approved twenty prompts in a row will approve the twenty-first without reading it.

Watch session reuse. The guide suggests reusing a session for follow-up tasks that need its browser state. That also keeps the login cookies alive. A session a user signed into on Monday for one task can still be authenticated when a different task runs in it on Tuesday. Delete sessions when the task that needed the login is done.

Keep screenshots out of your logs. Screenshots are off by default and optional with include_screenshots: true. If you turn them on for debugging, they carry whatever was on screen, account numbers included. The guide says to keep them out of application logs. Your observability pipeline probably doesn't know that.

Places, not actions

OpenAI shipped a hosted browser with better defaults than most homemade computer-use setups. The model never touches the password, and it can't open a new site without a human saying yes.

It also shipped documentation that is unusually direct about the gap. Approval is about places, not actions. If the account the agent signs into can move money, then the agent can move money, and the only thing between the two is whether the model remembers your instructions on that particular run.

That's the same bar every agent deployment ends up at. The platform gates where the agent can go. You still decide what it is allowed to change once it's there, and in this API the way you decide that is the account you hand it.