Browser-use agents — agents that drive a real browser, read rendered pages, and click, type, and navigate — are the fastest-growing agent category and the one with the worst intrinsic security properties. Not because the implementations are careless, but because of what the shape requires: reading arbitrary web content (maximum untrusted input) while holding authenticated sessions (maximum authority). Those are the two ingredients of every serious agent incident, combined by design.

Treating a browser agent like any other tool-using agent underestimates it. The controls need to be specific.

Why This Shape Is Uniquely Exposed

Every page is attacker-controllable. Not just pages the attacker owns — comment sections, user profiles, search results, ad slots, review text, any user-generated content on a legitimate site. The agent cannot distinguish an instruction planted in a product review from the review itself.

The injection surface is larger than the visible page. The model typically receives an accessibility tree, extracted text, or a screenshot plus DOM summary. That pulls in content a human would never see: display:none blocks, zero-opacity text, off-screen positioned elements, alt attributes, aria-label values, title tooltips, hidden form fields, HTML comments, and content in collapsed sections. Attackers put instructions exactly there — invisible to the site's human visitors and to the site's own moderators, fully visible to the agent.

Authority is ambient and broad. A browser session is a bearer credential in cookie form, and cookies are sent automatically to their domain. There is no per-action scoping: if the agent is logged into an admin console, every capability of that console is one navigation away. Site-level permissions are far coarser than anything you would grant an API-based agent.

Actions are real and often irreversible. Clicking submits. Buying, sending, deleting, transferring, changing settings — all normal browser interactions, all indistinguishable at the automation layer from clicking a harmless link.

Cross-domain reach is inherent. A page can navigate or redirect anywhere. An agent following links crosses trust boundaries continuously, and each crossing is invisible unless something is watching.

Session and Credential Design

This is where most of the risk is decided.

Never attach a human's real browser profile. Sharing a person's profile hands the agent every session that person holds — email, banking, cloud consoles, internal tools — and makes every action indistinguishable from that person's own in the target site's logs. Convenient, and the single worst configuration available.

Use dedicated, purpose-scoped accounts. The agent gets its own account on each target service, with the minimum role that service offers. Where the service supports API access with scoped tokens, prefer that over browser automation entirely — driving a UI to accomplish what an API call could do accepts unnecessary risk for no benefit.

One session per task, destroyed after. A fresh browser context per task, discarded on completion. This prevents cookies, tokens, and cached state from one task reaching another, and it prevents a poisoned page from persisting influence through local storage or service workers.

Never put credentials in the model's context. Credential injection must happen at the automation layer — the framework fills the login form, or the context is pre-authenticated with cookies the model never sees. An agent that can read its own password can be talked into printing it. See agent session hijacking and token replay.

Keep the browser off internal networks. A browser agent should have no route to private ranges or cloud metadata. Public internet only, through a proxy. Reachability into internal systems plus arbitrary page content is the combination that turns a page into internal-service access. See SSRF risks in agent tool calls.

Domain allow-list, enforced at the network layer. Enumerate the domains a given agent task may reach. Any navigation elsewhere fails. This is the most effective single control because it bounds both the injection surface and the exfiltration channel, and it costs nothing to evaluate. Where open-ended browsing is a genuine requirement, run it as a distinct agent with no credentials at all — read-only research with nothing worth stealing.

Classify actions by consequence, and gate the consequential ones. Navigation and reading are unremarkable. Form submission, payment, deletion, permission changes, and outbound messaging are not. Interpose on the state-changing interactions and require either explicit policy authorization or human approval, with the proposed action and its target rendered for review. See human-in-the-loop approvals for agents.

Block credential entry into unexpected domains. If the agent is about to type something that matches a known secret into a domain that is not the credential's registered origin, stop. This is anti-phishing for agents, and it catches the "you have been logged out, sign in again at this URL" injection that works alarmingly well.

