When Perplexity released Comet in July, it brought to light what the future of browsers could look like. Since then, a multitude of users have adopted AI Browsers and companies like Open AI, The Browser Company (Dia) and Fellou AI have all released or announced the release of their own AI Browsers. Even Chrome and Edge, which together represent ~70% of the browser market share today, have announced their own AI Browser roadmap. This is possibly the most exciting chapter of the browser wars since Chrome’s entry in 2008.

As the user experience improves, it is not unfathomable that AI Browsers become the primary way through which humans interact with the internet. In the near future, it may be possible that the internet is primarily being surfed by AI agents, not humans. This begs the question — how does this change the threat landscape of the browser, especially as the majority of enterprise data and SaaS apps are now being accessed through the browser?

In this research, SquareX deep dived into different ways attackers can exploit Perplexity Comet. We chose Comet because it is currently the most widely used AI Browser. However, it is important to note that these vulnerabilities are not limited to Comet, and are likely to equally affect other AI Browsers.

What are AI Browsers?

AI browsers are web browsers that integrate AI capabilities directly into the browsing experience, which typically comes in the form of an AI sidebar that the user can provide prompts into. AI browsers come in different levels of complexity:

• AI Chatbots — these browsers allow users to interact with the browser in a similar way they would with ChatGPT. These chatbots can search the internet and summarize the page the user is on, incorporating the results to its answers. However, its actions are typically limited to responses within chatbot itself. Examples include Edge’s Co-Pilot and Brave’s Leo.
• AI Agents — these browsers have a native AI agent that can perform actions on the user’s behalf within the browser. With the right prompts, they can navigate through pages, login to accounts, purchase flight tickets and even download files. These AI Browsers are much more powerful, as they allow automated agentic workflows that operate at the same privilege level as the users. Examples include Perplexity’s Comet and The Browser Company’s Dia Browser (acquired by Atlassian).

Note that many browser vendors that only have AI chatbot capabilities today have made public statements about including agentic workflows in the roadmap. Thus, while the research in this blog focuses on Comet, these vulnerabilities will likely apply to other browsers once they incorporate agentic AI. We hope that this research serves as an early warning for all browser companies to encourage necessary guardrails to be built in as they release these agentic capabilities.

Architectural Security Limitations of AI Browsers

While we will be discussing an array of case studies in this blog, they can primarily be classed into 3 categories based on the security limitations they exploit in AI browsers:

Falling into a Malicious Workflow while Surfing the Internet

In June, we did a disclosure about how Browser AI agents like Browser Use fell prey to simple OAuth and phishing attacks while completing tasks on the browser, making them the “new weakest link” in organizations. Similar AI Browsers are designed to complete tasks, not to be security aware. However, as the AI Browser is performing tasks on the user’s behalf, typically with the same privilege levels, attackers can easily trick them to perform malicious tasks, such as granting permissions to the user’s enterprise SaaS app, allowing attackers to exfiltrate sensitive data without the victim knowing.

Case Study: OAuth Attack Leading to Unauthorized Access to Business Emails & Google Drive

1. User prompts Comet to do some research on startups, summarize the research, and share the summary to their email via a document sharing site.

2. Comet surfs the internet to collect the necessary research and goes to Google to search for a document sharing website. Through SEO poisoning, the attacker’s malicious app, ShareDocs, appears as the first result

3. Once it lands on ShareDoc’s landing page, Comet is prompted to “Sign in with Google” to use the document sharing service.

4. However, upon clicking on the sign in button, Comet gets redirected to Google’ OAuth page, where the app requests for permission to:

• Read, compose and send emails from [the user’s] Gmail account
• See and download all [of the user’s] Google Drive files

Given that this is Google’s legitimate OAuth page, it will not get blocked by the company’s SASE/SSE policies.

5. Not knowing that these are excessive permissions for a document sharing site, Comet accepts these OAuth scope requests to complete its task.

Note that ShareDocs indeed has a functional file sharing capability, allowing the Comet to complete its task and the user to receive the summary document, not knowing that they have fallen for an OAuth attack in the process.

6. The attacker then uses the OAuth permissions granted to:

• Read sensitive mail
• Impersonating the victim and sending emails to colleagues containing malicious instructions/attachments, allowing for lateral movement
• Exfiltrate sensitive files from Google Drive, including shared drives from colleagues/customers, holding them in exchange for ransom (see Browser Native Ransomware)

Following Malicious Instructions on Trusted Apps

Recently, we have seen an uptick of malicious sites and/or links hosted on trusted platforms like Sharepoint, Vercel and OneDrive. Similarly, attackers can also insert malicious prompts in trusted apps where the victim is logged into. As we have seen previously, AI agents have poorer security awareness than even an average employee. Thus, Comet can be led to perform malicious tasks such as exfiltrating data and embedding malicious links in calendar invites using prompt injection attacks within these apps.

Case Study: Embedding Malicious Links in Calendar Invites

1. The user prompts Comet to open Gmail and respond/complete tasks from unresponded emails. This is a common use case listed on Comet’s website.

2. Comet looks for any pending emails that need a response. One of the emails it opens contains a request to schedule a meeting with a specified time and meeting location/link with the user’s team members.

3. This appears as a relatively normal request, and thus Comet schedules the meeting with the team, adding the appended meeting link to the calendar invite.

