A Browser Agent Acts as You. The Page Can Steer It

An agent in a browser is an agent inside your login. It can click, type, and call tools while the cookies for your mail, your bank, your cloud console, and your company's SaaS are already there. The page it is looking at is untrusted text. That text can include instructions. The model is built to follow instructions. The browser will not save you, because the same-origin policy constrains scripts, and the agent is not a script from the page. It is you, with a suggestion from the page that it may obey.

Chrome's documentation for agent security with WebMCP says this outright. Agents instrumenting the browser, including extension-powered agents, operate inside an authenticated session. WebMCP gives a site a way to offer those agents structured tools. The threats they name are malicious tool manifests and contaminated tool results. Both are prompt injection with a schema. A VS Code bug that hid fields on an MCP install is the editor version of a bad tool install, covered in the VS Code MCP note. A file that steers a coding agent is the repo version, covered in how a file can steer an agent. This note is the browser: the session, the page, and the tool the page registers.

The session is the privilege

Brave's work on agentic browsers states the break with ordinary web security. A script on a page cannot read your bank because the bank is a different origin. An assistant that can open the bank, because you are logged in and you asked it to "handle my tabs," is not stopped by that rule. A sentence on a forum, or in a product review, or in a page the agent was told to summarize, can tell it to open the bank and move money, or to open the inbox and forward a thread. The page never needed a cross-origin bug. It needed the agent to be helpful.

Their later note on unseeable injections adds the channel people forget once they have filtered HTML. Text drawn into a screenshot, in a color or a size a person does not notice, is still text the model reads if the agent "sees" the page as an image. Hiding the instruction from the user and showing it to the model is a reliable trick. A content filter on the DOM does not run on the pixels. An agent that uses both accessibility text and screenshots has two channels, and the defense has to cover both.

The practical consequence Brave draws is the one to adopt while the platform-level fix does not exist. Isolate agent browsing from normal browsing. Start an agent action — opening a site, reading mail — when a person asks for that action, not as a background pass over every tab. Until browsers can guarantee that, agentic browsing is a dangerous mode you turn on for a task and turn off after. It is not a sidebar you leave running in the profile where you are signed into production.

A separate browser profile is the control a team can actually deploy this week. The agent profile has no bank, no primary inbox, no cloud console, no password manager, no session for the admin SaaS. It may have a test account. The daily profile does not run the agent. A company that installs an "AI browser" as the default browser has skipped this control. The default browser is where the sessions live. Put the agent somewhere else, and accept the friction of signing the test account in once.

Extensions multiply the session. An agent extension that can read all tabs can read a tab the user did not hand it. Permission to "read all websites" is the opposite of a task-scoped credential. If the product needs that permission to be useful, the product needs the separate profile even more. The permission is the blast radius. The profile is how you keep the blast off the accounts that matter.

What WebMCP gives the page

WebMCP is a proposal for letting a site expose tools to an agent: a name, a description, parameters, and a function the page runs when the agent calls it. Chrome's guidance lists two attacks that follow immediately.

A malicious manifest hides instructions in the tool name, the parameter descriptions, or the tool description. The model reads those strings as part of deciding what to do. A tool called search whose description says to exfiltrate the last page of the inbox is a tool the model may follow while the user saw the word search. This is tool poisoning, the same pattern as a hostile MCP server, except the "server" is whatever origin the agent is on, and the user navigated there on purpose.

A contaminated result is the case where the tool is real and the data is not. A comment, a product title, a support ticket, or a document the tool returns contains an instruction. The model treats the tool output as information it should use. The instruction tells it to call a different tool, on a different site, with the user's session. Chrome's point is that safety training inside the model is not a guarantee. Researchers keep demonstrating injection against current models. The prevalence of hostile text on the web is not going down. The control has to sit outside the model: which origins may offer tools, which calls need a person, which arguments are shown in full before anything runs.

Chrome's concrete recommendations line up with that. Set an origin boundary. Restrict cross-origin actions. A tool on a shopping site does not get to drive the bank tab. Require a confirmation the page cannot dismiss, and show the arguments, not a summary the page wrote. A summary is another string the attacker can shape. The arguments are the request.

There is a money-shaped version of the same confirmation problem in the MCP security guidance generally. A server can name a price and a recipient in a tool result and ask the client to pay. The client that pays without showing those terms has handed the page a wallet. The browser agent that "completes checkout" is that client. Bind the amount, the recipient, and the arguments into the approval a person sees. A per-payment cap that the model can raise is not a cap.

The tool does not stay inside the page

Research on WebMCP's fit with the browser's security model says the same-origin policy is the wrong shape for these tools. A paper on a design called WebMCP-Phalanx describes failures that come from the spec's assumptions, not from one bad extension. Scripts on a page — the site, an ad, an analytics tag — share an origin. Any of them can register a tool, replace a tool, or keep a tool alive after the user thinks they navigated away in a single-page app. The tool list does not, in the model they criticize, carry a strong notion of which principal registered it. A tool can claim to be read-only and send data out when it runs. The description can contain the injection even when the tool's behavior is otherwise legitimate.

The W3C's WebMCP threat model tracks the same families: poisoned tool metadata, poisoned results, agent memory that keeps a page's instruction after the page is gone, and calls that cross a boundary the user did not intend. You do not need to adopt the paper's dual-model architecture to use the threat list. You need to stop treating "the site I visited" as a trusted MCP server. It is a page. Pages have ads. Ads have scripts. Scripts will register tools if the platform lets any script on the origin do it.

