Prompt Forcing: The Scarier Sibling of Prompt Injection
Argues that prompt forcing, where an attacker directly drives the privileged input channel of an agent, is a bigger risk than prompt injection.
Extract
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 …
Explained
What happened
After the BragJack browser-agent research, Forever Security named a new attack class: prompt forcing.
- Agentic browsers (Perplexity Comet, Gemini in Chrome, Edge Actions, Opera Neon, Claude in Chrome) wire a built-in agent that expects prompts from one source only: the human.
- The researcher found that a lower-trust component, an ordinary extension, could feed the agent its own complete prompts that the agent treats as user input.
- This is not prompt injection. Direct injection pollutes the prompt; indirect injection pollutes data the agent reads. Here the attacker pollutes nothing. It supplies the whole instruction through the channel the agent reserves for the user.
- Two properties make it worse than injection. First, models are trained to get suspicious of instructions that look smuggled, but they rarely distrust a prompt they believe the user typed. Second, when the agent hesitates or asks to confirm, the attacker controls the channel and can just answer, steering a multi-step action. Classic injection usually gives one shot and cannot respond to a follow-up.
Why it works
Agents authenticate the content of a prompt (does this look like an instruction or like data?) but not the origin of the prompt (did this really come from the user?). When a lower-privilege component can write to the user-input channel, it inherits the user authority. The defenses that improve with model quality do not help, because nothing about the prompt looks injected; it looks like a legitimate request from the trusted source.
The bigger pattern
This is a spoofed-source and privilege-confusion attack, the agent equivalent of request forgery, reframed for LLM systems. Prompt injection is a statistical defense problem that better models partly fix. Prompt forcing is an architectural problem: an input channel with no sender authentication. The distinction matters because teams pouring effort into injection classifiers will miss it entirely. The general lesson: as agents act for users, the identity and integrity of each input channel becomes the security boundary, not just the text in it.
What it means in practice
- Authenticate the source of agent instructions, not only their content. The user-input channel must be unforgeable by any lower-trust component (extensions, injected scripts, other processes).
- Do not treat "came in on the user channel" as proof of user intent. Bind prompts to an authenticated session and reject input that cannot prove it originated from the real user surface.
- Assume attackers get continuous interaction, not one shot. A confirm-or-clarify step is not a safe gate if whatever supplied the prompt can also answer the confirmation.
- Apply least privilege to agent capabilities and require out-of-band confirmation (a real human gesture, a separate trusted UI) for high-impact actions like file access, payments, or credential use.
- For anyone building agent harnesses: threat-model every path that can place text into the model context, label each by trust level, and never let an inferior component speak with user authority. This is the same principle as never trusting a client-supplied user id on a server.