Prompt Injection über Suchergebnisse

Was ist Prompt Injection über Suchergebnisse?

Prompt Injection über Suchergebnisse ist indirekte Prompt Injection, die ein Modell über einen suchbasierten Workflow erreicht: Ein Assistent formuliert eine Suchanfrage, ruft ein Such- oder Browsing-Tool auf, erhält eine Trefferliste mit Titeln, Snippets, URLs und Metadaten des Anbieters, wählt einen oder mehrere Treffer aus, ruft die zugehörigen Seiten ab und extrahiert sie gegebenenfalls, und setzt all das zu einem Modellkontext zusammen, bevor eine Antwort oder eine Aktion vorgeschlagen wird.

Das Besondere ist nicht die Seite am Ende der Kette, sondern alles davor. Auffindbarkeit, Ranking, Snippet-Erzeugung, Trefferauswahl und Query-Reformulierung entscheiden darüber, welche beeinflussbaren Inhalte das Modell überhaupt sieht und in welcher Form. Ein Treffer kann allein über Titel und Snippet wirken, bevor eine Seite geöffnet wird, sofern die Architektur Trefferdaten in den Kontext legt.

Modelleinfluss und Sicherheitsauswirkung bleiben getrennt. Eine veränderte Zusammenfassung oder Empfehlung zeigt Einfluss. Eine Sicherheitsfolge setzt zusätzlich einen Pfad zu sensiblen Daten oder Fähigkeiten voraus sowie eine fehlende, zu weit gefasste oder versagende Anwendungskontrolle.

Abgrenzung zu Website- und RAG-Prompt-Injection

Diese Seite liegt zwischen zwei Nachbarthemen und wiederholt sie bewusst nicht. Website Prompt Injection beschreibt, was geschieht, sobald eine Seite abgerufen, gerendert und extrahiert wird. RAG Prompt Injection beschreibt ein Abrufmuster der Anwendung über einen indexierten Bestand. Suchbasierte Recherche ist eine eigene Schicht: häufig extern, flüchtig und anfragegetrieben, wobei Auffindung, Ranking und Auswahl durch einen Suchanbieter oder Suchdienst gesteuert werden können. Dieser kann öffentlich, authentifiziert, unternehmensintern oder von der Anwendung selbst kontrolliert sein.

Die Schichten können sich verketten: Suchergebnisse werden später womöglich in einen RAG-Bestand oder eine Rechercheablage geschrieben, dann gelten zusätzlich die Persistenz-, Provenienz- und möglichen Autorisierungsfragen der RAG-Seite. Weder Suche noch RAG sind allein aufgrund ihrer Bezeichnung sicher: Jede konkrete Umsetzung muss die für ihre Daten nötigen Berechtigungen und das Security Trimming selbst implementieren. Das ist eine Kombination zweier Probleme, kein Grund, sie zu vermischen.

Keine SEO-Manipulation, kein Angriff auf die Suchmaschine

Search Poisoning, SEO-Manipulation, bösartige Anzeigen, Typosquatting und kompromittierte legitime Seiten sind bekannte Wege, beeinflussbare Inhalte auffindbar zu machen. Sie sind Zustell- und Ermöglichungsmechanismen. Sie werden hier nur konzeptionell beschrieben, weil sie nicht das Prompt-Injection-Primitiv sind und weil die Manipulation produktiver Rankings nicht Gegenstand dieser Seite ist.

Das eigentliche Primitiv ist schlichter: Inhalte, die ein KI-Workflow modellsichtbar macht, erhalten mehr Autorität, als ihnen zusteht. Das kann eine erstplatzierte Seite betreffen, eine zehntplatzierte, ein Snippet, eine zwischengespeicherte Kopie oder eine Seite, die Angreifende gar nicht erstellt, sondern nur um einen Absatz ergänzt haben.

Die Such- und Browsing-Kette von Anfang bis Ende

Produkte unterscheiden sich entlang dieses Pfads erheblich. Manche geben nur Snippets an das Modell. Manche rufen den ersten Treffer automatisch ab. Manche lassen das Modell entscheiden, welche Treffer geöffnet werden, wie viele und ob erneut mit verfeinerter Anfrage gesucht wird. Manche rendern Seiten im Browser, andere nutzen einen Extraktionsdienst, wieder andere führen OCR aus oder öffnen verlinkte Dokumente. Sicherheitsarbeit beginnt damit, den tatsächlich laufenden Pfad zu dokumentieren.

