AI browser agents read pages, fill forms and click buttons inside a real browser, often with the user's own logged-in sessions.
This guide shows how to secure them at work: browser settings, approvals, and page-type checks from an AI agent allow list at the egress point.
Two kinds of tool now browse on a user's behalf. They need the same controls, applied in slightly different places.
Agentic browsers sit with a person. Browser-driving agents often run alone.
Most organisations already have both, whether they approved them or not.
A full browser with an assistant built in. The user asks, and the browser navigates, reads and acts in the same window.
It usually runs with the user's cookies, saved logins and extensions.
An agent, often running on a server, that controls a browser through automation. It may run with no human watching at all.
It usually has its own session, but may be given credentials to log in.
Below, a browser agent works through a simple task. Each URL is checked against its page type before the page loads.
The demo cycles through the four pages every few seconds.
The domain is the same for most requests. The page type makes the difference.
A chat assistant only talks. A browser agent acts on real websites, with real accounts, in real time.
None of these are bugs in a single product. They come from what browser agents are for.
Four things make that harder to secure than ordinary browsing.
Everything the agent reads can steer what it does next, including hidden text.
The user is logged in to email, banking and admin tools in the same browser.
Checkout, signup and posting pages are ordinary pages to the agent.
The agent can finish a wrong action before the user reads the screen.
Map the attack surface before choosing controls. Each area below has been used against browser agents in public research.
Controls chosen without this map tend to cover the easy areas and miss the busy ones.
The web page itself is the largest area, because the agent reads so much of it.
| Area | What can go wrong | Main control |
|---|---|---|
| Page content | Hidden instructions steer the agent | Page-type checks on every next URL |
| Logged-in sessions | The agent acts inside the user's accounts | Separate agent profile, no saved logins |
| Forms | Personal or company data typed into the wrong site | Deny signup and form-heavy action pages |
| Payments | Purchases made without a clear yes | Approval on cart and checkout pages |
| Downloads and uploads | Files fetched or sent without review | Deny upload pages, scan downloads |
| Extensions | Other extensions read what the agent sees | Managed extension allowlist |
No single control is enough. Use them in layers, so one miss does not become an incident.
Controls 1 to 3 can usually be in place within a month.
The first three give the most protection for the least effort.
Every URL is checked before it loads. Action pages are denied or sent for approval.
No saved passwords, no personal cookies, no payment details.
Checkout, signup and subscribe need a clear yes from the user.
Central policy for which agent features are on, and for whom.
Only approved extensions run in the agent profile.
Scan or block file types the task does not need.
Block typing company secrets into unknown sites.
Every page, page type and decision, tied to the user and agent.
Switch agent features off centrally in minutes.
Most browser agent tasks are about reading and comparing. Very few need to act.
This default reflects that. Loosen it per team only when a task proves the need.
blogdocumentationpricingaboutproducthelp_center
Plain reading pages, where the risk is what the agent reads, not what it does.
signuppassword_resetcartcheckoutsubscribeuploadpost_createcomment
The 8 action page types. Deny by default, with approval for the few tasks that need them.
Browser settings and network checks each see things the other cannot. Use both where you can.
Where only one is possible, pick the one that covers the most agent traffic.
| Question | In the browser | At the egress proxy |
|---|---|---|
| Sees which tab is the agent | Yes | Only with an agent header or separate profile |
| Hard for the agent to bypass | Medium | High |
| Covers server-side browser agents | No | Yes |
| Works with unmanaged devices | No | Only on company networks |
| Checks page types | If the browser supports it | Yes, with page-type data |
For server-side agents, the egress proxy is the only reliable point. For agentic browsers on laptops, pair managed settings with the proxy.
Browser agents spread fast once people try them. A short, staged rollout keeps control without blocking useful work.
Announce the approved tools early, so people have a safe option before they pick their own.
Start with visibility, then add limits.
Look for agentic browsers and automation traffic in device and proxy logs.
Choose which browser agents are allowed, and for which teams.
Separate profiles, extension allowlist, and page-type policy in log-only mode.
Deny action pages, turn on approvals, and review denials weekly.
Technical controls do most of the work. A few plain rules help users avoid the rest.
Put them on one page, and link it from the browser's start page.
Never your main profile with saved passwords.
Check the site and the page type in every approval request.
"Compare these three pricing pages" is safer than "sort out our subscriptions".
Stay with the agent the first time it does a new kind of task.
Unexpected pages, forms or downloads go to security.
Ask before rolling out any agentic browser or browser automation service. Get written answers.
Keep the answers on file and revisit them at renewal.
A vendor that cannot answer the first two is not ready for company use.
By page type, by domain, or through your proxy.
For payments, signups, posts and uploads.
Per user and per group, without uninstalling.
Pages, actions and decisions, available to your team.
Locally or on the vendor's servers, and for how long it is kept.
And can that be turned off by policy?
These are the mistakes seen most often in early rollouts. Each one turns a helpful tool into a liability.
Most take minutes to fix once somebody looks.
Every saved login is now in reach.
An allowed shop still has a checkout page.
A steered agent can describe a checkout as a quote.
You cannot investigate what you never recorded.
"Allow this action?" tells the user nothing.
Nothing checks where they go.
Report these monthly. They show both adoption and control.
Share them with team leads as well as security, since they show where agents help most.
A rise in denials after a new rollout is normal. A rise months later deserves a look.
Approved and unapproved.
Target: all of it.
By page type and team.
Watch for rubber-stamping.
An approval is only as good as the information in it. The user should know exactly what will happen if they say yes.
Show the site, the page type, the task and a time limit.
Never offer "always allow" for action pages. Each purchase or signup deserves its own yes.
A browser agent types whatever the task seems to need. On the wrong page, that can include names, emails or contract details.
Three layers keep that data where it belongs.
Signup, subscribe and comment pages are where data is most often typed.
No saved payment cards, passwords or personal autofill in the agent profile.
Data loss rules on the proxy flag sensitive values sent to unknown sites.
Browser agent controls meet a few common objections. Short answers help keep the rollout on track.
Each answer comes back to the same idea: reading is fine, acting needs a check.
That is why the controls should be light on reading pages. A useful approved tool beats a hidden one.
Built-in safety helps, but it lives inside the product. Your own check at egress holds whatever the product does.
Only action pages need them. Most agent tasks never hit one.
It takes one click to switch, and it keeps every saved login out of the agent's reach.
Browser agents touch endpoint, network and identity teams. Agree the split before rollout.
Write it into the agent registry, so users know who to ask.
| Task | Owner |
|---|---|
| Approved browser agents and settings | Endpoint team |
| Page-type policy at egress | Network security |
| Agent profiles and saved logins | Identity team |
| User rules and training | Security awareness |
| Monthly review of denials and approvals | Security with team leads |
The honest fine print — the same two assumptions we publish, plus two operational ones
28 page types, including 8 action types, on 40M+ domains.
