Giving an agent browser access safely

A browser profile is a credential store. It holds session cookies for your email, your bank, your employer’s systems and everything else you have not signed out of — which is everything.

Running an agent in that profile grants it all of them at once. Nothing about the job-application task required access to your inbox, but the profile does not distinguish, and neither does an agent that has been persuaded by something it read.

A password manager extension raises the ceiling further. It will autofill on request, which means the agent’s reach extends beyond the sessions currently open to anything the vault can unlock — and nothing about filling a job application needed that.

On its own, a browser with your sessions is just your browser. On its own, an agent that follows instructions in text is a curiosity. Together they are a system that holds your credentials and takes instructions from strangers.

Every web page it visits is untrusted input. A page can contain text directed at the agent, invisible to you, and the agent has no reliable way to distinguish page content from your instruction.

A job board is a particularly exposed surface for this, because much of its content is written by third parties. A job description is a document from someone you have never met, rendered on a site you trust, read by an agent holding your sessions.

The single most effective step is a separate browser profile that has never been signed into anything except what the task requires. Not a private window in your main browser — a genuinely separate profile with its own cookie store.

Sign it into the job boards it needs and nothing else. If it is compromised, the loss is a job board session rather than your email, and that difference is the entire security posture.

A container or virtual machine is better again where the task warrants it, because it bounds what a compromise reaches beyond the browser — the filesystem, the local network and anything else running on the machine.

• A separate profile, not an incognito window of your main one
• Signed into only the sites the task requires
• No password manager extension installed
• Cleared between sessions where practical
• Never the profile you use for banking or work systems

Exfiltration requires reaching an attacker-controlled destination. An allowlist of domains the agent may navigate to turns a successful injection into a failed one, because the instruction to send data somewhere cannot be carried out.

This is more effective than trying to detect malicious instructions, and considerably easier to reason about. You do not need to anticipate the attack; you need to make the payoff unreachable.

Enforce it below the browser as well. A page can issue a request without navigating anywhere, so restricting outbound traffic at the container or network level covers the channels a navigation allowlist does not see.

Access is not only about the profile. An agent that can read a posting and fill a form needs no ability to send email, download files or install anything, and every capability it does not have is one an injected instruction cannot reach for.

Keep reading separate from acting where the tooling allows. Content the agent reads should inform a proposal, and a separate validated path should decide whether that action is permitted — so page text can influence the suggestion and not the outcome.

Prefer a session the agent cannot extend. An expiring session scoped to the sites it needs is much better than a stored password, because the worst case is bounded in time as well as in reach.

Record the navigation history, every form submission with its values, and screenshots at decision points. The agent’s own account of what it did is not evidence — it is output from the same system you are investigating.

Review those records the first several runs rather than trusting the summary. This is where people discover their agent logged into something they did not expect, or submitted a form twice, and it is cheap to catch early.

Watch for the shapes that suggest steering rather than difficulty: navigation outside the expected domains, an unusual number of steps on one page, the same action repeated, or an attempt to use something the task should not require. Any of those is worth halting on.