Vertrauenswürdige Infrastruktur liefert nicht vertrauenswürdige Inhalte zuverlässig aus. Eine funktionierende Such-API, ein korrekter TLS-Handshake und ein sauberer Extraktor belegen Eigenschaften der Pipeline, nicht Autorität für den gelieferten Text.

Vertrauensgrenzen in Suchworkflows

In Suchworkflows werden vier Dinge regelmäßig verwechselt. Ihre Trennung beseitigt den größten Teil der Entwurfsunklarheit.

Was tatsächlich modellsichtbar wird

Ein Suchschritt kann sehr unterschiedliche Textbestandteile beisteuern. Welche davon existieren, hängt vollständig von der Produktkonfiguration ab, und jeder einzelne ist eine eigene Expositionsentscheidung.

Nichts davon ist an sich schädlich. Es ist eine Sichtbarkeits- und Provenienzlage: Was das Modell beeinflusst hat, kann ein Snippet sein, das niemand gelesen hat, zugeordnet zu einer Seite, die niemand geöffnet hat.

Exposition allein über Snippets

Viele Architekturen legen die gesamte Trefferliste in den Kontext, damit das Modell entscheiden kann, welchen Treffer es öffnet. In solchen Entwürfen ist beeinflussbarer Text bereits modellsichtbar, bevor irgendeine Abrufrichtlinie, eine Domain-Freigabeliste oder eine Extraktionskontrolle gelaufen ist. Kontrollen, die nur abgerufene Seiten prüfen, schützen damit eine spätere Stufe als die tatsächlich zuerst exponierte.

Snippets sind zudem kompakt und zahlreich. Eine Trefferliste kann zehn kurze, auffällige Zeichenketten enthalten, die mit der Aufgabenbeschreibung konkurrieren, während eine geöffnete Seite einen langen Fließtext beisteuert. Kompaktheit ist nicht harmlos, sondern Prominenz.

Die architektonische Antwort ist nicht, Treffer vor dem Modell zu verbergen - das würde den Workflow zerstören. Sie besteht darin, nur die für die Auswahl nötigen Trefferdaten aufzunehmen, jeden Textbestandteil mit seiner Quelle zu kennzeichnen und sicherzustellen, dass kein Treffertext Aufgabenumfang, Toolwahl, Zieladresse oder Berechtigungen verändern kann.

Query-Erzeugung und Reformulierung als Angriffsfläche

Agentische Rechercheschleifen stellen selten nur eine Anfrage. Sie reformulieren: Das Modell liest eine Trefferliste, verfeinert Begriffe, sucht erneut, verfolgt einen Ansatz weiter und wiederholt das. Jede Iteration ist ein Kontrollpunkt, denn die Anfrage in Schritt drei kann von Inhalten aus Schritt zwei geprägt sein.

Zwei Folgen sind wichtig. Erstens können abgerufene Inhalte die weitere Suche auf Quellen lenken, die derselbe Akteur beeinflusst, wodurch die spätere Trefferliste weniger unabhängig ist, als sie wirkt. Zweitens können reformulierte Anfragen Material aus dem umgebenden Kontext nach außen tragen - auch Aufgabendetails oder Daten, mit denen der Assistent gerade arbeitet. Das ist ein eigenständiger Egress-Vorgang und sollte wie jeder andere ausgehende Aufruf protokolliert und geprüft werden.

Teams sollten daher jede erzeugte Anfrage zusammen mit dem Turn und den vorausgegangenen Inhalten protokollieren und die Query-Erzeugung als anwendungskontrollierten Schritt behandeln, nicht als freie Modellausgabe.

Ranking, Auswahl und konkurrierende Anweisungen mehrerer Treffer

Die Trefferauswahl ist meist eine Modellentscheidung und kann deshalb von genau der Liste beeinflusst werden, aus der gewählt wird. Ein Treffer, dessen Snippet größere Autorität, höhere Aktualität oder offiziellen Status behauptet, konkurriert um die Auswahl mit Treffern, die das nicht tun. Nichts an diesem Wettbewerb ist überprüft.

