OpenAI Computer Use: Browser Agents Need Credentials, Not Demos
By Greg Nowak. Last updated 2026-08-18.
A browser agent that completes a supplier form or updates an admin portal makes a good demonstration. The operational test begins when it must sign in, handle sensitive data, recover from a changed page, and stop before an expensive mistake.
That changes the nature of the project. OpenAI computer use is not simply a clever layer on top of browser automation. Once it reaches authenticated systems, it becomes an identity, security, and workflow-control project. Business owners should judge it by the quality of those controls—not by how confidently the cursor moves.
Computer use is ready for narrow, controlled workflows
OpenAI’s current guidance describes three implementation patterns: the built-in Responses API computer tool, custom tools connected to an existing automation harness, and code-execution environments with browser or desktop controls. Current guidance centres this work on GPT-5.4; an older pilot built around computer-use-preview should be treated as a migration project.
The right pattern depends on the work. A visual loop can handle shifting labels and irregular layouts. A custom harness suits teams that already use Playwright, Selenium, or an internal automation platform. Code execution helps when the workflow needs DOM inspection, conditional logic, or browser-library calls. If every field and rule is stable, conventional automation may still be cheaper and easier to maintain.
Give the workload its own identity
The quickest route to a risky pilot is letting the agent borrow an employee’s administrator account. Instead, create a dedicated account or role for the workflow wherever the target application supports it. Grant access only to the necessary records and actions, and keep production credentials separate from development.
For OpenAI API authentication, workload identity federation can remove the need to store long-lived API keys in supported environments. A trusted workload presents an externally issued identity token, which OpenAI exchanges for a short-lived access token mapped to a project service account. This limits the value and lifetime of a stolen credential.
Run the browser in an isolated environment, pass an empty environment-variable set, and disable extensions and local filesystem access where possible. Maintain an allowlist of permitted domains and actions. Page content must remain untrusted: instructions displayed inside a portal do not become valid merely because the agent can read them.
Put approval at the point of consequence
Human approval should not interrupt every harmless click. Let the agent navigate, inspect, and prepare the work, then pause immediately before an action changes the risk. OpenAI specifically recommends human involvement for purchases, authenticated workflows, destructive actions, and anything difficult to reverse.
- Confirm before submitting a purchase, payment, deletion, or permission change.
- Confirm before sending, posting, or uploading information to another party.
- Confirm before typing sensitive data unless narrowly defined consent already covers that exact use.
- Stop and escalate when a page contains suspicious instructions or possible prompt injection.
The confirmation should name the action, destination, and likely consequence. “Continue?” is not informed approval.
Choose the least complex workable harness
| Workflow characteristic | Starting approach | First control to add |
|---|---|---|
| Stable page and predictable rules | Conventional browser automation | Tests, retries, and change detection |
| Visual variation with low-risk actions | Built-in computer-use loop | Isolated browser and domain allowlist |
| Existing Playwright or Selenium estate | Custom harness with model tools | Narrow schemas and audit logging |
| DOM-heavy logic or conditional loops | Code-execution harness | Sandbox, timeouts, and resource limits |
| Money, deletion, permissions, or external communication | Hybrid workflow | Human approval before execution |
Bound side effects with explicit functions
Visual control is useful for reading an irregular screen. It is a poor reason to make every consequential action an unrestricted click. Route actions such as creating an order, changing access, sending a message, or submitting a payment through explicit functions with narrow JSON schemas.
OpenAI recommends enabling strict mode so function calls adhere reliably to their schemas. Use tool_choice to limit the available tools. When sequence matters, set parallel_tool_calls to false, ensuring that the model calls no more than one function in a turn.
This creates a practical division of labour: the model interprets the page, while ordinary application code validates inputs, checks policy, records the event, and performs the approved side effect.
Run it as a recoverable job
Browser work is naturally failure-prone. Sessions expire, pages time out, layouts change, and approvals may take hours. Production workflows therefore need durable states such as queued, running, awaiting approval, completed, failed, and cancelled.
For long OpenAI requests, use background=true and poll the response until it reaches a terminal state. Webhooks can notify your system when a response completes; verify every webhook signature against the raw request body before accepting the event.
Store the workflow version, account used, approved domains, tool calls, confirmations, outcome, and safe error details. Define retry rules per action. Retrying a page read may be harmless; retrying “submit order” may create a duplicate. When the outcome is uncertain, escalate instead of guessing.
What should the first pilot prove?
- Value: one repetitive workflow has enough volume or delay to justify intervention.
- Containment: the agent can reach only named systems, accounts, and actions.
- Control: sensitive or irreversible steps stop at the correct approval boundary.
- Recovery: operators can inspect, resume, or terminate a failed run safely.
- Maintainability: the team can detect page drift and update the workflow without reconstructing a demo.
Track completed cases, human interventions, exceptions, run time, and cost per completed case. Clean escalation can be more valuable than a high apparent completion rate that conceals duplicate submissions or silent errors.
The sensible procurement question is not, “Can an agent use this website?” It is, “Can we operate this workflow safely when credentials expire, screens change, and people need to intervene?” That is the difference between a promising demonstration and a dependable business capability.
Planning a browser-agent pilot?
Greg can help map the workflow, select the right harness, define credential and approval boundaries, and coordinate the rollout. Talk through the project with Greg.
Related on GrN.dk
- AI agents need a browser policy before they start clicking around
- AI automations need a spend dashboard before the first runaway bill
- A Voice Agent Is Only Ready When the Human Handoff Works
Need help with this kind of work?
Plan a controlled browser-agent pilot Get in touch with Greg.