BrowseSafe++: construirea unor apărări mai puternice împotriva injecțiilor de prompturi din lumea reală

Agenții care pot naviga pe web, cum ar fi asistentul integrat în Comet sau Computer, trebuie să interacționeze cu paginile web, citind conținutul și folosindu-l pentru a efectua acțiuni în numele utilizatorilor. Acest lucru îi face vulnerabili la injecția indirectă de prompt, în care un atacator plasează text rău intenționat pe o pagină web. Dacă agentul urmează aceste instrucțiuni, poate returna un răspuns înșelător sau poate efectua o acțiune pe care utilizatorul nu a solicitat-o.

În decembrie 2025, am lansat BrowseSafe, un benchmark și un model de detecție pentru această amenințare. L-am construit adăugând atacuri sintetice în pagini web realiste pe care agenții le-ar întâlni probabil. În ultimul an, atacurile au evoluat, devenind mai sofisticate și semănând tot mai mult cu conținutul obișnuit al paginilor. În loc să folosească formulări revelatoare precum „ignoră instrucțiunile anterioare”, ele imită adesea conținut în care agentul are, probabil, încredere, cum ar fi o notificare oficială a site-ului sau o notă despre preferințele utilizatorului.

Pornind de la aceste schimbări, am construit un benchmark actualizat, BrowseSafe++, pentru a măsura dacă detectoarele actuale de injecții prind aceste atacuri și dacă agenții le pot rezista. Acesta conține 38.675 de perechi de pagini atacate și curate, construite în principal în jurul unor injecții colectate în mediul real. Pentru fiecare pagină, rescriem conținutul din jur pentru a proteja confidențialitatea, dar păstrăm atacul cuvânt cu cuvânt. Fiecare pagină este disponibilă în cele patru formate pe care le citesc agenții de browser: HTML, Markdown, arbori de accesibilitate și capturi de ecran. Am folosit un subset al benchmarkului pentru a antrena BrowseSafe-Guard, o pereche de detectoare cu 0,8 miliarde de parametri: un detector de text și un detector multimodal. Cele două detectoare Guard identifică injecțiile cu o acuratețe mai mare decât modelele folosite prin prompt pe care le-am testat, inclusiv modelele de frontieră. De asemenea, sunt mai rapide, mai ieftine și semnalează din greșeală mult mai puține pagini obișnuite.

Lansăm BrowseSafe++ ca benchmark deschis. Site-ul proiectului conține linkuri către setul de date, SDK, lucrarea de cercetare și un clasament public. Orice echipă își poate evalua detectorul pe pagini de test ale căror etichete nu sunt furnizate și poate trimite etichetele pentru notare și posibila includere în clasament. Pentru a vă evalua și trimite rezultatele, consultați Primii pași.

Construirea unui benchmark din injecții observate

BrowseSafe++ este construit din injecții de prompt observate pe site-uri web reale. Între septembrie 2025 și septembrie 2026, detectorul de injecții de prompt al Comet a semnalat 1,15 milioane de injecții în paginile citite de agentul său. Am construit 32.187 de perechi în jurul acestor injecții și am adăugat 6.488 de perechi din benchmarkul BrowseSafe original, pentru un total de 38.675 de perechi. Fiecare pereche conține atât o pagină atacată, cât și geamăna sa curată, adică aceeași pagină fără injecție.

Cum arată injecțiile în mediul real

Două exemple din benchmark ilustrează cum arată aceste injecții în practică.

Într-unul dintre ele, o cerere de achiziție falsă încurajează agentul să efectueze o acțiune neautorizată. Detectorul din Comet a semnalat acest bloc de text în limba engleză pe o pagină de documentație pentru dezvoltatori în limba rusă, în octombrie 2025:

Textul începe și se încheie cu ordine, iar la mijloc conține marketing obișnuit pentru tokenuri. Pretinde că provine chiar de la dezvoltatorul agentului și se încheie cu un cod de autorizare, pentru ca achiziția să pară aprobată.

În alt exemplu, o conversație falsificată urmărește să perturbe sarcina agentului. Acest text a fost găsit pe pagina unui depozit de cod în martie 2026:

Textul este conceput să arate ca o conversație între un utilizator și un agent: <|im_start|> și <|im_end|> sunt marcaje pe care unele modele de chat le folosesc pentru a separa replicile unei conversații. Un agent care ar cădea în capcana acestui atac ar răspunde la interogarea falsificată a utilizatorului și ar reproduce fraza atacatorului.

