BrowseSafe++: sterkere verdediging bouwen tegen promptinjectie in de praktijk

Agents die op het web kunnen browsen, zoals de assistent die is ingebouwd in Comet of Computer, moeten met webpagina’s interacteren: ze lezen content en gebruiken die om namens hun gebruikers acties uit te voeren. Dit maakt ze vatbaar voor indirecte promptinjectie, waarbij een aanvaller kwaadaardige tekst op een webpagina plaatst. Als de agent deze instructies volgt, kan hij een misleidend antwoord geven of een actie uitvoeren waar de gebruiker niet om heeft gevraagd.

In december 2025 brachten we BrowseSafe uit, een benchmark en detectiemodel voor deze dreiging. We hebben het gebouwd door synthetische aanvallen toe te voegen aan realistische webpagina's die agents waarschijnlijk zouden tegenkomen. Het afgelopen jaar zijn aanvallen geavanceerder geworden en lijken ze steeds meer op gewone pagina-inhoud. In plaats van herkenbare zinnen als ‘negeer eerdere instructies’ te gebruiken, bootsen ze vaak inhoud na die de agent waarschijnlijk vertrouwt, zoals een officiële mededeling van de site of een notitie over gebruikersvoorkeuren.

Naar aanleiding van deze veranderingen hebben we een bijgewerkte benchmark gebouwd, BrowseSafe++, om te meten of de huidige injectiedetectoren deze aanvallen onderscheppen en of agents ze kunnen weerstaan. Deze bevat 38.675 paren van aangevallen en schone pagina’s, voornamelijk opgebouwd rond injecties die in de praktijk zijn verzameld. Voor elke pagina herschrijven we de omringende content om de privacy te beschermen, maar laten we de aanval letterlijk intact. Elke pagina is beschikbaar in de vier formaten die browseragents lezen: HTML, Markdown, toegankelijkheidsbomen en screenshots. We hebben een subset van de benchmark gebruikt om BrowseSafe-Guard te trainen, een tweetal detectoren met 0,8 miljard parameters: een tekstdetector en een multimodale detector. De twee Guard-detectoren herkennen injecties nauwkeuriger dan de geprompte modellen die we hebben getest, inclusief frontiermodellen. Ze zijn bovendien sneller en goedkoper, en markeren veel minder gewone pagina’s ten onrechte.

We brengen BrowseSafe++ uit als open benchmark. De projectwebsite bevat links naar de dataset, SDK, het onderzoeksartikel en een openbare ranglijst. Elk team kan zijn detector laten scoren op testpagina’s waarvan de labels niet worden verstrekt, en de labels indienen voor beoordeling en mogelijke opname in de ranglijst. Zie Aan de slag om je resultaten te evalueren en in te dienen.

Een benchmark bouwen op basis van waargenomen injecties

BrowseSafe++ is opgebouwd uit promptinjecties die op echte websites zijn waargenomen. Tussen september 2025 en september 2026 markeerde de promptinjectiedetector van Comet 1,15 miljoen injecties op pagina’s die de agent las. We hebben 32.187 paren rond die injecties gebouwd en 6.488 paren uit de oorspronkelijke BrowseSafe-benchmark toegevoegd, voor een totaal van 38.675 paren. Elk paar bevat zowel een aangevallen pagina als de schone tweelingpagina: dezelfde pagina zonder de injectie.

Hoe injecties er in de praktijk uitzien

Twee voorbeelden uit de benchmark laten zien hoe deze injecties er in de praktijk uitzien.

In het ene voorbeeld zet een vals aankoopverzoek de agent aan tot een ongeautoriseerde actie. De detector van Comet markeerde in oktober 2025 dit blok Engelse tekst op een Russischtalige pagina met ontwikkelaarsdocumentatie:

De tekst begint en eindigt met opdrachten en vult het midden met gewone tokenmarketing. Hij beweert afkomstig te zijn van de eigen ontwikkelaar van de agent en eindigt met een autorisatiecode om de aankoop goedgekeurd te laten lijken.

In een ander voorbeeld probeert een vervalst gesprek de taak van de agent te verstoren. Deze tekst werd in maart 2026 gevonden op een pagina van een coderepository:

