ChatGPT Agent makes browser automation a governance problem for UK firms

Model Intelligence & News

28 July 2026 | By Ashley Marshall

The interesting part is not that ChatGPT can click around websites. It is that every click now needs a permission model, an audit trail and a board level owner.

The browser is becoming an operating surface

OpenAI's launch of ChatGPT Agent matters because it brings web interaction, research, file work and tool use into one agentic workflow. In OpenAI's announcement, the company describes a system that can navigate websites, filter results, prompt a user to log in securely, run code, conduct analysis and deliver editable slideshows or spreadsheets. It combines earlier Operator style browser control with deep research and ordinary ChatGPT conversation. That is a meaningful product shift, but it is also a governance shift. A staff member no longer only asks a model for a recommendation. They can ask it to gather data, open a website, work through forms, use a connector and prepare an artefact that looks ready to use.

The business risk sits in the gap between assistive software and delegated action. A browser agent can inherit the authority of the person who logs in. It may see customer records, pricing, bank details, supplier portals, HR systems, CRM screens, email threads and calendar context. OpenAI says users remain in control because the agent asks permission before consequential actions, can be interrupted, paused or stopped, and supports browser takeover. Those product controls are useful, but they do not remove the need for an organisational control layer. A UK firm still has to define which systems are in scope, which tasks are permitted, which actions require approval, and which logs prove what happened.

This is why browser automation should not be treated as just another productivity feature. The right question is not whether a member of staff can save an hour by asking an agent to submit an expenses form or update a spreadsheet. The harder question is whether the firm can explain the agent's access, evidence the human approval points, recover from a mistake, and show that sensitive data was handled lawfully. Once the browser becomes the agent's operating surface, governance has to move from policy language into practical permission maps.

Capability gains raise the cost of weak controls

The case for browser agents is not imaginary. OpenAI reports that ChatGPT Agent reaches 68.9 percent on BrowseComp, which it says is 17.4 percentage points higher than deep research. It also reports 45.54 percent on SpreadsheetBench when the agent can edit xlsx files directly, compared with 20.00 percent for Copilot in Excel in the benchmark table. Those numbers do not mean every business task is solved. They do mean that agents are becoming good enough to be used on real operational work, especially where the task involves gathering information, transforming data, completing routine web steps and presenting a draft output.

That is exactly where UK firms need discipline. If a tool is unreliable, the governance problem is mostly about experimentation. If it is useful, people will route work through it. Sales operations will ask it to cleanse pipeline data. Finance teams will ask it to reconcile spreadsheet exports. HR teams will ask it to compare policy documents. Delivery teams will ask it to navigate supplier portals. The more useful the agent becomes, the more likely it is to encounter production data and perform actions with business consequences. Productivity creates adoption pressure, and adoption pressure creates control debt.

The practical governance angle is to classify agent tasks by authority, not by novelty. Read only research in public sources belongs in one class. Reading internal documents through a connector belongs in another. Drafting an email is different again. Sending the email, updating a CRM record, changing a supplier order, booking travel, approving a refund or uploading a file to a client portal are all higher risk. Each class should have a named owner, approved systems, logging rules, data handling rules, and a clear answer to the question: what must a human approve before the agent proceeds?

The common mistake is to judge these tools only by benchmark quality or time saved. Those are inputs to the decision, not the decision itself. The operational decision is whether the company has enough control around identity, access, consent, review and incident response to let a non-human workflow act inside a human browser session.

Prompt injection becomes an operational threat

OpenAI is unusually direct about the risk. The ChatGPT Agent announcement says direct web action introduces new risks because the agent can work with data accessed through connectors or sites the user has logged into. It also says particular emphasis has been placed on adversarial manipulation through prompt injection. In plain English, the agent may read a web page, document, email or hidden instruction that tries to override the user's original intent. If the agent has access to useful systems, the attacker is not just trying to influence an answer. They may be trying to trigger an action, extract private information, or steer the agent into sharing data from a connector.