Observăm tipare similare în rândul injecțiilor semnalate:

• Imită surse de încredere. Ambele exemple fac ca textul paginii să pară că provine de la o sursă în care agentul are încredere: dezvoltatorul său, în primul caz, și propria conversație, în al doilea. Injecțiile se pot da și drept site-ul însuși, imitând verificări de securitate și notificări privind politicile, sau drept utilizatorul, prezentând preferințe false. Aproximativ două din trei sunt scrise într-un limbaj formal.
• Multe sunt scrise în alte limbi. În 24,4% dintre perechi, injecția folosește o limbă diferită de cea a restului paginii. De obicei, aceasta ia forma unei instrucțiuni în engleză pe o pagină care nu este în engleză, ca în primul exemplu. Astfel de atacuri se adresează în mod clar unui agent care citește orice limbă și care, de regulă, funcționează nativ în engleză. Schimbările de limbă îngreunează și detecția: în evaluarea noastră inițială BrowseSafe, atacurile multilingve s-au numărat printre cele mai greu de detectat.
• Majoritatea vor acțiuni, nu cuvinte. Peste patru din zece împing agentul spre o acțiune pe care utilizatorul nu a cerut-o niciodată, precum cumpărarea tokenului din primul exemplu, iar aproximativ o treime încearcă să-l determine să abandoneze sarcina utilizatorului, ca în al doilea exemplu. Doar aproximativ 3% încearcă să introducă informații false în răspuns.
• Adesea, se folosesc de conținut pe care îl poate publica oricine. Un atacator nu trebuie să controleze un site. Ajunge o postare pe un forum sau un document partajat pe site-uri obișnuite, iar peste 23.000 de injecții din BrowseSafe++ au ajuns astfel. Chiar și un domeniu de încredere poate fi folosit pentru a injecta textul unui atacator.

Injecțiile prezente în benchmarkul final acoperă 12 tipuri de site-uri web, 24 de tipuri de atac, 6 obiective ale atacatorului și 18 poziționări în pagină.

Extinde

De la o pagină semnalată la o pereche din benchmark

Nu putem folosi paginile semnalate așa cum sunt în benchmark, deoarece acestea pot conține informații personale ale utilizatorului pentru care lucra agentul. Transformarea unei pagini într-o pereche de benchmark care poate fi distribuită necesită trei etape principale:

1. Colectarea injecției: Colectăm paginile semnalate, eliminăm duplicatele și mascăm informațiile personale cu PII-Tracer. Apoi, confirmăm că pagina conține o injecție; mai exact, cerem ca un grup de modele să fie de acord că aceasta conține o instrucțiune care încearcă să abată un agent de la sarcina dorită de utilizator.
2. Construirea perechii: Un agent elimină textul injecției din fiecare pagină și rescrie conținutul din jur, înlocuind detalii precum nume și mărci cu unele fictive. Un al doilea agent verifică pagina rescrisă pentru a depista conținut real rămas și trimite înapoi eșecurile împreună cu feedback. Evaluatori umani inspectează aleatoriu 10% dintre pagini; problemele pe care le găsesc sunt remediate în fluxul de procesare, iar corecțiile sunt aplicate în întregul corpus. Injecția este reinserată în pagina rescrisă pentru a crea copia atacată și este omisă din copia curată. Cele două pagini au aceeași sarcină, același rezultat așteptat și aceleași instrucțiuni obișnuite.
3. Verificarea: Agenții citesc paginile în forme diferite, așa că randăm codul HTML al fiecărei pagini ca Markdown, ca arbore de accesibilitate (o listă structurată a elementelor de interfață ale paginii și a etichetelor acestora) și ca captură de ecran. Un alt agent verifică dacă injecția apare în toate cele patru vizualizări ale paginii atacate și dacă pagina curată este considerată benignă în fiecare vizualizare. Dacă injecția lipsește din una dintre vizualizări, o mutăm într-un alt loc din pagină și randăm din nou, asigurându-ne că injecția apare în pagina atacată finală în toate vizualizările. Un set final de verificări automate corectează orice perechi care încă poartă urme ale sursei lor, cum ar fi nume de gazdă sau nume de mărci reale.

Extinde

