Google presents a multilayered security vision for agentic browsing capabilities in Chrome, focusing on the most prominent threat facing browsers capable of carrying out tasks automatically: indirect prompt injection. This type of attack can appear inside malicious websites or third-party content in iframes or user reviews, then prompt the agent to carry out actions that do not align with the user’s goal, such as initiating financial transactions or exfiltrating sensitive data.
Google says Chrome’s secure agentic browsing design benefited from collaboration with the company’s security experts, as well as existing protections in Gemini and agent security principles. The proposed architecture combines deterministic and probabilistic defenses, with the aim of making exploitation of the agent more difficult and costly while keeping the user in the loop when consequential actions are performed.
An Independent Model for Reviewing Agent Actions
Gemini relies during the planning stage on page content shared with it by Chrome to determine the next step. However, this content is inherently untrusted, leaving the planning model vulnerable to attempts to influence it and alter the course of the task. Google uses techniques such as Spotlighting to direct the model to prioritize user and system instructions over instructions contained in the page, and has also incorporated known attacks into Gemini’s training to help it avoid them.
To add another layer, Google introduces a component called User Alignment Critic, a separate model built using Gemini that operates as a highly trusted component. This model comes after planning is complete to inspect every proposed action and focuses on a specific question: Does the action serve the goal specified by the user? If it considers the action misaligned with the goal, it can reject it.
This component does not see unfiltered web content; instead, it views metadata associated with the proposed action. This architecture gives it less context, but keeps its task simpler and more isolated from harmful content: approval or rejection. When an action is rejected, the critic sends its feedback to the planning model to rework the plan, while the system can return control to the user when failures recur.
Restricting the Scope of Sites the Agent Can Access
Google extends the principles of site isolation and the same-origin policy to the agent environment through the concept of Agent Origin Sets. Agents need to work across more than one site, such as collecting components from one site and then filling a shopping cart on another, but giving a compromised agent unrestricted ability to interact with arbitrary sites could turn it into a pathway for bypassing site isolation and leaking data from local authenticated sessions.
A trusted control function identifies the origins associated with the task and divides them for each session into two clear groups:
- Read-only origins: Gemini is allowed to consume their content, while iframe content is not shown to the model if its origin is not included in this group.
- Read-write origins: The agent is allowed to read from them and perform actions on them, such as clicking and typing.
This separation limits the possibility of passing data between origins unrelated to the task, and also allows the browser not to send data outside the read set to the model in the first place. The planning model cannot add new origins on its own; the control function must approve them. A similar separation applies to non-web content, such as tool calls, by distinguishing between read and write calls and checking whether they are appropriate for the task.
Navigation to new origins is also subject to review. If the planner proposes navigating to an origin not included in the read set, a copy of the User Alignment Critic checks its relevance to the task before adding it and beginning the navigation. Chrome also uses a deterministic check to restrict URLs generated by the model to known public URLs, because model-crafted URLs could be exploited to exfiltrate private information. If the page navigates automatically to a new origin, that origin undergoes the same review.
Google acknowledges that setting these boundaries correctly on the first attempt is difficult before learning how users’ tasks interact with them. It therefore initially implemented a simpler version of asset control that tracks the read and write sets, with plans to tune the control functions and the rest of the system to reduce friction and improve security.
User Confirmations and Monitoring Sensitive Actions
Chrome displays the agent’s steps in an activity log within the tab, allowing the user to follow what is happening moment by moment; the user can also stop the task or regain control at any time. This transparency is supported by a set of deterministic and model-based checks that request user confirmation before consequential actions.
The main checkpoints include:
- Requesting confirmation before navigating to sensitive sites, such as sites involving banking transactions or personal medical information, based on a deterministic check against a list of sensitive sites.
- Requesting confirmation before signing in to a site using Google Password Manager, without making stored passwords directly available to the model.
- Pausing before actions such as completing a purchase or payment, sending a message, or any action with consequences, then requesting permission or asking the user to perform the next step.
Detection, Testing, and Response
The system scans every page the agent sees for indirect prompt injection, alongside Chrome’s real-time scanning through Safe Browsing and on-device AI to detect traditional scams. The prompt injection classifier operates in parallel with the planning model’s inference and can block actions that it determines page content prompted in an effort to steer the agent away from the user’s purpose. Google acknowledges that the classifier will not detect every possible harmful influence, but says it represents an additional layer within a defense-in-depth approach.
To verify the effectiveness of these controls, Google created automated attack-testing systems that generate isolated malicious sites attempting to derail the agent. The tests begin with attacks devised by security researchers and then expand them using language models and technology adapted for browser agents. The tests focus on widely encountered content, such as user posts on social media sites and advertisements, as well as attacks that could cause lasting harm, such as financial transactions or credential leaks. Google uses the attack success rate to evaluate engineering changes and prevent regressions, while automatic Chrome updates help deliver fixes quickly.
Google updated its vulnerability reward program guidelines to clarify how external researchers can focus on Chrome’s agentic capabilities, and says it will pay up to $20,000 for critical vulnerabilities that demonstrate a breach of security boundaries. The company emphasizes that web agent security is still an emerging field and that these protections will evolve as testing continues and collaboration with the security research community grows.