Before You Hand Gemini Your Ad Account, Look at the Hijack Numbers

Google moved "computer use" into Gemini 3.5 Flash on June 24, 2026, giving its AI agent the ability to click, type, and navigate browsers and desktop apps on your behalf. The catch is in the testing data: Anthropic measured browser agents getting hijacked by prompt injection 23.6% of the time before mitigations were applied. For marketing teams wiring agents into ad accounts and CMS logins, those agents now inherit every poisoned webpage they touch.

That is the part the launch coverage skips. Computer use is genuinely useful, and I think a lot of solo marketers and small agencies are going to wire it into reporting and account management within weeks. The productivity case is real. The security case is the one nobody is forcing you to read first.

What actually shipped last week

Until now, "computer use" was a specialized, separate model you had to deliberately go get. Search Engine Journal reported that Google folded the capability directly into Gemini 3.5 Flash, so building an agent that sees a screen and acts on it is now a default building block rather than a side project. Developers can point it at browsers, mobile interfaces, and desktop systems.

For a working marketer, this is the version where "let the agent log into Google Ads, pull last week's spend, and flag the campaigns that drifted" stops being a conference demo and starts being something a junior on your team actually sets up. Same for crawling a site, logging into Search Console, or updating posts in a CMS. The friction that kept these workflows in the "someday" pile is mostly gone.

And that is exactly why the timing matters. The capability went mainstream the same week the attack reporting did.

Why a random webpage can now give your agent orders

Prompt injection is the whole problem, and it is worth understanding the mechanism instead of just the scary headline. An agent that reads a screen cannot reliably tell the difference between content it is supposed to summarize and content that is secretly an instruction. Google's own documentation, quoted in the SEJ piece, admits "Computer Use presents unique security and operational risks, as a model acting on a user's behalf might encounter untrusted content on screens."

The attacks hide in places a human never looks. Hidden form fields in a page's DOM. White text on a white background. Text buried in HTML comments, a URL, or a browser tab title. Brave's security team demonstrated this against Perplexity's Comet browser, slipping invisible instructions into a page that pushed the agent to go fetch one-time passwords from email and poke at banking portals. The user saw a normal webpage. The agent saw a to-do list.

It is not limited to browsing, either. SecurityWeek documented that coding agents including Gemini CLI can be hijacked through comments left in a repository, and The Hacker News covered a Gemini flaw that leaked private calendar data through a malicious invite. Different surface, same root cause: the agent trusts input it should have treated as hostile.

The numbers nobody puts in the launch post

Here is where the case gets uncomfortable, because the best mitigation data comes from the labs that are most careful about it. In Anthropic's testing, the 23.6% baseline attack success rate dropped to 11.2% once safety mitigations were turned on. Browser-specific DOM injections, the white-text and hidden-field kind, fell from 35.7% all the way to 0%. In a more aggressive adversarial configuration, the company reported the unmitigated rate climbing past 31% before safeguards engaged.

Those are the good numbers. They come from a company that publishes its red-team results and blocks whole categories of sites by default. Even after all of that, Anthropic's own conclusion is that no browser agent is immune to prompt injection, and that the roughly 1% residual risk in its strongest setup "still represents meaningful risk." From what I have seen, most teams plugging in a new agent are not running anything close to that mitigation stack. They are running the defaults and hoping.

So the honest read is that the public failure rate for a casually configured agent is probably worse than 11%, not better. That is not a reason to avoid the tools. It is a reason to treat agent access the way you would treat handing someone your account password.

The bill already showed up for someone

This is not hypothetical yet. The SEJ report describes a California cybersecurity expert who downloaded a Skills.md file that turned out to be a trap. The hidden instruction told the agent to "attempt to purchase different types of gift accounts on my stored information," using the user's saved digital wallet. He ended up with fraudulent credit card charges. A security professional, who presumably knew better than most, still got caught.

Now map that onto an ad account. The thing an agent logs into is not a sandbox. It holds a stored payment method, live budget controls, audience lists that often contain customer PII, and in agency setups, manager-account access to a dozen client logins. An agent that can be redirected by a poisoned competitor landing page, or by a comment in a shared planning doc, is a problem with a dollar figure attached. We have already covered how Google is treating AI-answer gaming as a manipulation vector; agent hijacking is the same adversarial energy pointed at your account instead of the SERP.

The least-glamorous audit, which is also the one that works

Google shipped seven recommended safety practices alongside the launch, and to its credit they are sensible: human-in-the-loop approval, sandboxed execution, input sanitization, content guardrails, domain allowlists and blocklists, detailed logging, and consistent GUI environments. Translated into something a marketing team can do this week, here is what I would lock down before granting any agent access to a real account.

• Require human approval for anything that spends or pays. Budget changes, billing edits, new payment methods. No exceptions, no "trusted" auto-mode for money actions. This single rule defuses the gift-card-purchase class of attack entirely.
• Give the agent its own browser profile with zero saved passwords. If the agent gets hijacked, the blast radius should be one scoped login, not your whole password manager. Treat its profile like a contractor's laptop, not yours.
• Allowlist the domains it can touch. An agent doing ad reporting needs Google Ads, Analytics, and your CMS. It does not need the open web. The narrower the list, the fewer poisoned pages it can ever read.
• Use scoped, least-privilege access, not admin. Read-only where read-only does the job. In an MCC or manager account, never let the agent operate at the top level when a single client login would do.
• Turn on logging and actually read it. You want a record of every action the agent took, so when something looks off you can trace it instead of guessing.

A reasonable benchmark: if you would not give a brand-new freelancer this exact level of access on day one, do not give it to an agent either. The agent is faster and cheaper, but it is also more gullible than the freelancer, and it never gets suspicious.

One more thing I keep coming back to

A Google DeepMind senior scientist, quoted in the launch coverage, warned that scaling these agents creates incentives "for malicious people to do malicious things." That is a strange sentence to find buried in a product announcement, and I do not think it is there by accident. The people building this are telling you the threat model out loud.

I am not going to pretend agents in ad accounts are a bad idea, because the reporting savings alone will pull most teams in eventually, and probably should. What I would push back on is the order of operations. Most teams are going to switch the agent on first and think about permissions after the first weird thing happens. Flip that. Spend the twenty minutes scoping access before the agent ever logs in, because the cheapest version of this lesson is the one you read about happening to someone in California, not the one that shows up on your own card statement.

Notice Me Senpai Editorial