A browser agent can be scoped to retrieving a named report, but a written instruction alone does not remove the account’s ability to change records. Use the narrowest supported access, define permitted pages and actions, and verify the actual exported file. Where the portal cannot enforce a retrieval boundary, keep the uncertainty visible and use a supervised process approved by the portal owner.
Start with the report a person needs
A request to “download the monthly report” leaves several decisions unresolved. Specify the account, legal entity, reporting period, report variant and intended use. A sales summary and a detailed transaction export can cover the same dates while providing different evidence. The agent should not choose between them merely because one appears first.
Ask the report owner which filters matter and what evidence confirms the correct selection. If dates are interpreted in the portal’s timezone, record that interpretation before retrieval. A South African team’s calendar date should not silently replace an account-specific reporting boundary.
Set an acceptance owner as well as an operator. The person checking the exported information may have different responsibilities from the person maintaining the integration. Retrieval prepares evidence; the business owner decides whether that evidence supports the intended reporting use.
Check whether the access boundary can be enforced
Source: OpenAI API changelog records Agents API computer use in an OpenAI-hosted browser on 29 September 2026, with website access approvals and sign-in handled by the application. That capability does not establish a read-only role in a particular supplier portal or grant permission to automate it.
Before planning a pilot, confirm the portal owner’s accepted use, available roles and actual permissions. Prefer a supported retrieval role that cannot amend the relevant records. Where no suitable role exists, identify every retained write capability and decide whether supervised retrieval is acceptable. Do not label broad access read-only because the task description says so.
Keep credentials in the approved sign-in process. The review worksheet needs a role and secure reference, not a password or session token. A new login challenge belongs with the authorised person; it does not expand the agent’s task.
Separate navigation from business mutations
Selecting a report filter is different from editing the source record used by that report. Define the permitted operations in terms the portal owner can recognise: open the approved reporting page, set the specified filters, generate the report and save the resulting file to approved storage.
Explicitly exclude record amendments, account-setting changes, purchases and permission changes. Unexpected controls such as “save as default” require attention because they may alter shared settings even when the page looks like an ordinary reporting screen. Do not assume that every button near an export control is part of retrieval.
Source: OpenAI function calling describes a model requesting actions that application code executes. For an application-controlled tool, enforce the accepted operation independently. Browser restrictions need their own supported controls and testing; the function-calling guide is not proof that every click can be blocked in an arbitrary portal.
Inspect the export instead of trusting the message
A filename ending in a spreadsheet extension can still contain an error page or an incomplete report. Open the actual output in the approved environment and check its format, named report, account/entity, period and expected columns. A zero-row report needs a documented interpretation rather than automatic rejection or reassurance.
Compare totals or sample references with an authorised reporting view where the agreed process requires reconciliation. Keep an observed difference separate from a reason for the difference. An export produced at a different time may have changed legitimately, but that explanation must be checked rather than invented.
Source: OpenAI Structured Outputs supports schema-constrained response fields. A proposed receipt can therefore require the file reference, selected period and acceptance state. A correctly shaped receipt does not prove the file exists or contains the requested data.
Use a retrieval brief that another operator can follow
The following template is a proposed operating control. Adapt it with the report owner and technical maintainer before a live pilot. Its value is making retrieval and acceptance conditions explicit, not certifying a portal’s permissions.
Restricted report-retrieval brief
Task reference: ______ | Portal/account: ______ | Report owner: ______ | Reviewer: ______
| Control | Record before starting | Required completion or stop evidence |
|---|---|---|
| Purpose | Named report, approved use and requesting owner | Retrieval serves this task only. |
| Scope | Permitted report pages and approved account/entity | Stop on a different entity or an unexpected destination. |
| Filters | Reporting period, status and agreed timezone | Compare visible selections with the approved brief. |
| Access | Accepted retrieval role and supported restrictions | Record any write privileges that cannot be removed. |
| Actions | Navigation, filter selection and export only | No editing, deleting, ordering or changing permissions. |
| File checks | Expected format, report identity and period | Open the actual file; reject sign-in pages and error exports. |
| Data checks | Expected columns and reconciliation references | Missing or conflicting information stays unresolved. |
| Destination | Approved storage, permitted recipients and retention owner | Do not publish or email the file automatically. |
| Handoff | Block reason, last verified step and responsible person | No attempted bypass or repeated blind clicking. |
| Acceptance | File reference, retrieval time and reviewer outcome | Report accepted, rejected or awaiting clarification. |
Completion: the authorised reviewer can locate the actual file, confirm its report identity and inspect unresolved limitations. A download message alone does not complete the task.
Walk through a valid file and two misleading outcomes
Consider a hypothetical distributor requesting a September dispatch report for its approved account. The operator confirms the report page and period, downloads the export, opens it and checks the dispatch-reference column. The reviewer records the file location and accepted report identity. No order or dispatch record is edited during this retrieval.
In a second hypothetical case, the export link downloads an HTML sign-in page after the session expires. The browser reports a completed download, but the file check rejects it as the wrong format. Record the last verified page and hand the login challenge to the authorised person. Do not count this file as an accepted report.
A third case exposes two reports with the same display name under different entities. The agent must stop when it cannot establish which entity matches the brief. The report owner resolves the account context. Selecting whichever row is newest would turn an unresolved identity question into an apparently successful retrieval.
An empty but well-formed report is another useful test. Ask whether the selected filters legitimately return no records, whether a data permission hides rows, or whether the report is still being prepared. Preserve the observed empty result and the owner’s explanation separately. Do not fabricate rows to satisfy an expected volume.
Keep evidence and delivery proportionate
Retain the brief version, permitted role, report selections, file reference and acceptance decision. Screenshots should capture only the necessary reporting context and be stored with suitable access. Avoid copying unrelated customer records into a general troubleshooting channel.
Saving a report to approved storage is not permission to email it, publish it or use it in another workflow. Treat delivery as a separately scoped action with its own recipients and review. If the approved task ends at retrieval, the final status should say that the file is ready for acceptance rather than implying the next business process has completed.
During testing, deliberately introduce a changed report name, wrong entity, expired session and malformed export. Record whether the process stops with a usable explanation. A successful ordinary download is useful evidence, but it cannot establish that retained write capabilities are harmless or that every later portal layout will behave the same way.
FAQ about restricted report retrieval
Is a read-only instruction enough to prevent portal changes?
No. Verify actual role restrictions and supported application controls. If write access remains available, disclose that limitation and agree a supervised scope with the owner. A prompt is an operating instruction, not evidence that a permission boundary exists.
What should happen when the exported report is empty?
Record the selected filters and observed file, then obtain the report owner’s interpretation. Empty data can be valid or can reflect missing access or an unfinished report. Keep that uncertainty visible until the agreed acceptance check resolves it.
Does downloading the file mean the reporting task is complete?
Only when the actual file meets the accepted identity, format and content checks. A browser notification proves less than an inspected export. Report retrieval and any later distribution or reporting approval remain separate steps.
If your business needs help scoping this workflow, explore Custom AI agents, our AI automation services, and the custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the options. To discuss your systems and approval rules, get in touch.