AI Agents in the Browser: What Changes, What to Secure

Since 12 August 2026, Claude has not stayed inside a separate chat window. It runs a full session directly in Chrome's side panel, inside the tab where the work already happens. That is not just a convenience. An agent that reads a web page reads everything it displays, including what was never meant for the user to see. This piece covers that shift, and what to secure because of it.

What changed on 12 August 2026?

On 12 August 2026, Anthropic turned the side panel of its Claude extension for Chrome into a full Claude Cowork session. A task started in a browser tab now continues in the desktop app without losing its history, skills or connectors, and the reverse holds too. Skills, plugins and connectors work directly in the browser for the first time, with no extra setup.

Access is immediate for Max and Team subscribers, with Pro access following in the weeks after. Several outlets confirmed how the handover between tab and desktop app works in practice, built on a single session shared across both environments.

Why is this more than an interface change?

We have already defined what an AI agent is elsewhere on this blog: software that plans, acts through tools, and observes the outcome to adjust its next move. What changes here is not its nature, it is its territory. It now operates inside the tab where the user is already browsing, with access to whatever the page displays and, potentially, to whichever connectors are active in that session.

That proximity is exactly what raises the security question. An agent reading a web page has no built-in way to tell content written for the user apart from content written for it. That is the point worth treating seriously, without overstating it.

What is prompt injection from a web page?

A page can carry discreet text written not for the person reading it but for the agent parsing it: a hidden comment in the code, white text on a white background, a block of metadata. That is what prompt injection from page content means.

If the agent treats that text as a genuine instruction, it can drift away from the task it was actually asked to do, without the user seeing it happen. This is not a theoretical risk. It follows directly from the fact that an agent reads everything a page displays, useful content and planted content alike.

What is connector scope, and why does it need limiting?

A connector gives the agent access to a specific tool: email, a CRM, a file store, a payment method. Now that skills, plugins and connectors work directly inside the browser, the practical question becomes: which tools can the agent reach while it browses a page nobody has vetted?

The wider the scope of active connectors during an open browsing session, the more an instruction planted on a page can actually do. Connector scope is a decision to make task by task, not a setting to configure once and forget.

What safeguards are worth setting up?

Three habits cover most of the risk, without slowing down everyday use.

• Separate sessions by sensitivity. Avoid keeping an agent connected to sensitive data active in the same tab where it is also browsing unfamiliar sites.
• Limit active connectors to what the current task needs, rather than letting a session accumulate access out of convenience.
• Never let an agent take an irreversible action without confirmation: sending, paying, deleting, publishing.

None of these require special tooling, just a habit worth building in from day one.

Should this hold a business back from using it?

No. These precautions are not a reason to avoid the tool, they are what a business deploying an agent seriously would do anyway. The direction is broader than one vendor too: several players in the sector are bringing their agents closer to the tools where work already happens, rather than keeping them confined to a separate chat window. The New Stack documented this shift towards continuous sessions between browser and desktop app.