De tekst is zo opgezet dat hij lijkt op een gesprek tussen een gebruiker en een agent: <|im_start|> en <|im_end|> zijn markers die sommige chatmodellen gebruiken om de beurten in een gesprek van elkaar te scheiden. Een agent die in deze aanval trapt, zou reageren op de vervalste gebruikersvraag en antwoorden met de zin van de aanvaller.

Bij de gemarkeerde injecties zien we vergelijkbare patronen:

• Ze bootsen vertrouwde bronnen na. Beide voorbeelden laten de paginatekst klinken als een bron die de agent vertrouwt: de eigen ontwikkelaar in het eerste, het eigen gesprek in het tweede. Injecties kunnen zich ook voordoen als de site zelf, door beveiligingscontroles en beleidsmededelingen na te bootsen, of als de gebruiker, door valse voorkeuren op te voeren. Ongeveer twee op de drie zijn in formele taal geschreven.
• Veel zijn in verschillende talen geschreven. In 24,4% van de paren gebruikt de injectie een andere taal dan de rest van de pagina. Meestal gaat het om een Engelse instructie op een niet-Engelse pagina, zoals in het eerste voorbeeld. Zulke aanvallen zijn duidelijk gericht aan een agent die elke taal leest en meestal Engels als moedertaal heeft. Taalwisselingen maken detectie bovendien moeilijker: in onze oorspronkelijke BrowseSafe-evaluatie behoorden meertalige aanvallen tot de aanvallen die het moeilijkst te onderscheppen waren.
• De meeste willen acties, geen woorden. Meer dan vier op de tien sturen de agent aan op een actie waar de gebruiker nooit om heeft gevraagd, zoals de aankoop van de token in het eerste voorbeeld, en ongeveer een derde probeert ervoor te zorgen dat de agent de taak van de gebruiker laat vallen, zoals in het tweede voorbeeld. Slechts ongeveer 3% probeert valse informatie in het antwoord te planten.
• Ze liften vaak mee op content die iedereen kan plaatsen. Een aanvaller hoeft geen site in handen te hebben. Een forumbericht of een gedeeld document op gewone sites is genoeg, en meer dan 23.000 injecties in BrowseSafe++ kwamen op deze manier binnen. Ook een vertrouwd domein kan nog steeds worden gebruikt om de tekst van een aanvaller te injecteren.

De injecties in de uiteindelijke benchmark beslaan 12 soorten websites, 24 aanvalstypen, 6 aanvallersdoelen en 18 plaatsingen op de pagina.

Vergroten

Van een gemarkeerde pagina naar een benchmarkpaar

We kunnen gemarkeerde pagina’s niet ongewijzigd in de benchmark gebruiken, omdat ze persoonsgegevens kunnen bevatten van de gebruiker voor wie de agent werkte. Om van een pagina een deelbaar benchmarkpaar te maken, zijn drie hoofdfasen nodig:

1. De injectie verzamelen: We verzamelen de gemarkeerde pagina’s, verwijderen duplicaten en maskeren persoonsgegevens met PII-Tracer. Vervolgens bevestigen we dat de pagina een injectie bevat; concreet vereisen we dat een panel van modellen het erover eens is dat de pagina een instructie bevat die een agent probeert af te leiden van de taak die de gebruiker voor ogen had.
2. Het paar bouwen: Een agent verwijdert de injectietekst van elke pagina en herschrijft de omringende paginacontent, waarbij details zoals namen en merken worden vervangen door fictieve. Een tweede agent controleert de herschreven pagina op achtergebleven echte content en stuurt afgekeurde pagina’s met feedback terug. Menselijke beoordelaars inspecteren willekeurig 10% van de pagina’s; problemen die zij vinden, worden in de pijplijn opgelost en de oplossingen worden op het hele corpus toegepast. De injectie wordt opnieuw in de herschreven pagina ingevoegd om de aangevallen kopie te maken en weggelaten uit de schone kopie. De twee pagina’s hebben dezelfde taak, hetzelfde verwachte resultaat en dezelfde gewone instructies.
3. Verifiëren: Agents lezen pagina’s in verschillende vormen, dus we renderen de HTML van elke pagina als Markdown, een toegankelijkheidsboom (een gestructureerde lijst van de interface-elementen van een pagina en hun labels) en een screenshot. Een andere agent controleert of de injectie in alle vier de weergaven van de aangevallen pagina voorkomt en of de schone pagina in elke weergave als onschadelijk wordt beoordeeld. Ontbreekt de injectie in een van de weergaven, dan verplaatsen we die naar een andere plek op de pagina en renderen we opnieuw, zodat de injectie in de uiteindelijke aangevallen pagina in alle weergaven voorkomt. Een laatste reeks geautomatiseerde controles corrigeert paren die nog sporen van hun bron bevatten, zoals echte hostnamen of merknamen.

