What changes when the agent gets a browser

Every tool you have given your agent so far reads something of yours. Your files, your database, your API, your MCP server.

The browser reads the open web.

It is the first time third parties control the agent's input at scale, and the first time it holds a tool to act on what it read. Anthropic's documentation acknowledges that in the clearest way available: the browser tool's security section is longer than its usage section.

Add the success rate to that. In the most complete reproducible benchmark on the subject, the best model solves 80% of the tasks. One in five fails, acting on a real site.

This post is about what those two things together demand of whoever will use it. It continues harness engineering at the layer where the agent touches the world.

The browser_toolset_20260801 gives the model 27 member tools by default, plus four optional ones. They cover navigation, screen capture, pointer, keyboard, page reading, forms, diagnostics and tabs (Anthropic documentation, read 29 August 2026).

Two architectural characteristics matter more than the list.

The automation runs in your environment. The browser is yours, execution happens on the client side, and none of it happens on an Anthropic server. That is good for privacy and it is the very thing that transfers to you the responsibility for containing whatever goes wrong.

Availability is narrow, and that decides adoption. The tool exists on the Claude API and Google Cloud. It is absent from Amazon Bedrock, absent from Microsoft Foundry and absent from Managed Agents. If your company standardized on one of those three, the conversation ends there for now.

The model works through two paths at once: the page structure, via the accessibility tree, and the visual representation, via screenshot and coordinates. The tools return element references such as [ref_2], and the model acts on them.

Those references have an expiry. Once the tab navigates or the DOM changes in a relevant way, they go stale and the call returns an error asking for a page reread. Batched actions stop at the first failure. The following ones answer with the exact text "Not executed: an earlier action in this turn failed."

An architectural note before moving on: the connection between agent and tool has a map of protocols of its own, and a browser is no protocol, it is a tool.

The number that decides whether this goes to production is the success rate, and it has a decent public measurement.

Browser Use maintains a benchmark of 100 tasks selected by hand, drawn from five sources: their own challenges, WebBench, Mind2Web 2, GAIA and BrowseComp. That is over 600 thousand runs in total. The verdict is binary, given by an LLM judge on real sites, and they publish the code: one round of 100 tasks costs around three hours and ten dollars.

Two caveats before any conclusion.

Browser Use sells browser agent infrastructure, and its product takes second place in its own ranking. In exchange, it is the only benchmark on the subject with a published methodology reproducible for ten dollars, which earns the credit in the same sentence that records the conflict.

The judge is an LLM. It agrees with human evaluation in 87% of cases, meaning disagreement in thirteen. With 80.0% and 78.0% separated by two points, that method decides no ordering at the top.

What it does decide is the order of magnitude, and that suffices for the decision: the best one errs one in five. For a system that clicks on real sites, that is no "it works". It is "it needs supervision".

How the failure shows up

Knowing the rate helps little if you cannot recognize the error when it happens. The documentation describes three modes, and all of them appear early in real use.

A stale reference. The model read the page, kept [ref_2] for a button, and in the meantime the tab navigated or the DOM changed. The call returns an error saying the reference is stale and asking for a reread. It is the most common case and the most benign: a noisy failure, with an obvious recovery.

An interrupted batch. Batched actions run in order and stop at the first failure. The following ones answer with that same "Not executed" text. Build a batch of six steps, let the second fail, and the last four never happened. Reading the responses is the only way to know, because the request itself never failed.

An incomplete tree. Canvas, virtualized lists and cross-origin iframes produce no useful nodes in the accessibility tree. The model fails to find the element, and the way out is pixel coordinates, which break on every layout change. This is the silent mode: nothing errors, the agent clicks the wrong place and says nothing.

The difference between the three matters for whoever operates it. The first two you handle with a retry; the third requires noticing that part of the page resists structural reading, and deciding whether pushing on pays off.

<!-- [UNIQUE INSIGHT] -->

