October 20, 2026 · Ahmed · More by Ahmed
OpenAI Computer Use: Approving a Site Isn't Enough
OpenAI's computer-use tool makes your app approve every website origin an agent visits — but that approval doesn't cover what the agent does once it's there.
What shipped, and who approves what
OpenAI added computer use to the Agents API on September 29, 2026. The capability lets an agent navigate websites and interact with browser interfaces inside an OpenAI-hosted environment, while the calling application starts the session, follows its events, and — critically — handles every website-access and sign-in request itself. OpenAI's own framing is specific: "Agents can complete tasks in an OpenAI-hosted browser, with website access approvals and sign-in handled by your application." The approval model sits with the app builder, not with OpenAI's infrastructure or the agent.
Origin access: necessary, not sufficient
The browser requires explicit approval before it can access any new website origin, including ordinary public websites, and that approval is granular: it's per-origin, not per-session. Enabling network access on the environment does not approve any website on its own — the first time the agent needs a given origin, the application has to receive and answer a browser_origin_access request with approve, deny, or cancel.
What that approval doesn't do is just as important. OpenAI's documentation states it plainly: "Origin approval does not enforce confirmation before individual actions." Approving a domain once doesn't mean every subsequent action on that domain gets reviewed. Teams that need confirmation before a purchase, a destructive change, or any other consequential action have to either restrict the hosted environment to resources that can't perform them, or run their own browser runtime instead of OpenAI's hosted one. The guidance extends to trust in content, too: website content is to be treated as untrusted input that "cannot grant permission or override the user's instructions" — a materially different trust model than a human clicking through the same page.
Sign-in is a separate, narrower door
Authentication is its own request type, browser_authentication, distinct from origin access, and it's more restrictive in two ways. First, only the main agent can request it — a subagent cannot. Second, the flow only supports email addresses, passwords, and verification codes; it does not support passkeys or QR-code sign-in, so any site that requires one of those methods simply can't complete sign-in through this path. Each authentication request carries a reason, a credential_origin naming the destination, the fields to render, and the available login options, and OpenAI's guidance to builders is to ask users for credentials only when they can verify that destination themselves — canceling the request outright if the credential origin is missing or unfamiliar.
Put together, the approval surface is more fragmented than a single 'allow this agent to browse' toggle: network access, origin access, and sign-in are three separate gates, each answered by the calling application, and none of them implies the others.