The Risks When Chrome Becomes a Silent AI Runtime
Key Takeaways
- We demonstrated successful prompt injection of Chrome's built-in AI workflows: We showed how text on a webpage, when processed by Chrome's Summarizer and Writer APIs, and Chrome’s former on-device Scam Detector (since replaced by a cloud model in Chrome 156), can redefine tasks and change the intended behavior of the local models. A core problem is that trusted instructions and untrusted content ultimately have to be interpreted by the same language model.
- Chrome AI is prone to parasitic computing of the user's resources: Any website can silently harvest a visitor's compute through the Chrome inference APIs at an average of 30 tokens per second. The per-visitor-hour value is comparable to browser cryptomining malware, which browsers considered abusive enough to build throttling, detection, and blocking against.
- Silent attacker tool calling as a future risk: Chrome’s experimental tool-calling prototype, when prompt injected, can allow an attacker to trigger the tools a web application has declared, with no permission gate, in an attack known as Return-to-Tool (RTT). This attack was previously shown against cloud agents and MCP, and the browser version needs only a page visit. It is not confirmed in the wild, and it depends on how a given site implements tool calling.
- Granular user and enterprise security controls are limited: Inference happens in the background with no model for consent, no indicator it is being used, no rate limiting, and no clear way to control which origins are allowed, which tools may be called. Available security tools today are not granular and take an all-or-nothing approach.
Every desktop running Chrome is now an AI runtime. Google's Optimization Guide component quietly downloads a Gemini Nano language model, approximately 4.27 GB, to qualifying installations and exposes it to any website the user visits through JavaScript APIs. This happens with no notification, no consent prompt, and no in-browser indicator. Once downloaded, any HTTPS site can invoke the model without additional user action or approval.
This is not a software bug and no CVE applies. What TrendAI™ Research found and measured across live Chrome installations are properties of the current design, and they have meaningful consequences for any organization whose employees use Chrome on a managed or unmanaged desktop.
A new kind of browser risk
Chrome's on-device AI inverts the assumptions that protect cloud-hosted AI services. Cloud APIs carry authentication tokens, generate audit logs, and enforce rate limits. Chrome's local model has none of these: no API keys, no logs, no rate limits, and the interface is available to any website the user visits. The person invoking the model is not the person at the keyboard. It is the JavaScript code on whatever page they happen to be viewing, which could be authored by an attacker.
TrendAI™ Research recovered the verbatim system prompts for Chrome's AI features from their on-disk configuration files and confirmed them against Chrome's own inference logs. After measuring inference throughput across a range of devices and analyzing the tool-calling architecture from the Chromium source code, three risks emerged: Two are active today on eligible Chrome 138 or later installations: prompt injection against the Summarizer and Writing Assistance APIs, and parasitic computing. The third remains behind an experimental flag that is moving toward general availability. Our scam-detection findings apply to the earlier on-device implementation, which Chrome 156 replaced with a cloud-based model.
Risk 1: Prompt injection against Chrome's AI features
Chrome's AI features combine a system prompt with content from the webpage the user is viewing. Both enter the same context window and are interpreted by the same model. The model is not bound to treat system instructions as authoritative over page content. An attacker who controls the page controls part of what the model reads.
TrendAI™ Research tested this against three Chrome features, starting with the on-device Scam Detector. When we tested it, its output fed Google’s Enhanced Safe Browsing to help classify whether a page is a scam or phishing site. Its system prompt contained no injection defenses, and page text was concatenated directly after a literal “Text:” marker. A task-redefinition payload, not a blunt “ignore your instructions” directive but a plausible-sounding clarification of how to classify login pages, achieved a 100% bypass rate. It flipped both the brand identification and intent classification fields that feed the Safe Browsing server-side verdict.
As this research was published, Google announced fundamental changes to scam detection. Chrome 156 and later use a cloud-based AI model instead of the local one. Google has also said it is exploring solutions to potential exploits such as prompt injection in content. Injection against a cloud-hosted model is likely more difficult than against the local model we tested. We include these results because they show how an architecture with no privilege boundary fails when a model’s output feeds a security decision.
The Summarizer API includes an explicit defense: an instruction telling the model not to answer questions it finds in article text. That defense blocks exactly the injection class it names and no others. Task redefinition, format-breaking, and direct instruction override each succeed. A defense that enumerates its threats is only as broad as its enumeration.
The Writing Assistance API goes furthest, declaring its system parameters as non-negotiable with highest authority. Every attack we measured defeats that declaration. Naming a parameter as highest authority does not prevent the model from following conflicting instructions embedded in page content.
The underlying limitation is architectural. A roughly 3.25-billion-parameter on-device model cannot reliably distinguish trusted instructions from untrusted content when both arrive through the same channel with no enforced privilege boundary. That is a property of current language-model architectures, not a defect specific to Chrome's implementation.
Risk 2: Parasitic computing
Any website on HTTPS can silently drive Chrome's on-device inference against a visitor's hardware. No user trigger is required after the initial model download. The engine stays loaded when the tab moves to the background. No throttling was observed across multiple test sessions, and the Chromium source confirms the absence of per-origin rate limiting on the inference path.
We measured throughput across a representative range of devices: integrated-GPU laptops average around 5 tokens per second, mid-range laptop GPUs reach approximately 30, and high-end machines approach 60. At 30 tokens per second, one visitor produces roughly 108,000 tokens per hour. Using mid-2026 cloud inference pricing for comparable 3-billion-parameter models, that yields approximately $0.009 per visitor-hour in avoided cloud cost — nearly identical to what academic studies measured for Coinhive at its peak.
Coinhive was a JavaScript cryptomining file that websites included to mine Monero on visitors' CPUs. At its peak, it was present on approximately 50,000 websites and generating around $24,000 per week for operators. Browsers responded with throttling, detection, and blocking that contributed to Coinhive's shutdown in March 2019. The per-cycle economic value of Chrome's on-device inference is comparable. The countermeasures are not.
To make this concrete, we built TokenHive, a proof-of-concept client-server system in which visitors to a page running the TokenHive JavaScript silently connect as inference nodes. The server dispatches prompts; each client processes them using Chrome's Summarizer or Prompt API and returns results through an OpenAI-compatible endpoint. An operator running such a system would pay nothing for compute, because the visitors' hardware provides it.
This attack vector is not confirmed in the wild. The injected content can only trigger tools that the page developer has declared, and we have not demonstrated the full chain end to end, because it depends on how a specific website implements tool calling.
The key finding is not that parasitic compute harvesting is a viable business model today. It is that the governance boundary is absent. The same primitive that browsers classified as abuse in 2017 can now operate without the countermeasures that drove that earlier form of abuse off the web.
Risk 3: Return-to-Tool
Chrome's experimental tool-calling feature extends the Prompt API to let web applications declare functions the model may invoke, with the model deciding when to call them. This pattern, in which injected content causes a model to call its own authorized tools against the user it serves, is known as Return-to-Tool, and TrendAI™ Research has previously demonstrated it against cloud-based agents and exposed MCP servers. The browser extends the same attack path to any website a user visits.
Whether that path is reachable depends on how Chrome has gated the feature: From Chrome versions 138 through 143, enabling the Prompt API also enabled tool calling. From version 144, the two were split into separate flags. Tool calling remains experimental on the current stable build, and a default user cannot reach it without enabling experimental features. If tool calling follows the base Prompt API into general availability, the attack path below becomes reachable by any website.
An attacker can plant text on a webpage that frames a tool call as already authorized by the user; the model then returns that tool call with attacker-chosen arguments, and the page executes it, producing a real consequence like a sent email, exfiltrated data, or an internal API call from the page's own authenticated origin.
Schema validation doesn’t close this gap. An argument can be correctly typed and structured while carrying an attacker's value. No confirmation prompt gates tool calls under the current design, unlike the camera, microphone, and geolocation APIs, which require explicit user permission before access is granted. Hardening the model's sandboxed process does not address this risk either, because the network operation is performed by the page's own JavaScript. The risk sits one layer up: at whether the page executes tool calls and with what arguments.
Security recommendations
No patch resolves these risks, as they are properties of the current design. The controls available today are broad rather than precise, and the governance gap will widen as tool calling moves toward general availability.
For CISOs and enterprise security teams
- Decide whether the model stays enabled. The GenAILocalFoundationalModelSettings policy blocks the download and deletes any existing local copy. It is the only control with real scope, and it is all or nothing. The
BuiltInAIAPIsEnabledpolicy separately blocks use of the Built-in AI APIs, but it also offers no per-site or per-API control. - Audit internal web applications for Chrome's built-in AI constructors. Any application that passes web-fetched or user-generated content through them inherits the injection risks documented here. Restrict APIs that should not invoke inference using Permissions-Policy response headers.
- If the model stays enabled, document the residual exposure explicitly: any visited site can run silent inference with no consent prompt, indicator, or rate limit.
- Update endpoint threat models to treat any managed Chrome desktop as an AI runtime reachable by any visited website, alongside other compute-abuse vectors.
For application developers
- Never render model output via innerHTML — use textContent. Model output can contain script tags that innerHTML executes as XSS.
- Schema validation confirms an argument's type, not its legitimacy. Check every tool-call argument against an allowlist of permitted recipients, URL prefixes, and actions.
- Treat on-device model output as untrusted input and give it the same validation and sanitization as raw form data before placing it in SQL, shell commands, URLs, or eval().
- Implement application-level rate limiting. The browser sets no per-origin limit — add your own ceilings on calls per minute and tokens per session.
- Do not use on-device AI for security-critical decisions without independent, non-LLM corroboration. Our scam-detector tests, run against Chrome’s former on-device implementation, show why: model output that feeds an authentication, moderation or safety decision needs independent verification.
For model providers
- Ship per-origin consent and a visible in-use indicator before inference runs, matching the model that already governs camera and screen-share access.
- Enforce a privilege boundary on existing role tokens. Delimiters are present in the current design; enforced privilege is not.
- Encrypt prompt configuration files at rest. They are signed but stored unencrypted, so any process running as the user can read and tamper with them.
- Gate tool calling. Require user approval for tool declaration and per-call confirmation for tools that send, delete, modify, or share data.
- Ship fine-grained enterprise controls. Per-origin and per-API allow/deny lists, plus audit logging of inference invocations on managed desktops, are a necessary replacement for the all-or-nothing policy pair that exists today.
Download the full report here .
AI Skills as an Emerging Attack Surface in Critical Sectors: Enhanced Capabilities, New Risks
Unconventional Attack Surfaces: Identity Replication via Employee Digital Twins