BrowseSafe++: defenses més sòlides contra la injecció de prompts en entorns reals

Els agents que poden navegar pel web, com ara l’assistent integrat a Comet o Computer, han d’interactuar amb pàgines web, llegint-ne el contingut i utilitzant-lo per dur a terme accions en nom dels seus usuaris. Això els fa vulnerables a la injecció indirecta de prompts, en què un atacant col·loca text maliciós en una pàgina web. Si l’agent segueix aquestes instruccions, pot retornar una resposta enganyosa o dur a terme una acció que l’usuari no ha sol·licitat.

El desembre de 2025 vam llançar BrowseSafe, un banc de proves i un model de detecció per a aquesta amenaça. El vam crear afegint atacs sintètics a pàgines web realistes que els agents probablement trobarien. Durant l’últim any, els atacs han evolucionat per ser més sofisticats i semblar-se més al contingut habitual d’una pàgina. En lloc de fer servir frases delatores com ara «ignora les instruccions anteriors», sovint imiten contingut en què l’agent probablement confiaria, com ara un avís oficial del lloc o una nota sobre les preferències de l’usuari.

Motivats per aquests canvis, hem creat un banc de proves actualitzat, BrowseSafe++, per mesurar si els detectors d’injeccions actuals detecten aquests atacs i si els agents els poden resistir. Conté 38.675 parells de pàgines atacades i netes, construïts principalment al voltant d’injeccions recollides en el món real. Per a cada pàgina, reescrivim el contingut circumdant per protegir la privadesa, però mantenim l’atac literalment. Cada pàgina es presenta en els quatre formats que llegeixen els agents de navegador: HTML, Markdown, arbres d’accessibilitat i captures de pantalla. Hem utilitzat un subconjunt del banc de proves per entrenar BrowseSafe-Guard, un parell de detectors de 0,8B de paràmetres: un detector de text i un detector multimodal. Els dos detectors de Guard identifiquen les injeccions amb més exactitud que els models amb prompt que hem provat, inclosos els models de frontera. També són més ràpids i més econòmics, i marquen per error moltes menys pàgines normals.

Publiquem BrowseSafe++ com a banc de proves obert. El lloc web del projecte enllaça al conjunt de dades, a l’SDK, a l’article de recerca i a una classificació pública. Qualsevol equip pot puntuar el seu detector amb pàgines de prova les etiquetes de les quals no es proporcionen i enviar les etiquetes perquè es qualifiquin i, possiblement, s’incloguin a la classificació. Per avaluar i enviar els resultats, consulteu Primers passos.

Creació d’un banc de proves a partir d’injeccions observades

BrowseSafe++ s’ha creat a partir d’injeccions de prompts observades en llocs web reals. Entre setembre de 2025 i setembre de 2026, el detector d’injeccions de prompts de Comet va marcar 1,15 milions d’injeccions en pàgines que llegia el seu agent. Vam crear 32.187 parells al voltant d’aquestes injeccions i vam afegir-hi 6.488 parells del banc de proves BrowseSafe original, per a un total de 38.675 parells. Cada parell conté una pàgina atacada i la seva bessona neta, que és la mateixa pàgina sense la injecció.

Com són les injeccions en el món real

Dos exemples del banc de proves mostren com són aquestes injeccions a la pràctica.

En un d’ells, una sol·licitud de compra falsa incita l’agent a dur a terme una acció no autoritzada. El detector de Comet va marcar aquest bloc de text en anglès en una pàgina de documentació per a desenvolupadors en rus l’octubre de 2025:

El text comença i acaba amb ordres i omple la part central amb màrqueting habitual de tokens. Afirma que prové del mateix desenvolupador de l’agent i acaba amb un codi d’autorització perquè la compra sembli aprovada.

En un altre, una conversa falsificada pretén pertorbar la tasca de l’agent. Aquest text es va trobar en una pàgina d’un repositori de codi el març de 2026:

El text està dissenyat perquè sembli una conversa entre un usuari i un agent: <|im_start|> i <|im_end|> són marcadors que alguns models de xat utilitzen per separar els torns d’una conversa. Un agent que caigués en aquest atac respondria a la consulta d’usuari falsificada i contestaria amb la frase de l’atacant.

