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

When the browser is an MCP tool server, Praesidia governs it like any other: an agent calls the browser's tools through Praesidia only over an active connection to that server, in enforce mode its tool policy refuses any tool that none of its rules allows, and the connection's per-tool permissions can deny a tool, constrain its argument values — such as a pattern the URLs a navigation tool opens must match — or cap its calls per hour, so browsing capability is granted per agent and revocable independently. No spend ceiling or trust level is checked on the browser's tool calls; a connection's monthly spend cap and minimum trust level apply to tasks between agents. Praesidia does not hold the credentials the browser uses on the sites it visits: it stores the browser server's own API key or OAuth credentials and attaches them when it connects to the server, and the model is offered the browser's tools by name, without those credentials.

When the agent calls a browser tool during a chat turn, the organization-wide guardrails and the agent's own check the call's arguments before it is sent and the page content it returns before the model reads it, for injection patterns and sensitive data, with block, redact, or warn dispositions. Tool calls that pass through Praesidia are recorded with the agent, the MCP server and tool, the arguments (subject to redaction), the policy decision and the task; navigation inside the browser that does not go through a governed tool call is not recorded. 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.