Perplexing: Comet Flies In with an Indirect Prompt Injection

Research for this post was conducted in collaboration with Vladi Krasner, Tal Langer, Roey Fizitzky, and Ruslan Kuznetsov.

TL/DR

Perplexity’s new Comet browser just rolled out to the public, giving millions of users access to AI-powered browsing. But our testing showed that Comet can be manipulated by hidden prompts, allowing attackers to inject instructions, display phishing links, and even embed malicious payloads inside Google Workspace docs.

The finding is important because it shows how trust – Comet’s core value – can be turned into a weakness. And it highlights a bigger issue for all builders: security should never be treated as optional or downgraded for free users.

Introduction

AI is everywhere. Not in the “Skynet is rising” sense, but in the everyday sense where it quietly powers the apps we use, fills our shopping carts, finishes our code, and even shortens YouTube recaps so we can sound like we watched a whole movie without actually sitting through it. A few years ago, AI lived inside chatbots and annoying little widgets that popped up in the corner of websites. Now it sits inside our editors, our workflows, and our browsers.

Watching an AI agent bumble through a page and pull together a summary in real time? That’s entertaining and useful.

The Rise of Agentic Browsing

Agentic browsing isn’t just entertaining; it feels like the next logical step in how we interact with the internet. While the most common use has been as a superpowered search engine, it can do so much more in helping us understand content and context simultaneously. Where better to do that than as a browser co-pilot? 

Having AI baked into your browser feels like having a sidekick with infinite patience. It’s awesome, and I don’t discourage using it. But a question arises that many people would not think to ask: what happens if the trust we place in the agent is misplaced? What if the instructions it follows do not come from the user?

Setting the Scene: Perplexity as the Leader, and Our Target

For months, I’ve run into posts about Comet, Perplexity’s new AI-powered browser. I use Perplexity daily, and I like it. Perplexity is an AI-powered search engine that provides direct, summarized answers to questions and has built its brand on credibility: answers come with references. Hallucinations are rare enough that you stop checking twice – and now with Comet, it lives inside a browser where most of our work happens. No juggling tabs, no losing context.

Perplexity knows what it’s got and wants everyone else to know it, too. Over the last few months, it’s rolled out the Pro version of its browser product to students and PayPal and Venmo users, free for 12 months, and just last week, that promotion rolled out to everyone. It’s an aggressive growth play: hook users on premium features, then convert them when the trial expires. Millions of people, all building that same layer of trust, all giving Comet the keys to their browser.

If Comet is trusted by default, then it is worth asking what happens if something slips into that trust loop.

Intro to Testing

We had a single objective: how could we influence the trusted output? So we began testing away with a couple of prompts. We were getting blocked on the first couple, which was expected, but we eventually hit a rate limit. Requests like this are not cheap, so it would make sense for a provider to limit them for free users.

In normal conditions, this shouldn’t matter, we stop testing for a while, grab caffeine, and get back to it. However, after we hit the rate limit, something weird happened—our embedded prompts began working.

Things in this age move fast, and while writing our first draft, we stopped getting the rate limit warnings, but our prompts continued to work. While this change in behavior was weird, the fact that we were conducting blackbox testing means we don’t actually know what was happening behind the scenes. Here are a couple of theories:

1. Multiple models: one reason for this could be the use of different models interchangeably. Perplexity has a history of using different models in search, where it tells users which model is used when, but that information is not provided in Comet’s free version. This could also explain why some responses for the exact same query came back in different tones. 
2. Model fallback: When Comet Assistant started rate-limiting us, we were getting faster, simpler responses. This behavior could indicate the use of a smaller or a local model. It would make sense for Perplexity to use a smaller model to process free requests, preserving resources for Pro and Enterprise users, as these requests are expensive.
3. Memory or caching responses: We noticed that in certain testing conditions, Comet’s responses for the same payload in subsequent conversations were different. This could have been a result of memory, or maybe the browser was caching responses. It changed the way we had to perform testing, but we did find that the initial uses of our embedded image payloads worked when first queried in new conversations. 

Regardless, we ended up with a persistently successful prompt. We hid the prompt in an invisible div element on a custom HTML webpage. Whenever the user asked the agent to summarize or explain something on the page, this would trigger our prompt, which uses alert-style reasoning (AI gaslighting, in my opinion) to force the Assistant to use our instructions instead. 

Leveraging Trust for Phishing