BrowseSafe-Guard: detectoare rapide și precise pentru fiecare vizualizare

Un detector util trebuie să verifice fiecare pagină rapid și ieftin. De asemenea, trebuie să fie precis atât pe paginile atacate, cât și pe cele curate. Precizia ridicată este deosebit de importantă, deoarece majoritatea paginilor sunt sigure; chiar și o rată de fals pozitive relativ scăzută ar face ca majoritatea alertelor să fie alarme false. Modelele de uz general folosite prin prompt sunt adesea insuficiente la capitolul precizie și sunt prea lente și costisitoare pentru a fi rulate pe fiecare pagină.

Un detector antrenat pe pagini atacate și pagini curate colectate separat ar putea învăța scurtături care se întâmplă să separe cele două seturi, cum ar fi subiectul sau aspectul unei pagini. Un astfel de detector, însă, nu generalizează bine. În schimb, Guard se antrenează pe perechi a căror singură diferență este injecția însăși, ceea ce contribuie la îmbunătățirea preciziei detectorului. Pentru fiecare pereche, Guard citește separat pagina atacată și geamăna ei curată și îi atribuie fiecăreia un scor care indică cât de probabil este să conțină o injecție. Modelul este actualizat folosind două obiective de antrenare: obiectivul standard de clasificare și un obiectiv de ierarhizare care îl penalizează pe Guard dacă pagina atacată nu obține un scor mai mare decât geamăna ei cu cel puțin o marjă fixă. Intuitiv, obiectivul de clasificare îl învață pe Guard ce decizie să ia, iar obiectivul de ierarhizare leagă această decizie de injecția însăși și ignoră elementele de distragere benigne. Astfel, Guard este antrenat să reacționeze la injecția însăși, nu la conținutul din jur al paginii.

Guard este format din două detectoare, fiecare obținut prin ajustarea fină a modelului Qwen3.5-0.8B. Detectorul de text citește o singură reprezentare text a paginii: HTML, Markdown sau arborele de accesibilitate. Detectorul multimodal citește o captură de ecran a întregii pagini. În producție, Guard citește o pagină într-o singură trecere înainte (forward pass) și generează un scor de injecție, iar pagina este semnalată dacă scorul depășește un prag. Deoarece Guard are doar 0,8 miliarde de parametri și generează un singur scor, este suficient de rapid și de ieftin pentru a rula pe fiecare pagină.

Evaluarea comparativă a performanței

Am comparat Guard cu 18 modele folosite prin prompt pentru a detecta injecții pe un subset rezervat al benchmarkului. Raportăm patru metrici, măsurate pe BrowseSafe++:

• Recall-ul este proporția paginilor cu injecții pe care detectorul le semnalează; el măsoară câte atacuri prinde, deci o valoare mai mare este mai bună.
• Rata de fals pozitive (FPR) este proporția paginilor curate pe care detectorul le semnalează din greșeală; ea măsoară cât de des declanșează alarme false, deci o valoare mai mică este mai bună.
• Precizia este proporția paginilor semnalate care conțin cu adevărat o injecție; ea măsoară cât de des o alertă este corectă, deci o valoare mai mare este mai bună.
• F1 este media armonică dintre recall și precizie; are o valoare ridicată doar atunci când un detector prinde majoritatea atacurilor și puține dintre semnalările sale sunt alarme false.

Folosim F1 ca metrică principală, deoarece un detector bun ar trebui să aibă atât precizie, cât și recall ridicate. Toate cele patru metrici sunt calculate ca medie pe cele trei vizualizări de text.

Extinde

Extinde

Comparații între modele

Modelele mici cu ponderi deschise pe care le-am testat s-au situat la coada clasamentului. Mistral NeMo și Qwen3 30B-A3B semnalează fiecare aproximativ jumătate dintre paginile curate, în timp ce Llama 3.1 8B semnalează rareori ceva, ratând majoritatea atacurilor. Chiar și cel mai puternic model din grup, GPT-OSS 20B, atinge doar un scor F1 de 70,97%. DeepSeek V3.1, un model cu ponderi deschise mult mai mare, se descurcă puțin mai bine, cu un scor F1 de 75,23%.