Vergroten

BrowseSafe-Guard: snelle en precieze detectoren voor elke weergave

Een bruikbare detector moet elke pagina snel en goedkoop controleren. Hij moet ook nauwkeurig zijn op zowel aangevallen als schone pagina’s. Een hoge precisie is vooral belangrijk, omdat de meeste pagina’s veilig zijn; zelfs een relatief laag fout-positiefpercentage zou ervoor zorgen dat de meeste meldingen vals alarm zijn. Geprompte algemene modellen schieten vaak tekort op precisie en zijn te traag en te duur om op elke pagina te draaien.

Een detector die is getraind op afzonderlijk verzamelde aangevallen en schone pagina's, kan sluiproutes leren die de twee sets toevallig van elkaar scheiden, zoals het onderwerp of de lay-out van een pagina. Zo'n detector generaliseert echter niet goed. Guard traint in plaats daarvan op paren waarvan het enige verschil de injectie zelf is, wat de precisie van de detector helpt verbeteren. Voor elk paar leest Guard de aangevallen pagina en haar schone tegenhanger afzonderlijk en geeft elk een score voor hoe waarschijnlijk het is dat ze een injectie bevat. Het model wordt bijgewerkt met twee trainingsdoelstellingen: de standaard classificatiedoelstelling en een rankingdoelstelling die Guard bestraft tenzij de aangevallen pagina met ten minste een vaste marge hoger scoort dan haar tegenhanger. Intuïtief leert de classificatiedoelstelling Guard welke beslissing het moet nemen, en koppelt de rankingdoelstelling die beslissing aan de injectie zelf, waarbij onschuldige afleiders worden genegeerd. Zo leert Guard te reageren op de injectie zelf in plaats van op de omringende pagina-inhoud.

Guard bestaat uit twee detectoren, die elk zijn gefinetuned op basis van Qwen3.5-0.8B. De tekstdetector leest één tekstweergave van een pagina: HTML, Markdown of de toegankelijkheidsboom. De multimodale detector leest een screenshot van de volledige pagina. Bij gebruik in productie leest Guard een pagina in één forward pass en geeft het een injectiescore als uitvoer; de pagina wordt gemarkeerd als de score een drempelwaarde overschrijdt. Omdat Guard slechts 0,8 miljard parameters heeft en één score als uitvoer geeft, is het snel en goedkoop genoeg om op elke pagina te draaien.

Prestaties benchmarken

We hebben Guard vergeleken met 18 modellen die werden geprompt om injecties te detecteren op een achtergehouden subset van de benchmark. We rapporteren vier metrieken, gemeten op BrowseSafe++:

• Recall is het aandeel geïnjecteerde pagina’s dat de detector markeert; dit meet hoeveel aanvallen hij onderschept, dus hoger is beter.
• Het fout-positiefpercentage (FPR) is het aandeel schone pagina’s dat de detector ten onrechte markeert; dit meet hoe vaak hij vals alarm slaat, dus lager is beter.
• Precisie is het aandeel gemarkeerde pagina’s dat daadwerkelijk een injectie bevat; dit meet hoe vaak een melding terecht is, dus hoger is beter.
• F1 is het harmonisch gemiddelde van recall en precisie; de score is alleen hoog als een detector de meeste aanvallen onderschept en weinig van zijn markeringen vals alarm zijn.

We gebruiken F1 als primaire metriek, omdat een goede detector zowel een hoge precisie als een hoge recall moet hebben. Alle vier de metrieken zijn gemiddeld over de drie tekstweergaven.

Vergroten

Vergroten

Modelvergelijkingen

De kleine open-weight-modellen die we hebben getest, eindigden onderaan. Mistral NeMo en Qwen3 30B-A3B markeren elk ongeveer de helft van de schone pagina’s, terwijl Llama 3.1 8B zelden iets markeert en de meeste aanvallen mist. Zelfs het sterkste model uit deze groep, GPT-OSS 20B, haalt slechts een F1 van 70,97%. DeepSeek V3.1, een veel groter open-weight-model, doet het iets beter, met een F1 van 75,23%.