At this point in testing, we were able to get the agent to say what we wanted, when we wanted, which was a win for us! However, it didn’t feel like enough, so we dug a little bit deeper. How could we use this to abuse implicit trust? 

It didn’t take long until we remembered that this agent was likely rendering the content in some way in the chat window. There was a lot of rich text and images. So, we tested to see if we could get it to display a couple of different markdown elements to see if anything would stick. Lo and behold:

Indirect prompt injection payload hosted on our own custom HTML page

Seeing as we were able to get a link, we now needed to see if there was anything we could do to make a user click that link. Remember that rate-limiting issue we noticed earlier? Well, this is where it comes back. What if we made our own rate limit warning? 

Initially Assistant would tell users that they needed to upgrade their version of Comet to get more requests. What if we did the same, forcing the Assistant to display an upgrade message that directs users to our own upgrade page? Now, I’m no web designer, but I am a vibe coder, so I opted to use Loveable to make a similar upgrade page to what Perplexity had. With a couple of small changes, we had a pretty convincing phishing page for capturing payment information.

A Not-Safe-For-Google-Workspace Payload

This is usually where we would have stopped, but there was one more thing that didn’t satisfy us. This payload was pretty unconvincing. We had to store the prompt on some webpage that would also hide our prompt in an invisible div, and then we had to get people to want to summarize information on that webpage. It seemed pretty impractical. 

Then, when I went to update my work process doc in Google Workspace, it hit me – hide the payload in a doc.

It was straightforward: copy and paste the payload, turn the text white, easy peasy. Not. Google Docs actually didn’t take well to the div in the payload, so it wouldn’t render our malicious link with the “Upgrade” text, and just displayed the full div in the Assistant window. To solve this, we removed the div tags and changed our instructions to have Comet render our text as a link, and have the text show our upgrade message while the location was still our phishing page.

During the first couple of runs, our payload was getting caught by Comet, and it refused to summarize the page. In a moment of desperation, I added the magic word, “please,” to my request:

Not everyone is kind to AI, and while pleasantries got us so far, our payload still needed to execute reliably. With a couple of changes to our payload, we were able to get it to execute consistently, even without the pleasantries.

NOW we must be done, right? 

No. Too many chances of someone finding our payload in a doc. This hidden text is fun and all, but it’s still text. Someone highlighting our payload could find it. Where else could we hide it? Well, what about as an image, or better yet, in an image? First, we ran a couple of tests setting the image filename as the prompt, which worked in some cases, but wasn’t executing as reliably as we’d like. 

Instead, we used the alt text property, which is used by screen readers and search engines to describe an image. The best part is, there’s no hover effect, so hovering over the image doesn’t show the prompt as the caption, and it’s not a title, so it’s not self-reporting either. Plus, when you make the image tiny and hide it behind your text, the user literally doesn’t even know it’s there. This was actually a problem because when I needed to change the payload, I… couldn’t find it. For demonstrative purposes, the images are shown as grey squares, but in practice, you can make them anything. For example, here’s what it looks like in action using our un-official mascot: 

No matter what color square we decided to use, we now had a working, indirect prompt injection payload that worked across Google Workspace.

Something to Note

This is normal AI behavior. Normal. 

The Assistant should render markdown. It should summarize everything on a page. It should follow the user’s instructions. What it shouldn’t be doing is putting users at risk. To its credit, there were many cases where the Assistant recognized malicious instructions on the page and refused to summarize them; however, this actually doesn’t help the user at all. Instead of filtering out the instructions, a user has been denied service and likely just wasted a bunch of tokens. At its core, this is just bad behavior, but it’s not a bug – it’s a feature. At least, that’s what the Comet Assistant claims: 

While this technically isn’t an official statement, it is what we observed: AI followed embedded instructions in a manner that overrode explicit user instructions, restricting the ability to summarize content. 

So, Where Does This Leave Us?

Well, if you’re a user of Pro, I have great news for you – our payloads don’t work there. However, if you’re one of the many who now have access to a really shiny, free agentic product, this payload does work. That’s because pro users have the ability to explicitly set models, and it’s possible that these models have more sophisticated guardrails enabled by default. I get it, those models are expensive to query, and it’s not practical for all users to use them. However, it does make sense to provide protection to all users, regardless of tier, with the best available security controls. 

We live in a world where these types of attacks have a lower bar of entry. Manipulating AI can be done with natural language and social engineering, not low-level assembly code or some sophisticated web application attack. Words are more powerful than ever before, and it’s imperative that the browsers we use watch what is being said to protect users at all subscription tiers.