Disable downloads and file uploads by default. Downloads bring executables and documents into your infrastructure; uploads are a direct exfiltration path from the agent's filesystem. Both should be explicit exceptions.

Cap navigation depth and action count per task. Bounds runaway loops and limits how far a hijacked task can wander before something notices.

Strip or mark hidden content before it reaches the model. Filter elements that are not visually rendered, and label the remainder with provenance. This is imperfect — CSS visibility is complicated — but it removes the cheapest injection technique. It should be paired with, not substituted for, action gating.

Exfiltration Runs Both Ways

Two directions matter and teams usually control only one.

Out through the browser. The agent types sensitive content into a form on an attacker-controlled page, or navigates to a URL with data in the query string, or the injected instruction says "search for the contents of the previous page." Domain allow-listing addresses the destination; content guardrails on typed input and navigation URLs address the payload. See data exfiltration risks in agentic AI.

Out through your own telemetry. Screenshots and page text captured for debugging or evaluation contain whatever was on screen — customer records, internal dashboards, personal data. Those artifacts flow to logs, traces, and vendor observability pipelines with broad read access. Redact before storage, restrict retention, and treat the screenshot store as a sensitive data system. See how to redact PII from agent prompts.

Detection

  • Navigation to a domain outside the allow-list, or first-seen domains for that agent.
  • Credential-shaped input typed into a non-registered origin.
  • Action rate or navigation depth exceeding the agent's baseline.
  • Hidden-element instruction patterns found in extracted page content — worth alerting on even when the agent ignored them, because it tells you a site in your allow-list has been poisoned.
  • State-changing actions on domains where the agent has only ever read.
  • Guardrail hits on typed content or on captured page text.

Common questions

Is a headless browser safer than a full one?

Marginally and for the wrong reasons. Headless mode removes some rendering surface but changes nothing about the injection or authority model, and many sites detect and behave differently under headless automation, which can push teams toward stealth configurations that disable security features. Choose based on functionality; do not treat headless as a security control.

Should I use the accessibility tree, extracted text, or screenshots as input?

Each has a different exposure. The accessibility tree includes ARIA labels and hidden-but-exposed nodes, so it is a rich injection surface. Extracted text can be filtered by computed visibility, which makes it the most controllable. Screenshots are hardest to inject through invisible text but carry everything visually present into your telemetry, and they are vulnerable to visual injection — text rendered in an image instructing the model. Most robust deployments use screenshots plus filtered text, and apply injection scanning to the text channel.

Can browser agents be used safely for authenticated workflows at all?

Yes, when the workflow is narrow: a specific site, a specific dedicated account with the minimum role, an allow-list of one domain, action gating on the state-changing steps, and a session that lives for one task. That configuration is defensible. What is not defensible is an open-ended agent with a human's profile and a general instruction to "handle my accounts."

How do I test this before shipping?

Build an adversarial page set: hidden-text instructions, fake logout prompts, forms that harvest typed content, redirect chains to private addresses, visual injection in images. Run your agent against it in CI and assert the controls hold — allow-list blocks the navigation, credential guard blocks the typing, approval gate catches the submission. Injection defenses regress silently, so this belongs in a pipeline rather than in a one-time review. See continuous adversarial testing for AI agents.

How Praesidia approaches browser-agent risk

Praesidia governs the browser surface as a connection with enumerated scope, a destination constraint, guardrails on both directions, a trust-level requirement, and a spend ceiling — so browsing capability is granted per agent and revocable independently. Credentials for target services are held at the proxy and attached after policy evaluation, keeping them out of the model's context.

Content moving through the connection is evaluated for injection patterns and sensitive data with block, redact, or warn dispositions, and every navigation and action is recorded with the destination and the task attributed — which is what makes first-seen-domain and poisoned-page signals available without a separate pipeline. Consequential actions can be gated for human approval, and a kill switch halts the agent including in-flight work. See tool use safety and sandboxing agent actions and the Praesidia documentation.