Modelele API ușoare, inclusiv GPT-5.4 nano, Gemini 3.1 Flash-Lite și Claude Haiku 4.5, detectează mai multe atacuri, cu un recall între 85% și 97%. Totuși, costul îl reprezintă o proporție mare de alarme false; Gemini 3.1 Flash-Lite are cea mai mică rată FPR din grup, de 35,2%, iar rata FPR a lui Haiku este de aproape 69%. Prin urmare, scorul F1 maxim al grupului este de 80,9%, obținut de Gemini 3.1 Flash-Lite.

Celelalte modele sunt modele de uz general mai puternice, cu scoruri F1 între 85% și 92%. Totuși, ele se confruntă în continuare cu compromisuri între recall și FPR: modelele înclinate spre prudență blochează pagini legitime, iar modelele care semnalează mai rar ratează atacuri. Claude Sonnet 5 are cel mai mare recall dintre toate detectoarele, de 98,73%, dar un FPR de 24,65%. Gemini 3.1 Pro și GPT-5.5 ating un recall de 97,78%, respectiv 97,19%, cu un FPR de 19,80%, respectiv 20,44%. GPT-6 Astra are cea mai mare acuratețe generală, cu un recall de 96,42% și un FPR de 14,41%. Decider se clasează pe locul al doilea, cu un recall de 96,02% și un FPR de 17,44%. Claude Opus 5.5 are cel mai mic FPR, de doar 4,21%, dar recall-ul său de 77,71% înseamnă că ratează mai mult de unul din cinci atacuri. Claude Fable 5.1 pare puternic pe paginile la care răspunde, cu un recall de 89,31% și un FPR de 7,92%, dar refuză să răspundă la aproximativ 30% dintre pagini, pe care rândul „(all)” le consideră semnalări.

Extinde

Guard avansează frontiera Pareto, obținând un compromis mai bun între atacurile ratate și alarmele false. Atinge un scor F1 de aproximativ 95% și se clasează pe primul loc în fiecare vizualizare de text. Semnalează doar aproximativ o pagină curată din 20, cam o treime din rata lui Astra, modelul folosit prin prompt cu cea mai mare acuratețe. Această diferență provine din antrenarea noastră; modelul standard Qwen3.5-0.8B pe care este construit Guard, folosit prin prompt în același mod ca celelalte modele, atinge doar un scor F1 de 64% și semnalează aproape trei din patru pagini curate. În scenariul vizualizării prin capturi de ecran, comparăm detectorul multimodal al lui Guard cu patru modele capabile să proceseze imagini. Pe capturi de ecran ale paginilor complete, Guard obține un scor F1 de aproximativ 93%, față de aproximativ 79% pentru cel mai bun dintre celelalte modele evaluate.

A recunoaște un atac nu înseamnă a-i rezista

Intuitiv, un model care poate identifica corect o injecție ar trebui să o și ignore atunci când întâlnește pagina în timp ce îndeplinește sarcinile utilizatorului. Totuși, experimentele noastre arată că scorurile bune de detecție nu garantează că un model va rezista unui atac. Am dat fiecărui model aceeași pagină atacată de două ori: o dată pentru a evalua dacă aceasta conține o injecție și o dată pentru a îndeplini sarcina utilizatorului fără a vedea verdictul anterior. Un evaluator separat a verificat dacă modelul a urmat injecția. Fiecare model testat a urmat totuși unele injecții pe care le semnalase, de la 1,64% dintre paginile semnalate pentru GPT-6 Astra până la 24,73% pentru Llama 3.1 8B.

Extinde

Scorurile de detecție nu prezic în mod fiabil diferențele dintre modele. Claude Sonnet 5 și GPT-5.5 detectează injecțiile aproximativ la fel de bine, cu scoruri F1 de aproximativ 88%, respectiv 89%. Totuși, Sonnet 5 a urmat o injecție pe care o semnalase în 19,74% dintre pagini, de zece ori mai des decât GPT-5.5, cu 1,97%.

Un sistem implementabil pentru apărarea împotriva injecțiilor

Aceste rezultate sugerează că este util să delegăm decizia de a bloca o pagină unui model specializat, în loc să ne bazăm pe modelul care îndeplinește sarcina utilizatorului. Un detector separat, care verifică fiecare pagină înainte ca agentul să acționeze, oferă un strat suplimentar de apărare și nu are nicio sarcină care să poată fi deturnată și niciun instrument care să poată fi folosit abuziv.