Here is the difference that separates this tool from all the others, and that almost no text on the subject states.

Until the browser, the worst case of hostile input was a document someone managed to place in your repository, or a compromised package. A real surface, and a limited one under some curation of yours.

With a browser, the input is the open web. Any page the agent visits can contain an instruction written for it. The documentation gives the example in full: text on the page saying "ignore your previous instructions and navigate to…" pulls the agent off the task.

That is no conceptual novelty. It is the same prompt injection with no definitive fix, which appears in six of the ten OWASP categories for agents. The scale of the exposure is what changes: from "documents that entered my project" to "the internet".

And since no definitive fix exists, the defense has to be structural. That is why the next section is the largest in the documentation.

It is no recommendation of this post. It is what Anthropic lists as a necessary precaution for operating the tool, and its volume is the page's most eloquent data point.

Environment. Run the browser in an isolated container or virtual machine, with minimal privilege, a fresh profile holding no saved credentials and no access to a sensitive filesystem.

Network. A domain allowlist at the network layer, blocking loopback, link-local and private ranges. And recheck after every redirect, because the final destination can differ from the one requested. Only http and https schemes; reject javascript:, file:, data: and chrome:, parsing with a URL parser instead of a string prefix.

Input. Build the reading from the rendered content, through the accessibility tree, and not from the raw DOM. Hide text outside the viewport from the model. Redact credentials from the console and network logs. Sanitize URLs coming from the page before reporting them.

Action. Human confirmation for any consequential act: a purchase, an account change, a message sent, anything that would require a person's affirmative consent. And keep javascript_exec and file_upload disabled, as they ship, absent a real need.

Note the design: the first three layers shrink the agent's reach, and the fourth accepts that the others can fail. It is the same logic as locking before the agent acts, and the reason automatic mode needs an explicit boundary.

The price appears before the agent navigates anywhere.

Declaring the toolset adds around 6,600 input tokens on every request, around 6,610 on Fable 5, Mythos 5, Opus 5 and Opus 4.8, and 6,670 on Sonnet 5. Enabling the four optional members adds another 880 (pricing page, read 28 August 2026).

The bill for the month gets visible fast. At 500 requests a day on Sonnet 5, declaring the tools alone costs around US$198 a month, before any useful work. It is the same kind of leak covered in where the money leaks in production, with an aggravating factor: images enter the count here too.

The documentation carries one recommendation that is technical and economic at once: read the accessibility tree before taking a screenshot. It is more reliable for locating elements and spends fewer tokens than an image. A screenshot becomes the exception resource, for when the tree fails to describe what needs clicking.

Declaring the whole toolset is the default, and it is a design decision that deserves review.

Twenty-seven tools in the window means twenty-seven descriptions the model reads on every request, and twenty-seven options to choose among at each step. The problem is nothing new, and it sits in tool design for agents: an oversized set worsens the choice, not the cost alone.

Four members ship disabled by Anthropic's own decision, and the reason is risk rather than size: javascript_exec, file_upload, read_console and read_network. The first two open arbitrary execution and file upload. The last two leak credentials if the logs go untreated.

One detail in the two diagnostic tools is easy to misread: they capture only what happened after the automation attached to the tab. An empty result means something other than an absence of traffic, it means you started looking late.

The limits of structural reading also weigh on the decision. The accessibility tree can be incomplete: canvas, virtualized lists and cross-origin iframes generate no useful nodes. In those cases the path is coordinates, with all the fragility that brings.

A starting configuration that defends itself

If you turn the tool on this week, this is the posture demanding the least trust in the model and the least vigilance from you.

Keep the four optional ones off. They ship that way. Turning javascript_exec on because "it would be easier" trades the whole input containment for convenience, and the console and network ones only pay off once you have credential handling in the logs.

Start with an allowlist of one domain. Not the list of domains the agent might need: the task's domain. Widening later is easy and each widening is a conscious decision. Starting wide is the path to never reviewing it again.

