Only a week ago, we published #BragJack, and it really blew up!
We showed how we leveraged extensions with very basic permissions to attack internal agents in 5 different browsers: Perplexity Comet, Gemini Live in Chrome, Edge Actions, Opera Neon, and Claude in Chrome.
Today, I’d like to focus on a different subject by answering a very important question regarding this research: What made me go into it in the first place?
Prompt Injection
Are you also slightly tired of hearing about Prompt Injection?
Don’t get me wrong, it is very revolutionary from a security research perspective, and it is the best way to wrap our heads around how agentic systems - which are completely new - can be attacked.
However, I feel like it’s gotten more attention than it should, at the expense of reflecting on other ways to attack agentic systems.
As a browser security researcher who’s just entered the agentic software security space, I took it upon myself to explore uncharted territories beyond Prompt Injection attacks.
Perplexity had just released its agentic browser, introducing the first agentic side panel. Other browsers soon followed.
The cybersecurity industry’s focus was one - exposing the agent to data, such as by using websites, that the agent would be tricked into processing as instructions. Aka - a prompt injection.
In contrast, I was more interested in how the agents were wired into the browsers in the first place.
I found roughly the same flaw in 5 different browsers. An ordinary extension, with basic permissions, could feed its own prompts to the built-in agent - even though the agent expects prompts from one source only: the human.
I found a Prompt Injection(?)
My first thought was, “I managed to inject a malicious, unexpected prompt to the agent in the browser, so I guess that’s prompt injection, right?”
At this point, I had to make sure I fully understood prompt injection.
Essentially, Prompt Injection could either be direct or indirect.
A Direct Prompt Injection occurs when an attacker introduces instructions into the prompt-construction process, so the legitimate prompt given to the agent gets enriched with malicious content. That content is malicious instructions that trick the agent into performing unexpected actions.
An Indirect Prompt Injection still influences the agent, but instead of polluting the prompt itself, it pollutes the data the agent processes when acting on the prompt. For example, a legitimate, free-of-injection prompt may ask the agent to summarize a webpage. If the webpage content contains instructions the agent might act upon, it may be vulnerable to indirect prompt injection.
Reflecting on these against what I found, it was clear - my attack doesn’t fit either.
Unique Properties of My Findings
Two main properties of my attack made it unfit for the Prompt Injection category.
Beyond Polluting
Direct Prompt Injection is about polluting the instruction (the prompt). Indirect Prompt Injection is about polluting the data. In my research, the attacker didn’t have to pollute anything because it could feed the agent the whole prompt.
This changes the impact - Prompt Injection is a statistical attack by definition, meaning the better models get, the more aware they become of telling injected instructions apart from data.
However, the model is far less likely to become suspicious of prompts it believes the user provided, as demonstrated in my research.
Continuous Interaction
The agents I attacked were sometimes suspicious of my instructions because they were malicious. They did not always refuse them, but they occasionally asked whether I was sure I understood what I was asking for.
Prompt Injection usually gives an attacker one chance. The attacker pollutes data that later becomes instructions. If the agent asks for clarification or approval, the attacker cannot answer because they do not control the conversation.
In my research, hijacking the prompt channel changed that. I could send another prompt when the agent hesitated or asked a follow-up question.
That continued interaction was often necessary to complete the attack. It would have been a significant blocker if I had only been able to inject data once.
Prompt Forcing
I was thinking about all of this a while ago. I think I summed it up pretty well back then:
Prompt Forcing is an attack in which a lower-trust component makes an agent accept prompts as if they came from the user. If the attacker can keep sending those prompts, they can guide the agent through an action instead of relying on a single injected instruction.
Prompt Forcing in Reality
We’ve already covered instances of Prompt Forcing in our recent research. All were able to force prompts from inferior positions against agentic components that sit above them:
- #BragJack - We showed how extensions were able to force prompts against the internal agents built into the browsers.
- MaXSS - We showed how websites were able to abuse a critical vulnerability in the MaxAI Chrome extension to compromise every website the victim was authenticated to. As part of our demonstration, we forced prompts against authenticated AI providers, like Claude.
We’ll keep this post updated as we publish more Prompt Forcing findings.
Impact to the Industry
When Prompt Forcing occurs, one agentic system takes actions from a different, inferior system, and it looks as if the user initiated them. Not keeping Prompt Forcing in mind will make it harder to uncover attacks, let alone stop them.
I hope this experiment helps anticipate future emerging agentic attack techniques, so we can all identify and address these gaps before attackers take advantage of them.