Perplexity hat kürzlich BrowseSafe veröffentlicht, ein Open-Source-Modell, das Entwickler dabei unterstützen soll, KI-gestützte Browser vor Prompt-Injection-Angriffen zu schützen.
Red-Team-Tests von Forschern bei Lasso legen jedoch nahe, dass die Schutzvorkehrung möglicherweise nicht so umfassend ist wie beworben.
„Mit Standardtechniken – nicht mit fortgeschrittenen Methoden – haben wir innerhalb weniger Stunden eine Umgehungsrate von 36 % erreicht. Motivierte Angreifer mit mehr Zeit werden noch erfolgreicher sein“, sagte Eliran Suisa, Head of Product Research bei Lasso.
Sicherheitsrisiken autonomer Web-Agenten
BrowseSafe wird bereits im KI-eigenen Browser Comet von Perplexity eingesetzt und soll autonome Agenten schützen, die Live-Webinhalte lesen und mit ihnen interagieren.
Wenn sich die Annahmen zur Erkennung als falsch erweisen, könnten Unternehmen, die sich darauf als primäre Abwehrmaßnahme verlassen, nachgelagerte Modelle schädlichen Anweisungen aussetzen – mit potenziellen Folgen wie Datenlecks, Richtlinienverstößen oder unsicheren Aktionen.
Die Forscher untersuchten, wie gut BrowseSafe Prompt-Injection-Angriffe in realistischen HTML-Browsing-Kontexten erkennen kann.
Im Mittelpunkt stand die Frage, ob das Modell als eigenständige Sicherheitskontrolle eingesetzt werden kann, wie es die Kommunikation von Perplexity nahelegt.
Statt sich auf das manuelle Erstellen von Prompts zu verlassen, nutzten die Forscher automatisiertes Red-Teaming, um systematisch Kodierungs- und Verschleierungstechniken anzuwenden, die allein durch Tests von Menschen nur schwer aufgedeckt werden können.
BrowseSafe auf Angriffe testen
BrowseSafe ist als binärer Klassifikator implementiert, der auf Qwen3-30B aufsetzt und eine einfache Entscheidung ausgibt: sicher oder schädlich, bevor Inhalte die Kernlogik eines Agenten erreichen.
Laut Model Card ist das System darauf ausgelegt, robust gegenüber unübersichtlichem HTML, Ablenkungen und gängigen Injektionsmustern zu sein, die beim Browsen auftreten.
Dieses Design funktioniert gut gegen einfache Angriffe. Das Modell hatte jedoch Schwierigkeiten mit Prompt-Injection-Techniken, die statt auf Anweisungen in Klartext auf Kodierung setzen.
In den Tests erkannte BrowseSafe schädliche Prompts nicht, die mit Base32, dem NATO-Buchstabieralphabet oder Pig Latin codiert waren – selbst wenn diese Payloads in HTML-Strukturen eingebettet waren, die echten Webseiten ähnelten.
Im Gegensatz dazu wurden hexadezimal codierte Angriffe durchgängig erkannt, was darauf hindeutet, dass diese Muster in den Trainingsdaten des Modells häufiger vorkamen.
Insgesamt wurden etwa 36 % der schädlichen Prompts fälschlicherweise als sicher klassifiziert.
Wie codierte Angriffe durchschlüpfen
Das Kernproblem ist architektonischer und nicht implementierungsspezifischer Natur. BrowseSafe klassifiziert den rohen Eingabetext, ohne ihn zu decodieren.
Kodierungstechniken verändern das äußere Erscheinungsbild schädlicher Anweisungen, bewahren aber deren Absicht.
Ein nachgelagertes Large Language Model – oder ein Mensch – kann diese Transformationen problemlos decodieren, nachdem die Schutzvorkehrung die Eingabe bereits freigegeben hat.
Dadurch entsteht eine gefährliche Lücke: Das Sicherheitsmodell bewertet nicht decodierten Text, während das Zielmodell die decodierte Absicht interpretiert.
Wenn die Schutzvorkehrung eine codierte Payload freigibt, hindert grundsätzlich nichts den nachgelagerten Agenten daran, die Anweisungen des Angreifers auszuführen.
In Umgebungen, in denen BrowseSafe als primäre oder einzige Schutzvorkehrung eingesetzt wird, entsteht dadurch ein Single Point of Failure – sobald ein Prompt als sicher klassifiziert wurde, gibt es möglicherweise keine nachgelagerte Kontrolle mehr, die schädliches Verhalten erkennt oder stoppt.
Bei den Fehlschlägen handelte es sich nicht um mehrdeutige Randfälle.
In vielen Fällen gab BrowseSafe für eindeutig schädliche Inhalte Klassifizierungen mit hoher Konfidenz als sicher aus. Das zeigt, dass Konfidenzwerte allein kein verlässlicher Schutzindikator sind.
Mehrschichtige Kontrollen für die Sicherheit von Agenten
Eine einzelne modellbasierte Schutzvorkehrung reicht nicht aus, um sich gegen Prompt-Injection-Angriffe aus der Praxis zu verteidigen – insbesondere nicht gegen solche, die Kodierungs- und Verschleierungstechniken ausnutzen.
Eine wirksame Abwehr erfordert einen Defense-in-Depth-Ansatz, der Ausfälle sowohl vor als auch nach dem Erreichen der Kernlogik eines Agenten berücksichtigt.
Unternehmen sollten davon ausgehen, dass einige Angriffe die erste Prüfung umgehen werden, und Kontrollen entwickeln, die Auswirkungen begrenzen, Missbrauch erkennen und sich im Laufe der Zeit anpassen.
- Red-Teamen Sie die gesamte Agenten-Pipeline vor der Bereitstellung mit automatisierten Tests, die semantische, codierte und verschleierte Prompt-Injection-Techniken abdecken.
- Normalisieren und decodieren Sie Eingaben vor der Klassifizierung, um Umgehungen durch Verschleierung zu reduzieren und sicherzustellen, dass die Schutzvorkehrungen die tatsächliche Absicht bewerten.
- Verwenden Sie mehrschichtige Schutzvorkehrungen und Ensembles statt eines einzelnen Modells, um semantische, strukturelle und verhaltensbezogene Anomalien zu erkennen.
- Setzen Sie deterministische Richtlinien und Least-Privilege-Kontrollen durch, die begrenzen, was Agenten und Tools tun können, selbst wenn Prompts die erste Prüfung bestehen.
- Fügen Sie Laufzeitüberwachung und Kontrollen auf Aktionsebene hinzu, um verhaltensbedingte Abweichungen zu erkennen, die Nutzung von Tools zu validieren und unsichere Browseraktionen in Echtzeit zu blockieren.
- Betrachten Sie Schutzvorkehrungsmodelle als Komponenten innerhalb einer kontinuierlich aktualisierten Sicherheitsarchitektur, die durch laufende Tests, Überwachung und Feedbackschleifen informiert wird.
Zusammen tragen diese Schritte dazu bei, das Verhalten von Agenten während ihres gesamten Lebenszyklus ausgerichtet, widerstandsfähig und sicher zu halten.
Nicht Open Source ist das Risiko – sondern die Annahmen
Die Einschränkungen von BrowseSafe spiegeln einen breiteren Trend in der KI-Sicherheit wider: Je spezialisierter Schutzvorkehrungen werden, desto häufiger setzen Angreifer auf Manipulationen auf Darstellungsebene statt auf offensichtlich schädliche Sprache.
Prompt-Injection auf Basis von Kodierung ist nicht neu, bleibt aber gegenüber Systemen wirksam, die davon ausgehen, dass Bedrohungen zum Zeitpunkt der Prüfung semantisch verständlich sind.
Open Source ist nicht das Problem. BrowseSafe bietet Transparenz, Reproduzierbarkeit und eine wertvolle Grundlage für die Sicherheit von KI-Browsern. Das Risiko liegt darin, ein einzelnes Schutzvorkehrungsmodell isoliert als ausreichenden Schutz zu positionieren.
Da autonome Agenten immer mehr Kontrolle über Tools, Daten und Workflows erhalten, müssen Sicherheitsteams davon ausgehen, dass einige Angriffe die frühe Erkennung umgehen werden – und Systeme entwickeln, die auch dann sicher ausfallen können.
Dieser Wandel zeigt, warum moderne KI-Systeme zunehmend eine Zero-Trust-Denkweise erfordern – eine, die von einer Kompromittierung ausgeht und die Auswirkungen in jeder Phase der Ausführung begrenzt.