Liegen mehrere Treffer gleichzeitig im Kontext, konkurrieren ihre Inhalte auch untereinander und mit den Anweisungen der Anwendung. Berichte und Tests sollten festhalten, auf welchen Treffer sich das Modell tatsächlich gestützt hat, nicht nur, welche Treffer vorhanden waren - ein Plan kann von einem niedrig platzierten Treffer getragen sein, der nie als Hauptquelle gedacht war.

Deterministische Auswahlgrenzen helfen: die Zahl der Treffer im Kontext begrenzen, je Aufgabentyp festlegen, welche Quellenkategorien geöffnet werden dürfen, und verlangen, dass zu jeder Aussage die Quelle mitgeführt wird.

Ergebnis-URLs, Weiterleitungen und Zieladresse

Die in einem Treffer angezeigte URL ist eine Anzeigezeichenkette. Der Inhalt, der das Modell erreicht, stammt vom endgültigen Ziel nach Weiterleitungen, kanonischen Umschreibungen, regionalem Routing, Kurzlinks, Tracking-Sprüngen und jeder clientseitigen Navigation, der die Abrufkomponente folgt. Eine Domainprüfung nur auf der angezeigten URL prüft also den falschen Wert.

Daraus folgen zwei Regeln. Prüfen Sie die aufgelöste Ziel-URL nach vollständiger Weiterleitungskette gegen dieselbe Richtlinie wie die Ausgangsadresse und speichern Sie die gesamte Kette als Nachweis. Wenden Sie dieselbe Disziplin auf jede URL an, die das Modell für einen weiteren Abruf oder als Ziel vorschlägt: Ein beeinflusster Plan kann eine plausibel wirkende Adresse nennen, und die deterministische Egress-Entscheidung muss gegen das aufgelöste Ziel fallen, nie gegen die Beschriftung.

Parameter verdienen dieselbe Behandlung. Eine URL, die Kontextmaterial in ihrer Query-Zeichenkette trägt, ist ein Abflusskanal, unabhängig davon, wie gewöhnlich der Hostname aussieht.

Voraussetzungen und Zustellwege

Suchbasierte Injection setzt voraus, dass auffindbare Inhalte beeinflussbar sind und dass eine realistische Aufgabe sie erreichbar macht. Dies sind die üblichen Flächen, konzeptionell beschrieben und ohne jedes Vorgehen zur Verbesserung der Auffindbarkeit.

Jede Fläche hat eine andere Voraussetzung: eine Domain, ein Konto, Schreibrechte, eine Übernahme oder schlicht ein öffentliches Beitragsformular. Zu erfassen, wer Inhalte beeinflussen kann, die eine bestimmte Aufgabe zutage fördern würde, ist der erste Schritt sowohl der Bedrohungsmodellierung als auch einer autorisierten Prüfung.

Offensive Perspektive auf suchbasierte Recherche

In einer autorisierten Prüfung lautet die erste Frage nicht, wie etwas formuliert wird. Sie lautet, welche auffindbaren Inhalte die prüfende Seite legitim kontrolliert und welche realistische Nutzeraufgabe einen Suchworkflow überhaupt dazu bringen würde, sie zutage zu fördern. Inhaltskontrolle ohne Query-Erreichbarkeit ergibt keinen Befund - und genau diese Stufe überspringen Laborvorführungen, die Inhalte direkt in den Kontext legen.

Die Randbedingungen sind architektonisch, nicht sprachlich. Der Inhalt muss indexiert und für die Anfragen geeignet sein, die der Assistent für die geprüfte Aufgabe tatsächlich erzeugt. Er muss in der Trefferliste an einer Position erscheinen, die der Workflow berücksichtigt. Entweder gelangt sein Snippet in den Kontext, oder der Treffer wird ausgewählt und abgerufen, übersteht Weiterleitungen, Extraktion und Kürzung und landet in der modellsichtbaren Repräsentation neben dem legitimen Material. Erst dann lässt sich Einfluss bewerten, und erst dann werden Fähigkeitsreichweite und Richtlinie relevant.

