Origin approval is not action approval
4
min read
Agent Infrastructure
OpenAI added computer use to its Agents API on September 29, and the approval model it ships with shows where safety controls on browser agents can and cannot attach. The user approves each new website origin. After that, the agent works inside the site. OpenAI's own guide states that origin approval does not enforce confirmation before individual actions.
This post covers why the gate sits at the site level, what a gate at the action level would need, and where a structured action manifest fits.
What the computer use tool does
According to OpenAI's computer use guide, the agent drives a browser in OpenAI's hosted environment. Your application starts a session and streams events. The agent can navigate, click, type and take screenshots. Before it visits a new origin, including a public site, the API raises an approval request. Your application shows the origin and the reason to the user, who can approve, deny or cancel. Sign-in requests get their own approval step.
Mixed reports that the feature is in beta behind a header and that, once a site is approved, the agent does not ask again before each step. The guide's advice for consequential work is to restrict the browser to read-only resources, use function tools that guarantee a confirmation, or run a self-hosted runtime.
Why the gate lands on the site
An origin is the one unit the runtime can identify reliably. The agent works from what it observes on the page and acts through clicks and keystrokes. From the runtime's side, pressing Search and pressing Delete account are the same kind of event: a pointer click at some coordinates, then a page change. Nothing in the loop says what the click means.
To require confirmation for an action, the runtime has to be able to name it. With screenshot-driven control it can't, unless it asks a model to guess what a click will do. That model is the same one that chose the click, so the check is weak.
The documentation's advice follows from this. If you need a guaranteed confirmation, take that action out of the browser and expose it as a function tool you define. It works, but it puts the work on each developer, for each site, one function at a time.
What a per-action gate needs
Three things are enough to start. Each action needs a stable name. Each needs a typed description of its inputs, so the runtime can validate a call before it runs. And each needs some statement of its effect, such as whether it only reads or whether it changes state.
With those, a runtime can apply rules like "searches run freely, anything that changes an account asks the user first." Without them, rules can only mention the site.
Where a manifest fits
A manifest is a structured JSON description of the actions a page offers. Manifest API generates these for existing webpages, so an agent calls a named action with inputs instead of locating a button in a screenshot. That gives the runtime what the previous section asked for: something to name, validate and apply policy to.
There are two limits. A manifest makes an action addressable, not safe. Whether a buy action needs confirmation is still a policy decision for the developer or the user. And a manifest has to match the page it describes. If the page changes and the manifest does not, calls fail or do the wrong thing, so keeping manifests current matters as much as the format.
Two other items from this week
Salt Labs described how one email with obfuscated JavaScript led the Manus agent to run attacker code. In Salt's write-up, the guardrail flagged the content only after it had executed, and the attacker obtained a reverse shell and OAuth tokens for connected accounts. Salt's recommendation is to monitor what the agent does across tools and APIs, not only inspect prompts. That is easier when actions are enumerable, because there is a defined set to log and compare against.
WordPress.com's October 2 changelog lists plugin support in Cursor's marketplace and a connection for Grok Bot, alongside plugin management in its own WordPress Agent. A platform that controls every site can build one agent interface and handle authorization and activity logs centrally. Most sites are not on such a platform and have no team to build that interface.
What to do if you build on a hosted browser agent
Treat site approval as access control and nothing more. Put purchases, deletions and outbound messages behind function tools that require an explicit confirmation. Restrict the browser to read-only resources where the task allows it. Log each action with enough detail to review later, including the origin and the inputs.
If you control a site that agents will visit, or build for sites you don't control, a typed action list is worth having because it is the only thing per-action policy can attach to. That is the case for generating one from the page rather than waiting for each site to publish its own.
Sources