This is the governance point many firms will miss. Prompt injection is not only a model safety issue. For a browser agent, it is also a workflow design issue. If an agent can read a supplier portal and also access Gmail, SharePoint, Google Drive, HubSpot, Salesforce or Xero, the boundary between information gathering and information leakage becomes thin. A malicious instruction hidden in a page, a support ticket, a PDF or a customer email can become part of the agent's input. The organisation needs controls that assume some external content is hostile.

The controls are practical. Disable connectors when they are not needed for a task. Use separate accounts for agent work where possible, with least privilege access and no standing authority for payment, deletion, account administration or external sending. Require human approval for consequential actions. Maintain task logs that capture prompt, source systems, user, timestamps, agent action and human approval. Run red team style tests against likely workflows before allowing broader use. Treat agent instructions and prompt templates as controlled operational artefacts, not casual notes in a shared document.

OpenAI's product controls, including explicit confirmation, Watch Mode for some critical tasks, refusal of high risk tasks such as bank transfers, and cookie clearing controls, are useful safeguards. They are not a substitute for company governance. A supplier's safety stack reduces baseline risk. It does not define your business risk appetite, regulatory exposure or recovery plan.

UK cyber guidance already points to the answer

The UK governance frame is already there if leaders connect the dots. The Cyber Governance Code of Practice says it was created to support boards and directors in governing cyber security risks and sets out the most critical governance actions that directors are responsible for. It also gives the commercial context: 50 percent of businesses and 66 percent of high-income charities reported some form of cyber security breach or attack in the previous 12 months, rising to 70 percent for medium businesses and 74 percent for large businesses in the cited Cyber Security Breaches Survey 2024. Browser agents do not sit outside that risk picture. They are a new way for cyber risk to enter normal operations.

The Code asks boards to agree senior ownership of cyber risks, define risk appetite, gain assurance on suppliers, exercise incident plans, and require formal reporting at least quarterly. Those are exactly the right questions for agentic browser automation. Who owns the risk when a team deploys ChatGPT Agent into customer operations? Is it IT, security, operations, legal, data protection, or the business unit? What is the risk appetite for agents acting inside authenticated portals? Which suppliers and connectors are permitted? What happens if an agent sends incorrect information, discloses personal data, changes a record, or follows a malicious instruction?

The AI Cyber Security Code of Practice makes this even more specific. It says AI systems have distinct risks including data poisoning, model obfuscation and indirect prompt injection. It also says developers and system operators should document data, models and prompts, maintain audit trails, design for human responsibility, conduct testing, secure the supply chain, and monitor system behaviour. DSIT also says 80 percent of respondents endorsed the proposed intervention, with support for each principle ranging from 83 percent to 90 percent. That is strong evidence that the UK market expects more than informal tool adoption.

For UK firms, the governance answer is not to ban browser agents by default. It is to pull them into the same risk machinery as other business critical systems. Put them on the risk register. Map their access. Assign owners. Require assurance from vendors. Test high risk workflows. Report adoption and incidents to the board. If an agent can act through a browser, it belongs in cyber governance, not only in an innovation team demo.

Data protection duties follow the data, not the user interface

A common misconception is that a browser agent is safe from a data protection perspective because the human remains the logged in user. That is too simplistic. Under UK GDPR and the Data Protection Act 2018, the organisation still has to account for personal data processing, lawful basis, transparency, fairness, accuracy, security and retention. The user interface does not decide whether data protection applies. The processing does. If an agent reads customer tickets, employee records, health notes, credit information, complaints, emails or call transcripts, the organisation needs a data protection position for that workflow.

The ICO's guidance on AI and data protection points organisations towards accountability, governance, DPIAs, transparency, lawfulness, fairness, accuracy and automated decision-making considerations. For browser agents, the practical question is whether the firm can explain what data the agent can see, why it can see it, how long artefacts are retained, whether the data is used for model improvement, how outputs are checked, and whether affected individuals would reasonably expect that use. If the answer is unclear, the workflow is not ready for production.