Weil diese Seite Abwehr und autorisierte Prüfung zugleich adressiert, erklärt sie die Struktur der Schranken, ihre offensive Bedeutung und wie jede Stufe gemessen wird. Sie verzichtet bewusst auf Verfahren zur Ranking-Manipulation, SEO-Poisoning-Anleitungen, Verschleierungsmethoden, wiederverwendbare Anweisungstexte und jede Technik zur Erhöhung der Auffindbarkeits- oder Einflusswahrscheinlichkeit. Diese Implementierungsdetails bleiben in der zitierten Forschung.

Erfolgskette der Prompt Injection über Suchergebnisse

Die Kette verzweigt sich nach der Präsenz in der Trefferliste. Auf Pfad A gelangen Titel, Snippet oder Treffermetadaten direkt in den Modellkontext, sodass es keine Schranke für Seitenabruf oder Extraktion gibt. Auf Pfad B wählt der Workflow einen Treffer aus, löst Weiterleitungen auf, ruft das endgültige Ziel ab und erhält den relevanten Inhalt durch Rendering oder Extraktion, bevor er den Kontext erreicht. Für eine Ende-zu-Ende-Wirkung sind die gemeinsamen vorgelagerten Schranken, ein vollständiger Kontextpfad sowie die nachgelagerten Schranken für Einfluss, Fähigkeitsreichweite, Kontrollversagen und Wirkung nötig. Abruf und Extraktion sind nur auf Pfad B erforderlich.

Jede gemeinsame und jede pfadspezifische Schranke ist einzeln beobachtbar. Die Berichterstattung sollte sie trennen: auffindbare beeinflussbare Inhalte sind ein Inhaltsbefund, die Präsenz in der Trefferliste bei realistischen Anfragen ein Erreichbarkeitsbefund, die Aufnahme von Titel, Snippet oder abgerufenem Inhalt ein Kontextbefund, eine veränderte Antwort ein Einflussbefund - und nur eine versagende Autorisierungs- oder Egress-Entscheidung mit echter Nebenwirkung ein Autorisierungsbefund.

Kontrollen können die Kette an mehreren Stellen brechen: Query-Erzeugung begrenzen, Trefferdaten im Kontext reduzieren, zulässige Quellen einschränken, aufgelöste Ziele prüfen, Kontext minimieren, Provenienz je Treffer kennzeichnen, Aufgabendrift erkennen, geringste Rechte durchsetzen und vor jeder folgenreichen Aktion deterministisch entscheiden. Diese Schichtung vermeidet die Abhängigkeit von perfekter semantischer Erkennung und behandelt beobachteten Einfluss dennoch als untersuchungswürdiges Signal.

Konkurrierende Randbedingungen für Angreifende

Die Kette beschreibt zugleich, wogegen Angreifende antreten - und warum eine Ende-zu-Ende-Ausnutzung über öffentliche Suche weit unsicherer ist, als eine Vorführung mit vorplatziertem Kontext nahelegt.

Diese Randbedingungen sind der Grund, warum stufenweise Messung aussagekräftiger ist als eine einzelne Erfolgszahl: Sie zeigen, welche Schranke ihre Schutzwirkung tatsächlich trägt.

Offensive Review-Fragen

Eine autorisierte Prüfung sollte jede Schranke einzeln belegen - mit Testinhalten, die der Organisation gehören, synthetischen Schutzdaten, begrenzten Rechten und umkehrbaren Nebenwirkungen. Diese Fragen strukturieren die Prüfung, ohne eine Ausnutzungsfolge vorzugeben.

Durchgespieltes Szenario: interner Rechercheassistent

Einfluss hat stattgefunden, weil abgerufene Sprache den Vorschlag verändert hat. Die Auswirkung blieb eingedämmt, weil der synthetische geschützte Datensatz nie in den Kontext gelangte und kein externer Aufruf ausgeführt wurde. Der Suchanbieter hat nicht versagt; die Architektur hat seine Ausgabe als nicht vertrauenswürdiges Arbeitsmaterial behandelt. Alle Daten einer solchen Übung sollten synthetisch und alle Nebenwirkungen umkehrbar sein.

