Skip to contentINQUORYWORLD
Account ↗
Menu

AI news · Inquory Research

OpenAI’s Agents API adds a hosted browser: business controls before sign-in

· Sources checked October 1, 2026 · AI-assisted research

A conceptual browser approval boundary, an operator key with purchases and edits blocked by account permissions, and source-to-report comparison with recovery of the same interrupted session.
AI-generated editorial illustration · Inquory

Inquory's proposed control flow separates approved destinations, operator sign-in and account or resource permissions, then checks a drafted report against its source. The blocked purchase and edit icons represent permissions a business must enforce; origin approval itself does not make an account read-only. Recover the same session after uncertain delivery before deciding whether to retry. OpenAI announced the browser capability September 29, 2026; this conceptual illustration is not a screenshot or an Inquory-tested implementation. Generic chart marks and interface words are invented illustration symbols, not measurements, real supplier records or a vendor interface; no customer outcome or endorsement is depicted.

OpenAI computer-use documentation

OpenAI added a hosted browser to its Agents API on September 29. For a business commissioning an integration, the useful question is what the application can safely let an agent access. Start with a task whose account permissions prevent changes, and check the result before expanding access.

What changed, and when

Announcement date: September 29, 2026. Analysis edition: October 1, 2026.

OpenAI’s API changelog records the computer-use addition on September 29. The Agents API itself entered public beta on September 10. This is a developer integration: OpenAI manages the agent harness, while an application supplies tools and chooses an execution environment. The Agents API overview describes durable sessions and managed orchestration and recovery.

Our September 30 news edition covered dots, an ongoing-agent product. This follow-up examines the developer-facing browser capability and its operational boundaries. The announcement predates this edition; it is not October 1 breaking news.

Website approval does not guarantee action approval

OpenAI’s computer-use documentation says the application handles approval for each website origin and any sign-in request. Network permission alone does not approve a website. An origin is the combination of a website’s scheme, hostname and port.

The same documentation cautions that origin approval does not enforce confirmation before individual consequential actions. For a guaranteed boundary, restrict the browser to resources that cannot perform those actions, or use a browser runtime you control. A confirmation tool depends on the agent invoking it.

Documented sign-in support includes email addresses, passwords and verification codes; passkeys and QR-code sign-in are unsupported. Only the main agent can request authentication. Authentication requests expire after five minutes. If delivery is uncertain, retrieve the same session before deciding whether to retry. A recorded authentication response is not proof of successful sign-in. These are documented limitations, not results of an Inquory test.

A business trial with a checkable result

Inquory’s interpretation: a useful first trial could read a supplier portal’s order status and draft a report for a staff member. This is a proposed example, not a customer case study. Use a test account or appropriately sanitized records, and confirm that its permissions prevent purchases, cancellations and record changes. “Read only” in a prompt is insufficient if the account can still perform those actions.

Ask the developer to demonstrate the following before introducing a live account:

Hosted-browser business-control worksheet
Trial questionEvidence to inspect
Can this account change anything?Account permissions and a test showing that writes are unavailable
Which websites can it reach?Named destinations, permitted redirects and the displayed approval request
What happens after an interrupted sign-in?Recovery of the existing session without blindly resending the task
Did the report preserve the facts?A comparison with the actual portal record, including missing or uncertain details
What data remains afterward?The application’s credential, screenshot, logging and session-cleanup behavior

Keep an operator available for sign-in and exceptions. Stop the trial if it reaches an unexpected destination, invents a status or cannot establish whether an action completed. Extend the CRM handoff checklist with the portal’s own acceptance criteria. Use the AI pilot measurement guide to record the baseline, review time and failed cases.

What will it cost?

OpenAI’s Agents API overview separates charges for the selected model, OpenAI tools and hosted containers. It does not give one universal price for a completed browser task. The practical budget depends on the work performed and environment usage.

Inquory’s interpretation: record the billed components for each trial alongside retries, elapsed time and staff corrections. Compare the final usable report with the manual process. A successful demonstration alone does not establish recurring savings. Our break-even worksheet can organize measured inputs; hypothetical savings remain hypothetical.

About this analysis

Inquory Research prepared this article with AI assistance and checked the linked primary sources on October 1, 2026. We have not tested this API, Canadian account access, portal compatibility, reliability or task cost. Product behavior is attributed to OpenAI’s documentation; the trial and interpretations are proposed Inquory methods. The original cover is an AI-generated conceptual illustration, not a software screenshot or photographed event. See our editorial method, AI-use disclosure and corrections policy.

Inquory analysis · Substantive update

Execute an application-side action boundary locally

The current computer-use documentation distinguishes origin approval from guaranteed action confirmation. An application needs to decide which operations its runtime can execute. A model instruction to ask permission is not the same as removing a write capability from the runtime.

The local results below test Inquory's small reference policy, using no browser agent or vendor API. The public-read case remains allowed even when a page contains an instruction; the policy does not follow that instruction. Emailing, purchasing, deleting and private-data access stay outside the allowed operation. An actual implementation must also bind the evaluated action to the action executed, avoiding a check-then-change gap.

Local policy cases and their expected dispositions
Synthetic requested operationLocal disposition
Read approved public documentationALLOW_PUBLIC_READ
Read another unapproved originDENY_ORIGIN
Website asks to email a reportSTOP_ACTION_REQUIRES_SEPARATE_CONTROL
Website asks to upload customer recordsSTOP_SENSITIVE_DATA
Read public page containing an instruction to ignore the ownerALLOW_PUBLIC_READ
Delete a remote recordSTOP_ACTION_REQUIRES_SEPARATE_CONTROL
Inspect private account contentsSTOP_SENSITIVE_DATA
Submit a purchase on an approved originSTOP_ACTION_REQUIRES_SEPARATE_CONTROL

How to use this analysis

A deterministic reference policy allows only non-sensitive public reads on an approved origin. It denies other origins, stops sensitive-data access and stops mutations. A page's claim of permission never changes the result.

Download the analysis table and methodology (JSON, version 1.0.0)

Limitations: No hosted browser, model, network, account or prompt-injection benchmark was tested. Boolean case attributes are predeclared; the example does not classify arbitrary page text or enforce policy inside OpenAI's runtime. It is a reference boundary for an application that controls its own action executor.

Compare this boundary with the extension-permissions decision ledger

About the publisher.