There is also a difference between decision support and automated decision-making. A browser agent that gathers records for a human reviewer is one thing. An agent that changes an account status, prioritises a complaint, rejects an application, sends a pricing offer, or triggers a service action is closer to operational decisioning. Article 22 and wider fairness obligations may become relevant if decisions are solely automated and have legal or similarly significant effects. Even where Article 22 is not triggered, the firm still needs to manage fairness, transparency and accuracy.

In practice, UK firms should require a lightweight DPIA screen for any browser agent workflow touching personal data. It should capture the source systems, categories of personal data, purpose, lawful basis, human review point, retention, vendor terms, logging, risk mitigations and escalation route. That is not bureaucracy for its own sake. It is the minimum evidence needed to show the agent has been deployed as a controlled business process rather than an unsupervised shortcut.

The practical control model is smaller than people think

The counterargument is predictable: if staff already use SaaS tools, browser agents are only another interface. There is some truth in that. A well controlled agent can be safer than a tired human copying data across tabs at speed. It can produce logs, follow standard operating procedures, ask for approval, and perform repeatable checks. The point is not that agents are uniquely dangerous. The point is that they concentrate authority, context and action in a way most existing policies were not written to handle.

A practical control model starts with a register. List each approved agent workflow, the owner, source systems, data categories, permitted actions, prohibited actions, approval requirements, logging location, retention period, vendor, and review date. Then create an access pattern. Do not let agents use normal privileged human accounts if a restricted service account or separate low privilege user is possible. Remove connectors by default and enable them only for defined workflows. Prevent agents from using payment, admin, deletion, external sending or bulk export capabilities unless there is a specific approved case and a second human approval.

Next, build approval tiers. Low risk tasks such as public research and draft summaries can be reviewed after completion. Medium risk tasks such as internal document synthesis need source citation and human review before sharing. High risk tasks such as sending messages, changing customer records, uploading files, booking services or submitting forms need explicit step approval and audit logging. Very high risk tasks such as payments, account administration, disciplinary actions, legal notices and irreversible deletion should remain out of scope unless the firm has a mature control environment.

Finally, test the workflows. Use prompt injection test pages, misleading PDFs, hostile email text, stale records, duplicate customer names, broken forms and ambiguous instructions. Check whether the agent stops, asks, cites sources, respects exclusions and records evidence. Review logs monthly for the first quarter and after major model or vendor updates. That is the governance pattern UK firms need: not a grand AI policy that nobody reads, but a small set of enforceable controls around the places where agents can actually act.

Frequently Asked Questions

What is ChatGPT Agent?

ChatGPT Agent is OpenAI's agentic mode that combines web interaction, research, code execution, connectors and artefact creation. It can use a virtual computer to navigate websites, analyse information and produce outputs such as spreadsheets or slide decks.

Why is browser automation a governance issue?

Because a browser agent can act inside authenticated systems using a user's authority. That raises questions about access control, approvals, audit logs, personal data, incident response and accountability.

Can UK firms safely use browser agents?

Yes, but not as an uncontrolled staff experiment. Firms should define approved workflows, restrict connectors, apply least privilege, require human approval for consequential actions, and keep logs that can be reviewed.

Does UK GDPR apply if the agent is only helping a human?

It can. If the agent reads, summarises, transforms or acts on personal data, the organisation still needs to consider lawful basis, fairness, transparency, security, retention and accountability.

What is prompt injection in this context?

Prompt injection is when hostile instructions hidden in a web page, document, email or other content attempt to influence the agent. With browser agents, the concern is that the agent may have access to internal data or authenticated systems.

Should agents be allowed to send emails or update CRM records?

Only under controlled conditions. Drafting can be lower risk, but sending messages or changing live records should require explicit human approval, clear logs and a defined rollback or correction process.

What should boards ask about browser agents?

Boards should ask who owns agent risk, which systems agents can access, what actions are prohibited, how human approval works, what logs exist, how incidents are reported, and how supplier assurance is handled.

Is banning browser agents the safest answer?

A ban may be appropriate for high risk systems, but it is not a long term governance model. A better default is controlled enablement: approved workflows, least privilege access, documented approvals, testing and regular review.