Suchergebnisse in RAG und abgeleiteten Artefakten

Rechercheworkflows speichern das Gefundene häufig: Notizen, Zusammenfassungen, Briefings, zwischengespeicherten Seitentext oder neue Einträge in einem Retrieval-Bestand. In diesem Moment wird aus einer flüchtigen Einzelexposition ein dauerhafter, geteilter Zustand, der Personen erreichen kann, die die ursprüngliche Anfrage nie gestellt haben. Provenienz muss den Weg vom Treffer über die Notiz bis zu Chunk und Embedding überstehen, und das gespeicherte Artefakt muss mitführen, dass sein Ursprung nicht vertrauenswürdiger öffentlicher Inhalt war.

Der Artikel zur RAG Prompt Injection behandelt Abruf-Erreichbarkeit, Security Trimming, Mandantentrennung und Indexgenerationen ausführlich. Diese Seite ergänzt die vorgelagerte Herkunft, die der Bestand bewahren und nicht einebnen muss: welche Anfrage, welcher Anbieter, welcher Treffer und welche Ziel-URL den Text überhaupt erzeugt haben. Das Löschen einer Recherchenotiz entfernt nicht automatisch Zusammenfassungen, Caches, Embeddings oder daraus abgeleitete Dokumente.

Erkennung und Telemetrie

Diese Signale belegen Reihenfolge und Zusammenhang; interne Modellkausalität beweisen sie selten. Harte Nachweise liefern Rechercheprotokoll, Autorisierungsentscheidungen und Aktionsprotokoll. Anfragen und abgerufene Inhalte können vertrauliches Material enthalten, daher gelten Zweckbindung, Zugriffskontrolle, Aufbewahrungsgrenzen und Schwärzung - bei gleichzeitiger Rekonstruierbarkeit eines Vorfalls.

Prävention und sichere Architektur

1. 01
   Treffer als nicht vertrauenswürdig behandeln

   Trefferlisten, Titel, Snippets, Anbieter-Metadaten und abgerufene Seiten grundsätzlich als nicht vertrauenswürdig einstufen, unabhängig von Rang und Domain.

2. 02
   Provenienz je Treffer erfassen

   Jeden Bestandteil mit Anbieter, Treffer-Kennung, Rang, Ziel-URL und Repräsentation kennzeichnen und diese Labels bis in den Kontext mitführen.

3. 03
   Autorität von Inhalt trennen

   Anwendungsanweisungen und Richtlinien außerhalb abgerufener Texte halten und keinem abgerufenen Text erlauben, Umfang, Tools, Empfänger oder Rechte zu ändern.

4. 04
   Query-Erzeugung begrenzen

   Die Anfrageerzeugung als anwendungskontrollierten Schritt behandeln, jede Anfrage protokollieren und Egress-Richtlinien auf ihren Inhalt anwenden.

5. 05
   Kontext minimieren

   Nur die für die Auswahl nötigen Trefferdaten und nur den für die Aufgabe nötigen Seiteninhalt aufnehmen.

6. 06
   Ziele validieren

   Richtlinien auf die aufgelöste URL nach vollständiger Weiterleitungskette anwenden, für Abrufe und für jedes vom Modell vorgeschlagene Ziel.

7. 07
   Fähigkeiten eingrenzen

   Tools und Ziele freigeben, aufgabenbezogene kurzlebige Berechtigungen nutzen und Rechercheworkflows wo möglich lesend halten.

8. 08
   Deterministisch autorisieren

   Modellausgaben als nicht vertrauenswürdigen Vorschlag behandeln und jeden sensiblen Abruf, Aufruf und Schreibvorgang außerhalb des Modells entscheiden.

9. 09
   Abruf isolieren

   Browsing und Extraktion in einer isolierten Komponente ohne mitlaufende Berechtigungen und ohne internen Netzzugriff ausführen.

10. 10
    Zitate sichtbar machen

    Quellenangaben für Nutzende sichtbar machen und erkennen, wenn eine zitierte Quelle die vorgeschlagene Aktion nicht stützt.

11. 11
    Freigabe an die Aktion binden

    Wo menschliche Freigabe genutzt wird, an die exakte unveränderliche Aktion und Zieladresse binden und bei geändertem Vorschlag verfallen lassen.

