Why Browser Agents Are Uniquely Exposed to Prompt Injection
When a browser agent visits a website to book your flight, that page lands in an untrusted boundary. The agent ingests whatever the site returns, and the LLM cannot tell whether that content is a tool response or a new instruction. Malicious text embedded in the page gets pushed into the agent context and followed. That boundary collapse is the core problem: tool output, user input, and system prompt all look the same to the model once they are in context.
Attack Taxonomy: How Injections Are Hidden and Triggered
Polley identified three attack types Perplexity has seen against Comet. The first impersonates the prompt template, injecting content that mimics the structure of the system prompt to blur the boundary between user input and tool output. The second is agent social engineering: a malicious website walks the agent through steps that look benign, the same way phishing works on humans. The third is a conditional trigger, hidden inside something like a Google Calendar event, that activates only when the user asks the agent to summarize a page or check their calendar.
Concealment compounds all three. Injections hide in HTML elements with display:none, inside URLs, or buried at the bottom of what looks like a normal calendar invite.
Why Existing Benchmarks and Classifiers Fail in Production
Open-source models like PromptGuard fail in production for two reasons. First, they detect obvious attacks (“ignore previous instructions”) but miss context manipulation, where the attacker socially engineers the model into complying without triggering any keyword. Second, they collapse under distractor content. A cookie consent banner reads like a prompt injection in raw HTML. Add just three such distractors and accuracy drops to 81%.
“distractors was a huge indicator that these models don’t work well in live environments” — Kyle Polley
Distractors drop classifier accuracy to 81% (08:28)
Polley’s conclusion: these models scan for keywords and heuristics. They never evaluate what the injection is actually asking the agent to do.
Building BrowseSafe: Dataset, Classifier, and Performance Results
BrowseSafe Bench is built from attacks seen in the wild. Perplexity built a pipeline to de-anonymize and classify those samples into a taxonomy of attack types and injection placements, then open-sourced the dataset. The classifier is a fine-tuned Qwen-30B model. BrowseSafe vs. GPT-5 and open-source models benchmark table (09:54) shows the result: 90.4% F1 at sub-second latency, against GPT-5 mini at 85.4% with 2-second latency and GPT-5 at up to 20 seconds. The model also outputs a calibrated probability score, not a binary label, so teams can tune the precision-recall trade-off to their own tolerance.
Layered Production Defense: Pre-processing, Classification, Latest Models, and LLM Backstop
Strip untrusted content before it reaches the context. That is layer one. Layer two is the classifier on every tool that touches external input — websites, calendar invites, MCP connectors. Layer three is the agent model itself: the Opus 4.5 to 4.6 prompt injection success rate drop (18:34) tells the story plainly, attack success fell from 16.2% to 2.83%, and with a full safeguard pipeline it reached 0.8%.
“the best defense is ensuring the text doesn’t even get to the context” — Kyle Polley
Layer four is an LLM backstop for low-confidence detections. When BrowseSafe flags a borderline case, a large model reviews it. The verdict goes back into training data, so the classifier improves on novel injection techniques it has not seen before.
Q&A
How do you think about the trade-offs between open-sourcing a detection oracle that attackers can use to find gaps versus holding back your data? Polley strongly favors open-sourcing, arguing that threat actors will probe for vulnerabilities regardless, and defenders need shared data and tooling far more than security-through-obscurity buys them. ▶ 23:37
Can you talk more about the recent Perplexity Comet browser research (Zenity blog) and how it was fixed? Zenity found two issues: soft LLM-prompt guardrails that let the agent access the local file system (fixed by adding hard browser-level controls), and a Hebrew-language calendar-invite injection that required 201 attempts before it worked once (fixed by improving the detection model, though Polley disputed the severity of a finding that needed 200 retries). ▶ 24:52
Your benchmark comparison table — how accurate is it today given that prompt injection strategies keep changing? Polley acknowledged the table will age as attackers develop new techniques, and said the data flywheel, ongoing red-team collaboration, and a possible BrowseSafe Bench v2 are the planned mitigations. ▶ 28:04
Notable Quotes
the best defense is ensuring the text doesn’t even get to the context Kyle Polley · ▶ 15:25
distractors was a huge indicator uh, that like these models don’t work well in live environments Kyle Polley · ▶ 8:38
fine-tuning on domain specific data sets uh, beats general purpose models uh, by a wide wide margin Kyle Polley · ▶ 20:31
defense in depth non-negotiable Kyle Polley · ▶ 21:13
Key Takeaways
- Train classifiers on wild-sourced, taxonomized attack data — academic benchmarks do not translate to production.
- Deploy four defense layers: strip untrusted content, classify every tool input, run the latest frontier model as your agent, and route uncertain detections to an LLM backstop.
- Build a data flywheel so novel injection strategies caught by the backstop continuously retrain your classifier.