Observem patrons similars en les injeccions marcades:

• Imiten fonts de confiança. Tots dos exemples fan que el text de la pàgina sembli provenir d’una font en què l’agent confia: el seu desenvolupador en el primer cas i la seva pròpia conversa en el segon. Les injeccions també es poden fer passar pel mateix lloc, imitant comprovacions de seguretat i avisos de polítiques, o per l’usuari, presentant preferències falses. Aproximadament dues de cada tres estan redactades en un llenguatge formal.
• Moltes estan escrites en altres llengües. En el 24,4 % dels parells, la injecció utilitza una llengua diferent de la de la resta de la pàgina. Normalment, es tracta d’una instrucció en anglès en una pàgina que no és en anglès, com en el primer exemple. Aquests atacs s’adrecen clarament a un agent que llegeix totes les llengües i que sol tenir l’anglès com a llengua nativa. Els canvis de llengua també dificulten la detecció: en la nostra avaluació original de BrowseSafe, els atacs multilingües eren dels més difícils de detectar.
• La majoria volen accions, no paraules. Més de quatre de cada deu empenyen l’agent cap a una acció que l’usuari no ha demanat mai, com la compra del token del primer exemple, i aproximadament un terç intenten que abandoni la tasca de l’usuari, com en el segon exemple. Només aproximadament un 3 % intenten introduir informació falsa a la resposta.
• Sovint s’aprofiten de contingut que qualsevol pot publicar. Un atacant no necessita controlar un lloc. N’hi ha prou amb una publicació en un fòrum o un document compartit en llocs habituals, i més de 23.000 injeccions de BrowseSafe++ van arribar d’aquesta manera. Fins i tot un domini de confiança es pot utilitzar per injectar el text d’un atacant.

Les injeccions presents al banc de proves final abasten 12 tipus de llocs web, 24 tipus d’atac, 6 objectius de l’atacant i 18 ubicacions a la pàgina.

Amplia

D’una pàgina marcada a un parell del banc de proves

No podem utilitzar les pàgines marcades tal com són al banc de proves, perquè poden contenir informació personal de l’usuari per a qui treballava l’agent. Convertir una pàgina en un parell del banc de proves que es pugui compartir requereix tres fases principals:

1. Obtenir la injecció: Recollim les pàgines marcades, eliminem els duplicats i emmascarem la informació personal amb PII-Tracer. A continuació, confirmem que la pàgina conté una injecció; concretament, exigim que un grup de models coincideixi que conté una instrucció que intenta desviar un agent de la tasca que l’usuari pretenia fer.
2. Crear el parell: Un agent elimina el text de la injecció de cada pàgina i reescriu el contingut circumdant de la pàgina, substituint detalls com ara noms i marques per altres de ficticis. Un segon agent comprova si la pàgina reescrita conté restes de contingut real i retorna els errors amb comentaris. Revisors humans inspeccionen un 10 % aleatori de les pàgines; els problemes que troben es corregeixen al procés, i les correccions s’apliquen a tot el corpus. La injecció es torna a inserir a la pàgina reescrita per crear la còpia atacada i s’omet de la còpia neta. Les dues pàgines comparteixen la mateixa tasca, el mateix resultat esperat i les mateixes instruccions normals.
3. Verificar: Els agents llegeixen les pàgines en formes diferents, de manera que convertim l’HTML de cada pàgina en Markdown, en un arbre d’accessibilitat (una llista estructurada dels elements de la interfície d’una pàgina i les seves etiquetes) i en una captura de pantalla. Un altre agent comprova que la injecció aparegui a les quatre vistes de la pàgina atacada i que la pàgina neta es consideri benigna en totes les vistes. Si la injecció falta en alguna de les vistes, la movem a un altre lloc de la pàgina i la tornem a renderitzar, de manera que la injecció aparegui a la pàgina atacada final en totes les vistes. Un conjunt final de comprovacions automatitzades corregeix els parells que encara contenen rastres del seu origen, com ara noms d’amfitrió o noms de marca reals.

