Securing a browser agent

A browser agent visits pages nobody vetted. Any of them can contain text addressed to the agent — in a comment, in white-on-white text, in an image, in an attribute — and the agent has no reliable way to distinguish page content from operator instruction.

So the defensive question is never "how do I stop it reading something bad". It is "what can it do once it has". Everything useful follows from accepting that the reading cannot be controlled.

Job boards are an unusually exposed case because the content is written by third parties and rendered on a site the agent has reason to trust. A job description is a document from a stranger delivered through a domain on your allowlist.

Run the browser in a container or virtual machine with nothing valuable in it, a fresh profile per session, and no credentials on disk. Treat the environment as disposable and destroy it afterwards.

This bounds the damage of any successful manipulation to that session. An agent that cannot reach your filesystem, your other sessions or your network cannot do much on an attacker’s behalf regardless of what it was told.

Isolate per candidate as well as per session. Reusing a browser profile across users to save startup time carries one person’s cookies into another’s run, which is a data breach with no attacker required.

• A container or VM, destroyed after each session
• A browser profile with no history and no stored logins
• No password manager, no extensions beyond what the task needs
• No credentials on disk; secrets injected at the moment of use

Allowlist the domains the agent may navigate to. A job agent needs a handful of job boards and employer careers pages, and nothing else — so a redirect to an attacker’s host simply fails.

Restrict outbound network access at the container level too, not only in the browser. Exfiltration needs somewhere to go; removing the destinations defeats the attack without needing to detect it.

A page can issue a request without navigating anywhere, which is precisely why the browser-level allowlist is insufficient on its own. Blocking at the network layer covers the channels the navigation rule never sees.

The highest-value structural control is refusing to let page content trigger consequential actions directly. Content the agent reads should inform a proposal; a separate, validated path performs anything with an effect.

Concretely: the agent may read a form and propose values, and your code decides whether that submission is permitted for this candidate on this job. An instruction embedded in a page can influence the proposal and cannot reach the decision.

That validator is where the rules that cannot be argued with live: this origin is allowed, this action type is permitted here, this field is on the never-fill list, this submission has a recorded human confirmation. None of them is reachable by the component that reads the page.

Keep the tool set narrow for the same reason. An agent that can read a posting and fill a form does not need to send email, download files or execute script, and a capability that does not exist cannot be reached for however persuasive the page was.

Text the model produces has passed through content written by strangers, so anything it emits that reaches a database, a shell, a URL or a template is an injection vector. The fact that it came from your own agent is not a reason to trust it.

Validate on the way out as well as in: a field value against an expected shape, a URL against the allowlist, an identifier against something you issued rather than something the model composed.

Never let the model supply the identifiers that decide scope. The candidate and the job should come from the verified session and an explicit parameter, because an id the model can produce is an id a page can influence.

Log navigation, every action with its arguments, and screenshots at decision points — then watch for the shapes that indicate manipulation rather than difficulty.

Useful signals: navigation to a domain outside the expected set, an unusual number of steps on one page, the same action repeated, or the agent attempting a tool that the current task should not require. Any of them is worth halting on and reviewing, because the alternative is finding out afterwards.

Record refusals as well as actions. A run repeatedly attempting a blocked origin or a withheld capability is the clearest evidence available that something is steering it, and it is invisible in a log that only captures what succeeded.

Give those logs the handling they deserve. They contain page content, form values and candidate data, so they need a retention limit and the same access controls as the primary records rather than sitting in an unexamined bucket.