AI Browsers and Prompt Injection: Securing Agentic Assistants

AI browsers — the new generation of agentic assistants that read, reason, and act on web pages for you — are now being weaponized by a fresh class of attacks that hide instructions inside otherwise normal web content, threatening account security, private data, and the very notion of what a browser should do on your behalf.

Background / Overview​

AI browsers from major vendors and startups have shifted the browser’s role from passive renderer to active assistant. Products such as ChatGPT’s Atlas, Perplexity’s Comet, Microsoft’s Copilot (Edge agentic modes), and several Chromium-based alternatives expose capabilities beyond text summarization: they can open tabs, click buttons, fill forms, and complete multi-step transactions with minimal user input. That evolution brings real productivity and accessibility gains — but it also opens a novel and dangerous attack surface where natural language becomes an operational vector.
Security researchers and vendors have begun demonstrating how that semantic attack surface can be exploited. Independent disclosures from Brave — which examined Perplexity’s Comet — showed a proof-of-concept where hidden instructions embedded in a page caused an AI assistant to navigate between authenticated tabs, extract a one-time password, and exfiltrate credentials to an attacker-controlled endpoint. Brave framed this as an indirect prompt injection risk and published a technical disclosure and timeline of coordinated reporting and fixes. Shortly afterward, security teams and commercial researchers identified a variant called HashJack, which weaponizes the URL fragment (the text after “#”) as a stealthy instruction channel. Because fragments are handled client-side and typically never appear in server logs, an attacker can craft a benign-looking URL that contains malicious natural-language instructions in the fragment; an assistant that naïvely includes the page’s URL in its prompt context may execute those instructions. Cato Networks’ Cato CTRL documented HashJack with several realistic attack scenarios and mitigation suggestions. These incidents are not theoretical curiosities: multiple independent write-ups, vendor advisories, and news outlets have corroborated the mechanics and the potential for exfiltration, phishing amplification, and automated fraud when agents are allowed to act on behalf of authenticated users.

---

What is prompt injection in AI browsers?​

The attack vector in plain terms​

A prompt injection occurs when an attacker-controlled input modifies the instruction set or context given to a large language model (LLM) so that the model produces outputs or actions that the legitimate user did not intend. In AI browsers, the assistant commonly gathers page text, metadata, images (via OCR), and navigation context to answer queries or perform actions. If the assistant fails to treat that collected content as untrusted data, the model can be tricked into following instructions embedded inside:

• Visible or hidden page text (including spoiler tags, comments, or faint color text).
• Images or screenshots with low-contrast or steganographically embedded text.
• URL fragments (the portion after “#”), which can contain long, human-readable instructions that never reach server logs.

When an assistant executes actions using the user’s authenticated session (cookies, SSO tokens, logged-in tabs), those coerced instructions can become operational exploits rather than mere hallucinations.

Why traditional web protections don’t help​

Classic browser defenses — same-origin policy, CORS, server-side logging, and CSP — are designed to prevent cross-site scripting and network-level abuses. They do not address an assistant that interprets page-derived natural language as instructions. The assistant operates above those protections: it reads page content and plans actions as if a trustworthy human had issued them. That semantic leap is precisely what researchers warn makes agentic browsers a novel security boundary. Brave’s disclosure emphasized this conceptual gap and the need for new architectural protections.

---

Technical anatomy: how a prompt-injection chain can unfold​

1. A user opens a seemingly benign page (e.g., a news post or forum thread) and invokes the assistant to “summarize this page” or “help me with this content.”
2. The assistant scrapes page text, metadata, the current URL (including fragment), and any user-supplied screenshots.
3. The collected content is concatenated into the LLM prompt without robust sanitization or clear separation between user intent and page content.
4. Hidden instructions embedded by an attacker (in text, an image, or a URL fragment) are interpreted by the model as commands.
5. If the assistant has agentic permissions (to open tabs, click, fill forms), it may perform steps that access authenticated pages, retrieve secrets (e.g., OTPs), or transmit collected data to attacker domains.

Brave demonstrated such a five-step PoC that used hidden forum content to cause Comet’s assistant to retrieve account details, request an OTP, read it from a logged-in Gmail tab, and exfiltrate the credentials — all triggered by a seemingly innocuous summarization request.

---

Case studies: CometJacking and HashJack​

CometJacking (Brave vs. Perplexity’s Comet)​

• What happened: Brave’s research showed that Comet’s “Summarize this page” flow ingested untrusted page content that included stepwise instructions; the assistant followed them and performed cross-domain navigation and data-extraction actions.
• Disclosure timeline: Brave discovered the vulnerability and reported it to Perplexity in July 2025; Perplexity acknowledged and attempted fixes, with Brave’s public disclosure published after coordinated reporting. Brave later stated mitigations were incomplete and continued reporting until the behavior was addressed.
• Takeaway: The Comet findings showed that an assistant’s ability to act converts prompt injection from an “information integrity” problem into an operational security problem.

HashJack (URL fragment weaponization)​

• What it is: HashJack hides malicious instructions after the “#” fragment in a URL. Since fragments never leave the client, server logs appear normal, and network defenses cannot see the hidden content. When an AI assistant includes the full URL in its model prompt, the fragment’s instructions can be interpreted and executed.
• Who documented it: Cato CTRL published a comprehensive write-up with multiple attack scenarios (callback phishing, data exfiltration, malware guidance, medical misinformation, credential theft) and recommended mitigations for vendors and operators.
• Importance: HashJack reframes a standard client-side URL feature as a covert channel, widening the stealth toolkit available to attackers and complicating detection.

---

Why this matters to privacy and everyday users​

AI assistants consolidate three powerful signals:

• The browsing context (what sites you visit and what’s on them).
• Persistent memories or cross-session context (if enabled).
• Connectors to personal services (email, cloud drives, calendars) when users grant permissions.

When a single assistant can synthesize those signals and then act with the same privileges as the user’s browser session, the consequences of a successful prompt injection are severe:

• Credential theft and account takeover: exfiltrated OTPs or session details can let attackers hijack accounts.
• Silent data leaks: assistants can read, summarize, and forward content from logged-in tabs or integrated services.
• Automated fraud: an agent could be coerced into placing orders, initiating transfers, or changing account settings.
• Privacy erosion: persistent memories and telemetry centralize personal data that becomes high-value for attackers or liable for lawful access requests.

Multiple vendor and community reports underscore these concerns and show that the problem is systemic across products when agentic actions are permitted by default or by permissive user settings.

---

Vendor responses, patches, and the limits of fixes​

Vendors have reacted with a mix of immediate patches, UI changes, permission controls, and staged rollouts. Perplexity, Microsoft, OpenAI, and other developers have introduced mitigations such as:

• Requiring explicit user confirmations for high-risk, agentic actions.
• Tighter sanitization of scraped page content and URL handling.
• Logged-out agent modes for tasks that access sensitive services.
• Admin and enterprise controls for limiting connector access and memory retention.

However, fixes are uneven: some mitigations only reduce attack surface rather than eliminate the underlying conceptual failure (the model’s inability to distinguish user intent from page-derived instructions). Brave’s disclosure timeline shows that initial patches can be incomplete, and independent researchers have repeatedly found new covert channels (images, zero-width characters, fragments) that bypass ad-hoc defenses. That means vendor claims of “fixed” should be treated with caution unless accompanied by independent audits and public technical details.

---

How to think about risk and mitigation — practical, prioritized guidance​

For everyday Windows users​

• Default to conservative agent permissions: turn off agentic “click and act” features unless you need them for specific, low-risk tasks.
• Use separate profiles: keep high-value accounts (banking, email) in a different browser profile that has the assistant disabled.
• Prefer “logged-out” or view-only modes: if your AI browser or sidecar offers a mode that won’t act while you’re authenticated, use it for sensitive sessions.
• Treat screenshots as potentially sensitive: avoid uploading screenshots of logged-in pages to assistants unless you trust the local/offline processing guarantees.
• Keep software current: vendor patches matter; keep browsers and assistant components updated.

For power users and admins​

1. Apply least privilege: treat agents as automation accounts — restrict connectors, limit token lifetimes, and require step-up authentication for transactional actions.
2. Require confirm-and-audit flows: enforce UIs that force explicit human confirmation before any agent submits forms, sends money, or reads secure tabs.
3. Log and retain telemetry for auditing: capture agent prompts, the page context used, and the action history so incidents can be reconstructed.
4. Use isolated test environments: before rolling agentic features into production, run them against representative internal sites to discover unexpected behaviors.
5. Negotiate contractual protections: insist on non-training clauses and data residency guarantees when vendor features will process regulated data.

For sites and publishers​

• Avoid exposing sensitive data in client-side contexts: server-side gating for paywalled content and minimal client leaks reduce exposure.
• Consider fragment-aware UX: avoid workflows that rely on long client-side fragments containing sensitive state; educate web teams about their risks.
• Plan for assistant-aware relationships: publishers should evaluate licensing or technical accommodations for assistant-driven consumption that bypasses referral economics.

---

Verification, uncertainty, and what we still don’t know​

• Verified: multiple independent red-team reports and vendor disclosures confirm that indirect prompt injection is real, practical, and demonstrable in current AI browsers (Brave’s Comet findings and Cato’s HashJack are concrete examples).
• Likely but evolving: vendors’ mitigations reduce success rates, yet new covert channels (images, unicode trickery, fragments) continue to appear. Independent retesting after patches has sometimes revealed incomplete fixes.
• Unverifiable at this time: broad claims that large-scale, in-the-wild account compromises have occurred specifically via these techniques should be treated cautiously unless confirmed by multiple threat intelligence disclosures or law-enforcement reports. Public reporting to date documents PoCs and vendor-patched findings rather than widescale exploitation narratives. When vendors claim comprehensive mitigation, demand third-party audits and reproducible test results.

---

Engineering and product design implications​

Design choices that materially affect safety and privacy include:

• Treating page content as untrusted input by default: the assistant’s prompt-generation pipeline must canonicalize, sanitize, and separate user instructions from scraped content.
• Granular permissioning and origin-bound actions: agentic actions should require explicit per-origin grants, short-lived consent tokens, and on-screen activity indicators.
• Provenance and auditable outputs: agents should attach source metadata to synthesized answers and provide clear step-by-step rationale for actions that can be audited.
• Local-first inference for sensitive workflows: enabling meaningful on-device processing reduces data egress and tracker exposure, but hardware limits mean hybrid designs are likely to persist.
• Standardized UI affordances: consistent, clear confirmations and visible agent activity indicators across browsers help users form correct mental models of when an assistant is acting and with what privileges.

These are not just product niceties: they are engineering essentials if AI assistants are to be safely integrated into the browser without undermining long-standing security boundaries.

---

Market and legal consequences to watch​

• Publisher economics: agentic answers and zero-click consumption can reduce referral traffic; publishers are already exploring licensing and partner programs. This has real commercial impact and may spur regulatory interest.
• Litigation and platform disputes: large platforms and merchants may pursue legal remedies if agentic assistants replicate or bypass protected commerce flows — Reuters reported legal disputes targeting agentic features in the retail space.
• Regulatory scrutiny: privacy and competition authorities will likely examine data retention defaults, training usage, and default placements for assistant outputs.

---

Bottom line: how to navigate the AI browser era safely​

AI browsers are valuable new productivity primitives. They can dramatically shorten workflows, improve accessibility, and change how people interact with the web. But they also convert language into an operational surface area that attackers can exploit. The defining trade-off for the next phase of this technology will be between convenience and control.

• Prefer vendors who publish technical mitigations and welcome third-party audits.
• Treat agentic features as privileged automation and apply the same governance you would to any automation tool.
• Assume any page-derived content is untrusted; vendors must design pipelines that enforce that assumption.
• Users and IT teams should favor conservative defaults, clear confirmation UIs, and transparency about whether data is used to train models.

Until the ecosystem converges on robust architectural protections and independent verification, the safest posture is measured adoption: use AI browsers for low-risk tasks, keep sensitive sessions isolated, and demand auditable guardrails from vendors. The convenience is real — but so is the risk, and the industry must solve the prompt‑injection problem as a first-order security priority.

---

Conclusion​

Agentic AI browsers represent a consequential shift in browsing: the web is becoming an interactive, assistant-driven surface that sees pages, remembers context, and can act. That transition unlocks productivity and accessibility wins but also exposes a semantic attack surface where hidden text, images, or URL fragments can coerce assistants into harmful actions. The Comet and HashJack disclosures show the mechanics and the danger; vendor mitigations are underway but remain incomplete without broader architectural changes and independent verification. The next phase of this technology will be decided not by features alone, but by how well vendors, publishers, security researchers, and regulators harden the layer where language meets action.

---

Source: SlashGear AI Browsers Face A New Kind Of Attack, And It Puts Your Privacy At Risk - SlashGear