A browser agent in a logged-in session inherits everything that login can reach. Judge the session, not the task, and default to no where irreversible or highly sensitive actions are available.
This series has spent three pieces establishing how an agent gets compromised and how far the damage can spread once it is. This piece applies that thinking to a specific, increasingly common setup: a browser agent operating inside a session where the person has already logged in, to email, to internal tools, to a CRM, sometimes to all three tabs at once. The honest governance question is not "how do we configure this safely." It is "should we allow this at all, and if so, for which tasks specifically." That question deserves an answer before the agent is given the keys, not after.
A logged-in browser session is not a neutral workspace. It is an accumulated set of permissions, cookies, and standing access that took a person months or years to build up, and a browser agent operating inside it inherits all of it at once, for whatever task it happens to be doing at the time.
When a person authorises a browser agent to act inside their logged-in session, they are not granting access to one task. They are granting access to everything that session can already reach: every tab the browser could open, every link the account is authenticated against, every action the interface allows a click to perform. The agent's task might be narrow, summarise this inbox, fill in this form, but its actual reach is the full breadth of what that login already permits, which is rarely narrow at all.
An API integration is built against a defined, documented set of endpoints; whatever it can do was decided in advance, by someone who wrote the integration. A browser agent in a logged-in session has no such boundary. It can click whatever the interface presents, follow whatever link appears, and act on whatever content loads into the page it happens to be reading, which is precisely the surface this series described in its pieces on prompt injection and blast radius. The browser does not distinguish between a link the person intended the agent to follow and one an attacker, or simply a poorly designed advert, put in its path.
A browser agent in a logged-in session does not just do the task it was given. It operates with the full reach of everything that login already permits, and the honest governance question is whether that reach, not the task, is one the organisation is actually willing to hand over.
Before allowing a browser agent into any logged-in session, ask what the session itself can reach rather than what the task requires, and set a default of no for sessions with irreversible or highly sensitive actions available unless there is an explicit, documented exception.
Before connecting an agent to a new system, ask what it could reach on its worst day. Grant access per task rather than per agent, and separate read, write and send, so one mistake stays contained.
Custom Agents & Tools · 4 minExplainer · 1 October 2026To an agent that reads it, any shared drive or ticket system many people could edit is untrusted content. Scope read access, curate trusted sources and log what the agent reads.
Custom Agents & Tools · 4 minExplainer · 1 October 2026Prompt injection hides instructions in content an agent reads, and OWASP ranks it the top LLM risk. A plain-language explanation, a vendor's own test figures, and layered defences any organisation can apply.
Custom Agents & Tools · 4 minIf this is the question on your desk, a thirty-minute call tells you whether the service fits, or that you do not need us yet.