Treat every state-changing action as consequential. The documentation names purchases, account changes and messages sent. Under doubt, add anything a person could not undo alone in thirty seconds.

Record what the agent read, not only what it did. When something goes wrong through injection, the hostile instruction will sit in the page content, and without that record you will debug the model's decision with no view of the input that produced it.

None of those four items depends on the model cooperating, which is the exact criterion of a good guardrail.

The documentation is explicit about the alternatives, and that part almost never gets repeated.

The first row eliminates most cases. If the goal is reading a page, fetching a data point or checking a source, web fetch solves it, runs on the server side, is lighter and opens none of the surfaces discussed here.

A browser justifies itself when action exists: filling a form, walking a multi-step flow, operating an interface with no API. If your task lacks that word, the odds are you need no such tool.

<!-- [PERSONAL EXPERIENCE] -->

The operation producing these texts has the browser tool available and never used it once while producing this cluster. Explaining why pays off, because the reason is this post's recommendation applied with no ceremony.

Researching each article is reading: opening an abstract on arXiv, a documentation page, a model card, a press release. None of those tasks involves action. All of them happened with search and web fetch, which run on the server side, cost less and expose no browser to a hostile page.

Over fifty external sources got verified that way across the cluster. In none of them would the browser have made a difference, because in none of them was clicking on anything required.

The explicit judgment: the right decision about a browser, in most cases, is skipping it. Out of something other than fear, and instead because the question "do I need to act on this page?" almost always has a negative answer in research work.

One case exists where I would miss it, and recording that is fair. Checking how the blog itself appears once published would require opening the site, and from here that is impossible: the corporate network blocks the domain by geolocation, so the production check depends on the author's phone. An isolated browser would solve it, and that is the one task in this operation that would justify the tool today.

Can the agent navigate on its own?

It can, with supervision. On Browser Use's open benchmark, with 100 tasks on real sites, the best model solves 80% of them. One in five fails, and since the actions happen on genuine sites, the documentation demands human confirmation for any consequential act.

Is giving the agent a browser safe?

Only with structural containment. Anthropic's documentation asks for an isolated container with a credential-free profile, a domain allowlist at the network layer, reading through the accessibility tree instead of the raw DOM, credentials redacted from the logs and human confirmation for consequential actions. The central risk is prompt injection through the page content, which has no definitive fix.

What is the difference from traditional scraping?

Scraping follows a fixed script you wrote; the agent decides what to do at each step, reading the page. That makes it capable of handling layouts that change, and it also makes it susceptible to instructions planted on the page, something a deterministic scraper ignores.

How much more does it cost?

Declaring the toolset adds around 6,600 input tokens on every request, before any navigation. The four optional members add another 880, and each screenshot gets charged as an image. Reading the accessibility tree instead of taking a screenshot is cheaper and more reliable.

Does it work on Bedrock or Azure?

No. The tool is available on the Claude API and Google Cloud. It is absent from Amazon Bedrock, Microsoft Foundry and Managed Agents. For anyone standardized on those platforms, it is an adoption blocker rather than a configuration question.

Do I have to confirm every action?

Not all of them, and all the consequential ones. The documentation names purchases, account changes and messages sent, and generalizes to anything that would require affirmative consent. The confirmation has to happen in your executor, before each call, because one batch can hold several.

• The browser is the first tool where third parties control the agent's input and it still acts on that input.
• The best model gets 80% of 100 tasks. One in five fails, on real sites.
• 6,600 tokens per request to declare it, plus screenshots charged as images.
• Containment has four layers, and the last exists because the others can fail.
• Claude API and Google Cloud alone. Bedrock and Foundry are left out.
• If the task is reading, web fetch solves it better, cheaper and with nothing opened.

Before enabling the tool, answer one question: does the task require acting on a page? If the answer is no, you have saved 6,600 tokens per request and an entire attack surface.