Lichtgewicht API-modellen, waaronder GPT-5.4 nano, Gemini 3.1 Flash-Lite en Claude Haiku 4.5, vangen meer aanvallen af, met een recall tussen 85% en 97%. De keerzijde is echter een hoog aandeel valse alarmen: Gemini 3.1 Flash-Lite heeft met 35,2% de laagste FPR van de groep, en de FPR van Haiku is bijna 69%. Hierdoor is de hoogste F1-score van de groep 80,9%, behaald door Gemini 3.1 Flash-Lite.

De overige modellen zijn sterkere algemene modellen, met F1-scores tussen 85% en 92%. Ze hebben echter nog steeds te maken met een afweging tussen recall en FPR: modellen die naar voorzichtigheid neigen, blokkeren legitieme pagina’s, en modellen die minder vaak alarm slaan, missen aanvallen. Claude Sonnet 5 heeft met 98,73% de hoogste recall van alle detectoren, maar een FPR van 24,65%. Gemini 3.1 Pro en GPT-5.5 halen een recall van respectievelijk 97,78% en 97,19%, met een FPR van 19,80% en 20,44%. GPT-6 Astra heeft de hoogste algehele nauwkeurigheid, met een recall van 96,42% en een FPR van 14,41%. Decider staat op de tweede plaats, met een recall van 96,02% en een FPR van 17,44%. Claude Opus 5.5 heeft de laagste FPR, slechts 4,21%, maar door de recall van 77,71% mist het meer dan één op de vijf aanvallen. Claude Fable 5.1 lijkt sterk op de pagina’s die het beantwoordt, met een recall van 89,31% en een FPR van 7,92%, maar het weigert op ongeveer 30% van de pagina’s te antwoorden, wat in de rij “(all)” als markeringen wordt geteld.

Vergroten

Guard verlegt het Pareto-front en bereikt een betere afweging tussen gemiste aanvallen en vals alarm. Het haalt een F1 van ongeveer 95% en staat in elke tekstweergave op de eerste plaats. Het markeert slechts ongeveer één op de 20 schone pagina’s, zo’n derde van het percentage van Astra, het nauwkeurigste geprompte model. Dit verschil komt voort uit onze training: het standaard Qwen3.5-0.8B-model waarop Guard is gebouwd, op dezelfde manier geprompt als de andere modellen, haalt slechts een F1 van 64% en markeert bijna drie op de vier schone pagina’s. In het scenario met screenshotweergave vergelijken we de multimodale detector van Guard met vier modellen die afbeeldingen kunnen verwerken. Op basis van screenshots van volledige pagina’s scoort Guard ongeveer 93% F1, tegenover ongeveer 79% voor het beste van de andere modellen die we hebben geëvalueerd.

Een aanval herkennen is niet hetzelfde als die weerstaan

Intuïtief zou je verwachten dat een model dat een injectie correct kan herkennen, die injectie ook negeert wanneer het de pagina tegenkomt tijdens het uitvoeren van gebruikerstaken. Onze experimenten laten echter zien dat sterke detectiescores niet garanderen dat een model een aanval weerstaat. We gaven elk model twee keer dezelfde aangevallen pagina: één keer om te beoordelen of die een injectie bevatte en één keer om de taak van de gebruiker uit te voeren zonder het eerdere oordeel te zien. Een aparte beoordelaar controleerde of het model de injectie volgde. Elk getest model volgde nog steeds een deel van de injecties die het zelf had gemarkeerd, variërend van 1,64% van de gemarkeerde pagina’s voor GPT-6 Astra tot 24,73% voor Llama 3.1 8B.

Vergroten

Detectiescores voorspellen verschillen tussen modellen niet betrouwbaar. Claude Sonnet 5 en GPT-5.5 detecteren injecties ongeveer even goed, met F1-scores van respectievelijk ongeveer 88% en 89%. Toch volgde Sonnet 5 op 19,74% van de pagina’s een injectie die het zelf had gemarkeerd, tien keer zo vaak als GPT-5.5 met 1,97%.

Een inzetbaar systeem ter verdediging tegen injecties

