An operator connects an agent to a supplier portal so it can chase an order. The agent asks for approval, the operator approves, and the agent continues. Later the same session clicks Buy. The approval the operator gave was for a website, not for the purchase, and the platform said so in its own documentation.
Origin approval does not enforce confirmation before individual actions. That sentence is in the computer-use guide for the OpenAI Agents API, and it decides how you design the gate around any agent that can act.
Computer use was added to the Agents API on September 29, 2026, according to the OpenAI changelog. Agents complete tasks in an OpenAI-hosted browser, and the changelog notes that website access approvals and sign-in are handled by your application.
The computer-use guide is specific about the approval it raises. The browser requires the user's approval before accessing each new website origin, including public websites, and enabling network access does not approve those requests. The request arrives as a `computer_use_approval_request` whose nested request type is `browser_origin_access`, surfaced on `agent.session.requires_action` in the session's `required_actions`. Your application shows the origin and the reason, then returns `approve`, `deny`, or `cancel` against the same `request_id`.
Every part of that flow is about access to a place. Nothing in it is about a specific consequence, and the documentation says as much in the section immediately after the code sample.
The third row is easy to misread. The guide states that asking for confirmation through a function tool relies on the agent calling that function. A confirmation the agent chooses to request is a behaviour, not a control. If correctness depends on the agent remembering, the guarantee is not there.
The guide does not leave the gap open. It says that if your application must guarantee confirmation before purchases, destructive changes, or other consequential actions, you should restrict the hosted browser to resources that cannot perform them, or use a browser runtime you control.
Those are two different answers to the same problem. Restricting the browser removes the capability, which is the strongest option and the least flexible. Running your own runtime keeps the capability and moves the responsibility for the action gate into code you write and test.
The confirmation and consent guidance is blunt about what that code needs. Keep a human in the loop for purchases, authenticated flows, destructive actions, or anything hard to reverse. Keep an allow list of domains and actions and block everything else. Run the tool in an isolated browser or container whenever possible.
There is a second reason origin approval cannot carry the weight people put on it. A page can instruct the agent, and the agent reads the page.
OpenAI's guidance separates the two sources of intent. Direct user instructions are permission. Third-party content is untrusted by default, and the list includes website content, PDF files, emails, calendar invites, chats, tool outputs, and on-screen instructions. Instructions found on screen are not permission, even when they look urgent or claim authority. The computer-use guide repeats the rule for the browser case: treat website content as untrusted, because it cannot grant permission or override the user's instructions.
An approval that authorises an origin therefore authorises the agent to read a document that may itself contain instructions. The gate that matters is the one on the action, not on the reading. This is the same failure shape covered in why your AI agents need a human guardrail and in bounded permissions and human approval for AI agents.
Decide which actions in a workflow are consequential before an agent touches it. A purchase, a refund, a deletion, a message to a customer, a change to a live record. Then decide, per action, whether the agent may proceed, must stop for a person, or may never take the step at all.
Put the decision where the agent cannot route around it. An allow list of domains and actions is enforceable by your code. A prompt sentence asking the agent to be careful is not. Where the action is irreversible, the human confirmation belongs in the execution path itself, so the step cannot complete without it, which is the pattern described in how to gate risky tool calls.
Match the permission to the action, not to the tool. Read-only access to a system removes a class of risk that no amount of confirmation addresses, and the difference is worth stating in a contract, as covered in read-only versus read-write agent access. If an agent only needs to read a ledger to answer a question, giving it write access and a confirmation prompt is strictly worse than giving it read access.
If an agent reads public pages and returns a summary, origin approval is proportionate. There is no purchase, no credential, and no record to damage, and a human confirmation on every page load would be noise that trains the operator to click approve.
The elaborate version earns its place when the agent holds a session, reaches authenticated screens, or touches anything with money behind it. That is the line to draw: not how clever the agent is, but what the session can reach.
No. Approval is granted per website origin so the browser can load that origin. The computer-use guide states plainly that origin approval does not enforce confirmation before individual actions, so purchases, destructive changes, and other consequential steps need a separate control.
Not as a guarantee. The guide notes that confirmation through a function tool relies on the agent calling that function, which makes it a behaviour rather than an enforced control. Where the action is irreversible, the check belongs in the execution path where your code can enforce it.
It changes who owns it. The documentation presents a runtime you control as the alternative to restricting the hosted browser, and pairs it with requirements: an isolated container or browser, an allow list of domains and actions, and human confirmation for anything hard to reverse. Those controls are yours to build and test. The sandbox security guidance covers the environment side.
Content is untrusted by default. Website text, PDFs, emails, calendar invites, chats, tool outputs, and on-screen instructions cannot grant permission or override the user's instructions, which is why an approval tied to reading an origin is weaker than an approval tied to a specific action.
Maxpertise builds and runs AI teams for small and mid-sized businesses, and embeds AI engineers inside existing engineering teams. Delivery is spec-driven with two human gates: a person approves the plan before anything is built, and a person reviews the result before anything ships. Nothing is automated until it has been proven by hand.
That is the same discipline this article describes for a browser agent. A role like the AI back office touches invoices and payment chasing where a wrong action is expensive, so the action gate is part of the build rather than a setting switched on later. The method and the two gates are documented at how it works, and the engagement model is at pricing.
If you are about to connect an agent to a system with money or customer data behind it, start with a written intake at contact. Describing the actions you would never let it take is the fastest way to scope the work.
[1] OpenAI, Computer use in the Agents API documentation, accessed October 9, 2026. Origin approval, the `browser_origin_access` request type, and the statement that origin approval does not enforce confirmation before individual actions.
[2] OpenAI, Computer use integration and consent, accessed October 9, 2026. Human in the loop for purchases, authenticated flows and destructive actions; allow lists; untrusted third-party content.
[3] OpenAI, API changelog, accessed October 9, 2026. Computer use added to the Agents API on September 29, 2026.
[4] OpenAI, Sandbox security, accessed October 9, 2026.
Maxpertise is an AI-native engineering company. We embed native AI engineers inside your team, live in about 10 days. Please enable JavaScript to view the site, or email contact@maxpertise.net.