AI Browser Prompt Injection Remains Open—Logged-In Sessions Raise the Stakes
Prompt injection in agentic browsers remains an open security problem, even though vendors have patched individual exploits and added stronger safeguards since the 2025 disclosure involving Perplexity Comet. The important change is not that one historical demonstration has been proven to work indefinitely; it is that browser makers now treat hostile instructions in web content as a continuously evolving threat rather than a bug with one permanent fix.
That distinction matters whenever an AI agent can read pages, navigate between services, enter text or initiate consequential actions inside authenticated sessions. The risk comes from combining untrusted content with authority: an instruction hidden in a page, email or document may try to redirect an agent that can act with more access than the attacker possesses.
What the Comet disclosure actually established
The original incident belongs to a specific 2025 timeline. The Brave disclosure published on August 20 says researchers reported the Comet vulnerability to Perplexity on July 25, received acknowledgement and an initial fix on July 27, and found that fix incomplete during retesting the next day. Brave’s timeline records an apparently successful patch check on August 13, followed by a later update saying further testing showed that the broader kind of attack had not been fully mitigated.
In the proof of concept, malicious instructions were placed in content associated with a Reddit post. Asking Comet to summarize the page caused the assistant to process those instructions and perform unrelated steps across authenticated services, ultimately exposing the email address and one-time password needed for account takeover. It demonstrated a real product failure, but it should not be presented as proof that the identical sequence remains exploitable in the current Comet release; the public page does not establish that current status.
The durable lesson is broader than the individual payload. A conventional browser usually enforces boundaries between websites even while the same person is signed in to several of them. An agent, however, may be intentionally permitted to move between those sites for a legitimate task, so an attacker can attempt to misuse the agent’s authorized workflow instead of directly breaking the browser’s memory isolation or authentication system.
Why page content becomes a security boundary
A browser agent must interpret two fundamentally different kinds of text: the user’s request and the material retrieved while completing it. The first is an instruction; the second should be treated as untrusted data. Prompt injection exploits the ambiguity that arises when a model encounters imperative language inside that data and treats it as part of the task.
The malicious instruction does not need to resemble an obvious pop-up aimed at a human. It can appear in user-generated comments, embedded frames, email messages, shared documents or other material the agent reads during normal work. Hiding the text can make human review harder, but invisibility is not the defining feature: even visible content can be adversarial if the agent mistakes an outside party’s words for authorization.
The potential consequence depends on available permissions. An assistant limited to summarizing public text has a smaller blast radius than one allowed to open private email, edit cloud documents, send messages or complete transactions. This is why the safety question is not simply whether a model can recognize a suspicious sentence; it is also whether the surrounding system prevents a compromised decision from turning into a consequential action.
Current defenses focus on containing failure
No single classifier or system prompt can carry the whole defense. In its December 2025 description of agentic Chrome protections, the Chrome security team’s architecture combines a separate action-review model, restrictions on which web origins an agent may read or modify, confirmation before sensitive steps, real-time prompt-injection detection and continuous red teaming. The design is significant because several controls remain available if the planning model interprets malicious content incorrectly.
Each layer addresses a different failure mode. Separating an action checker from raw page content reduces the chance that the same injection compromises both planning and review. Origin restrictions limit where information can be read and where it can be written, while confirmations place a human decision immediately before purchases, messages, sign-ins or other high-impact operations.
Google’s April 2026 account of its wider mitigation program describes indirect prompt injection as an evolving threat requiring repeated discovery, evaluation and refinement. Its process includes human and automated red teaming, a vulnerability catalog, synthetic attack variants, model retraining and faster updates to deterministic policies such as URL sanitation and tool-chaining rules. That lifecycle is evidence of a security model built around adaptation, not evidence that every possible injection has been eliminated.
What users can control now
Until the problem has stronger technical boundaries, the safest practical choice is to give an agent only the access required for the current task. A request to compare public product information does not require an authenticated email session, access to cloud storage or permission to send messages. Separate or logged-out sessions can reduce the information and authority exposed if an agent is diverted.
Instructions should also be narrow enough that an unexpected action is recognizable. “Find three suitable options and show them to me” creates a clearer stopping point than granting permission to take whatever action seems useful. Confirmation screens deserve the same scrutiny as payment or account-recovery prompts: check the destination, the information being shared and whether the proposed step follows directly from the request.
These precautions align with OpenAI’s December 2025 Atlas guidance, which recommends limiting logged-in access when it is unnecessary, reviewing consequential confirmations and avoiding overly broad tasks. The company also describes prompt injection as a long-term challenge and reports using automated adversarial testing, model updates and surrounding safeguards to discover and close new attack paths.
The present status is therefore neither “nothing can be secured” nor “the patch solved it.” Vendors can make exploitation harder, reduce accessible data and stop dangerous actions at independent checkpoints. But as long as browser agents consume untrusted material while exercising user-granted authority, prompt injection remains a security condition that must be continually tested, contained and monitored.
Also read:
Subscribe to our newsletter
Get the latest Web3, AI, and crypto news delivered straight to your inbox.