Chat assistants now offer an agent mode that browses sites, fills forms and connects to company apps. Admins need to decide what it may reach.
This guide covers the five settings to get right, where your own proxy helps and where it cannot, and how an AI agent allow list shapes the site list.
In agent mode, a chat assistant stops only answering and starts doing. It plans steps, opens web pages, clicks, types and uses connected apps.
That makes it far more useful, and it moves the risk from what it says to what it does.
The user sees a summary. The actions happen on real sites and in real accounts.
Opens and reads web pages, often in a browser the vendor runs.
Fills forms, clicks buttons and can reach signup or checkout pages.
Uses company apps such as mail, files and calendars through connectors.
Before setting anything, find out where the agent's browser runs. It changes which controls you can use.
Ask the vendor in writing. Product pages rarely say it clearly.
Many agent modes run the browser in the vendor's cloud. That traffic never passes your network.
Names differ between products, but most admin consoles offer these five controls in some form.
If your product lacks one of them, record the gap and raise it at renewal.
Try the switches below to see what each one changes.
Everyone, selected groups, or nobody.
Mail, files, calendars, code and business apps.
An allowed or blocked list of domains.
Purchases, signups, sending and posting.
Records of actions for compliance tools.
Most admin consoles only accept domains. Nearly every domain has action pages as well as reading pages.
Page-type data tells you which of those domains carry the action pages to watch.
So a domain list decides where the agent may go. Confirmation settings must decide what it may do there.
Not every team needs the same agent mode. Start narrow, and widen where a real task needs it.
Adjust the table after the pilot, based on what teams really used.
Confirmation stays on for everyone.
| Team | Agent mode | Connectors | Sites |
|---|---|---|---|
| Research and strategy | On | Files, read-only | Broad reading list |
| Marketing | On | Files, calendar | Reading list plus own sites |
| Sales | On | Calendar, CRM read-only | Reading list, no signups |
| Finance and procurement | Pilot only | None at first | Named suppliers only |
| IT administrators | Off for admin accounts | None | Not applicable |
| Executives | Pilot only | Mail and calendar, read-only | Reading list |
Connectors let agent mode read and write inside company apps. They often matter more than the website list.
Treat each connector as a separate risk decision, not a feature switch.
A page on the open web can steer an agent that also holds a mail connector.
Turn connectors on one at a time, per group.
Reading mail is less risky than sending it.
An agent that reads the web and can send mail is an easy route for data to leave.
Remove connectors nobody used.
Even when the agent's browser runs in the cloud, your network is not irrelevant. It still sees some important traffic.
It also shows how much agent use happens outside the approved workspace.
Where the browser runs on your side, it sees everything.
Allow only the approved workspace, not personal accounts.
Agent modes that drive a browser on the device pass your proxy.
On local traffic, action pages can be denied before they load.
Pages the agent suggests and the user then opens are checked too.
Uploads of company files to the assistant can be inspected.
Other agent tools show up in proxy logs.
Agent mode is popular the day it appears. A short plan lets you say yes quickly without losing control.
A clear date for each team reduces pressure to switch it on early.
Tell users the plan on day one, so they wait for the approved route.
Find out where the browser runs, and which of the five settings your product offers.
Turn it on for one low-risk team with no connectors.
Build the domain list from pilot use, and add read-only connectors.
Add teams one at a time, with the settings from the table above.
Ask before turning agent mode on for anyone. Keep the written answers with your risk register.
Vague answers to any of these are a finding in themselves.
The first three decide whether you can control it at all.
Your side, or the vendor's cloud.
By domain, by URL, or by page type.
Can admins make more actions require it?
So our page-type checks apply to cloud browsing too.
Pages, actions and confirmations, per user.
Quickly, without affecting chat.
These show up in many first rollouts. Each is easy to avoid once named.
Check your own rollout against the list before widening to new teams.
No pilot, no site list, no plan.
Cloud browsing bypasses your network.
To "reduce friction" for power users.
Sending mail and editing files from day one.
Allowed domains still have checkout pages.
Exports that nobody reads.
Agent mode reads pages and apps, then writes summaries and takes actions. Data settings decide what it may carry between them.
Many of these are set once for the whole workspace, so decide them before the pilot.
Check these alongside the five main settings.
Confirm in writing that business content is not used to train models.
How long pages, screenshots and actions are kept, and where.
Whether the agent remembers across sessions. Off for high-risk groups.
Which company files users may give the agent.
Whether agent results can be shared outside the workspace.
Where the agent's browsing and data processing happen.
Settings do most of the work. Plain rules help users with the rest.
Keep the list short enough to read in a minute.
Put them in the welcome message when agent mode is switched on.
"Compare these three suppliers" rather than "sort out our suppliers".
Check the site, the amount and the action before saying yes.
If a site needs a login, do that step yourself.
Unless the task and the data rules allow it.
Stay with the agent until you trust the pattern.
Unexpected sites, forms or emails go to security.
Agent mode sits in a collaboration tool, but its risks belong to security. Split the work clearly.
Record the owners in the agent registry.
| Setting | Owner |
|---|---|
| Who may use agent mode | Workspace admin with security |
| Connectors and their scopes | App owners |
| Site list | Network security |
| Confirmation settings | Security |
| Data and retention settings | Data protection |
| Log review | Security operations |
Agent mode rollouts meet the same few objections. Short answers keep things moving.
Most come down to one idea: reading is cheap to allow, acting needs a check.
Vendor defaults are built for all customers. Your settings reflect your data, your teams and your risks.
They only appear for purchases, signups, sending and posting. Those deserve a second look.
Start with the domains the pilot team really used. Page-type data speeds up the review.
Users then turn to personal accounts with no controls at all. A managed yes is safer.
A few figures show whether agent mode is both useful and under control.
Watch the trend across months rather than any single figure.
Share them with the workspace owners as well as security.
By team, against the rollout plan.
Declines show the control working.
And how many are read-only.
From proxy logs. It should fall as the approved route grows.
Short definitions for readers new to agent mode administration.
Product names for these settings differ, but the ideas are the same.
A chat assistant setting where it carries out tasks, not just answers.
A link that lets the agent read or write in a company app.
A prompt asking the user to approve an action before it happens.
A browser the vendor runs for the agent, outside your network.
What a page is for, such as documentation, signup or checkout.
One of 8 page types where something happens, such as a purchase or post.
The honest fine print — the same two assumptions we publish, plus two operational ones
28 page types, including 8 action types, on 40M+ domains.