Guard este conceput pentru a fi acel detector. Pe lângă faptul că are cel mai mare scor F1 și cea mai mare acuratețe dintre toate modelele testate, dimensiunea sa redusă îl face suficient de ieftin pentru a rula pe fiecare pagină. În medie, Guard a folosit aproximativ 0,15 secunde de timp GPU per pagină de text. Pe un H200 închiriat, estimăm un cost de 0,18 $ la 1.000 de pagini, comparativ cu 18,95–180,61 $ pentru modelele API de frontieră, la prețurile de listă. În comparația noastră, acest lucru face ca scanarea frecventă să fie mult mai ieftină, păstrând în același timp scoruri ridicate de detecție.

Figura de mai jos reprezintă acuratețea fiecărui detector în raport cu timpul pe pagină și cu costul la 1.000 de pagini, ambele pe scări logaritmice. Guard se află singur în colțul din stânga sus al ambelor panouri: câștigă la acuratețe, viteză și cost. Fiecare model folosit prin prompt are nevoie de aproximativ o secundă sau mai mult per pagină, iar cele două modele cu cea mai mare acuratețe, GPT-6 Astra și Claude Fable 5.1, costă peste 100 $ la 1.000 de pagini.

Extinde

Testarea apărărilor împotriva atacurilor adaptive

Benchmarkul BrowseSafe++ are un set finit de injecții. Totuși, un atacator real poate lansa un atac adaptiv: atunci când o injecție eșuează, atacatorul o poate rescrie și poate încerca din nou. Prin urmare, un agent care rezistă injecției originale ar putea fi totuși vulnerabil la atacuri viitoare. Mai mult, modelele sunt antrenate pe date colectate de pe internet, așa că ar putea învăța să reziste majorității injecțiilor din acesta; întrucât lansăm benchmarkul public, este probabil ca acesta să se satureze și să nu mai diferențieze bine modelele. Pentru a rezolva ambele probleme, am construit BrowseSafe-Adapt, un mediu de testare în care un model atacator poate rescrie injecțiile. Fiecare test are trei etape:

1. Configurarea cazului. Un caz grupează o intrare BrowseSafe++ cu un agent țintă. Intrarea BrowseSafe++ include un scenariu cu o interogare și o sarcină ale utilizatorului, o pagină atacată și rezultatul dorit de atacator. Agentul lucrează într-un sandbox care oferă instrumentele și datele sintetice necesare pentru executarea sarcinii. Un model verificator separat evaluează dacă atacul și-a atins scopul.
2. Rularea unei încercări: Inserăm injecția curentă în pagină și lăsăm agentul să îndeplinească sarcina. Verificatorul examinează răspunsul agentului și orice modificări aduse de acesta sandboxului pentru a determina dacă atacul a reușit. Prima încercare folosește injecția din intrarea BrowseSafe++ originală.
3. Revizuire și repetare: Dacă un atac eșuează, arhivăm încercarea, iar un model critic analizează ce nu a funcționat. Un model atacator folosește acel feedback pentru a rescrie injecția; poate modifica formularea, formatarea sau poziția atacului în pagină. Obiectivul atacului, criteriile de succes și conținutul din jur al paginii rămân aceleași. Următoarea încercare folosește atacul actualizat. Acest proces se repetă până când atacul reușește sau atacatorul atinge o limită stabilită de încercări.

Extinde

Am testat șapte agenți, fiecare construit pe un model diferit: Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite și modelele cu ponderi deschise DeepSeek V3.1 și Kimi K2. Fiecare agent a primit aceleași 1.024 de sarcini, cu până la 64 de încercări per sarcină. La prima încercare, succesul atacurilor a fost scăzut pentru toți cei șapte agenți. Injecțiile originale au reușit în cel mult 4% dintre sarcinile evaluate, indiferent de agent. În cadrul adaptiv, succesul atacurilor a crescut spectaculos. Atacatorul a reușit în cel puțin 79% dintre sarcini împotriva a cinci dintre cei șapte agenți. Chiar și cei mai robuști agenți au fost vulnerabili: atacurile au reușit în continuare în aproximativ două din trei sarcini împotriva GPT-5.5 și în aproximativ una din trei împotriva Claude Sonnet 5.