Deze resultaten suggereren dat het zinvol is om de beslissing om een pagina te blokkeren over te laten aan een speciaal daarvoor bedoeld model, in plaats van te vertrouwen op het model dat de taak van de gebruiker uitvoert. Een aparte detector die elke pagina screent voordat de agent actie onderneemt, biedt een extra verdedigingslaag en heeft geen taak die kan worden gekaapt of tools die kunnen worden misbruikt.

Guard is gebouwd om die detector te zijn. Guard heeft niet alleen de hoogste F1 en nauwkeurigheid van alle modellen die we hebben getest, maar is door zijn kleine omvang ook goedkoop genoeg om op elke pagina te draaien. Gemiddeld gebruikte Guard ongeveer 0,15 seconde GPU-tijd per tekstpagina. Op een gehuurde H200 schatten we de kosten op $ 0,18 per 1.000 pagina's, tegenover $ 18,95–180,61 voor de frontier-API-modellen tegen catalogusprijzen. In onze vergelijking maakt dit frequente screening veel goedkoper, met behoud van hoge detectiescores.

De onderstaande figuur zet de nauwkeurigheid van elke detector uit tegen de tijd per pagina en de kosten per 1.000 pagina’s, beide op een logaritmische schaal. Guard staat in beide panelen alleen in de linkerbovenhoek: het wint op nauwkeurigheid, snelheid en kosten. Elk geprompt model doet er ongeveer een seconde of langer over per pagina, en de twee nauwkeurigste, GPT-6 Astra en Claude Fable 5.1, kosten meer dan $ 100 per 1.000 pagina’s.

Vergroten

Verdedigingen testen tegen adaptieve aanvallen

De BrowseSafe++-benchmark bevat een eindige set injecties. Een echte aanvaller kan echter een adaptieve aanval uitvoeren: als een injectie mislukt, kan de aanvaller die herschrijven en het opnieuw proberen. Daardoor kan een agent die de oorspronkelijke injectie weerstaat, toch kwetsbaar zijn voor toekomstige aanvallen. Bovendien worden modellen getraind op data die van internet is verzameld, waardoor ze kunnen leren de meeste injecties daarin te weerstaan; omdat we onze benchmark openbaar maken, zal deze waarschijnlijk verzadigd raken en modellen niet goed meer van elkaar kunnen onderscheiden. Om beide problemen aan te pakken, hebben we BrowseSafe-Adapt gebouwd, een testomgeving waarin een aanvallermodel injecties kan herschrijven. Elke test bestaat uit drie fasen:

1. Stel de testcase op. Een testcase koppelt een BrowseSafe++-item aan een doelagent. Het BrowseSafe++-item bevat een scenario met een gebruikersquery en taak, een aangevallen pagina en het door de aanvaller beoogde resultaat. De agent werkt in een sandbox die de tools en synthetische gegevens biedt die nodig zijn om de taak uit te voeren. Een afzonderlijk verificatiemodel beoordeelt of de aanval zijn doel heeft bereikt.
2. Een poging uitvoeren: We voegen de huidige injectie in de pagina in en laten de agent de taak uitvoeren. De verificateur controleert het antwoord van de agent en eventuele wijzigingen die de agent in de sandbox heeft aangebracht om te bepalen of de aanval is geslaagd. De eerste poging gebruikt de injectie uit het oorspronkelijke BrowseSafe++-item.
3. Herzien en herhalen: Als een aanval mislukt, archiveren we de poging en beoordeelt een criticusmodel wat er misging. Een aanvallermodel gebruikt die feedback om de injectie te herschrijven; het kan de formulering, opmaak of positie van de aanval op de pagina wijzigen. Het aanvalsdoel, de succescriteria en de omringende paginacontent blijven gelijk. De volgende poging gebruikt de bijgewerkte aanval. Dit proces wordt herhaald totdat de aanval slaagt of de aanvaller een vastgestelde pogingslimiet bereikt.

Vergroten