A quarantine step, which is what the Phalanx design proposes, is one way to break the channel: a model with no tools reads the page content and the tool metadata, and only sanitized text reaches the model that is allowed to call tools. That is an engineering project. It is also an admission that the privileged model cannot be shown the raw page. If your agent puts the raw DOM into the same context as the tool list and the user's cookies, you have built the vulnerable shape. Split them, even crudely. The model that may click does not receive unscanned tool descriptions from an origin the user did not name.

Memory is the delayed form. An instruction seen on a page at 9 a.m. that still sits in the agent memory at 4 p.m. will fire when a later task gives it a tool. Clear agent memory between tasks, and do not share one memory across the inbox agent and the research agent. A research browse and a bank action do not belong in one context. They do not belong in one profile either.

What a confirmation has to show

The click on "Allow" is the only moment a person is in the loop. It has to be a moment about the real action. Show the tool name, the origin that registered it, and the arguments in full. If the argument is a URL, show the URL. If the argument is a payment, show the amount and the recipient. If the page can replace the dialog text, the dialog is part of the page and is not a confirmation. Draw it in the browser chrome, the way a permission prompt is drawn, not in a DOM element the site controls.

Do not offer "always allow this tool." A tool definition can change after the allow. That is the rug pull already documented for MCP servers. A site that was a search box can become a purchase. Re-prompt when the definition changes. Re-prompt when the arguments change. An approval for "search" is not an approval for "search" with a different parameter that posts the document somewhere.

Auto-run is the feature that deletes the moment. An agent that may click through its own confirmations, or a mode that skips prompts because the user got tired of them, is an agent with the session and no person. If you need unattended browsing, run it in the empty profile against sites you listed, with a credential that cannot reach the real accounts, and log every call. Unattended browsing in the daily profile is how a summarizing job becomes a wire transfer the user sees on Monday.

Logs are the way you notice. Record the origin, the tool, the arguments with secrets redacted, and whether a person confirmed. A support ticket that says the agent bought something is otherwise a mystery. The log is also how you revoke. If a tool started sending arguments to a new host, you want that host in a query, not in a screenshot the user took of the confirmation they do not remember.

A deployment that does not hand over the day

Give the agent a profile. Sign nothing important into it. If a task needs a particular SaaS, create a user in that SaaS with the minimum role and sign that user into the agent profile only. Do not sign the administrator in "just this once." Just this once is the session that remains.

Name the sites the agent may open. A list of two is a product. "The web" is not a list. Cross-origin jumps require a person. A research task that needs a second site stops and asks. The ask shows the URL it intends to open, not a title the first site supplied.

Treat tool results as data. The system prompt can say so. The enforcement is that a tool result cannot trigger a second tool without the confirmation dialog, and cannot include a block the model is instructed to obey. Delimiters help and do not hold against a determined page. The dialog holds if the user actually sees the call. If users click through it without reading, the dialog is too frequent and the agent is allowed to do too much. Reduce what it may do until the dialog is rare enough to read.

Keep the agent off MCP servers that hold other credentials in the same session. A browser agent plus a GitHub MCP server plus a cloud MCP server is a browser page away from your source and your infrastructure. The page does not need to be sophisticated. It needs the agent to be connected to those servers while it reads the page. Disconnect them. The MCP server note is the checklist for those servers. The browser is how an untrusted page reaches them.

Employees installing their own agent browser are a policy problem, not only a product problem. Write down whether company SaaS may be used from an agentic browser. If the answer is no, say so, and give people the separate profile for the tasks that genuinely need an agent. A ban with no alternative becomes a shadow install. A shadow install is the daily profile with an extension you have not reviewed.

What to check before an agent shares a profile with a login

1. Find which profile the agent runs in. If it is the profile that is signed into mail, banking, or a cloud console, move it.
2. List the sites it may open and the tools registered there. A tool you did not know the origin offered is a tool you have not reviewed.
3. Confirm confirmations show origin and full arguments, in browser chrome, and that "always allow" is off. Change of definition means a new prompt.
4. Confirm a tool result cannot start a second tool call, a payment, or a cross-origin navigation without that prompt.
5. Clear agent memory between tasks. Do not share memory between a browsing task and an account task.
6. Log origin, tool, and arguments. If you cannot list what the agent called yesterday, you cannot deploy it.
7. Disconnect other MCP servers from the agent that reads the web. A page should not be one hop from your repository token.

The page is not your user. The agent that treats it as one is using your accounts to obey a stranger.

How Techtribe traces what a browser agent can reach

We run the agent, or read the extension, and list the profile it uses, the sites it can open, and the tools a page can register. You get that list in writing, with the calls that would run without a person seeing the arguments. We do not add a prompt that says "ignore the page" and call the session safe.

If you are shipping the browser agent as a product, that boundary is part of AI agent development. If employees already run one against company SaaS, a Dedicated Team fits, because the next extension install will put it back in the daily profile unless someone owns the standard. The scope call is 30 minutes with a founder, and it is where we say which you are in.

Bring the agent product, or the extension, and which logged-in sites it can open. If it is already in the same profile as a cloud console, say that first.

The fixed scope for taking a generated app to production is a page per tool: Lovable, Bolt, v0, and Replit.