What should you let a browser agent do on your own site?

What should you let a browser agent do on your own site?

Start with work that is reversible, visible, and boring. Reading, drafting, checking, and reporting are safe places to begin. Publishing, spending, and anything touching customer data should stay behind a human confirmation until you have a review trail you trust.

This question arrived in my work faster than I expected. Clients are not asking whether AI can use a browser any more. They are asking whether to let it into the CMS, the ad account, and the CRM, and nobody wants to be the person who said yes to the wrong thing.

The useful news is that at least one vendor has published numbers on what goes wrong, which gives us something better than instinct to reason with.

What is a browser agent actually doing when it works for you?

It is reading the page you are on, deciding what to click, and typing into fields as if it were you. Anthropic describes exactly that for Claude in Chrome, saying the ability to see what you are looking at, click buttons, and fill forms is what makes it useful. Your session, your permissions, your consequences.

That last part is the part people skip. A browser agent inherits whatever you are logged into. If your browser has a live session for your CMS, your analytics, your email, and your billing, then the agent is operating inside all of those at once unless something stops it.

Anthropic's own list of internal uses in that post is a fair picture of the current sweet spot. Managing calendars, scheduling meetings, drafting email responses, handling routine expense reports, and testing new website features. Notice how much of that is drafting and checking rather than committing.

What do the published numbers say about the risk?

They say the risk is real and measurable. Anthropic ran 123 test cases representing 29 different attack scenarios against Claude in Chrome. Browser use without their safety mitigations showed a 23.6 percent attack success rate when deliberately targeted. With mitigations applied in autonomous mode, that fell to 11.2 percent.

The attack in question is prompt injection, where instructions are hidden in a page, an email, or a document so that the agent obeys the attacker instead of you. Anthropic's published example is a malicious email claiming that emails needed to be deleted for security reasons, which an unmitigated Claude followed, deleting the user's mail without confirmation.

I have a lot of respect for a vendor publishing that second number rather than only the improved one. An 11.2 percent success rate against deliberate attack is progress from 23.6 percent and it is not zero, which is the honest way to read it. Plan for the residual risk rather than pretending a fix exists.

Which tasks are safe to hand over first?

Hand over anything where a mistake produces a bad draft rather than a bad outcome. Pulling numbers into a summary, checking whether a page renders correctly, finding broken links, drafting a reply for you to send, comparing two dashboards. Each of those fails loudly and privately.

In my own practice the first genuinely useful browser tasks were verification tasks. Does this page look right on a phone, does this form submit, did this redirect land where it should. That work is tedious, needs eyes rather than judgement, and produces a report nobody acts on until a human reads it.

The second category is assembly. Gathering the state of things from several places, whether that is Google Search Console, your analytics, and your CMS, and writing it into one place. Reading widely and writing narrowly is a good shape for agent work, and it is also the shape with the least blast radius.

Which tasks should stay manual for now?

Keep publishing, spending, permissions, and anything involving personal data on a human confirmation. Anthropic's own defences treat this category the same way, asking users before high risk actions like publishing, purchasing, or sharing personal data, even for people who opted into an experimental autonomous mode.

My line is simple. If undoing the action requires an apology, it needs a person. Publishing to a live site qualifies, because a wrong page can be cached, crawled, and quoted before you notice. Sending email to a list qualifies for the same reason, only faster.

Money is its own category. Anthropic says it blocked Claude from using websites in certain high risk categories such as financial services, adult content, and pirated content. When a vendor removes a category from its own agent's reach, treat that as a hint about where the sharp edges are rather than as a limitation to work around.

How should you scope credentials for an agent?

Give it the narrowest access that completes the job, in a separate browser profile, with nothing extra logged in. The agent should not be able to reach systems the task does not need, because prompt injection turns any reachable system into part of the attack surface.

A separate profile is the cheapest control available and almost nobody uses it. If the profile the agent works in has a session for your CMS in read mode and nothing else, then a hidden instruction telling it to change your billing details has nothing to act on. Same instruction, no reachable target, no incident.

Site level permissions help here too. Anthropic's page describes users granting or revoking access to specific websites at any time in settings, and its December 2025 update says that for Teams and Enterprise, admins can enable or disable the extension organisation wide and configure site allowlists and blocklists. Check the vendor's current documentation before you rely on any specific control, since these details move. The principle behind it does not move, and it is the same principle as giving an agent the narrowest credential that works.

What does a review trail look like for agent work?

It looks like a record you can read after the fact without reconstructing anything. What the agent was asked, which pages it touched, what it changed, and who approved the change. If you cannot answer those four questions later, the agent is not audited, it is just trusted.

For anything that writes, I want the change to arrive as a proposal. A draft item, a pull request, a row marked ready for review. The agent produces, a person releases. That pattern costs almost nothing in speed and it converts an incident into a rejected suggestion.

Accountability is the part teams settle last and should settle first, because the answer determines who reads the trail. I wrote about this specifically in the context of who is accountable when an agent acts on your site, and the short version is that a named human owns every agent action or nobody does.

Does this change how you build your own site?

Yes, in two ways. Anything a machine will operate should be operable without guessing, and anything untrusted on your page should be treated as potentially hostile input. Clear labels, honest button text, and predictable flows help agents for exactly the reasons they help people.

The second half matters more than it sounds. If your site renders user generated content, review copy, or anything pulled from an external feed, you are publishing text that a visiting agent may read as instructions. That is not a reason to panic. It is a reason to know where untrusted text appears on your pages.

On the build side, a clean Webflow or any well structured site is already most of the way there. Real headings, real labels, forms whose fields say what they are. I compared how different browser agents behave against real client work in a piece on using Claude in Chrome and ChatGPT Atlas for daily standups, and the sites that fared best were the ones built for humans who skim.

Where does this leave the agentic browser promise?

Somewhere useful and unfinished. The reading, checking, and drafting half is genuinely valuable today. The acting half is improving and still carries measurable risk, which is why every serious vendor ships permission prompts rather than a single trust toggle.

My honest position is that the constraint is not model capability. It is that we do not yet have good shared habits for delegating authority to software that can be talked into things. Permissions, narrow profiles, and human release steps are those habits in their early form.

Anyone selling you a browser agent that needs no supervision is selling confidence rather than engineering. The vendors publishing attack success rates are the ones taking the problem seriously.

What should you do next?

Pick one task this week that is reversible and tedious, give the agent a separate browser profile with only what that task needs, and require a human to release anything it writes. Then write down what it touched. That single loop teaches you more than any policy document.

If you want help deciding which parts of your stack an agent should reach and which should stay human, that is the kind of automation design work I do most weeks. Tell me what you want to delegate and I will tell you where I would draw the line. Let's chat.