A browser agent's profile is a permission boundary, not a convenience setting
Browser agents are becoming more useful because they can work through the same interfaces people use: dashboards, documentation sites, issue trackers, admin panels, and forms. The productivity pitch is obvious. A browser tool can read a page, follow a workflow, and carry out a sequence of clicks without forcing the model to reconstruct the interface from an API.
The important design choice is less glamorous: which browser profile does the agent control?
A profile is not just a collection of bookmarks. It can contain logged-in sessions, cookies, saved passwords, extensions, site permissions, payment state, and synchronised account data. Granting an agent access to a real profile can be appropriate for a scoped task. It also changes the agent's authority. That choice deserves the same care as giving a service account a new credential.
Local control still has real authority
Public Browser is a small open-source browser-control server that connects to Chrome through the Chrome DevTools Protocol and returns accessibility-tree references for agent actions. Its documentation says it starts with a fresh temporary profile by default. It can also launch with a real profile, preserving extensions, cookies, logins, and sync.
That is a useful contrast. A fresh profile may be unable to reach a member-only site, but it contains no existing authenticated session. A real profile may complete the task with less friction, yet it can turn an instruction such as "check this account" into access to every site already signed in under that profile.
Chrome itself supports separate profiles so people can keep browsing data, settings, and accounts apart. Chrome's profile documentation describes profiles as a way to separate Chrome information. For an agent, that separation is a practical control: make one dedicated profile for the narrow set of sites and permissions the task needs.
The key point is that a local process is not automatically low-risk. If it can drive an authenticated browser, it can act with the authority of that session. Network egress, account state, and a visible browser window do not remove that fact.
Start with a disposable, task-specific profile
For research, public web work, or test environments, use an empty profile. Add only the access required for the task. If the agent must sign in, prefer a dedicated account with limited scope over a personal or administrator account.
This approach has ordinary engineering benefits too. It makes runs reproducible. A fresh profile does not contain a decade of cookies, experimental extensions, or an accidental sign-in from a previous task. When a workflow stops working, there is less hidden state to investigate.
A practical setup can have three profiles:
- A disposable profile for public browsing and test sites.
- A work profile for a small, reviewed set of low-risk accounts.
- A restricted profile for one consequential service, used only with an explicit task and human oversight.
The names are less important than the separation. Do not let a generic browser agent automatically select the most privileged profile because it happens to be open.
Treat browser actions like external side effects
Reading a page and changing a page are different operations. A browser agent can move quickly from search to form submission, account changes, uploads, purchases, or messages. Put a visible approval point before actions that create, modify, send, publish, delete, or disclose information.
This is where a tool's interface matters. A good workflow reports the target site, account, fields that will change, and the final action before it executes. It should also leave an audit trail that lets a person reconstruct what happened. If the tool supports an inspect-only mode, make that the default for unfamiliar sites.
The Model Context Protocol's authorization specification is written for OAuth-based authorization flows, but its basic discipline applies here: authorization should be scoped to a client, a resource, and a user-controlled grant. A browser profile is another place where scope can silently become broad unless a workflow constrains it.
Remote debugging deserves the same caution
Browser-control tools commonly use Chrome DevTools Protocol. Chrome documents remote debugging as a way to inspect and control a browser or Android WebView from DevTools. Its remote debugging guide is built for development and inspection. It is not a reason to expose a debugging endpoint casually on a network.
Keep browser-control connections local unless there is a specific, secured reason to do otherwise. Use a unique profile directory for automated sessions. Close the session when the task ends. Revoke site sessions or remove the dedicated profile when its work is complete.
These habits also limit prompt-injection fallout. A hostile page may try to persuade an agent to reveal data, switch tasks, or take an external action. A narrow profile cannot make the agent's reasoning perfect, but it reduces what a mistaken action can reach.
Review the tool before trusting the workflow
Browser automation is not interchangeable. Before installing a server or extension, read its permissions, process model, profile behavior, telemetry policy, and update mechanism. Public Browser, for example, documents a temporary profile default and describes its real-profile behavior. That documentation is useful, but it is not a substitute for reviewing the version you install and testing it with non-sensitive data.
The same is true for a benchmark claim. Public Browser publishes raw-run paths and notes where its comparisons do and do not hold. Its September 2026 comparison reports fewer tool calls than Playwright MCP on one controlled 30-test scenario, while also noting that its responses were not smaller. Treat that as project evidence for a narrow setup, not a universal performance ranking.
The safest default is simple: browser agents begin in a clean profile with read-only intent. Give them a separate, limited profile only when the task needs authenticated access. Ask for approval before consequential actions. Browser control becomes much easier to reason about when the identity behind it is deliberately small.