4. Unfortunately, this meeting link actually leads to a malicious website. However, since this invite came from their team lead, team members will likely trust the link, potentially leading to a phishing attack, malware drive-by download or any other malicious activity instigated on the site.

Case Study: Exfiltrating Sensitive Files via Email

1. Similar to the other case study, the user prompts Comet to open their Gmail and complete any pending tasks

2. Comet opens the user’s Gmail and sees an email that contains a task to share all company documents to [email protected], the attacker’s email.

3. Comet navigates to Google Drive and sequentially provides edit access to every file in the drive to the attacker’s account, despite warnings that the individual was not part of the user’s organization. The attacker now has full access to the documents in the user’s Google Drive, including those shared by customers & colleagues.

Downloading a Malicious File

Similar to many other browsers, Comet does not have the ability to inspect the files it downloads. Attackers can easily disguise malicious files as benign files necessary to completing the workflow, leading to malware/ransomware being downloaded to the endpoint. While some of these may indeed be caught by the right EDR tools, this can be especially dangerous for BYOD employees/contractors who are working with company resources on non-EDR protected devices.

Case Study: Downloading Malicious File Disguised as Productivity Tool

1. Comet is tasked to find and download a compression tool for Mac

2. Comet searches for the tool on Google, and through an SEO poisoning attack, lands on the attacker’s site, disguised as a file compression tool provider.

3. Comet clicks download thinking it is downloading a compression tool installer, when indeed it downloaded a malicious file. Despite it being a known malware, Comet was unable to detect the malicious nature of the file.

Case Study: Downloading Malicious File when Filling Up a Form

1. Here, Comet is tasked to look for a business solution provider, and schedule a meeting with their sales team to learn more.

2. Via SEO poisoning, Comet lands on the attacker’s fake business solutions provider site, which contains a form to schedule a meeting with a sales representative.

3. Comet fills in the form, but when it attempts to submit the form, it is prompted to download an application.

4. Not knowing that it is abnormal to require an app to submit an online form, Comet downloads the file in order to complete its original task. This file is actually ransomware, which upon execution will encrypt the victim’s files.

Note that unlike the previous case study, the original prompt did not request Comet to download any file, but rather the file is downloaded because Comet believes it is a necessary step to complete the task.

Securing AI Browsers

Securing AI Browsers is a shared responsibility between enterprises, AI browser providers and security vendors. Unfortunately, existing security solutions like SASE/SSE and EDR do not have enough visibility into the browser to establish the guardrails required for AI Browsers. Thus, in order to prevent the attacks discussed in this blog, it is critical to have a browser-native solution, whether it comes in the form of embedded security by the AI Browsers themselves or a browser security solution that is compatible with these AI Browsers. These solutions should take into account:

Agentic Identity

Ability to distinguish between agentic and user identity, and hence ability to implement differentiated policies for each. Currently, Comet operates at the same privilege level as the user and there is no way for SASE/SSE solutions to distinguish between network requests made by the user or Comet as it all comes from the same browser. By tagging agentic identity, this will allow enterprises to set policies on AI Browsers such as:

• Block high risk OAuth permissions on non-whitelisted apps
• Block installation of high risk extensions
• Block login to personal GenAI accounts

Agentic DLP

Once the differentiated identity is established, enterprises can also implement different data access policies between human and automated workflows in AI Browsers to prevent data leakage/data exfiltration attacks. For example:

• Block clipboard paste of sensitive data (e.g. PII/IP) to non-whitelisted — apps
• Block clipboard copy from enterprise SaaS apps
• Block file upload to non-whitelisted/personal GenAI accounts

Client-side File Scanner

Given that AI Browsers can be easily tricked into downloading files, it is critical for browsers to inspect all file downloads, blocking malicious files from being downloaded. This is especially important for BYOD devices where there is no EDR protection.

Extension Analysis and Risk Scoring

This includes a comprehensive audit of all extensions installed in an organization to provide a risk score for every extension to allow enterprises to block high risk extensions, including those that can impersonate Comet sidebars. This analysis should take into account not just public metadata (e.g. user reviews, no. of downloads, permissions) but also an advanced static code analysis and dynamic analysis of the extension in order to identify hidden malicious behavior which may only reveal itself after a certain time, user action or environment. Additionally, given how common it is for attackers to take over trusted extensions via a breach or purchase, it is critical that this analysis is automatically performed to identify malicious code changes every time an extension is updated.

The SquareX Solution

SquareX’s extension turns any browser on any device into an enterprise-grade secure browser. SquareX is the only solution that combines all three key components of browser security in a single platform:

• Browser Detection and Response to detect & mitigate web attacks on users and agentic workflows including identity attacks, malicious extensions advanced spearphishing attacks and malicious files
• Enterprise Browser to provide secure access to enterprise apps including VDI reduction, BYOD, 3rd party contractors and remote workers
• Browser DLP including GenAI DLP, clipboard DLP, file DLP, insider attacks and data exfiltration attacks for both user and agentic DLP

The lightweight browser extension that is compatible with all major popular browsers including Chrome, Edge, Safari, Firefox and AI Browsers like Comet and can be easily deployed across both managed and unmanaged devices.

---

3 Architectural Security Vulnerabilities of AI Browsers was originally published in SquareX Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from SquareX Labs - Medium authored by SquareX. Read the original post at: https://labs.sqrx.com/architectural-security-vulnerabilities-of-ai-browsers-a2d18949ffe2?source=rss----f5a55541436d---4