12. 12
    Restrisiko eindämmen

    Davon ausgehen, dass Einfluss gelegentlich eintritt, und sicherstellen, dass die Folge ein Entwurf, ein verweigerter Aufruf und eine Meldung bleibt.

Der Abwehrbereich ordnet diese Kontrollen in das übergreifende Modell aus Provenienz, Informationsfluss, geringsten Rechten, Aktionskontrolle, Monitoring und Wiederherstellung ein.

Kontrolliertes defensives Testen

Verwenden Sie Testinhalte der eigenen Organisation, synthetische Identitäten, synthetische Schutzdaten und einen Testmandanten. Variieren Sie Aufgabentyp, erzeugte Anfragen, Anzahl der Treffer im Kontext, Snippet- gegenüber Abrufpfad, Weiterleitungsverhalten, Extraktionskonfiguration und verfügbare Fähigkeiten. Messen Sie jede Stufe getrennt und nennen Sie zu jeder Kennzahl die Bezugsgröße. Das Lab Prompt Injection über Suchergebnisse zeigt Snippet-Exposition, Rang und Vertrauen, Query-Egress, finale URLs und gespeicherte Notizen als kontrollierte Simulation.

Fassen Sie diese Werte nicht zu einer Gesamtzahl zusammen. Hohe Auffindung bei geringem Einfluss ist ein anderes Ergebnis als hoher Einfluss ohne jede Richtlinienumgehung, und nur die Trennung zeigt, ob Anfrage- und Auswahlrichtlinie, Kontextminimierung, Erkennung, Autorisierung oder Eindämmung verbessert werden müssen.

Incident Response

Häufige Fehlannahmen

Standards und Forschungskontext

OWASP LLM01:2026 beschreibt indirekte Prompt Injection als Zugang über externe Quellen, die ein System verarbeitet, einschließlich Webinhalten, und hält fest, dass solche Inhalte für Menschen nicht sichtbar sein müssen, solange das Modell sie verarbeitet. Das NIST-Glossar definiert indirekte Prompt Injection als Prompt Injection, die mittels Resource Control ausgeführt wird. Der separate Eintrag zu Resource Control definiert die Kontrolle Angreifender über externe Ressourcen, die ein generatives KI-System zur Inferenzzeit verarbeitet. Dies bezeichnet den Mechanismus und bleibt von einer nachgelagerten Sicherheitsauswirkung getrennt.

Die Microsoft-Leitlinien zählen externe Webinhalte zu nicht vertrauenswürdigen Eingaben und empfehlen mehrschichtige probabilistische und deterministische Kontrollen. Die Leitlinie Input, Context, and Retrieval Hygiene hält fest, dass jeder Prompt, jedes Dokument, jeder abgerufene Chunk, jedes Tool-Ergebnis und jeder Speichervorgang als nicht vertrauenswürdige Eingabe zu behandeln ist und dass sicherer Abruf Quellenprovenienz, berechtigungsbewusste Indexierung und Validierung bei jedem Lesen und Schreiben erfordert. Dies sind von der Anwendung umzusetzende Kontrollen, keine Eigenschaften, die jedes Suchprodukt bereits bereitstellt. Übertragen bedeutet das: Provenienz je Treffer, zur jeweiligen Suchumgebung passende Berechtigungen, minimierter Kontext und Validierung jedes Abrufs und jedes Ziels.

Als Forschungskontext zeigen Chang et al. in Overcoming the Retrieval Barrier, warum realistische Analyse den Abruf unter echten Anfragen als eigene, messbare Stufe behandeln muss, statt Inhalte als bereits im Kontext vorhanden anzunehmen. Dieselbe Logik gilt für Suchworkflows, in denen Auffindung und Auswahl noch vor dem Abruf liegen. Dieser Artikel gibt Studienergebnisse mit ihren konfigurationsspezifischen Grenzen wieder und reproduziert weder Angriffskonstruktion noch Optimierungsverfahren, Ranking-Manipulation oder Payload-Texte. Greshake et al. haben das übergreifende Praxisproblem der indirekten Injection begründet.

Häufige Fragen