Amplia

BrowseSafe-Guard: detectors ràpids i precisos per a cada vista

Un detector útil ha de comprovar cada pàgina de manera ràpida i econòmica. També ha de ser exacte tant en pàgines atacades com en pàgines netes. Una precisió alta és especialment important, ja que la majoria de les pàgines són segures; fins i tot una taxa de falsos positius relativament baixa faria que la majoria de les alertes fossin falses alarmes. Els models de propòsit general amb prompt sovint no tenen prou precisió i són massa lents i costosos per executar-los en cada pàgina.

Un detector entrenat amb pàgines atacades i netes recollides per separat podria aprendre dreceres que casualment separen els dos conjunts, com ara el tema o el disseny d’una pàgina. Tanmateix, un detector així no generalitza bé. En canvi, Guard s’entrena amb parells en què l’única diferència és la mateixa injecció, cosa que ajuda a millorar la precisió del detector. Per a cada parell, Guard llegeix per separat la pàgina atacada i la seva bessona neta, i assigna a cadascuna una puntuació segons la probabilitat que contingui una injecció. S’utilitzen dos objectius d’entrenament per actualitzar el model: l’objectiu de classificació estàndard i un objectiu de rànquing que penalitza Guard tret que la pàgina atacada obtingui una puntuació superior a la de la seva bessona com a mínim en un marge fix. Intuïtivament, l’objectiu de classificació ensenya a Guard quina decisió ha de prendre, i l’objectiu de rànquing vincula aquesta decisió a la mateixa injecció i ignora els elements distractors benignes. Això entrena Guard perquè respongui a la injecció en si, en lloc de fer-ho al contingut de la pàgina que l’envolta.

Guard consta de dos detectors, cadascun obtingut mitjançant l’ajust fi de Qwen3.5-0.8B. El detector de text llegeix una vista de text d’una pàgina: HTML, Markdown o arbre d’accessibilitat. El detector multimodal llegeix una captura de pantalla de la pàgina completa. En el desplegament, Guard llegeix una pàgina en una sola passada endavant i genera una puntuació d’injecció, i la pàgina es marca si la puntuació supera un llindar. Com que Guard només té 800 milions de paràmetres i genera una única puntuació, és prou ràpid i econòmic per executar-lo a cada pàgina.

Avaluació del rendiment

Vam comparar Guard amb 18 models als quals vam demanar mitjançant un prompt que detectessin injeccions en un subconjunt reservat del banc de proves. Informem de quatre mètriques, mesurades a BrowseSafe++:

• L’exhaustivitat (recall) és la proporció de pàgines amb injecció que el detector marca, cosa que mesura quants atacs detecta, de manera que com més alta, millor.
• La taxa de falsos positius (FPR) és la proporció de pàgines netes que el detector marca per error, cosa que mesura amb quina freqüència genera falses alarmes, de manera que com més baixa, millor.
• La precisió és la proporció de pàgines marcades que realment contenen una injecció, cosa que mesura amb quina freqüència una alerta és correcta, de manera que com més alta, millor.
• L’F1 és la mitjana harmònica de l’exhaustivitat i la precisió; només és alta quan un detector detecta la majoria dels atacs i poques de les seves marques són falses alarmes.

Utilitzem F1 com a mètrica principal, ja que un bon detector ha de tenir una precisió i una exhaustivitat altes. Les quatre mètriques es calculen com a mitjana de les tres vistes de text.

Amplia

Amplia

Comparacions de models

Els models petits de pesos oberts que vam provar van quedar a la part inferior. Mistral NeMo i Qwen3 30B-A3B marquen aproximadament la meitat de les pàgines netes, mentre que Llama 3.1 8B rarament marca res i no detecta la majoria dels atacs. Fins i tot el model més potent del grup, GPT-OSS 20B, només arriba a un F1 del 70,97 %. DeepSeek V3.1, un model de pesos oberts molt més gran, obté un resultat lleugerament millor, amb un F1 del 75,23 %.