We hebben zeven agents getest, elk gebouwd op een ander model: Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite en de open-weight-modellen DeepSeek V3.1 en Kimi K2. Elke agent kreeg dezelfde 1.024 taken, met maximaal 64 pogingen per taak. Bij de eerste poging was het aanvalssucces bij alle zeven agents laag. De oorspronkelijke injecties slaagden tegen elke agent bij hooguit 4% van de geëvalueerde taken. Binnen het adaptieve framework nam het aanvalssucces drastisch toe. Tegen vijf van de zeven agents slaagde de aanvaller bij minstens 79% van de taken. Zelfs de sterkste agents bleken kwetsbaar: aanvallen slaagden nog altijd bij ongeveer twee op de drie taken tegen GPT-5.5 en bij ongeveer één op de drie tegen Claude Sonnet 5.

Het verschil tussen agents is het grootst wanneer de aanvaller als doel heeft de agent een bepaalde toolaanroep te laten doen. Bij taken met dit soort doel gaf Sonnet 5 bij ongeveer 8% van de taken toe en GPT-5.5 bij ongeveer 29%. De andere vijf voerden bij meer dan de helft van hun taken het doel van de aanvaller uit.

We hebben BrowseSafe-Adapt ook ingezet tegen de agent op basis van Gemini 3.5 Flash-Lite, waarbij Guard elke pagina eerst screende. Guard blokkeerde 94,5% van de oorspronkelijke injecties en verdubbelde bijna het gemiddelde aantal pogingen dat de aanvallers nodig hadden, van 9,7 naar 17,0. Met alle 64 pogingen slaagde de aanvaller echter nog steeds bij 84,2% van de taken (93,6% zonder Guard), vrijwel altijd met een injectie die Guard niet had gemarkeerd. Dit sluit aan bij het standpunt dat we uiteenzetten toen we BrowseSafe uitbrachten: geen enkel detectiemodel is een wondermiddel, dus een detector moet deel uitmaken van een gelaagde verdediging.

Vergroten

Conclusie

Browseragents zijn vaak vatbaar voor indirecte promptinjectie, waarbij aanvallen die op gewone pagina’s zijn verborgen de agents proberen te hinderen bij het uitvoeren van gebruikerstaken. De gevaren nemen in de loop van de tijd alleen maar toe: agents krijgen toegang tot meer data en tools, waardoor er bij aanvallen meer op het spel kan staan, en aanvallers kunnen hun injecties herzien om ze effectiever te maken.

Onze BrowseSafe-suite pakt deze bedreigingen aan. De BrowseSafe++-benchmark bevat 38.675 webpaginaparen die voornamelijk zijn opgebouwd uit echte injecties, wat betrouwbaardere training en evaluatie van detectoren mogelijk maakt. De BrowseSafe-Guard-detectoren, getraind op deze paren, maken zeer nauwkeurige, snelle en goedkope detectie mogelijk, zodat pagina’s kunnen worden gescand voordat een agent erop handelt. Met het BrowseSafe-Adapt-framework kunnen modellen worden getest tegen herziene injecties, wat kwetsbaarheden blootlegt die bij losse pogingen met vaste injecties mogelijk niet zichtbaar zijn.

We hopen dat deze tools het samen makkelijker maken voor onderzoekers en engineers om fouten te vinden en de verdediging tegen webgebaseerde promptinjectieaanvallen te verbeteren. Daarnaast evalueren en verbeteren we voortdurend de ingebouwde verdediging van Comet en Computer om onze gebruikers veilig te houden.

Aan de slag

1. Installeer de SDK en krijg toegang tot de data. De SDK wordt geïnstalleerd vanaf GitHub:

De dataset is afgeschermd. Vraag eenmalig toegang aan op de bijbehorende Hugging Face-pagina en log daarna in met hf auth login.

2. Dien je resultaten in bij de ranglijst. Evalueer je eigen detector op de testsplit van BrowseSafe++:

Dit schrijft per pagina één beslissing weg voor elke weergave die je opgeeft; geef alle drie de tekstweergaven op om een gemiddelde op het tekstleaderboard te krijgen. Log in bij de leaderboard-Space met je Hugging Face-account en upload predictions.jsonl. De Space geeft voor elke weergave F1, nauwkeurigheid, het percentage fout-positieven en de andere metrics terug en publiceert het resultaat desgewenst op het leaderboard. Elk account (minimaal 60 dagen oud) krijgt één beoordeelde inzending per UTC-week. De testpagina's zijn uitsluitend bedoeld voor evaluatie: train er niet op en verspreid ze niet verder. De inzendingsgids beschrijft het bestandsformaat en de publicatieregels.

Bronvermelding

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