Diferența dintre agenți este cea mai mare atunci când obiectivul atacatorului este să determine agentul să efectueze un anumit apel de instrument. Pentru sarcinile cu acest tip de obiectiv, Sonnet 5 a cedat în aproximativ 8% dintre sarcini, iar GPT-5.5 în aproximativ 29%. Ceilalți cinci au îndeplinit obiectivul atacatorului în peste jumătate dintre sarcinile lor.

Am rulat, de asemenea, BrowseSafe-Adapt împotriva agentului Gemini 3.5 Flash-Lite, cu Guard verificând mai întâi fiecare pagină. Guard a blocat 94,5% dintre injecțiile originale și aproape a dublat numărul mediu de încercări de care au avut nevoie atacatorii, de la 9,7 la 17,0. Totuși, având la dispoziție toate cele 64 de încercări, atacatorul a reușit în continuare în 84,2% dintre sarcini (93,6% fără Guard), aproape întotdeauna cu o injecție pe care Guard nu a semnalat-o. Acest lucru confirmă perspectiva pe care am prezentat-o când am lansat BrowseSafe: niciun model de detecție nu este o soluție miraculoasă, așa că un detector trebuie integrat într-o apărare stratificată.

Extinde

Concluzie

Agenții de browser sunt adesea vulnerabili la injecția indirectă de prompt, în care atacuri ascunse în pagini obișnuite urmăresc să interfereze cu capacitatea agenților de a îndeplini sarcinile utilizatorilor. Pericolele nu fac decât să crească în timp, atât pe măsură ce agenții obțin acces la mai multe date și instrumente, ceea ce ridică miza potențială a atacurilor, cât și pe măsură ce atacatorii își pot revizui injecțiile pentru a le face mai eficiente.

Suita noastră BrowseSafe abordează aceste amenințări. Benchmarkul BrowseSafe++ conține 38.675 de perechi de pagini web construite în principal din injecții reale, permițând o antrenare și o evaluare mai fiabile ale detectoarelor. Detectoarele BrowseSafe-Guard, antrenate pe aceste perechi, permit o detecție foarte precisă, rapidă și ieftină, făcând posibilă scanarea paginilor înainte ca un agent să acționeze pe baza lor. Cadrul BrowseSafe-Adapt permite testarea modelelor împotriva injecțiilor revizuite, evidențiind vulnerabilități care ar putea să nu fie vizibile în încercări unice cu injecții fixe.

Sperăm ca, împreună, aceste instrumente să le permită cercetătorilor și inginerilor să găsească mai ușor eșecurile și să îmbunătățească apărările împotriva atacurilor de injecție de prompt bazate pe web. De asemenea, evaluăm și îmbunătățim continuu apărările integrate în Comet și Computer pentru a-i menține în siguranță pe utilizatorii noștri.

Primii pași

1. Instalați SDK-ul și obțineți acces la date. SDK-ul se instalează din GitHub:

Accesul la setul de date este restricționat. Solicitați o singură dată accesul pe pagina sa de pe Hugging Face, apoi autentificați-vă cu hf auth login.

2. Trimiteți rezultatele în clasament. Evaluați propriul detector pe subsetul de test al BrowseSafe++:

Aceasta scrie câte o decizie per pagină pentru fiecare reprezentare pe care o specificați; specificați toate cele trei reprezentări text pentru a obține o medie în clasamentul pentru text. Conectați-vă la Space-ul clasamentului cu contul dvs. Hugging Face și încărcați predictions.jsonl. Space-ul returnează F1, acuratețea, rata de rezultate fals pozitive și celelalte metrici pentru fiecare reprezentare și, dacă doriți, publică rezultatul în clasament. Fiecare cont (vechi de cel puțin 60 de zile) are dreptul la o trimitere evaluată pe săptămână UTC. Paginile de test sunt destinate exclusiv evaluării: nu le folosiți pentru antrenare și nu le redistribuiți. Ghidul de trimitere descrie formatul fișierului și regulile de publicare.

Citare

@online{perplexity2026BrowseSafePlusPlus,
  author = {{Perplexity} and Yuetian Chen and Kaiyuan Zhang and Yuntao Du and Thomas Li and Mark Tenenholtz and Kyle Polley and Jerry Ma and Denis Yarats and Ninghui Li and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{BrowseSafe++: Building stronger defenses against real-world prompt injection}},
  date = {2026-10-28},
  url = {https://www.perplexity.ai/hub/blog/browsesafe-plus-plus}
}