Els models d’API lleugers, com ara GPT-5.4 nano, Gemini 3.1 Flash-Lite i Claude Haiku 4.5, detecten més atacs, amb una sensibilitat (recall) d’entre el 85 % i el 97 %. Tanmateix, el preu és una proporció elevada de falses alarmes: Gemini 3.1 Flash-Lite té la taxa de falsos positius (FPR) més baixa del grup, amb un 35,2 %, i la FPR de Haiku és de gairebé el 69 %. Com a resultat, la puntuació F1 màxima del grup és del 80,9 %, assolida per Gemini 3.1 Flash-Lite.

La resta de models són models de propòsit general més potents, que arriben a puntuacions F1 d’entre el 85 % i el 92 %. Tanmateix, encara han d’assumir compromisos entre l’exhaustivitat i la FPR: els models que tendeixen a la cautela bloquegen pàgines legítimes, i els models que marquen amb menys freqüència no detecten atacs. Claude Sonnet 5 té l’exhaustivitat més alta de tots els detectors, amb un 98,73 %, però una FPR del 24,65 %. Gemini 3.1 Pro i GPT-5.5 arriben a exhaustivitats del 97,78 % i el 97,19 %, amb FPR del 19,80 % i el 20,44 %, respectivament. GPT-6 Astra té l’exactitud global més alta, amb una exhaustivitat del 96,42 % i una FPR del 14,41 %. Decider queda en segon lloc, amb una exhaustivitat del 96,02 % i una FPR del 17,44 %. Claude Opus 5.5 té la FPR més baixa, de només el 4,21 %, però la seva exhaustivitat del 77,71 % implica que no detecta més d’un de cada cinc atacs. Claude Fable 5.1 sembla sòlid en les pàgines que respon, amb una exhaustivitat del 89,31 % i una FPR del 7,92 %, però es nega a respondre en aproximadament el 30 % de les pàgines, que la fila «(all)» compta com a marques.

Amplia

Guard fa avançar la frontera de Pareto i aconsegueix un millor equilibri entre atacs no detectats i falses alarmes. Arriba a un F1 d’aproximadament el 95 % i ocupa el primer lloc en totes les vistes de text. Només marca aproximadament una de cada 20 pàgines netes, prop d’un terç de la taxa d’Astra, el model amb prompt més exacte. Aquesta diferència prové del nostre entrenament: el Qwen3.5-0.8B estàndard en què es basa Guard, amb el mateix prompt que els altres models, només arriba a un F1 del 64 % i marca gairebé tres de cada quatre pàgines netes. En l’escenari de la vista de captura de pantalla, comparem el detector multimodal de Guard amb quatre models capaços de processar imatges. Amb captures de pantalla de pàgina completa, Guard obté un F1 d’aproximadament el 93 %, enfront d’aproximadament el 79 % del millor dels altres models que hem avaluat.

Reconèixer un atac no és el mateix que resistir-lo

Intuïtivament, un model que pot identificar correctament una injecció també l’hauria d’ignorar quan troba la pàgina mentre completa les tasques de l’usuari. Tanmateix, els nostres experiments mostren que unes puntuacions de detecció altes no garanteixen que un model resisteixi un atac. Vam donar a cada model la mateixa pàgina atacada dues vegades: una per determinar si contenia una injecció i una altra per dur a terme la tasca de l’usuari sense veure el veredicte anterior. Un jutge independent va comprovar si seguia la injecció. Tots els models provats van seguir algunes injeccions que havien marcat, des de l’1,64 % de les pàgines marcades en el cas de GPT-6 Astra fins al 24,73 % en el de Llama 3.1 8B.

Amplia

Les puntuacions de detecció no prediuen de manera fiable les diferències entre models. Claude Sonnet 5 i GPT-5.5 detecten les injeccions aproximadament igual de bé, amb puntuacions F1 d’aproximadament el 88 % i el 89 %, respectivament. Tanmateix, Sonnet 5 va seguir una injecció que havia marcat en el 19,74 % de les pàgines, deu vegades més sovint que GPT-5.5, amb un 1,97 %.

Un sistema desplegable per a la defensa contra injeccions

