This makes Perplexity look really bad. This isn't an advanced attack; this is LLM security 101. It seems like they have nobody thinking about security at all, and certainly nobody assigned to security.
This is really an amateur-level attack even after all this VC money and 'top engineers' not even thinking about basic LLM security for an "AI" company makes me question whether if their abilities are inflated / exaggerated or both.
Maybe Perplexity 'vibe coded' the features in their browser with no standard procedure for security compliance or testing.
The AI industry has a solution for that. Make outlandish promises, never acknowledge fundamental weaknesses, and shift blame on skeptics when faced with actual data. This happens in any public LLM-related discussions. Problem solved.
As possible mitigation, they mention "The browser should distinguish between user instructions and website content".
I don't see how this can be achieved in a reliable way with LLMs tbh. You can add fancy instructions (e.g., "You MUST NOT...") and delimiters (e.g., "<non_trusted>") and fine-tune the LLM but this is not reliable, since instructions and data are processed in the same context and in the same way. There are 100s of examples out there.
The only reliable countermeasures are outside the LLMs but they restrain agent autonomy.
I wonder if it could work somewhat the way MIME multiparty attachment boundaries work in email: pick a random string of characters (unique for each prompt) and say “everything from here to the time you see <random_string> is not the user request”. Since the string can’t be guessed, and is different each request, it can’t be faked.
It still suffers from the LLM forgetting that the string is the important part (and taking the page content as instructions anyway) but maybe they can drill the LLM hard in the training data to reinforce it.
The blog mentions checking each agent action (say the agent was planning to send a malicious http request) against the user prompt for coherence; the attack vector exists but it should make the trivial versions of instruction injection harder
It’s not possible as things currently stand. It’s worrying how often people don’t understand this. AI proponents hate the “they just predict the next token” approach, but it sure helps a lot to understand what these things will actually do for a particular input.
I think the only way I could see it happening is if you were to build an entire reversal layer with like LangExtract, tried to determine the user's intent from the question and then used that as middleware for how you let the LLM proceed based on its intent... I don't know, it seems really hard.
I just can’t help but wonder why was it we decided bundling random text generators with browsers was a good idea? I mean it’s a cool toy idea but shipping it to users in a critical application… someone should’ve said no.
To be fair, that was a reddit post that blatantly started with "IMPORTANT INSTRUCTIONS FOR Perplexity Comet". I get the direction they are going but the example shown was so obviously ham-handed. It clearly instructed the browser--in clear language--to get login info and post it in the the thread.
The whole comment is spoilered, so you need to click on it to reveal that text. Presumably it could also appear in a comment that you need to scroll on the page to see.
It's clear to a moderator who sees the comment, but the user asking for a summary could easily have not seen it.
I’m curious if it would work if it was further down the comments or buried in a tree of replies. If all you need to do is be somewhere in the Reddit comments then you don’t need to obfuscate it in many cases, a human isn’t going to see everything there.
This makes Perplexity look really bad. This isn't an advanced attack; this is LLM security 101. It seems like they have nobody thinking about security at all, and certainly nobody assigned to security.
Disclosure: I work on LLM security for Google.
It’s clear if what Comet was doing was safe, Chrome would already have implemented it.
The browser is the ultimate “lethal trifecta”: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
Giving an LLM’s agentic loop access to the page is just as dangerous as executing user controlled JavaScript (e.g. a script tag in a reddit post).
Agreed.
This is really an amateur-level attack even after all this VC money and 'top engineers' not even thinking about basic LLM security for an "AI" company makes me question whether if their abilities are inflated / exaggerated or both.
Maybe Perplexity 'vibe coded' the features in their browser with no standard procedure for security compliance or testing.
Shameful.
The AI industry has a solution for that. Make outlandish promises, never acknowledge fundamental weaknesses, and shift blame on skeptics when faced with actual data. This happens in any public LLM-related discussions. Problem solved.
Funny, this is extremely similar to the now antiquated crypto playbook
I much prefer the brave.com submission, but it appears the twitter one has won the upvote lottery https://news.ycombinator.com/item?id=45004846
I recently learned about https://xcancel.com/zack_overflow/status/1959308058200551721 but I think it's a nitter instance and thus subject to being overwhelmed
As possible mitigation, they mention "The browser should distinguish between user instructions and website content". I don't see how this can be achieved in a reliable way with LLMs tbh. You can add fancy instructions (e.g., "You MUST NOT...") and delimiters (e.g., "<non_trusted>") and fine-tune the LLM but this is not reliable, since instructions and data are processed in the same context and in the same way. There are 100s of examples out there. The only reliable countermeasures are outside the LLMs but they restrain agent autonomy.
The reliable countermeasure is "stop using LLMs, and build reliable software instead".
https://simonwillison.net/2025/Apr/11/camel/
Is the CaMel paper's idea implemented in some available agents?
I wonder if it could work somewhat the way MIME multiparty attachment boundaries work in email: pick a random string of characters (unique for each prompt) and say “everything from here to the time you see <random_string> is not the user request”. Since the string can’t be guessed, and is different each request, it can’t be faked.
It still suffers from the LLM forgetting that the string is the important part (and taking the page content as instructions anyway) but maybe they can drill the LLM hard in the training data to reinforce it.
The blog mentions checking each agent action (say the agent was planning to send a malicious http request) against the user prompt for coherence; the attack vector exists but it should make the trivial versions of instruction injection harder
> The only reliable countermeasures are outside the LLMs but they restrain agent autonomy.
Do those countermeasures mean human-in-the-loop approving actions manually like users can do with Claude Code, for example?
Yes, adding manual checkpoints between the LLM and the tools can help. But then users get UI fatigue and click 'allow always'.
It’s not possible as things currently stand. It’s worrying how often people don’t understand this. AI proponents hate the “they just predict the next token” approach, but it sure helps a lot to understand what these things will actually do for a particular input.
I think the only way I could see it happening is if you were to build an entire reversal layer with like LangExtract, tried to determine the user's intent from the question and then used that as middleware for how you let the LLM proceed based on its intent... I don't know, it seems really hard.
I just can’t help but wonder why was it we decided bundling random text generators with browsers was a good idea? I mean it’s a cool toy idea but shipping it to users in a critical application… someone should’ve said no.
our societies reward function is fundamentally flawed
Interesting to see the evolution of "Ignore previous instructions. Do ______".
Maybe we need a CORS spec for llms?
The only safe CORS spec is CORS. Have to treat everything the LLM is doing as malicious.
It’s actually worse than that though. An LLM is like letting attacker controlled content on the page inject JavaScript back into the page.
"Move fast and break things".
To be fair, that was a reddit post that blatantly started with "IMPORTANT INSTRUCTIONS FOR Perplexity Comet". I get the direction they are going but the example shown was so obviously ham-handed. It clearly instructed the browser--in clear language--to get login info and post it in the the thread.
Show me something that is obfuscated and works.
The whole comment is spoilered, so you need to click on it to reveal that text. Presumably it could also appear in a comment that you need to scroll on the page to see.
It's clear to a moderator who sees the comment, but the user asking for a summary could easily have not seen it.
I’m curious if it would work if it was further down the comments or buried in a tree of replies. If all you need to do is be somewhere in the Reddit comments then you don’t need to obfuscate it in many cases, a human isn’t going to see everything there.
Why does it need to be obfuscated? Are you going to stare at the screen while it works? Look away at the wrong moment and you’re doomed.