Viele Unternehmen ziehen bei KI-Agenten eine scheinbar klare Sicherheitslinie: Was in der Cloud läuft, gilt als riskant; was lokal auf dem Endgerät bleibt, wirkt kontrollierbarer. Für Datenschutz und Datenresidenz ist diese Unterscheidung oft relevant. Für eine der zentralen Schwachstellen von Agenten reicht sie nicht aus. Indirect Prompt Injection entsteht nicht in erster Linie durch den Standort des Modells. Sie entsteht, wenn ein KI-System vertrauenswürdige Anweisungen und fremde Inhalte im selben Kontext verarbeitet.
Ein neuer Research-Beitrag von Brave vom 8. Juni 2026 zeigt das an zwei sehr unterschiedlichen Beispielen: Mozilla Tabstack, einer cloudbasierten Web-Ausführungsumgebung für Agenten, und Cotypist, einem lokal laufenden Autocomplete-Assistenten für macOS. Die Fälle sind nicht deshalb wichtig, weil jedes Unternehmen genau diese Produkte nutzt. Entscheidend ist das Muster dahinter: Sobald ein Agent Webseiten, Dokumente, Tool-Ausgaben oder lokale Dateien liest und daraus Aktionen oder Vorschläge ableitet, kann Inhalt zur Steuerungsfläche werden.
Technische Details: Die Grenze zwischen Daten und Befehlen bricht auf
Indirect Prompt Injection unterscheidet sich von der direkten Manipulation eines Chatfensters. Der Angreifer gibt dem Modell keine Anweisung über das normale Prompt-Interface. Stattdessen versteckt er die Anweisung in einem Inhalt, den das System später legitim verarbeitet: in einer Webseite, einem Dokument, einem Ticket, einer E-Mail, einem Repository, einem Tool-Resultat oder einer lokalen Datei. Für Menschen kann diese Anweisung unsichtbar bleiben — etwa durch weiße Schrift auf weißem Hintergrund, versteckte HTML-Elemente oder andere nicht offensichtliche Textebenen. Für den Agenten ist sie trotzdem Teil des Inputs.
Das Grundproblem liegt in der Architektur. Ein LLM verarbeitet Systemanweisungen, Nutzervorgaben und fremde Inhalte häufig als gemeinsamen natürlichen Sprachkontext. Das Modell kann semantisch lesen. Es besitzt aber keine harte Sicherheitsgrenze zwischen „das ist ein Befehl des Betreibers“ und „das ist nur untrusted Content“. Genau diese Vermischung beschreibt Brave als gemeinsamen Nenner der beiden Fälle.
Im Tabstack-Beispiel ließ Brave einen Agenten eine Webseite zusammenfassen. Auf der kontrollierten Zielseite waren versteckte Instruktionen platziert. Der Agent blieb nicht bei der ursprünglichen Aufgabe. Er öffnete ein Formular, übertrug Konversationshistorie und sendete sie ab. Der konkrete Payload ist dabei weniger wichtig als die Wirkungskette: Ein eigentlich passiver Lesevorgang wurde zu einer nicht autorisierten Web-Aktion mit Datenabfluss.
Beim Cotypist-Beispiel war die Architektur anders. Das Modell lief lokal und diente als systemweiter Autocomplete-Assistent. Auch hier konnten in einem lokalen Dokument eingebettete Anweisungen die Modellvorschläge beeinflussen. Brave beschreibt unter anderem das Risiko, dass falsche Inhalte vorgeschlagen oder Zugangsdaten als Vorschlag sichtbar werden. Der Blast Radius ist kleiner als bei einem autonomen Browser-Agenten, weil ein Nutzer die Vervollständigung noch aktiv per Tastendruck übernehmen muss. Trotzdem zeigt der Fall: Lokale Ausführung beseitigt den Angriffsvektor nicht, wenn der Assistent untrusted Content in seinen Kontext übernimmt.
Faktenlage und Quellen
Brave veröffentlichte den Research-Beitrag am 8. Juni 2026 und nennt eine Responsible-Disclosure-Timeline. Tabstack sei am 13. Mai gemeldet worden. Mozilla habe die Schwachstelle am 14. Mai bestätigt, am 1. Juni eine Behebung bestätigt, und Brave habe diese unabhängig verifiziert. Cotypist sei am 1. Juni gemeldet worden; das Team habe das Problem am 2. Juni bestätigt.
Als unabhängiger Kontext ist OWASP relevant. In den OWASP Top 10 for Large Language Model Applications steht Prompt Injection weiterhin an prominenter Stelle. OWASP unterscheidet direkte und indirekte Varianten und betont, dass manipulierte externe Inhalte das Verhalten von LLM-Anwendungen beeinflussen können. OWASP bestätigt damit nicht die konkreten Brave-Fälle. Die Organisation ordnet die Risikoklasse aber als grundlegendes, branchenweit relevantes Problem ein.
Quellen: Brave Research, „Indirect Prompt Injection remains a fundamental security challenge for AI“, 8. Juni 2026; OWASP Top 10 for Large Language Model Applications, LLM01 Prompt Injection; öffentlich erreichbare Produktseite von Cotypist zur Einordnung als macOS-Autocomplete-Werkzeug.
Branchenkontext: Agenten werden zu Arbeitsoberflächen
Der Zeitpunkt ist wichtig, weil KI-Agenten zunehmend in produktive Workflows rücken. Browser-Agenten lesen Webseiten, füllen Formulare, recherchieren in SaaS-Anwendungen und arbeiten in authentifizierten Sessions. Coding-Agenten durchsuchen Repositories, Issues und Dokumentation. Office-Assistenten verarbeiten E-Mails, PDFs und interne Wissensdatenbanken. Lokale Assistenten beobachten Eingabekontext oder schlagen Text in Anwendungen vor.
Damit wandert die Angriffsfläche aus dem klassischen Promptfenster in die Inhalte selbst. Eine manipulierte Webseite kann für einen Browser-Agenten zur Handlungsanweisung werden. Ein präpariertes Ticket kann einen Support-Agenten zu falschen API-Aufrufen verleiten. Ein README kann einen Coding-Agenten zu riskanten Installations- oder Exfiltrationsschritten bringen. Ein lokales Dokument kann die Vorschläge eines Autocomplete-Systems beeinflussen. Das Sicherheitsproblem lautet daher nicht „Cloud gegen lokal“, sondern: untrusted Content trifft auf handlungsfähige Modelle.
Für Unternehmen ist das unbequem, weil viele bestehende Kontrollen an anderen Stellen ansetzen. DLP prüft Datei-Uploads oder ausgehende Datenströme, aber nicht zwingend die semantische Vermischung von Inhalt und Instruktion. IAM regelt, wer Zugriff hat. Es verhindert aber nicht automatisch, dass ein Agent eine Anweisung aus einer Webseite fälschlich als Auftrag interpretiert.
Konkrete Implikationen für Unternehmen
Erstens sollten Unternehmen Agentenrechte konsequent nach Wirkung begrenzen. Ein Agent, der Webseiten zusammenfasst, braucht nicht automatisch Formular-Submission, Datei-Upload, Zugriff auf vollständige Chat-Historien oder freie Navigation in authentifizierten Anwendungen. Tool-Rechte müssen feiner geschnitten werden als klassische Nutzerrechte.
Zweitens braucht jeder Agent eine klare Trennung zwischen Lesen, Denken und Handeln. Das Lesen untrusted Contents darf nicht direkt zu irreversiblen Aktionen führen. Kritische Schritte wie Senden, Löschen, Kaufen, Deployen, Rechteändern oder Datenexport sollten explizite, kontextreiche Freigaben erfordern. Diese Freigaben müssen zeigen, welche Quelle die Aktion ausgelöst hat und welche Daten betroffen sind.
Drittens sollten Teams Inhalte nach Herkunft kennzeichnen. Tool-Ausgaben, Webseiten, Dokumente und Nutzeranweisungen sollten intern unterschiedliche Vertrauensklassen tragen. Das löst das LLM-Grundproblem nicht vollständig. Es schafft aber eine Grundlage für Policy-Checks: Ein Befehl aus einer untrusted Webseite darf nicht dieselbe Wirkung haben wie eine Administrationsanweisung.
Viertens gehören lokale KI-Werkzeuge in das Sicherheitsmodell. „On-device“ reduziert bestimmte Datenschutzrisiken. Es ersetzt aber keine Inhalts- und Rechtekontrollen. Lokale Autocomplete-, Coding- oder Recherche-Assistenten können sensible Vorschläge erzeugen, Secrets sichtbar machen oder Nutzer zu falschen Handlungen verleiten. Unternehmen sollten auch lokale Modelle inventarisieren, konfigurieren und testen.
Fünftens sollte Prompt-Injection-Testing Teil der Abnahme von Agenten-Workflows werden. Red Teams müssen nicht nur direkte Prompts testen, sondern präparierte Webseiten, PDFs, Tickets, E-Mails, Repositories und Tool-Antworten. Besonders wichtig sind Tests in authentifizierten Sessions. Dort wird aus einer Modellfehlentscheidung schnell ein realer Geschäftsprozess.
Risiken und Limitierungen
Die Brave-Beispiele sind kontrollierte Demonstrationen. Sie belegen nicht, dass jedes lokale oder cloudbasierte KI-Werkzeug in gleicher Weise ausnutzbar ist. Die konkrete Wirkung hängt von Modell, Tool-Rechten, UI, Bestätigungslogik, Datenzugriff und Logging ab. Cotypist hat etwa einen kleineren Wirkungskreis als ein autonomer Browser-Agent, weil ein Mensch Vorschläge aktiv übernehmen muss.
Umgekehrt wäre es falsch, das Problem als erledigt zu betrachten, sobald ein Hersteller einen Einzelfall behebt. Brave beschreibt den Kern treffend als Kontext-Kompositionsproblem. Solange ein System vertrauenswürdige Anweisungen und untrusted Content in einem gemeinsamen Sprachraum verarbeitet, bleibt ein Restrisiko. Bessere Prompts, Alignment-Checks oder Filter helfen. Eine harte Sicherheitsgrenze sind sie nicht.
Fazit
Indirect Prompt Injection ist kein Spezialproblem einzelner Browser-Agenten und kein reines Cloud-Risiko. Der aktuelle Brave-Research zeigt, dass sowohl cloudbasierte Agenten als auch lokale KI-Assistenten betroffen sein können, wenn sie fremde Inhalte in denselben Kontext wie ihre Handlungslogik übernehmen.
Für Unternehmen ergibt sich daraus eine nüchterne Architekturaufgabe: Agenten brauchen minimale Rechte, klare Tool-Grenzen, Herkunftskennzeichnung, explizite Freigaben für riskante Aktionen, Monitoring und Tests mit realistisch manipulierten Inhalten. Lokale Ausführung ist ein Baustein für Datenschutz, aber kein Ersatz für Agenten-Sicherheit. Die entscheidende Frage lautet nicht, wo das Modell läuft. Sie lautet, was es lesen darf, welche Schlüsse daraus Aktionen auslösen dürfen und welche Sicherheitsgrenze zwischen untrusted Content und produktiver Wirkung steht.
