Google Handed Its Agent Your Saved Passwords

Google began rolling out Chrome browsing for Gemini Spark in the US on August 3, 2026, to AI Pro and AI Ultra subscribers. The agent can now complete web tasks on your behalf — researching flights and starting a booking, scheduling apartment viewings, working through multi-step forms.

The consequential detail is how it authenticates. Google's documentation describes two modes. In the first, Spark drives a remote browser in the cloud; when a site demands a sign-in, the task stops and waits for you. In the second, Spark drives your own local Chrome, where it has access to every site you are signed into — and to your saved passwords.

The second mode is the product. The first mode is a browser that gives up at the login wall, which is where most useful tasks begin.

Google says it has built safeguards, including protections against prompt injection — hidden instructions on malicious sites or in user-generated content that attempt to redirect the agent toward unwanted actions such as financial transactions or data theft. For sensitive steps like payments, Spark hands control back to you.

Those safeguards are real work by serious people. They are also mitigations for a problem that has no known solution.

Prompt injection is not a bug being patched

The reason prompt injection remains unsolved after three years of concentrated effort is architectural, not a matter of insufficient filtering.

A language model consumes a single stream of tokens. Your instruction — book me a flight to Lisbon — and the contents of the page it fetches arrive in the same channel. There is no hardware privilege bit, no memory boundary, no type system that marks one span as trusted command and another as untrusted data. The model infers that distinction from context, which means the distinction can be attacked with context.

That is not a class of bug that gets fixed. It is a property of how the systems work. Classifiers, instruction-hierarchy training, and provenance tagging all reduce the success rate of known attack patterns. None establishes the boundary in the way that memory protection or same-origin policy establishes one — because there is no mechanism in the architecture to establish it.

Now add credentials. An agent with your session cookies and your password manager is not merely a program that can be tricked into saying something wrong. It is a program that can be tricked into acting as you, against every service you are logged into, with every authorization you hold.

The blast radius of a successful injection is no longer a bad answer. It is your email, your bank's web interface, your employer's SaaS tenancy, and any account that treats an authenticated browser session as proof of identity.

The handback is doing a lot of work

Google's most substantive mitigation is procedural: for sensitive steps such as payments, Spark returns control to the human.

This is the right instinct, and it is worth being clear about its limits.

It depends on a correct classification of "sensitive." Payment is easy to detect — there is a checkout flow, a card field, a confirm button. The dangerous actions in a compromised session are frequently not payments. Adding a mail forwarding rule. Changing a recovery email. Granting an OAuth application persistent access. Exporting a contact list. None of those looks like a transaction, all of them are catastrophic, and each is a documented step in real account-takeover chains.

It also depends on human vigilance surviving routine. Every confirmation dialog that appears frequently and is nearly always benign trains the user to approve it. That is not a hypothetical failure mode; it is the entire history of security prompts on consumer platforms. An agent good enough to be used daily will generate handbacks often enough for them to become reflexive.

And it depends on the user being able to evaluate what they are approving. Confirming a payment after fifteen agent steps you did not watch requires trusting that the preceding fourteen were what you asked for.

Two philosophies, one week apart

Two days before this rollout reached wider notice, Cloudflare shipped a browser designed for agents rather than people — a separate execution surface with its own identity and its own permissions, on the premise that agents should not be borrowing a human's session at all.

Set the two approaches side by side and the design question is stark.

Google's is delegation by impersonation. The agent inherits your identity wholesale, which is why it works on every site immediately, with no integration and no cooperation from any service. Universal reach, undifferentiated authority.

The agent-first approach is delegation by scoped credential. The agent gets an identity of its own, distinguishable to the sites it visits, revocable independently, and auditable separately from your own activity. Narrower reach — it requires the ecosystem to recognize agent identities — but a compromise that can be contained and revoked without resetting your entire digital life.

The first is available today and works everywhere. The second is the one that has an answer for what happens after something goes wrong.

What is actually being tested

Google is not reckless here. Spark's protections are more developed than most of what shipped in the agentic-browsing wave of the last year, the cloud mode exists precisely so credential-free tasks stay credential-free, and the payment handback is a genuine constraint rather than a disclaimer.

But the shipping decision encodes a bet: that mitigations can hold the line on an unsolved problem long enough for the utility to be worth it, at consumer scale, with real credentials, in a threat environment where the attacker only has to find one page the classifier has not seen.

Attackers do not need an average-case win. They need one crafted page, indexed and waiting, and a single agent that follows it.

The honest framing is that a very large, very capable company has decided the convenience is worth the exposure, and is running the experiment on paying subscribers. That may turn out to be correct. It is not the same thing as the problem being solved, and the marketing language around "protections against prompt injection" should not be read as though it were.