Aquests resultats suggereixen que té valor delegar la decisió de bloquejar una pàgina a un model específic, en lloc de dependre del model que duu a terme la tasca de l’usuari. Un detector independent que analitza cada pàgina abans que l’agent actuï proporciona una capa de defensa addicional i no té cap tasca que es pugui segrestar ni eines de les quals es pugui fer un mal ús.

Guard s’ha creat per ser aquest detector. A més de tenir la puntuació F1 i l’exactitud més altes de tots els models que hem provat, la seva mida reduïda el fa prou econòmic per executar-lo a cada pàgina. De mitjana, Guard va utilitzar uns 0,15 segons de temps de GPU per pàgina de text. En una H200 de lloguer, estimem un cost de 0,18 $ per cada 1.000 pàgines, en comparació amb un cost d’entre 18,95 $ i 180,61 $ dels models de frontera via API a preus de llista. En la nostra comparació, això fa que l’anàlisi freqüent sigui molt més econòmica i, alhora, mantingui unes puntuacions de detecció altes.

La figura següent representa l’exactitud de cada detector en relació amb el seu temps per pàgina i el seu cost per cada 1.000 pàgines, tots dos en escales logarítmiques. Guard se situa sol a l’angle superior esquerre de tots dos panells: guanya en exactitud, velocitat i cost. Tots els models amb prompt triguen aproximadament un segon o més per pàgina, i els dos més exactes, GPT-6 Astra i Claude Fable 5.1, costen més de 100 $ per cada 1.000 pàgines.

Amplia

Proves de les defenses contra atacs adaptatius

El banc de proves BrowseSafe++ té un conjunt finit d’injeccions. Tanmateix, un atacant real pot dur a terme un atac adaptatiu: quan una injecció falla, l’atacant la pot reescriure i tornar-ho a provar. Com a resultat, un agent que resisteix la injecció original encara podria ser vulnerable a atacs futurs. A més, els models s’entrenen amb dades recollides d’internet, de manera que poden aprendre a resistir la majoria de les injeccions que hi troben; com que fem públic el nostre banc de proves, és probable que se saturi i deixi de diferenciar bé els models. Per abordar tots dos problemes, hem creat BrowseSafe-Adapt, un entorn d’avaluació en què un model atacant pot reescriure injeccions. Cada prova té tres fases:

1. Configuració del cas. Un cas agrupa una entrada de BrowseSafe++ amb un agent objectiu. L’entrada de BrowseSafe++ inclou un escenari amb una consulta i una tasca de l’usuari, una pàgina atacada i el resultat que vol aconseguir l’atacant. L’agent treballa en un entorn de proves que proporciona les eines i les dades sintètiques necessàries per executar la tasca. Un model verificador independent avalua si l’atac ha assolit el seu objectiu.
2. Executar un intent: Inserim la injecció actual a la pàgina i deixem que l’agent dugui a terme la tasca. El verificador comprova la resposta de l’agent i qualsevol canvi que hagi fet a l’entorn de proves per determinar si l’atac ha tingut èxit. El primer intent utilitza la injecció de l’entrada original de BrowseSafe++.
3. Revisar i repetir: Si un atac falla, arxivem l’intent i un model crític revisa què ha fallat. Un model atacant utilitza aquesta retroalimentació per reescriure la injecció; pot canviar la redacció, el format o la posició de l’atac a la pàgina. L’objectiu de l’atac, els criteris d’èxit i el contingut circumdant de la pàgina es mantenen igual. L’intent següent utilitza l’atac actualitzat. Aquest procés es repeteix fins que l’atac té èxit o l’atacant arriba a un límit d’intents establert.

Amplia

Vam provar set agents, cadascun basat en un model diferent: Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite i els models de pesos oberts DeepSeek V3.1 i Kimi K2. Cada agent es va enfrontar a les mateixes 1.024 tasques, amb un màxim de 64 intents per tasca. En el primer intent, l’èxit dels atacs va ser baix en tots els set agents. Les injeccions originals van tenir èxit, com a màxim, en el 4 % de les tasques avaluades contra qualsevol agent. Amb el marc adaptatiu, l’èxit dels atacs va augmentar de manera espectacular. L’atacant va tenir èxit en almenys el 79 % de les tasques contra cinc dels set agents. Fins i tot els agents més robustos eren vulnerables: els atacs encara van tenir èxit en aproximadament dues de cada tres tasques contra GPT-5.5 i en aproximadament una de cada tres contra Claude Sonnet 5.

