Before AI agents start clicking, write a browser policy

By Greg Nowak. Updated 27 August 2026.

A browser-using AI agent can search websites, complete forms, update records and move through workflows that were previously handled by a person. That makes it useful—but it also gives the agent opportunities to disclose data, accept terms, modify production systems or follow malicious instructions hidden on a page.

Before connecting one to a CRM, CMS, supplier portal or admin tool, write a browser policy. This does not need to be a lengthy governance document. It should be a practical agreement describing where the agent may go, what it may do and when a person must take over.

A policy is more reliable than a clever prompt

Instructions such as “be careful” or “ask before doing anything important” leave too much room for interpretation. Define important in operational terms instead.

For each workflow, record the approved websites and accounts, permitted data, allowed actions, approval points, evidence requirements and stop conditions. Assign a business owner who can change or withdraw those permissions. Give the agent its own identity or dedicated account wherever the system supports it; shared employee credentials weaken accountability and usually grant more access than the task requires.

Treat everything the browser encounters as untrusted input. A webpage, email, document or image may contain instructions designed to redirect the agent. Current guidance from both OpenAI and Anthropic makes clear that prompt-injection defences reduce risk but do not eliminate it. A system prompt is therefore not a substitute for restricted credentials, network controls and enforced approval gates.

Separate the browser from everyday employee sessions

Run the agent in a dedicated browser profile, container or virtual machine with minimal privileges. It should not inherit an employee’s saved passwords, extensions, downloads, open tabs or personal browsing history. Restrict network access to the domains required for the job, including any authentication and file-storage domains the workflow genuinely needs.

Apply least privilege inside each application too. An agent checking delivery status does not need permission to change bank details. An agent drafting a CMS article does not automatically need production publishing rights. If a portal cannot provide suitably narrow access, that may be a reason to keep its workflow in draft-only mode.

Decide where downloaded files, screenshots and browser traces are stored, who can see them and when they are deleted. These records can contain customer data or session details, so “log everything forever” is not a safe audit strategy.

Put approval immediately before the consequence

An approval step should present a specific proposed action, not ask someone to approve a broad goal such as “finish the task.” The reviewer should see the target system and account, fields being changed, recipients, information being disclosed, financial amount and any irreversible consequence.

Place the gate immediately before the consequential click. Approval given earlier can become stale if the page, account, cart or draft changes. Login credentials, security codes and payment details should be entered through the browser’s protected takeover flow rather than pasted into an agent conversation.

Define stop conditions as carefully as permissions. The agent should pause on an unexpected domain, account mismatch, changed terms, ambiguous record, duplicate entry, authentication problem, suspected prompt injection or page state outside the tested route. Stopping safely is a feature, not a failed automation.

Test the controls, not only the happy path

Browser interfaces change, and an agent can misread a modal or choose a plausible-looking record. Test the surrounding controls independently of the model. Playwright can exercise known paths, capture traces and confirm that approval gates, account restrictions and blocked actions continue to work.

npx playwright test --trace on
npx playwright show-report

A trace helps a delivery team inspect page states, network activity and actions after a failure. Protect trace files as operational data: review them for personal information, credentials and confidential page content before sharing or retaining them.

Include awkward cases in acceptance testing: an expired session, wrong company account, changed button label, unexpected redirect, duplicate record, missing permission, hostile page instruction and a human who rejects the proposed action. Playwright can verify deterministic boundaries and repeatable workflows; it cannot prove that an agent will reason safely on every unseen page.

Start with one bounded workflow

A sensible first deployment has modest consequences, a clear owner and an output a person can verify quickly. Examples include collecting order statuses, preparing CRM notes, checking supplier availability or drafting CMS changes.

1. Map the browser states from login to recorded outcome.
2. Classify every action as allowed, approval-required or blocked.
3. Create the dedicated identity and restricted environment.
4. Test expected paths, exceptions and prompt-injection scenarios.
5. Review early runs, then expand permissions only with evidence.

The business case is not maximum autonomy. It is dependable relief from repetitive work without quietly transferring authority to software. If you need help mapping a browser workflow, defining its approval gates or testing a controlled pilot, talk to Greg about the rollout.

Related on GrN.dk

• OpenAI Computer Use: Browser Agents Need Credentials, Not Demos
• OpenAI File Search: Internal Docs Need Governance Before Trust
• Your AI Agent Has Shell Access. What Can It Reach?

Need help with this kind of work?

Plan a controlled browser-agent rollout Get in touch with Greg.

Sources

• Computer use tool — Claude Platform Docs
• Understanding prompt injections — OpenAI
• Secure agents: Identity, access, and data protection — Microsoft Learn
• Trace Viewer — Playwright