When reading a page also means being able to act
An assistant that summarizes an article only needs to interpret content. A browser agent can go further: it can read pages, navigate between sites and, depending on its permissions, click or type within a session where the person is already signed in. That difference expands what it can do on someone’s behalf, but it also increases the consequences of a mistake. Google notes that agents can operate in authenticated sessions and that an unwanted action could include a transaction or the exposure of sensitive data. https://developer.chrome.com/docs/agents/security https://blog.google/security/architecting-security-for-agentic/
That is why the question is not merely whether the model answers a prompt well, but what content it sees, which actions it is authorized to take, and who checks that each step matches the person’s goal. The boundary between reading and acting matters: summarizing a review has a different impact from sending a message, signing in, or completing a payment. Chrome’s documentation presents its measures as defense in depth, not as a magical property of the model that makes any text on the web harmless. https://blog.google/security/architecting-security-for-agentic/
A page may contain instructions aimed at the agent
Indirect instruction injection occurs when a command directed at the model appears inside data it consults, rather than arriving as a direct instruction from the person. It may be on a manipulated page, in embedded third-party content, or in user contributions such as comments and reviews. Google describes two specific risks for web tools: tool definitions containing hidden instructions and seemingly ordinary responses that incorporate hostile text. https://developer.chrome.com/docs/agents/security https://blog.google/security/architecting-security-for-agentic/
The difficulty is that the model processes text from different sources while trying to follow a task. If it mistakes page content for a legitimate command, it may stray from the original goal. The site does not need to have authority over the agent; the text only needs to influence its planning. Google explicitly warns that the probabilistic nature of models means safety cannot be guaranteed inside the model alone. Therefore, even an instruction hidden in, or mixed with, useful information should be treated as untrusted content, not as user authorization. https://developer.chrome.com/docs/agents/security
Research illustrates the extent of this attack surface, although its findings should not automatically be generalized to every browser. A study published as an arXiv preprint in May 2025 examined an open-source browser-use project in a white-box setting and reported instruction injection, domain-validation bypass, and credential exposure. This is an analysis of one particular project and configuration: evidence that failures are possible, not a universal measurement of current agents or proof about Chrome. https://arxiv.org/abs/2505.13076
Layers that reduce the opportunity for abuse
Chrome’s guidance for agents that use WebMCP recommends several deterministic safeguards: limit input volume, restrict the web origins with which the agent can interact, and ask for confirmation before acting. It also advises treating tool responses as untrusted data. The aim is to reduce both the amount of hostile material entering the context and the routes through which a manipulative instruction could cause harm. These are design recommendations for people building agents, not a guarantee that every extension or browser applies them automatically. https://developer.chrome.com/docs/agents/security
Another technique described is spotlighting: marking or transforming untrusted content so the model interprets it as data rather than instructions. Chrome warns that the options involve trade-offs. Delimiting text is inexpensive, but can fail if the delimiters are manipulated; encoding it in Base64 makes certain structural tricks harder, but consumes more context. In either case, the system must explain to the model how to handle that content. These are complementary measures, not an infallible filter capable of recognizing every malicious intent. https://developer.chrome.com/docs/agents/security
Google also describes an architecture for Chrome’s agentic capabilities: a planning model proposes actions, and a separate component, called the User Alignment Critic, reviews whether they fit the user’s goal. The company says this critic receives action metadata, not unfiltered web content, and can reject proposals. In addition, origin sets are intended to limit which sites the agent can read and on which it can act. The post notes that the first implementation of this restriction was simpler and that the design would continue to be refined. https://blog.google/security/architecting-security-for-agentic/
Confirmations and stated limits
Human confirmation can act as a brake when an action may have consequences. Google says its Chrome agent asks permission before certain sensitive sites, before signing in through Google Password Manager, and before actions such as purchases, payments, or sending messages. It also mentions a log of steps and the ability to pause or stop a task. These are features described by the provider; they do not mean that every feature is available in every region, version, or product, or that the person must approve every detail in the same way. https://blog.google/security/architecting-security-for-agentic/
The documentation itself acknowledges limitations: classifiers may fail to detect all content designed to influence the agent, and defenses require continuous testing and improvement. Google says it uses automated red-team exercises to generate test sites and observe whether safeguards stop attacks. Such evaluation helps identify regressions, but a success rate measured on a test set does not prove that future vulnerabilities are absent or cover every page, language, workflow, and combination of tools. The prudent conclusion is that layers raise the cost of an attack and can contain its impact, not that they make an attack impossible. https://blog.google/security/architecting-security-for-agentic/
What the user can do
Before delegating a task, it is worth reviewing which permissions the browser or extension requests and restricting access to the sites the task actually needs. If a feature can send data, change an account, or make a purchase, it is reasonable to stay involved and check the recipient, fields, and outcome before confirming. Chrome’s guidance recommends limiting origins and requesting confirmation for actions; the point is not to shift all responsibility to the user, but to preserve a checkpoint for effects that may be difficult to reverse. https://developer.chrome.com/docs/agents/security
It also helps to separate low-impact tasks—such as organizing public information—from operations involving credentials, medical data, financial information, or private messages. If an agent encounters an unexpected instruction on a page, do not assume it is part of the original request. It is better to stop and review the proposed action. Supervision reduces exposure, but does not replace technical controls: the official guidance emphasizes origin restrictions, regular evaluation, and confirmations, while the available research shows that failures can arise in different system components. There is no basis for promising absolute protection. https://developer.chrome.com/docs/agents/security https://arxiv.org/abs/2505.13076