In this analysis
A signed-in browser session does not authorize every action that the connected account can technically perform.
A browser agent can be signed in and still lack authority to perform a particular action. The Agents API expansion made this application boundary explicit: access and sign-in are integration responsibilities, while the user’s actual task can be much narrower than the account’s available powers.
The dated product boundary
The May 16, 2025 Codex launch provided earlier cloud-agent context. The September 10, 2026 Agents API beta introduced the managed service. The September 29, 2026 DevDay announcement added computer use, with application-managed website access and sign-in. The historical change concerns integration, not an automatic grant of every permission exposed by a website.
Authentication identifies a session
Consider a user asking an agent to inspect a shipment status. The connected account might also allow changing an address or canceling the shipment. Successful sign-in establishes that the browser can access the account; it does not establish that those other actions belong to the current task.
Keep the authenticated account, requested objective and permitted operations distinguishable. If the agent encounters a button outside the task, its visibility is not evidence that pressing it would fulfill the user’s instruction.
Authorization follows the intended action
A useful application policy can distinguish observation, preparation and committed change. These are proposed design categories, not asserted universal API states. They help describe what an application must decide when an agent moves from reading a page to affecting an external record.
The relevant review object is the intended action with its target and consequences. A screenshot can support identification, but it does not independently authorize the operation. Likewise, a previous successful login does not answer a new request’s scope question.
A fixture with different account powers
Use an illustrative account containing both read and modification controls. Ask only for an allowed status lookup. Preserve the requested scope and inspect whether the workflow returns evidence without extending the job into an unrelated change.
Then provide a separate request that genuinely needs a modification. Check how the application handles its required authorization before execution. The paired cases test task-specific authority while keeping authentication constant. They distinguish a login defect from an action-scope defect.
The retrospective implication
Managed browser infrastructure can simplify execution without owning every application decision about authority. A deployment still needs to connect user intent to the operations performed under a real account.
The September expansion is therefore best understood as a broader interaction surface with retained application responsibilities. An accurate adoption record explains whose session is used, what the task permits and which evidence confirms that the resulting action stayed within that scope.