La diferència entre agents és més gran quan l’objectiu de l’atacant és fer que l’agent executi una crida d’eina concreta. En les tasques amb aquest tipus d’objectiu, Sonnet 5 va cedir en aproximadament el 8 % de les tasques i GPT-5.5, en aproximadament el 29 %. Els altres cinc van dur a terme l’objectiu de l’atacant en més de la meitat de les seves tasques.

També vam executar BrowseSafe-Adapt contra l’agent de Gemini 3.5 Flash-Lite, amb Guard analitzant primer cada pàgina. Guard va bloquejar el 94,5 % de les injeccions originals i gairebé va duplicar el nombre mitjà d’intents que necessitaven els atacants, de 9,7 a 17,0. Tanmateix, amb el total de 64 intents, l’atacant va tenir èxit en el 84,2 % de les tasques (el 93,6 % sense Guard), gairebé sempre amb una injecció que Guard no havia marcat. Això coincideix amb la visió que vam exposar quan vam publicar BrowseSafe: cap model de detecció és una solució màgica, de manera que un detector s’ha d’integrar en una defensa per capes.

Amplia

Conclusió

Els agents de navegador sovint són vulnerables a la injecció indirecta de prompts, en què atacs amagats en pàgines normals intenten interferir en la capacitat dels agents de dur a terme les tasques dels usuaris. Els perills només augmenten amb el temps, tant perquè els agents obtenen accés a més dades i eines, cosa que augmenta el que hi ha en joc en els atacs, com perquè els atacants poden revisar les seves injeccions perquè siguin més efectives.

El nostre conjunt d’eines BrowseSafe fa front a aquestes amenaces. El banc de proves BrowseSafe++ conté 38.675 parells de pàgines web creats principalment a partir d’injeccions reals, cosa que permet un entrenament i una avaluació més fiables dels detectors. Els detectors BrowseSafe-Guard, entrenats amb aquests parells, permeten una detecció molt precisa, ràpida i econòmica, cosa que fa possible analitzar les pàgines abans que un agent actuï a partir d’aquestes pàgines. El marc BrowseSafe-Adapt permet provar models contra injeccions revisades i posa de manifest vulnerabilitats que podrien no ser evidents en intents únics amb injeccions fixes.

Esperem que, conjuntament, aquestes eines facilitin que els investigadors i els enginyers trobin fallades i millorin les defenses contra els atacs d’injecció de prompts basats en el web. També avaluem i millorem contínuament les defenses integrades de Comet i Computer per mantenir segurs els nostres usuaris.

Primers passos

1. Instal·leu l’SDK i obteniu accés a les dades. L’SDK s’instal·la des de GitHub:

El conjunt de dades té accés restringit. Sol·liciteu-hi accés una sola vegada a la seva pàgina de Hugging Face i, després, inicieu la sessió amb hf auth login.

2. Envieu els resultats a la classificació. Avalueu el vostre detector amb la partició de prova de BrowseSafe++:

Això escriu una decisió per pàgina per a cada vista que indiquis; indica les tres vistes de text per obtenir una mitjana a la classificació de text. Inicia la sessió a l’Space de la classificació amb el teu compte de Hugging Face i penja predictions.jsonl. L’Space retorna la puntuació F1, l’exactitud, la taxa de falsos positius i les altres mètriques de cada vista i, si ho vols, publica el resultat a la classificació. Cada compte (amb una antiguitat mínima de 60 dies) pot fer un enviament puntuat per setmana UTC. Les pàgines de prova són només per a avaluació: no les facis servir per entrenar ni les redistribueixis. La guia d’enviament explica el format del fitxer i les normes de publicació.

Citació

@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}
}