7 min read Agent Security

Browser agents: it isn't the password that exposes you, it's the session

Browser agents: it isn't the password that exposes you, it's the session

Google announced on 30 July 2026 that Gemini Spark now integrates directly with Chrome. The official post is unambiguous: with your permission, Spark can use your logged-in accounts and saved passwords to handle tedious web errands. The technical shift sits right there. The agent no longer works inside a remote browser run by the vendor, where any sign-in prompt stopped the task, but inside the Chrome installed on the machine, using the session the user already has open. The rollout started in the United States, with expansion to other regions announced.

Coverage focused on the passwords, and that is a misreading worth undoing. The security documentation published by the Chrome team is explicit: the model does not have direct access to stored passwords, and a user confirmation is required before Chrome signs in through the password manager. The credential, in other words, is protected by a mechanism that works. What is protected by nothing is the session that follows. Once authentication has happened, there is no further checkpoint: no per-action reauthorisation, no distinction between the human and the agent, and on the SaaS provider's side the request looks exactly like the employee's.

The 13 July article on access control for AI agents handled the problem the usual way round, with an agent calling APIs inside a perimeter defined by a scope, revocable and logged. The case described here is the exact inverse: the agent has no perimeter of its own, it inherits the machine's entire authenticated context, corporate single sign-on included, without passing through IAM and without leaving a distinct trace at the provider. What follows covers that inversion, the real state of the defences, and where the control point has moved.

A cursor moves freely between several already-open applications in a browser, while a control gate sits unused to one side.
The agent gains no new rights, it works inside the ones that were already open.

A perimeter inherited rather than granted

The difference between the two threat models fits in one sentence. An agent calling an API holds a token whose scope, lifetime and rights you chose, and every call shows up in a provider-side log under an identity of its own. An agent driving the user's browser holds everything that user is signed into at that moment, for as long as those sessions live, with that user's rights. The first perimeter is granted, the second is inherited. Nothing declares it, nothing bounds it, and nothing afterwards lets you separate, in the logs of an HR tool or a cloud console, the person's actions from the agent's.

Google does not play this down, which is what makes its documentation worth reading. The Chrome security team's post, published in December 2025, puts it in a security engineer's terms: an unrestricted agent that is compromised and can interact with arbitrary sites effectively creates a Site Isolation bypass, with severe impact when the agent runs in a local browser like Chrome, leaving logged-in sites vulnerable to data exfiltration. The vendor itself describes the risk class, and ships an architecture to contain it.

The pattern taking shape in the field looks a great deal like browser extensions a decade ago. A tool installs on the endpoint, at the user's request, for a real productivity gain, and by construction it obtains more reach than any integration approved through an architecture review. The difference is that an extension ran fixed, auditable code, whereas an agent runs a plan reformulated for every task, from content it reads on pages it did not choose.

Serious defences, and explicitly incomplete ones

Credit is due to what has been built. Chrome describes a layered defence going well beyond a warning in a dialog box. A separate model, the User Alignment Critic, vets each action the planner proposes and can veto it; that component sees only metadata and never raw web content, which makes it unpoisonable from the page. Agent Origin Sets extend origin isolation into the agentic world, distinguishing origins the agent may read from those it may act on, and withholding out-of-scope content from the model entirely. A deterministic list of sensitive sites, banking and health among them, triggers a confirmation before navigation. A prompt injection classifier runs alongside inference. A bug bounty pays up to $20,000 for a demonstrated breach of these boundaries.

Those same documents show where the subject actually stands. Chrome writes that the initial implementation of origin gating is simplified and tracks only the read-writeable set, and that security for web agents remains an emerging domain. Indirect prompt injection is named as the primary new threat facing all agentic browsers, with no brand exempted.

Independent research bears out that caution. At Black Hat USA 2026, Artem Chaikin, a security engineer at Brave, presented a session on attacking and defending AI browsers, with demonstrations against Opera's AI browser, Perplexity Comet and ChatGPT Atlas. His conclusion, as reported by Dark Reading on 5 August, is that every browser he analysed proved vulnerable to prompt injection, including those combining strict system-level prompts, untrusted content tagging, a secondary verifier model and human approval. One detail from that talk is worth carrying into any product comparison: free users hitting a usage cap could be downgraded to a model more susceptible to injection. The agent's robustness therefore depended on its pricing tier. Chaikin concludes that no perfect solution is currently known, each layer reducing risk without removing it.

Comparison between a perimeter granted by API token and a perimeter inherited from browser sessions.
Two ways for an agent to obtain rights, only one of which leaves a usable trace.

The control point moved to a different console

The organisational consequence is the one most often missed. Many companies built their AI governance around vendor contracts, API keys and a committee that arbitrates use cases. None of those levers reaches an agent running in an employee's own Chrome, on a managed device, with a corporate session open. The lever that reaches it is managed browser policy.

Chrome Enterprise exposes policies for exactly this, applicable per organisational unit. The broadest, GenAiDefaultSettings, takes three values: allow generative AI features and let interactions improve the models, allow them without that contribution, or disallow them. A dedicated Gemini policy takes precedence over that default when it is set, and other policies govern specific surfaces such as the address bar AI integration. These settings are managed from the admin console, under user and browser settings, organisational unit by organisational unit.

The question to settle is therefore not whether the company allows agents, it is which organisational unit carries which value, and who decided it. In most organisations the answer is that nobody decided and the default applies. That is exactly the mechanism the 23 July article on governing agentic risk described from the angle of runtime authorisation: a capability arrives through a channel the governance apparatus does not watch, and the absence of a decision serves as one.

What to put in motion this week

Inventory what is already running. List the browser extensions and agents present across the fleet, using managed browser telemetry rather than a questionnaire. An agent missing from that inventory is not absent, it is merely invisible.

Set the browser's generative AI policy explicitly, per organisational unit, instead of letting the default stand. The decision can be permissive, but it has to be written and dated, with a named owner.

Separate the work profile from the profile an agent is allowed to operate in. That is the mitigation Brave chose for its own browser, with personal accounts logged out by default, and it is the only measure that breaks session inheritance at the root rather than trying to filter it.

Turn off credential autofill for agent-driven sessions, and draw up the list of domains barred from automation: banking, payroll, HR, cloud administration, signature tools. A deterministic list maintained by your company beats a sensitive-site list maintained by a third party for the general public.

Move logging to the proxy rather than the agent. That is the only place you will see the traffic whatever application produced it, and the only way to answer, later, whether a human or an agent triggered an action.

Finally, add one question to the selection file for any browser agent: what is the floor model, and what happens when a quota is hit? The answer determines the real security level of the product you are deploying.

Conclusion

The shift under way is easy to state and expensive to ignore: for two years agent security played out on the server side, inside the perimeter of tokens and API permissions, and it now also plays out on the endpoint, in a space where your identity management has no grip. Vendors are building real defences and describe the work themselves as unfinished, which is the honest position. That leaves companies with a responsibility they cannot delegate, and one concrete lever whose value most of them have not yet set.

Sources: As of August 2026

Godwin AVODAGBE